Performance-Based Project Management? with Deliverables-Based Planning
Glen Alleman MSSM
Applying Systems Engineering Principles, Processes & Practices to Increase Probability of Program Success for Complex System of Systems, in Aerospace & Defense, Enterprise IT, and Process and Safety Industries
Even the most experienced project managers aren’t immune to the common and destructive reasons for project collapses. Poor time and budget performance, failure to deal with complexity, uncontrolled changes in scope . . . they can catch anyone off guard. Performance-Based Project Management? can improve your project’s success rate, despite the obstacles that will try to take it down.
This approach can increase the probability of project success, detailing a step-by-step plan for avoiding surprises, forecasting performance, identifying risk, and taking corrective action to keep a project successful. Project leaders wishing to stand out among their peers who are continually hampered by these unexpected failures can:
The Foundation of Project Success
Increasing the Maturity of Project Deliverables
Deliverables?Based Planning integrates five critical program management process areas with – Cost, Schedule, and Technical Performance Measures. The inclusion of Technical Performance Measures (TPM) separates our approach from conventional methods based solely on managing cost and schedule. In conventional approaches, the cost and schedule baseline and their variances generate the data for Earned Value variables used to make programmatic decisions.
In Deliverables?Based Planning, Earned Value measures are integrated with measures of Physical Percent Complete (PPC) derived from Technical Performance Measures (TPM) at planned assessment points in the Integrated Master Schedule (IMS).
The Events and Milestones defined in the Integrated Master Plan (IMP) describe the planned technical or operational maturity of the products or services measured against their actual technical performance.
The Earned Value measurements are used with Technical Performance measures for each deliverable to produce a credible measure of progress and a credible forecast of future performance using the To Complete Performance Index (TCPI). The result is increased visibility and credibility of the Independent Estimate at Completion (IEAC).
As the program progresses, technical and programmatic risks are identified, their mitigation or retirement is planned and executed, and adjustments to the program are made to ensure planned progress is maintained.
Successfully executing a program requires a Program Planning and Controls discipline that identifies what “Done” looks like, measures progress toward “Done,” identifies the risks and impediments to reaching “Done,” and assures timely corrective action to maintain progress toward “Done.”
“Done” is always defined in units of measure meaningful to the customer. The best tangible evidence is the Deliverables needed to meet the requirements that fulfill the system’s requested capabilities that are recognized as a success for the program.
Using this approach, Deliverables fulfill the requirements that meet the system or business performance criteria, produced at the planned time, using the planned budget. This performance is measured as Physical Percent Complete and is the only Credible measurement of progress.?With the planned requirements fulfilled, the system or operational capabilities become available to the customer at the planned time.
Deliverables?Based Planning provides actionable information in units of measure meaningful to the decision maker to increase the Probability of Program Success.
Increasing the Maturity of Project Deliverables
The integration of these five process areas is the foundation of Deliverables?Based Planning.
Each process area stands alone and, at the same time, is coupled with the other process areas. Each process area contains specific process steps for producing beneficial outcomes for the project while establishing the basis for overall project success.
Each process can be developed to the level needed for specific projects. All five process areas are critical to the success of any project.
If a process area is missing or poorly developed, the capability to manage the project will be jeopardized, possibly in way not known until the project is too far along to be recovered.
Each process provides information needed to make decisions about the flow of the project. This actionable information is the feedback mechanism needed to keep a project under control. These control processes are not impediments to the progress of the tools needed to increase the probability of success.
Every systematic development of any subject ought to begin with a definition, so that everyone may understand what the discussion is about. — Marcus Tullius Cicero (196BC ? 16BC), De Officiis, Book 1, Moral Goodness
Identifying Needed System Capabilities
Identifying System Capabilities is the starting point for any successful program. Systems Capabilities are not direct requirements but statements of what the system should provide in terms of “abilities.” For example, there are three capabilities stated by the NASA Program Manager needed for the Hubble Robotic Servicing Mission (which I worked on the proposal for):
How is this to be done, and what are the technical, operational, safety, and mission assurance requirements? Don’t really know yet, but the Capabilities guide their development.
The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question, “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?”
The Capabilities statement can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer.
The “meaningful to the customer” unit of measures is critical to the success of any program. Without these measures, the program may be cost, scheduled, and technically successful but fail to fulfill the mission.
The process flow above is the starting point for Identifying the Needed Capabilities and determining their priorities.
Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of all needed requirements that are missing a well-formed topology. This Requirements Architecture is no different from the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities fulfilled by the program.
In order to fulfill these capabilities, requirements need to be met. But we need the capabilities first. Without these capabilities, it is never clear that the mission will be a success because there is no clear and concise description of what success means.
The concept of CBP recognizes the interdependence of systems, strategy organization, and support in delivering the capability and the need to examine options and trade-offs in terms of performance, cost, and risk to identify optimum development investments. CBP relies on scenarios to provide the context to measure the level of capability.
There are only two phases to a big program:
Too early to tell and too late to stop!
领英推荐
? Mr. Blaise Durante, Deputy Assistant Secretary (Acquisition Integration), U. S. Air Force
Identifying Requirements
?Requirements are the necessary attributes defined for an item before the efforts to develop a design for the item. System requirements analysis is a structured or organized methodology for identifying an appropriate set of resources to satisfy a system need (the needed capabilities) and the requirements for those resources that provide a sound basis for designing or selecting those resources.
It acts as the transformation between the customer’s system needs and the design concept implemented by the organization’s engineering resources.
The requirements process decomposes a statement of the customer’s need through a systematic exposition of what that system must do to satisfy that need. This need is the ultimate system requirement into which all other requirements and designs flow.
There are two fundamental classes of requirements.
The Process Performance Requirements define how the work processes produce a beneficial outcome for the customer.
The Product Performance Requirements define the product specifications and how they are related to the process requirements.?
As well as the product and process requirements, there are functional and non?functional requirements.
These non?functional requirements play a significant role in the development of the system. Non?functional requirements are spread across the entire system or within individual services and cannot be allocated to one specific software artifact (e.g., class, package, component).
This makes them more difficult to handle than functional requirements. The specifics of the system’s architecture, such as highly distributed services, bring up additional difficulties.
The distinction between process and product requirements lays the foundation for the Work Breakdown Structure. The WBS, the Related Integrated Master Plan (IMP), and Integrated Master Schedule (IMS) , also focus on this separation.
The success of the project or program depends on defining both the product and the processes that support or implement the product.
When properly connected, the Requirements Taxonomy, the Work Breakdown Structure, the Integrated Master Plan (IMP), and the Integrated Master Schedule (IMS) “foot and tied” to the Performance Measurement Baseline (PMB) provides the traceability of the increasing maturity of the deliverables (vertical) and the physical percent complete of the work efforts (horizontal).
Establishing the Three Elements of the Performance Measurement Baseline
The Performance Measurement Baseline (PMB) is the primary assessment document for assuring the credibility of a program plan. The PMB is the baseline of the cost, schedule, and deliverables for each Work Package in the plan.
Constructing the PMB requires knowledge of the business requirements, skill in developing the Work Packages that produce the deliverables for these requirements, and discipline in assembling the cost, schedule, and relationships between the Work Packages. It is the discipline that requires the most focus from the planners and program controls staff. Without this discipline, the development of a credible baseline is simply not possible.
In the end, the planners and program control staff must “know” in intimate detail each Work Package, its deliverables and resource requirements, the performance measurement criteria, and the dependencies that form the critical path through the program schedule.
The concept of a Deliverables?Based Plan (DBP) is at the core of the Performance Measurement Baseline (PMB).
The Technical Performance Baseline is the requirements flow down and traceability map for each deliverable in the program.
The Schedule Performance Baseline is the sequence of Work Packages and Planning Packages that produce the products or services from the program. This baseline contains the schedule margin derived from the Monte Carlo simulation described in DID 81650.
The Cost Performance Baseline is the “authorized time-phased budget?at?completion (BAC) used to measure, monitor, and control overall cost performance on the program.” This budget ( PV) is held in the Control Accounts, the Work Packages, and the Planning Packages owned by the Control Account Manager.
Executing the Performance Measurement Baseline (PMB)
With the Performance Measurement Baseline established, its execution becomes critically important.
The execution process is called the “program rhythm.” this means the processes are repeated – at least every month and many times every week. This business rhythm must create actionable information for the program manager on a time scale that allows actions to be taken. For Government programs, this time scale is at a minimum once a month – the Contract Performance Report – in the form of DI?MGMT?81466A.
A larger question must be answered, however. How long is the Program Manager willing to wait before she discovers she is late? Waiting one month seems risky. Many programs have weekly status reviews which answer the question, “where are we in terms of progress to plan?”
In the Deliverables?Based Planning method, the “progress to plan” measure is provided by the tangible physical deliverables from the work efforts.?These tangible, physical deliverables must be defined in the work package created during the Deliverables?Based Planning Planning process. The measures of physical percent complete can be applied on weekly boundaries in a variety of ways:
In all cases, a measure of physical percent complete is mandatory if the program manager is to receive actionable information.
The necessary process here is to have an agreed measure of performance that is defined before the work starts. Keep these measures and the work efforts that produce “fine-grained” durations. Focus on answering the question How long are we willing to wait before we find out we’re late? The answer to this question must be short enough to take corrective action, so you are on time.
Perform Continuous Risk Management
Why Deliverables?Based Planning is different from traditional approaches to Program Management?
Why Deliverables?Based Planning is the same as traditional approaches to managing programs?