In the Systems Engineering paradigm a project is a temporary creation brought into being to implement specific goals. At the end the team goes back to the businesses that spawned the project. The control mechanism for a Systems Engineering based project is the Project Management Plan. This plan documents the deliverables, schedule, tasks, responsibilities, applicable standards, cost estimates and resources.
A typical table of contents for the PM Plan is:
- Configuration Item Structure - what items are to be developed or integrated
- Schedule - when they are delivered
- Organizational Breakdown Structure - who will produce them
- Work Breakdown Structure - what work is needed to make, manage and test them
- Cost Breakdown Structure - How much will they cost
- Process standards - What standards apply to the work
- Process choice - What life cycle will the development follow
This is a very simplified PM Plan when compared to a real one, but the basic structure is there.
Project management is core the success of any systems engineering effort, possibly more important than the technical issues. Poor management can ruin a good engineering effort. Project management is meaningless unless it is tightly couple to systems engineering. They are inseparable.
There are some common failure threads across projects identified in the systems engineering paradigm:
- Inadequate understanding of the requirements
- Lack of systems engineering, discipline and authority
- Lack of technical planning and oversight
- Stovepipe developments with late integration
- Lack of subject matter expertise at the integration level
- Availability of systems integration facilities
- Incomplete, obsolete, or inflexible architectures
- Low visibility of software risk
- Technology maturity over estimates
Project management and its planning discipline can directly address 1, 3, and 8 through the IMP/IMS development. The other areas need to have risk mitigation tasks shown in the IMS.
