Systems Engineering Management and Project Management

Whether you realize it or not, as a project manager you have been performing some of the functions of a systems engineer—trade-off analysis, systems design, and data management, for example. The question is not so much whether we do systems engineering, but rather, how can we do it deliberately and effectively? The fact that we do some systems engineering intuitively is good, but it is not nearly enough to ensure an optimized solution and a successful project. To be able to more effectively plan and integrate the various components of an IT project, we first need to understand why there is even a need for systems engineering. Then, we must understand how the systems engineering function fits into the overall project management environment.

Why Systems Engineering Management?

Systems engineering management techniques actually rose to prominence during Secretary of Defense Robert McNamara's tenure, to be exact. The problem the DOD had was that programs were becoming more complex and, probably more importantly during that period, more costly. Consequently, the DOD, with Secretary McNamara driving the initiative, began aggressively requiring a formalized approach to defining and defending programs of interest to the different service branches. The initial intent of this effort was to force the services to first accurately define their programs, and second, provide review points that offered possibilities for real go/no-go decisions. The results of formalizing this procedure were that the services complied with the original intent of completely defining their requirements, and the procedure created a whole new way of defining, describing, and managing projects—systems engineering management. Exhibit 8-5 is a depiction of the systems engineering process. For the typical practicing project manager and organization, the problem since then has been: How do you integrate the system's process into the project management environment, and vice versa? Perhaps a better understanding of the philosophy of systems engineering is needed to set the baseline, or point of departure, for discussing how these two disciplines interrelate.

Exhibit 8-5: The systems engineering process.

The Systems Engineering Philosophy

Basically, systems engineering can be described through an understanding of ten propositions (premises) of the systems engineering philosophy, or the systems approach to defining a project's deliverables.

1. Separation of Problem and Solution. Traditionally, engineers are incorrigible optimists. In order to generate the enthusiasm needed for tackling seemingly insoluble problems, they have to be. But, at times, this very enthusiasm leads to solutions after only a superficial study of the problem. The purpose of a system's approach to a problem is to first completely define the problem and then, and only then, select a suitable solution after exploring a number of alternative solution approaches. The primary purpose of systems engineering management is to make it possible to organize and relate system data so that various combinations and permutations of options can be investigated and weighed. The outcome of this process is, hopefully, an optimized solution that provides the best and the most one can get, functionally, for one's dollar at a particular point in time. In optimization, there is a natural tendency to guard against force-fitting a preconceived solution to a problem, based on the strength of a past success with a similar solution. Preconceived solutions stand the risk of becoming either weak solutions or overkill solutions that reduce system effectiveness and/or boost costs.

2. Defining Systems Definition. The system definition process should unfold in progressively expanding stages downward, like a pyramid, and not like a uniform cube. Initially, a system is defined in a gross sense; as definition progresses in successively expanding stages, so does the level of understanding and confidence in end-item components and assemblies that make up the total system. Detail definition that is done too soon can lead to the optimization of too many choices on too many levels. This would tend to produce a mass of data, which might constrain management's vision, confuse, and waste effort, not to mention money.

3. Responsiveness to Customer's Management Requirements, Not to Procedures. A provider's internal management practices must be responsive to the customer's requirements, based on the negotiated and tailored approach to fitting or mapping the provider's resources to the customer's requirements. In other words, the procedures in place in the provider's organization have to be flexible enough to accommodate the customer's requirements. Likewise, the customer and the provider have to ensure that the provider's resources sufficiently map to the project requirements, so that the project will be a success, both for the customer and the provider.

4. Top-Down Approach to Driving Out Packaging of Functional Requirements. Top-down analysis and packaging of functional requirements, from a total systems perspective down to the lowest component, are practiced by systems engineers to completely define the end products needed to fulfill system requirements. Such an approach ensures attention to detail in progressively expanding stages so that every requirement is accurately identified, accounted for, and mapped to a functional block in the design architecture.

5. Cost-Schedule-Performance Relationship. The necessity of controlling the tendency of system costs to grow means that a tight relationship between cost, delivery schedule, and the performance expectations is essential when making realistic trade-offs at every stage of the system design and evaluation.

6. Constraining a Profusion of Data. Because the flow of data to stakeholders must be controlled so that the information does not constrain visibility of actual progress—or problems, as the case may be—a tailored process may be required for each individual project. In approaching this problem, it is important to remember that for major levels of decision making, management needs mostly distilled data, but data distilled from conclusive study results and traceable to the customer's system specifications, i.e., requirements. Thus, only a specifically designed documentation process tailored for the purpose can be traced this way.

7. Importance of Baseline Control. After establishment of the baseline, any changes made must fall within the existing defined and agreed scope. This is a gray area between the systems management and project management responsibilities. The systems engineering process is actually the basis for defining the technical baseline of the project, but the project manager's hat requires that the baseline is not violated. Hence, this process is twofold—evaluating changes to the baseline (the function of the systems engineering management process) and evaluating and determining whether the change request is outside the scope (the function of the project management process).

8. Identification of Respective Responsibilities. The systems process gets into contractual issues in many ways. One primary responsibility of the systems engineering management function is to positively identify and separate the contractual responsibilities of various contributing entities. Simply stated, this means that if more than one contractor (or vendor) works on a project, the systems engineering process must delineate the responsibility boundaries between the various contributing organizations and the customer. In other words, the responsibilities have to correlate directly with any contract structure, and it is the systems process that identifies this relationship and tracks it.

9. Understanding Systems Requirements. The most effective way a contractor or internal provider can prove he understands the customer's system requirements is by making certain that any provided technical data is clearly traceable and responsive to the system requirements. This is one of the fundamental results of a systems engineering process.

10. Selling System Proposals. In the earliest stages of a project, one of the first things a provider has to do, or should do, is prepare a proposal—some documentation about how the project will be run and what the technical solutions will be. Hence, it is imperative that a thoroughly reasoned and traceably documented system proposal is prepared for appraisal by several tiers of decision-making hierarchy. And, since these different tiers of decision makers possess varying degrees of technical understanding, the proposal package must contain clear, self-supporting data. The systems process can analyze the system and identify the components, but the challenge is in being able to describe each of these components and the proposed solution in understandable terms.

These are the basic tenets of the systems engineering management philosophy. To be sure, this list is not exhaustive, but to add many more tenets would invite our getting into far more detail than is necessary to make two very important points. First, systems engineering is important to defining and carrying out a project charter, and second, systems engineering and project management are interrelated. They are sister disciplines and competencies. If they are so closely related, how then do they mesh together?

The Relationship of Systems Engineering and Project Management

Systems engineering and project management are separate but closely related functions. In very complex projects it is best to employ a systems engineer, that is, one whose specialty is systems engineering, to perform this function. However, in most typical, even relatively complex projects, it is not uncommon for the project manager and his team to perform the systems engineering function. However it is done, the important point to remember is that to accurately define, implement, and track a project, especially a multifaceted one, it is absolutely crucial that the project manager think in terms of the systems approach.

How these two functions interrelate is actually not so easy to understand because so much of the one function is identical to or overlaps with the other. However, a look at Exhibit 8-6 may explain the relationship, or interrelationship, of the two.

Exhibit 8-6: Relationship between project management and systems engineering management.

There are several noteworthy aspects of the graphic in Exhibit 8-6. First, notice that I have redrawn Exhibit 8-5, the systems process, so that the systems engineering functions fall logically within the project management activities of a typical four-phased project life cycle. Obviously, there are many internal steps and processes at work within each of these boxes, but I have simplified the graphic to clearly show how the project and systems engineering disciplines work together.

The second thing this graphic should portray is that project management is the overarching discipline throughout the systems engineering life cycle (it might be helpful at this point to refer back to Exhibit 3-2, as well). In other words, systems engineering is the hub of project management, but its use is a means for designing, building, and managing the product. Project management is the means for managing the project, which includes managing the product activities, as well as all other project activities.

The third thing I would draw your attention to is that the system consists of hardware and software, plus other components. The other components include services, human engineering (designing the system for optimal use), training, logistics, and all the myriad bits and pieces that make up the IT system.

One final thing to notice in this graphic is how much effort is required before the system actually gets built. On average, one half of a project budget is spent by the end of the second phase, or before a system is actually at a point to be constructed, tested, and shipped.

Systems engineering activities are, for the most part, activities that are not unfamiliar to us, but few organizations train their project managers or team members in how and why its techniques and disciplines should be applied. A focused, well-trained cadre of project managers and systems people will guarantee a greater project success history.