The goal of every program manager is to have a set of practices that connect all the programmatic planning, risk, and performance information in a single unified view needed to support the decisions that increase the probability of success of any project or program.
If we look to other paradigms, successfully unifying information doesn't start with a reductionist approach. Putting all the pieces and parts together into a higher level set of principles leads to a confusing set of information. This is like building a tree by gathering sticks and rubber banding them together. In the same way, when we build a unified set of principles, practices, and processes, and the information they depend on for successful program management by connecting unrelated pieces and parts a confusing and disjointed view of the program is the result. This disjointed approach can’t provide the information needed to make informed decisions.
Reductionism must be replaced by emergence where the complex system of data and processes and the sum of the pieces and parts provides a deeper insight into the functions of the system. We need to search for an approach that integrates the parts into this larger whole. Currently, there is no single frame of reference to view the discipline, because it is multi-disciplinary. Because each discipline tends to operate within its own stovepipe.
There are cost people, scheduling people, risk people, EVM people, engineers, testers, and others on any program. Each has its own set of tools, questions, and viewpoints. Integrating any two frameworks is challenging. Cost and Schedule are not easy to integrate. Cost is a linear summation of the work breakdown structure. SThe schedule is non-linear from its network topology and naturally occurring variances (Aleatory uncertainty) and probabilistic events Epistemic uncertainty) based risks. Cost is measured in dollars and schedule is measured in time. Technical performance is likewise difficult to integrate with either cost or schedule because its units of measure vary with the subject matter.
The two disciplines — Earned Value Management (EVM) and Systems Engineering (SE) — are in the best position to integrate the stovepipes of program management. That these disciplines and their respective frameworks ought to be integrated is not lost on most publications and guidance. These publications tell us what ought to be done and why we ought to do it, but rarely if ever describe how to do it.
One way to crack open the door of SE and EVM integration is to introduce yet another framework, that of the integrated master plan and integrated master schedule combination, or IMP/IMS. The IMP/IMS framework is one of program maturity, and employing it allows us to get closer to integrating SE and EVM.
The IMP is an event-driven plan that provides an overarching framework against which all work is accomplished within a program. It documents the progression of work required to reach program maturity in terms of outcomes. The IMS translates these outcomes into a time-phased dynamic model of the program’s evolving maturity. In other words, the IMP/IMS answers the question of “done” in a program. “How do we know we are done” is a critical question. Knowing “done” helps us determine answers to hard-to-tap-dance-around questions that include, but are not limited to:
- What does done look like for today, this week, this month, for the next release?
- What does done look like for entry/exit into the technical review?
- What does done look like for quality control?
- What does done look like for the customer?
- How do you know all this?
- How does the reporting reflect the “done-ness” you just described to me?
- When will we be done?
While these questions may seem obvious, less obvious is the mindset shift required to determine answers to these questions during the program's execution. The shift lay in the determination of physical percent complete. Determination of physical percent complete is rooted in performance measurement, the comparison of actual performance against an integrated baseline plan consisting of integrated cost, schedule, and technical goals. Such measurement is possible within a performance measurement system which refers to an organization’s internal management control system that provides decision-makers with specific performance information regarding progress and expenditures against a stated execution plan.
Earned Value Management (EVM) often anchors such a performance measurement system in DoD programs. Yet in many projects where EVM systems are implemented, what a control account manager (CAM) determines as physical percent complete often differs from what is reported through the EVM techniques. This is different than what disciplined measurement of physical percent complete would report using tangible evidentiary materials, like Technical Performance Measures, Measures of Effectiveness, Measures of Performance, and Key Performance Parameters. This disconnect in the measurement of done-ness is a sign that a cost, schedule and/or technical performance problem is going to materialize before the PM can properly take corrective or preventive actions.
Building an IMP/IMS offers opportunities for the direct integration of SE with EVM. The first, best opportunity, like most opportunities in program management, begins with requirements. Requirements are not simply an engineering thing; they impact every program management discipline. The EVM planning process ought to pick up on the same requirements as the SE process, and both be in collaboration on the program work breakdown structure. From this point forward, all activities ought to reference the WBS because the WBS is the single cross-disciplinary “communication tool” in the program. For all intents and purposes, the WBS is the program.
Having determined what the work is, the next step is to determine the who. This is done through the development of the organizational breakdown structure, or OBS. Taken together, the WBS and OBS for the responsibility assignment matrix, or RAM, that is used to show the management control points in the program, known as control accounts. Each control account is assigned a budget and then, in a traditional EVM sense, the process begins of building the performance measurement baseline.
Given the RAM, the IMP/IMS development activity branches off from the traditional EVM process and creates program events or Program Event. There are no surprises here in that PEs include major ticket items such as integrated baseline reviews, system requirements reviews, preliminary design reviews, test readiness reviews and the like. Rather than viewing these traditionally as “milestones,” the IMP/IMS development considers them key points in the program where progress can be measured. Each program event is associated with two or more significant accomplishments or SAs. An SA should describe the conditions necessary for successful completion of a program event. In other words, SAs are essentially entry criteria that reflect both functionally-related and product-related activities. In similar fashion, accomplishment criteria (AC) describe the conditions necessary for successful completion of each SA. Much of this can be extracted from a well-written systems engineering plan (SEP). Going further, each AC is associated with two or more work packages representing the actual work needed to meet the AC, with each work package comprised of activities required to produce the tangible results required. This sequence of events makes for a hierarchical structure that looks like the following:
Program Event (IMP)
- Significant Accomplishment (SA) X (IMP)
- Accomplishment Criteria (AC) X1 (IMP)
- Work package X11 (IMS)
- Activity X111 (Supplemental schedule)
- Activity X112 (Supplemental schedule)
- Work package X12 (IMS)
- Activity X121 (Supplemental schedule)
- Activity X122 (Supplemental schedule)
- Work package X11 (IMS)
- Accomplishment Criteria (AC) X1 (IMP)
This approach impacts IMS development. It forces a top-down approach to the development of the IMS, first in the vertical, and then in the horizontal. The vertical refers to the linkage from the program event all the way down to any given work package (and activity) and is accomplished first in order to ensure a focus on event-based program maturity outcomes. Then the development goes horizontally to reflect interdependencies between activities. Only then are days added to the activities to derive results in time. This ensures that the IMS is a truly dynamic model of program maturity; it also eliminates “level of effort” and other “management-type” work from the IMS. All IMS work packages and activities reflect discrete work that impact program maturity, each line item associated with tangible outcomes.
For example, a PE might be a Preliminary Design Review (PDR). Each entry criterion for PDR corresponds with an SA. We would expect to have multiple SA’s, one of which might be “allocation of system requirements to elements completed.” This SA will have multiple ACs such as “allocation of system requirements to element x completed,” “allocation of system requirements to element y completed.". We can begin to discern work packages to associate with each AC.
In this example, element x might consist of several subsystems, each needing to complete direct and derived requirements (in the form of a specification) for the element to be “complete.” Writing specifications can be resourced and associated directly with the control accounts in the WBS. The system engineering work that contributes to program maturity can now be directly associated with EVM artifacts. Work packages feed directly into the IMS, making the IMS a dynamic model of program maturity.
It is at the work package and activity level where integration of EVM and SE takes place, with each work package is associated with a control account on the performance measurement baseline. Here the detailed evidence of “done” is gathered through discrete, measurable events and/or deliverables, to include direct integration of technical performance measures or TPMs. TPMs compare actual versus planned progress in technical design and development and in the IMP/IMS framework serve very well as closure criteria for work packages and especially activities.
For example, as part of the PDR-related accomplishment criteria for subsystem X, we find that the both the allocated requirements and the preliminary design need to be completed. Each, therefore, warrants a separate work package, the completion of each constitutes satisfaction of the accomplishment criteria relative to this subsystem. We first assign these work packages to the WBS element where this subsystem resides, and then develop the associated activities. Verification of allocated requirement completion can consist of an actual tangible artifact, a requirement specification (or portion thereof). Similarly, a design document can be produced to verify the preliminary design but we also could require that the associated TPM is within expected tolerance bands and verified by the appropriate means. Thus, the work package for preliminary design cannot be “closed” (closure conditions satisfied) until the document and the TPM conditions are met.
The IMP/IMS framework views program progress through the lens of maturity, and by doing so it asks questions that require maturity-related answers. This is very much aligned with the systems engineering process. This framework “intersects” with the traditional product/work oriented EVM framework at the work package level. As such it informs the EVM system implementation of maturity-related completion criteria. The immediate impact is a more robust performance measurement baseline. In the bigger picture, the end result is the integration of systems engineering with earned value management. The linkage of these two disciplines ensures that maturity, or physical percent complete, is universally communicated within the context of the program. Together they ensure a disciplined focus on the end product, its enabling products, and associated interim maturity outcomes.
System Engineering and Earned Value Management, are independent frameworks that produce better results when combined. The grand unified theory of program management remains elusive, but SE and EVM provide the necessary power for a program to develop a robust performance measurement baseline and a performance measurement system capable of supporting informed decisions.
Here's a training briefing for this topic that has been applied in many domains, from defense, space, enterprise IT
