CHAPTER 3
The Five Immutable Practices of Project Success
With the Five Immutable Principles in place, let’s put them to work by implementing the Five Immutable Practices. Each of the Five Practices, like the Five Principles, is needed for project success. There are no shortcuts to success, so no skipping any practice.
The foundation of the Performance-Based Project Management method is the integration of the Five Practices with the Five Principles. These activities must be performed by project managers and participants to increase the probability of project success.
In the end, we must always remember that project management is about making decisions in the presence of uncertainty. Managing in the presence of uncertainty starts with the steps, outcomes, and benefits described in Figure 3.1.
Implementing the
Five Immutable Practices
The Five Practices may seem obvious, but the obvious is not always found in the project domain. If it was, more projects would be successful. Figure 3.1 shows the Five Practices, their relationships to one another, and the top-level outcomes that are needed to increase the probability of any project’s success. Each practice creates outcomes used by the following practice. Each practice creates outcomes used as feedback to the others. The first four practices are supported by the fifth, Continuous Risk Management. Every action done in the first four must be assessed for explicit and latent risks to the success of the project.
As Figure 3.1 illustrates, the Five Practices needed to implement the Five Immutable Principles are:
1. Identify the needed capabilities. This is the first and most important practice—the discovery of what capabilities are needed for the success of the project. To achieve the project’s objectives or a particular end state, we need to define these capabilities. We do this through scenarios from the customer’s point of view, using the customer’s Measure of Effectiveness (MoE) in units meaningful to the decision maker. Effectiveness measures describe how well the results from the project enable a business process or fulfill a strategic mission of the business.
2. Identify the baseline requirements. Define both technical and operational requirements that will fulfill the needed capabilities; stipulate the planned time, the planned cost, and the planned technical performance of the resulting product or service. This means every requirement is traceable to work, all work is traceable to at least one requirement, and each requirement is traceable to each capability. The baseline requirements must be defined in terms isolated from any implementation, technical products, or processes. Only then can we bind the requirements with a technology. This means the managers of the project should wait as long as possible to determine the technical solution to the requirements. Only when the requirements have been defined and traced back to the needed capabilities should candidates for the technical solution be considered. If this decision is made too soon, the commitment to a specific technology may constrain alternative solutions. These requirements are assessed using their Measures of Performance (MoP) in fulfilling the Measures of Effectiveness to then provide value to the customers’ business or mission; in other words, we must determine whether the requirements we’ve established will actually meet the customers’ need.
FIGURE 3.1 The Five Immutable Practices identify desired outcomes and provide opportunities for feedback.
3. Develop the Performance Measurement Baseline (PMB). Once we have established the capabilities and requirements, we can determine the sequence of the work, the budget for this work, the outcomes from the work effort, the Measures of Performance, and the risk-reduction activities for each outcome that ensures progress is being made as planned. This PMB is our guide for managing the project. It is not cast in stone, but it is a map to “done.” And like all maps, it needs to be reevaluated along the way.
4. Execute the Performance Measurement Baseline. Take each element of work and perform it in the planned order, ensuring that all work is completed successfully before proceeding to the next element. During execution, we measure project performance through adherence to cost, schedule, and Technical Performance Measures (TPM),1 and their supporting Key Performance Parameters (KPP).2
5. Perform Continuous Risk Management. During each of the four preceding practices we’ll need to manage risk by identifying, analyzing, planning, tracking, controlling, and communicating each technical and programmatic risk, and then taking corrective actions to reduce risk and increase the probability of the project’s success.
A Framework for the Five Immutable Practices
Each of the Five Practices, guided by the Five Immutable Principles, performs a specific function in our efforts to increase the Probability of Project Success (PoPS). Like the principles, the practices are not a cafeteria-style approach, from which you can pick and choose what to apply to the project.
Each practice contains specific steps needed to produce measurable outcomes to increase the PoPS. If a practice is missing or poorly applied, the PoPS will be reduced, possibly in ways not known until the project is too far along to be recovered. Each practice provides actionable information needed to make management decisions about the project and its deliverables. This actionable information is the feedback mechanism needed to keep a project under control and on track. These control processes are not impediments to progress; they are the tools needed to increase the probability of success.
Identify the Needed Capabilities
Capabilities describe what must be successfully delivered to achieve the project’s objectives or the particular end state for a specific scenario.
A capability provides the ability to do something using the project’s outcome that has a recognized and verifiable benefit. Often, the management of a project begins with requirements, technology, tools, and the process and people that apply the technology and tools. But the customer doesn’t actually buy features and functions. The customer buys a capability to do something of value. This can be a business value, a public service, or the completion of a mission. But the capability must have a verifiable value, recognized by all who participate in or benefit from the project. This measure of value has to be in units recognizable by the project’s participants.
Without knowing what capabilities we need at the end of the project, the requirements, and everything else around managing the project has no home, no reason for being, and no connection to the actual goal of the project. The goal of any project must be to produce the capabilities needed to get something useful done and measure those capabilities through the value delivered to the buyer of the project’s products or services.
These identified capabilities tell us what “done” looks like. Many project management methods skip this capabilities capture process and start by eliciting requirements; this is a mistake3 because if the capabilities capture process is omitted, the participants in the project only know what “done” looks like in terms of time, money spent, and the technical features produced because the key connection—the connection to the business or mission—was never made. The result is usually disappointment on all fronts—time, cost, and outcomes.
Instead of starting with requirements, we need to start with capabilities that describe “done” in Measures of Effectiveness for the outcomes of the project, not just delivery of solutions derived from the requirements. These MoEs are operational measures of success related to the achievement of the mission or operational objectives under a specific set of conditions.
Here is how to develop capabilities and their Measures of Effectiveness:
Describe the solutions needed to achieve a business or mission objective. Knowing the objectives is the starting point. With the stated objectives, the needed capabilities can be identified.
Connect the capabilities to the solution in units meaningful to the decision maker. The end users of the project outcomes rarely care how the capabilities are delivered as long as those capabilities fulfill the technical and operational requirements.
Focus on measurable beneficial outcomes, independent of any technical implementation. This allows a capability to be delivered in a variety of ways, providing freedom for the implementers to choose innovative, efficient, and effective solutions. If we choose the technical solution too soon, we are locked into a path that restricts innovation, streamlining, or even responding to changing requirements.
Connect the capabilities to mission success. In the end, the customers didn’t buy a technology, they bought a solution to a problem. Capabilities are not the requirements for the technology or the operations of the project’s outcomes.
Four steps are needed to determine the capabilities necessary for the success of a project. Like the other practices in the Performance-Based Project Management method, the steps to identify the needed capabilities are performed in a logical sequence, each with a measurable outcome that allow us to evaluate the increasing maturity of the deliverables needed for project success.
Let’s look at the four steps for identifying the needed capabilities.
Step 1 Define the Operational Concepts of the Project’s Deliverables
We need to answer the question, “What is the system going to do when it is complete?” We’ll start with the Concept of Operations (ConOps), which is a written or graphic statement that clearly and concisely shows what the stakeholders intended to accomplish through their mission or business strategy. The ConOps describes how these capabilities will be employed by the business to solve a problem or meet a business goal, and what benefits result when the project is “done.”
This sounds a lot like goals and objectives, or maybe a strategy, or even some business optimization process. Those are closely connected to the ConOps, but the key to the ConOps is to define what the outcomes of the project will provide, in units of measure meaningful to the decision makers. This means some measure of how effective the outcome will be at doing its job.
The ConOps describes the problem to be solved, the classes of users, and the operational scenarios that show what the system is doing.4 For example, the ConOps for an insurance transaction processing system would include all the possible transactions that would be processed, the staff needed for this processing, the procedures used to process them under normal conditions and any exceptions to those conditions, the number of transactions per day, and so on. The ConOps is the narrative description of what “done” looks like from the users’ point of view.
We can then break down the ConOps into a Statement of Work (SOW), Statement of Objectives (SOO), or maybe even a Request for Proposal (RFP). This is done through a top-to-bottom trace of the concepts that connects each requirement with a ConOps element. This structure is a “map” of the needed capabilities and their interrelationships. It forms the basis of the requirements flow-down process that we’ll see in the next step.
We need to start at the beginning of the project to capture capabilities in a form that can be used to trace requirements, deliverables, and performance measures back to these capabilities and define the MoEs for each capability. For example: “We need the capability to complete 95 percent of work on or before 15 business days or the negotiated deadline.” MoPs are the criteria used to organize these MoEs. Measures of Performance are qualitative or quantitative measures of system capabilities or characteristics as seen from the provider’s point of view. MoPs are broad physical and performance parameters, derived from the MoE. The basis of physical percent complete can be defined with MoPs, be traceable to the MoEs, and then traced to the needed capabilities.
The notion of physical percent complete is critical to the success of any project management method. Physical percent complete provides tangible evidence of progress to plan. It can be seen, touched, demonstrated, and observed in a predefined manner. The fact that it is “tangible” and “predefined” is the thing that is important. Use tangible evidence, not personal opinions—which are subjective—about how much progress has actually been made with objective proof.
Step 2 Define the Scenarios and Use Cases
Next, we need to answer the question, “How is are the business or stakeholders going to use the system, what actions can they take, and what are the results of these actions?” For each capability, we need a scenario and the use cases that fulfill the scenario. A use case is a list of steps, typically defining interactions between a role and the system, to achieve a goal from this system. These describe the sequence of the activities, who is performing them, and what the inputs and outputs are from these activities. This means that we must think through what we are going to do with the outcomes of the project in terms meaningful to the users.
One way to do this is to build a Value Stream Map (VSM) of the work processes of the outcomes and connect each scenario and use case to some point on the map to show how each capability provides value. The concept of the VSM originated at Toyota, where it was called material and information flow. It can be applied to any value chain. Our project example in Figure 2.2 is the “value chain” for the provider enrollment process at a health insurance firm. Value Stream Maps are typically found in manufacturing and information flows to identify products or services. Figure 2.2 is an example of a VSM for the delivered capabilities of the provider enrollment process for the health insurance claims processing system.
To build this map or something like it to show the increasing ability of the deliverables to meet the needed capabilities, we need to:
List individual capabilities in the form of scenarios described through use cases, process flows, or operational descriptions.
Assess the dependencies between the needed capabilities by identifying the “implicit” relationships. These are the dependencies that will cause trouble later. “I didn’t know there was a connection,” is the classic response. These implicit dependencies need to be made explicit for the capabilities description to be credible.
Step 3 Assess the Needed Capabilities
With our list of needed capabilities, we can ask and answer, “How will we measure the benefits of the resulting capabilities?” The questions are about schedule, cost, risk, and how they relate to the capabilities, and they need to be asked all at the same time. For example, if we are remodeling our kitchen, we need to ask when the appliances will be needed on site for installation. What preconditions will be needed to allow the appliances to be installed and put to use by the homeowner? This brings into focus a concept critical to the success of all projects. Before we can know what something is worth, we have to know what it costs and how much risk we are willing to take for that cost to produce the capability. We need to know this if we are going to define what success looks like.
Our assessment of the needed capabilities must also make probabilistic estimates of schedule, risk, cost, and technical performance. It does us no good to state a cost number, or any number, in fact, without knowing the variances in the values of that number. It is common for business cases to contain dollar values for cost and benefit. But without knowing the variances on those numbers, those values are of little use in risk adjusting the outcomes.
To perform this assessment we need to:
Take each implicit and explicit dependency in our Value Stream Map and assess the interfaces between the capabilities and how these drive the capabilities.
Assign the cost, risk, and operational needs to produce a tangible assessment of the tradeoffs between the needed capabilities.
Step 4 Define Explicit, Balanced, and Feasible Alternatives
For each capability that has been identified and analyzed, a tradeoff assessment of its usefulness to the project using some form of the measure of cost and benefit must be performed. These tradeoffs connect cost, schedule, and technical performance into a single trade space.5 The notion of a trade space provides the means to explore alternatives in design and development early in the project. The tradeoffs are compared to see how well they provide the needed capabilities to the customer. The MoEs and MoPs can be used to assess the alternatives during the trade space analysis.
We must remember that the project’s value is realized only when the capabilities the project produces are those needed for success as defined by the users. This is the definition of value used by the agile community. It is a definition that is universal and directly supported by the capabilities-based planning paradigm of Performance-Based Project Management described in Chapter 2.
For the alternatives to be usable, they must:
Be monetized in some way to assess the connections between cost, risk, value, and compliance with the technical performance requirements. This “trade space” is part of our decision-making process. What do we need? What can we afford? How much risk can we tolerate? What are the upsides and downsides of accepting this risk?
Provide tradeoffs measured in units of effectiveness and performance. These need to be risk adjusted. We’ll see how to do this in Chapter 5.
Identify the Requirements Baseline
Poorly formed requirements contribute up to 25 percent to the failure of projects.6 Requirements engineering is the result of requirements elicitation, requirements specification, and requirements validation. Most of the requirements management techniques and tools today focus on a specification—that is, the representation of the requirements. Our Performance-Based Project Management method concentrates instead on elicitation. This method addresses problems found with requirements engineering that are not adequately addressed by specification techniques.7 Our Five Immutable Practices incorporate advantages of existing elicitation techniques while providing new techniques to elicit requirements. These techniques include fact-finding, requirements gathering, evaluation and rationalization, prioritization, and integration.
Once we know what “done” looks like in Measures of Effectiveness derived from our capabilities, we can start to define the technical and operational requirements that need to be fulfilled to deliver these capabilities. But remember, requirements are not the same as capabilities. And capabilities are not the same as requirements. Both are needed, but capabilities come first; the requirements follow. Without this sequence, the requirements have no home.
There are five steps to establishing the requirements baseline.
Step 1 Perform Fact-Finding
We start by eliciting information to produce an overall statement of the project’s goal in its operational context. This provides the operational and technical objectives to be met by the project and answers two important questions: “What problem does the customer want to solve?” and “How will we recognize that the problem is solved?”
To perform this fact-finding, we need to take these steps:
1. Identify the relevant parties across multiple levels of the requirements breakdown. This is done using a list of the project stakeholders, participants, and suppliers assigned to each of the capabilities and the related requirements, and it provides the traceability needed to see who influences the use, consumption, creation, and constraints on the requirements.
2. Determine the operational and problem context. This includes the operational modes, goals, and business scenarios. Using the Concept of Operations, we can create a cross-reference between the project’s operational behavior and the stakeholders to confirm that they are going to get what they expect to get.
3. Identify similar systems and elements of these systems to help reveal requirements. Learning the attributes of similar systems can save us time and reduce risk.
4. Perform a context analysis for each requirement to isolate redundancy and duplication. This effort answers the questions, “Why is this requirement here?” “What value does it provide?” and “How can we measure its value?” Evaluating each requirement and how these requirements support the needed capabilities is the start of the economic assessment of the project.
5. Identify the domain experts we’ll need to provide information about the requirements and their connection to the needed capabilities. Connect these experts to specific capabilities and trace their recommendations to requirements and their prioritization.
6. Identify the domain and architecture models for each requirement and how these models interact with each other. This allows us to offer technical options for each requirement. These tradeoffs give us insight into the cost assessment process.
7. Assess any cost and implementation constraints imposed by the project owner. Associate these cost tradeoffs with each requirement based on a formal cost structure. This is the start of the value assessment of the project. It is difficult to know what the value of a capability is without knowing its cost.
Step 2 Gather and Classify the Requirements
With our fact-finding complete for each of the elicited requirements, we can now start to classify them. An easy way is to build categories that match the business capabilities. We can gather the operational, technical, functional, nonfunctional, and environmental requirements, along with the design constraints. With these, we can build a top-down list of capabilities and deconstruct the requirements. This is easily done in a “requirements flow-down tree,” where the root of the tree is the top-level business goals of the project. Each capability is the child of the root of this tree, and the requirements can then be connected to each needed capability. Making these connections visible is the key to success.
To gather and classify the requirements we need to:
Capture a “list” of requirements derived from the ConOps in some form of structured “tree.” This allows us to identify the connectivity between the requirements from the very beginning of the project. These connections may not be correct, so we need to continuously improve these structures as the project progresses.
Classify these requirements according to their functional, nonfunctional, environment, and design attributes. Partition the assignment of these requirements separately from the capabilities-based requirements. We must avoid the simple “wish list” approach with no means of separating value, risk, cost, feasibility, and other show-stopper attributes.
Step 3 Evaluate and Rationalize the Requirements
We now need to look at each requirement and ask, “Is this something that we really need?” “What happens if this requirement is dropped?” “Who is impacted by this requirement?” We need to define the connections between the requirements of the stakeholder and the beneficial outcomes from the project.
This is done through a cost/benefit assessment of the variables and dependencies:
Answer questions such as, “Why do you need Requirement X?” We can use some form of dependency modeling to connect the “need” to the requirement. The traceability from need to requirement is made visible to all participants so they can understand the impact on the cost and schedule for each requirement.
Capture the rationale for each requirement. This is done with a narrative explaining how this requirement supports a needed capability.
Perform a risk assessment, addressing technical, cost, and schedule concerns once the connections are made. This includes cost/benefit filtering and feasibility analysis based on technology attributes, such as technical performance, reliability, serviceability, or other attributes of the product or service produced by the project. Once we map risks to individual requirements, we get the information needed to manage risks and make tradeoffs based on risk. This activity takes place in the fourth practice.
Step 4 Prioritize the Requirements
Put these requirements in order of priority, starting with the must-haves. If the outcomes can’t deliver these requirements, the project is a failure. If they can, these are the requirements to be used in the next step.
This prioritization is straightforward:
Determine criticality of the essential functions for the mission. Build a ranked list of critical elements using a paired-comparison analysis with geometric progression.8
Sequence requirements based on cost and dependency. Assess how the system can be incrementally added to, and identify appropriate architectural models that support incremental development. If we build a model of these requirements that connects them to the needed capabilities and to each other, we can assess the impact of each requirement beyond just “making a list.”
Step 5 Integrate and Validate the Requirements
Using the ranked requirements, connect them by asking, “What data are needed, who is affected, and what high-level processes will be implemented as a result of this requirement?” Get this right for the ranked requirements before doing anything else. Then repeat this process for the next tier of requirements. The result is a “completeness” test for the requirements. We can validate and come to agreement on what requirements are needed to fulfill the desired capabilities and resolve any conflicts and inconsistencies.
Here’s how this can be done:
Address completeness by filling in as many “to be determined” requirements as possible. Using the “requirements” model, we can assess any missing components and grade the maturity of the requirements model. This approach allows us to make the “maturity” of the requirements visible in tangible form.
Validate that requirements are in agreement with originally stated capabilities. With the requirements traceability matrix, we can connect the requirements to the capabilities and ensure that each capability can be fulfilled with an explicitly defined solution.
Obtain authorization and verification to move to the next step in the Five Immutable Practices—the development of our Performance Measurement Baseline. Once the requirements are in place, the scope of the project is defined in preparation for the planning process.
Establish the Performance
Measurement Baseline
The Performance Measurement Baseline (PMB) is the primary representation of the project’s cost, schedule, and technical performance plan. Constructing the PMB requires knowledge of the capabilities and requirements, skill in developing the work packages (WPs) that produce the deliverables for these requirements, and discipline to assemble the cost and schedule relationships between the work packages. This discipline requires greater focus on the part of the project management staff. Without this discipline, it is simply not possible to develop a credible baseline, and the project is set up for failure because no one knows what “done” looks like.
The project management staff must know in intimate detail each WP, its deliverables and resource requirements, the performance measurement criteria, and the dependencies that form the critical path through the project schedule.
The PMB defines the following:
Deliverables with units of measure describing progress to plan
Deliverables that are known to be what the customer is paying money for
Deliverables that implement the needed capabilities
The first critical success factor in building the PMB is the deconstruction of the system requirements into technical capabilities, then into deliverables that enable those technical capabilities, and finally into a work breakdown structure and the work packages that produce those deliverables. This is illustrated in Figure 3.2.
The physical construction of the WPs takes many forms, based on the needs of the project. Their format is not critical. The contents are. The format of the WPs should be appropriate to the needs of the project.
The Principle of Performance-Based Project Management using WPs requires that we:
Define the deliverables independent of the needed system capabilities in a work breakdown structure. This deconstruction process MUST be iterative and incremental. Assessment of its reliability and deconstruction requires thought. The first deconstruction is likely not the best approach.
Estimate the duration and work effort for each WP. Estimating duration and effort is also iterative and incremental; it cannot be a one-time effort. The initial estimate MUST be assessed after the assembly of the WPs into the Activity Network of the tasks performing the work. Only then can they be considered credible.
There are six steps in doing this work, but the approach here is to define the work in packages—small chunks of effort that produce a tangible outcome. This outcome goes toward fulfilling a requirement, which, in turn, enables a capability. By now, you should be seeing a pattern—little steps.9
This, of course, is similar to agile development—do a little, test it, do a little more. This is the basis of Performance-Based Project Management. Build the project performance management system in little steps. This is not a new approach. It is a logical approach. But often this approach is not used. Instead, the big bang approach is used. Define all the work, build a huge and convoluted schedule, and start executing that schedule. This is a really bad idea and usually leads to project failure, because what “done” looks like hasn’t been defined, and, therefore, how is progress toward “done” going to be measured along the way, other than through the passage of time and consumption of money?
Step 1 Deconstruct the Project Scope into Work Packages
This starts with building a work breakdown structure showing the products and the processes needed to produce those products. The WBS is always “product centric,” not functional. The WBS shows what is going to be delivered, so we can trace the deliverables back to the requirements and then back to the needed capabilities.
Figure 3.2 shows how to:
Use the WBS to define the work packages that need to be scheduled and staffed. Resources and functions need to be assigned to each of the work packages.
Deconstruct the requirements into collections of deliverables at the terminal nodes of the WBS. “Lumps of work” can be assembled for assignment to the subject-matter experts, who can then estimate the cost and schedule. Discovering how these “lumps of work” are related is an iterative and incremental process, so plan on doing this several times.
Revisit the necessity for each requirement and the work needed to fulfill the capability. Trace each requirement back to its source capability to make sure we have a reason for the requirement and the requirement supports a needed capability. Without this final connection check we may end up with unneeded requirements or unfulfilled capabilities.
Step 2 Assign Responsibility for the Delivery of These Work Packages
After defining the work packages, the resources need to be assigned. The easiest way to do this is with a Responsibility Assignment Matrix (RAM). The RAM identifies the person accountable for each work package. Assigning accountability is mandatory. The person accountable can then assign responsibility to others doing the related work. This single point of integrative responsibility removes the confusion over who has the information about the performance of the work package and who is accountable for it.
Step 3 Arrange the Work Packages in a Logical Order
This is where the heavy lifting on any project starts. We need to arrange the work packages in a well-formed network with explicitly defined deliverables, milestones, and internal and external dependencies. The schedule that results from this sequencing effort describes the delivery of products or services, shows dependencies, shows deliverables, shows how maturity increases, identifies risks and their mitigation or retirement, and provides other measures meaningful to project management and the stakeholders.
Step 4 Assign Resources and Costs to These Work Packages
We start with a budget for each work package. This can be labor hour “spreads” and material costs. This cost spread can be made visible with a scheduling tool. This will be important when we start measuring the performance of our project. There are several ways to come up with the “estimated budget.” The best is to use past performance: “What did it take to develop a similar product or service in the past?” If we don’t have that identical information directly, we can use a reference class forecast. Reference class forecasting predicts the outcome of a planned action based on actual outcomes in a reference class of similar actions to that being forecast. The theories behind reference class forecasting were developed by Daniel Kahneman and Amos Tversky.10
Step 5 Assign Measures of Physical Percent Complete to Each Outcome
We can now assign objective performance measures for each work package and summarize these at the project level. These objective measures are assigned to deliverables in units meaningful to the decision makers. This measure of physical percent complete (PPC) is an unequivocal assessment of progress. It “shows” results through tangible evidence, never opinion, or measures of effort, passage of time, or consumption of resources.
The best way to measure physical progress to plan is to use a 0 percent/100 percent assessment of “done.” Either it is “done” or it is not “done”—nothing in between. The key here is to make fine-grained measures for planned work. One way to do this is to ask yourself, “How long are you willing to wait before you find out you are late?” Then define the assessment of physical percent complete at one-half that duration. That way, when you learn you are going to be late, there is time to fix it and get back on plan.
Step 6 Set the Performance Measurement Baseline
With the first five steps in place, we’re now ready to “baseline” our plan. We have identified all the capabilities, resolved all the requirements, and assigned them to the needed capabilities. We built a work breakdown structure from these requirements and connected these to the work packages. We sequenced the work packages, resource loading them, and assigning single accountabilities for the deliverables from the work packages. This prepares us to set the Performance Measurement Baseline. The PMB is a budgeted plan for all the work to be performed, the organizations needed to perform that work, the descriptions of the outcomes, and measures of these outcomes.
FIGURE 3.2 Performance Measurement Baseline.
Execute the Performance Measurement Baseline
Using the Performance Measurement Baseline, each work package must start as planned, complete on or near the planned date, and produce at or near the planned technical performance level. This is essential to the success of any credible Performance-Based Project Management method. In the absence of this, the project is behind schedule, over budget, and noncompliant with the technical goals. Notice the “on/at or near” phrase. All measures, all work, all plans must contain a margin for naturally occurring variances. They must also have a management reserve for the probabilistic uncertainties that occur on all projects.
The primary focus of the Performance Measurement Baseline execution is to physically assess the progress of the project in units reflecting three independent variables. All these variables are probabilistic, with confidence intervals. These means we must speak about a cost or a schedule date or a technical performance using our “at or below” for cost, “on or before” for a date, and “within tolerance” for a technical performance. And then use them with some confidence.
Cost. This is the budgeted and actual cost for all labor and materials used in the project. We determine our budget performance by comparing our planned spending with the actual spending on a time-phased basis. The assessment does not tell us about actual progress of course, just how we are spending money toward that progress. We must speak about cost as, “We have an 80 percent confidence that the project’s cost will be $1,225,500 or less on the planned completion date.”
Schedule. This is the sequenced set of work activities needed to deliver the outcomes of the project. We can measure progress to our schedule by looking at how we start and end the work packages. The assessment of “late starts” and “late finishes” is a good indicator of project performance. We’ll use this information in Chapter 5 to construct an “Estimate to Complete” for our sample project. We must speak about the schedule date as, “We have an 80 percent confidence of completion on or before September 30, 2014.”
Technical Performance. This is the assessment of the outcomes against the planned performance needed to satisfy the needed capabilities. This is the best measure of project performance. Cost and schedule are necessary, but, in the end, the product or service must actually work as planned. We predefine the expected “technical performance” of the outcomes of the work packages and assess their measures at the planned time. We must speak about technical performance as, “We have an 85 percent confidence that the system can process 10,000 transactions an hour in the first month of operation and increase to 15,000 transactions an hour after full operational checkout.”
The comparison of budget versus actual expenditures indicates what was planned to be spent versus what was actually spent at any given time. The comparison of actual technical performance with planned technical performance indicates how we are meeting the requirements and the resulting capabilities. We must be “on budget, on schedule, and on specification” for our project’s probability of success to increase.
With this approach, the use of physical percent complete for the amount of work performed is a starting point. It does not indicate anything about the conformance to specification of the work produced for the amount of money spent.
To successfully execute the PMB, we need to take five steps.
Step 1 Perform the Work in the Planned Order
Apply a Work Authorization process for starting work packages. The authorization process defines the planned start, actual start, projected finish, and actual finish. This makes our performance visible for all authorized work in the coming period of performance and confirms readiness to perform the work against our allocated budget. A fundamental rule of project management is “late start = late finish.” Keeping track of “late starts” and “late finishes” provides visibility to the project ability to meet its commitments.
Step 2 Capture and Report the Performance of the Work
Using measures of physical percent complete, the actual cost of the work is captured and compared to the budgeted cost. These actual costs are important to forecast future costs, but they are not measures of actual progress. To measure actual progress, we need both schedule performance and technical performance.
When we capture measures of physical percent complete, we must define what we expect it “should” be on the day we take this measure. The best measure of physical percent assessments is a “working product.” This means working software, working hardware, and a working process.
Step 3 Analyze the Performance
Analysis of the project’s performance takes many forms. Some are subjective, many objective. Let’s focus on the objective assessments of performance for now:
The Critical Path. This is the longest path through the network of activities. If this path were to get “longer,” the project would slip. But there are “near critical” paths as well. These paths are the source of most of the scheduling problems. When a “near critical” path becomes a critical path, it is usually too late to take corrective actions.
Duration Accuracy. This must be realistic and risk adjusted. Having a measure of variance for duration, cost, and technical performance provides credibility to the project’s schedule. We must remember that all project variables are random numbers. Knowing the value of a number is necessary but not sufficient. We must also know the variance of any number for that number to be credible for use in managing the project.
Integration. All the work packages must be connected horizontally as well as vertically. Horizontal connections are the sequence within a work stream, the intradependencies. Vertical integration describes the interdependencies between the work that produces increasing value to the project through the delivered capabilities.
Reality Testing. This is needed if we are to actually achieve the desired results. It starts with a “risk adjusted” cost and schedule baseline.
Forecasting. This is the prediction of the future cost, schedule, and technical performance based on past performance and risk management.
Step 4 Take Corrective Actions to Keep the Planned Work Moving Forward
With the cost, schedule, and technical performance indices we can construct a forecast of future performance of cost, schedule, and technical performance compliance efforts, and take management actions for any work packages not performing as planned by doing the following:
Calculating measured performance using tangible evidence of physical percent complete
Recording changes to the work sequencing, scope, budget, or any other variable and agreeing these changes will not negatively impact the outcome of the project without agreement from the stakeholders
Adjusting the sequence of work, budget, or resources to correct the undesirable outcomes of the current performance of the project
Step 5 Maintain the Integrity of the Performance Measurement Baseline
When we record past performance based on work package completion criteria, we can construct and estimate the future forecast. We can then manage the schedule, the labor, and other cost spreads through the performance measures of the deliverables using a change-controlled baseline. We capture the data from each period of performance and add that information to the PMB to record past performance, which we can use for future performance forecasts. These data of past, present, and future performance measures ensure that we have visibility into the project for management, technical experts, and project, planning, and controls staff.
Perform Continuous Risk Management
While we are off executing the Performance Measurement Baseline, we need to be mindful that project management is actually about the continuous management of risk. The notion of Continuous Risk Management (number 5 in Figure 3.1) is critical to the success of using Performance-Based Project Management. Risk management is not a one-time activity; it is performed “continuously” at every step along the way. The identification and management of risk is performed throughout project management.
The six steps to Continuous Risk Management are shown in Figure 3.3.11
Step 1 Identify Risks
Before risks can be managed, they must be identified. Identification surfaces risks before they become problems and adversely affect a project. The Software Engineering Institute (SEI) has developed techniques for surfacing risks by using a disciplined and systematic process that encourages project personnel to raise concerns and issues for subsequent analysis.
Capture a statement of risk describing the name of the risk, the probability of the risk occurring, the potential impact of the risk if it were to occur, and risk handling plans to either retire the risk or handle the risk if it were to occur.
Capture the context of a risk that provides additional information about the circumstances of the risk.12 The context is a detailed description of the events, circumstances, and interrelationships that may affect the project.
Step 2 Analyze the Risks
The analysis then converts this risk data into risk decision-making information. This information guides the project manager to work on the “right” risks. This analysis examines the risks in detail to determine the extent of the risks, how they relate to each other, and which risks are the most important.
To analyze risk, we need to do the following:
Evaluate the attributes of the risks to gain a better understanding of the risk to determine the expected impact, probability, and time frame of the risk.
Classify the risks by looking at the set of risks and how the risks relate to each other as a class. The classes or groups of risk provide different perspectives when planning the risk-mitigation processes.
Prioritize and rank the risks to separate which risks should be dealt with and in what order when allocating resources.
Step 3 Plan the Risk-Handling Strategies
Risk planning turns risk analysis information into decisions and necessary present and future actions to handle the risk. Planning develops actions to address individual risks, prioritize the actions, and create an integrated Risk Management Plan. This planning effort helps managers decide what if anything should be done with the risk. Planning produces risk action plans for individual or classes of risks. Risks are planned by the people who have the knowledge, expertise, background, and resources to effectively deal with the risks.
This planning process needs to:
Assign responsibility, starting with a review of the project risks by the project manager to determine what to do with them. This ensures that no risk is ignored.
Define the approach for handling the risk. This starts with knowing enough about the risk to decide what to do, and then picking an appropriate approach for management of the risk.
Define the scope and actions needed for a balanced approach in developing effective handling actions to mitigate risks.
Step 4 Track the Status of the Risk-Handling Strategies
Tracking monitors the status of risks and the actions taken to ameliorate them. Appropriate risk metrics are identified and monitored to evaluate the status of the risks and of risk mitigation plans. Tracking serves as the “watchdog” function of management. The person responsible for the tracking process:
Acquires information about the risk by collecting data about the context, impact, probability, time frame, rank, and planned approach for each risk.
Compiles which data for a given risk are analyzed, combined, calculated, and organized for tracking the risk and the risk-handling plans.
Reports this tracking information in a Risk Management Plan (RMP) used to communicate risk status and handling plans. These reports are delivered as part of routine project management activities of the project.
Step 5 Control the Risk-Handling Activities
The decision-making process takes the tracking status reports produced in the fourth step and decides what to do with the risks. The person accountable for a risk normally makes the control decisions for that risk.
Step 6 Communicate the Risk Information
Risk communication is at the center of all successful risk management processes. Without effective communication, no risk management approach is viable. To be analyzed and managed correctly, risks must be communicated to and among the appropriate organizational levels and entities. This includes levels within the project organization, the customer organization, and, most especially, across the interfaces between the project and customer. Because communication is pervasive, this approach is integral to every risk management activity and is not something performed outside of, and as a supplement to, other activities.
FIGURE 3.3 Communication is at the center of Continuous Risk Management.
Looking Back
We now have Five Practices to go with our Five Immutable Principles. Figure 3.4 shows these connections. The Five Principles are connected to the Five Practices through the components of project management.
The Concept of Operations (ConOps) is the narrative of what capabilities the project will need to deliver for the stakeholder to consider the project a success.
The technical and operational requirements define how the capabilities will be fulfilled.
The master schedule shows how the work packages deliver the requirements at the planned time and for the planned cost.
The work packages contain the activities needed to produce the outcomes that meet the project’s planned performance objectives.
Measures of physical percent complete ensure that progress is being made to plan.
Continuous Risk Management processes are performed on all activities of the project.
What’s Ahead?
With the principles and practices in place, we now need a process framework we can use to apply them before moving to our project examples. This framework is necessary to anchor our principles and practices in the “governance” process. Governance is the management framework for making decisions about the project. The accountabilities and responsibilities associated with the business processes are defined by governance.
This process framework is based on five guidelines:
1. Organizing. People perform projects. Organizing people to perform the work is a critical success factor for all projects.
FIGURE 3.4 The Five Immutable Principles and Five Immutable Practices are connected.
2. Planning and Budgeting. The plan is the strategy for the successful completion of a project. This strategy is a hypothesis of how we will execute the project. We must test this hypothesis while performing the work by measuring outcomes to see if they are technically compliant with our plan. If not, we need to take corrective action and adjust our plan.
3. Accounting. We need to keep track of our budget and compare how we are spending the budget to our plan.
4. Performance Analysis. Measuring progress to plan allows us to not only make adjustments but also to forecast future performance of the project.
5. Revision Management and Corrective Actions. All project work has cost variance, schedule variance, and technical variance. We must manage the project in the presence of these variances. Feedback from the project provides us the information we need to manage in the presence of these variances.