The aerospace and defense (A&D) project we work are different from IT projects for several reasons:
- Mission - there is usually a clear cut mission? Fly to Mars, build and fly some kind of machine, build some kind of software that flies or works on the ground processing data from flying machines. This "Concept of Operations" approach to defining the mission, along with the Statement of Objectives, the Mission Description and other "descriptions" of what done looks like are the shared communications between user and supplier.
- Firm Fixed Price Plus Fee (FFPPF) - many contracts today are semi-fixed price. The control of funds is a critical success factor. Incentives for performance is common. Technical Performance Measures along with Testable Requirements are the starting points for a conversation about "what are the units of measure of success?"
- Safety and Mission Assurance - with expensive machines comes expensive failures. At worst people die. At best they almost die. The concept that a separate, independent, informed observer that asks the question - "will this thing actually work when it's done?" is the starting point of Mission Assurance.
- Systems Engineering - the systems engineering paradigm is the basis of A&D projects. It starts with requirements allocation and ends with end-to-end integration testing. Along the way is interface management, trade studies and lots and lots of conversations about the behavior of the "system."
- Accountability to the end customer - the war fighter, astronaut, ship's captain, ... are all customers. The providers are accountable to the users.
So what's missing from the typical IT "train wreck" we see in enterprise development? Ask if any of the above are present in any form? They don't have to be full DoD compliant. Just some form, any form.
