1 Installing and Maintaining a System Engineering Culture Across Distributed Teams

Abstract

The natural behavior of most project teams is ad hoc. Ad hoc is fun for the participants in that the pain of planning, the embarrassment of accountability, the tedium of metrics, and the results of broken promises are avoided and instead, are replaced by a flurry of disjointed activity determined on the run by the individuals involved. In sharp contrast to ad hoc, System Engineering, along with its inseparable process mate Project Management, requires that the team deliver to difficult requirements, to an aggressive schedule, and with controlled funds, and does so by replacing ad hoc freedom with plans, process discipline, and “make a promise, keep a promise” behavior.The drive for efficiency demands that the processes used be integrated. However, the industry practice is to separate System Engineering (technical management) from Project Management, treating them as separate disciplines. This fact is confirmed by the separateness of the two corresponding professional organizations, INCOSE (International Council on System Engineering) and PMI (Project Management Institute). It is interesting to note that neither organization sponsors the other's conferences. It is also noteworthy that the System Engineering tools of INCOSE are distinctly different from the Project Management tools of PMI, even though the processes are co‐dependent.Most published system engineering or hardware/software development process models are non‐intuitive, inaccurate representations of what is actually required to manage technically challenging projects. When project teams attempt to follow them, they quickly discover that they are not realistic and provide little added value, and the team soon abandons them, reverting to the unstructured ad‐hoc approach. (Figure 1)System Engineering and Project Management reference books, handbooks, and Bodies of Knowledge typically present their subject matter as non‐connected specialty disciplines rather than by interrelated processes, and sub‐processes. (Figures 2&3) For instance, Requirements Management is usually absent or superficially addressed. Scheduling is usually treated separately from Network Development, ignoring the fact that schedules are derived from the network and both are part of Tactical Planning. Planning is shown as a discreet phase with a start and end, when in reality planning and replanning are continual, to adjust to the daily reality of the project events. Risk Management tutorials almost always ignore Opportunity Management, even though they are interdependent and the opportunity pursued must justify the risk assumed. Sections on Project Control typically deal with data gathering, plotting, and performance measurement (actually project status), none of which is Project Control. Contracting is treated separately from Configuration Management even though both are Control Techniques. Project Control of the technical baseline by using buyer/seller control gates is usually absent. These are just a sample of the blurred understandings that exist in System Engineering and Project Management.