CHAPTER 1

The Ten Drivers of Project Success

Project success is elusive. Many books, articles, and professional societies suggest methods that can be used to produce this success, and I believe that anything and everything we read, listen to, and participate in around the notion of managing projects can add value to and increase the probability of a project’s success.

Of course, anyone who has been around project management has anecdotes about failed projects and has participated in failed projects despite using the checklists, flowcharts, tools, competency assessments, and certifications designed to improve the chances of producing a successful project. In each of these cases, the project failed because something was missing.

To optimize project success, we need to look to the foundation of all project success, the immutable principles and practices of managing projects.

The Five Immutable Principles of project management success are built on ten success drivers, which are the underlying mechanics of all project work. They are the core processes that take place during the life of any project (see Figure 1.1). The Five Practices used during the management of projects are built on the Five Immutable Principles. The relationship between the principles and the practices is important to the success of any project. Without first establishing the principles, the practices have no foundation on which to “practice.” Figure 1.2 shows how these drivers relate to one another. We’ll look at them in detail later in the chapter. The principles, which are built on the drivers, and the practices, which are built on the principles, are the foundation of project success. This does not mean success is assured, but it does mean that without them the project has less of a chance of success.

The success drivers are organized into three classes:

1. Planning. We need a plan, a schedule, a budget, a description of the work to be performed, and the order in which that work should be performed.

2. Execution. Once the work is defined and the required order established, execution of the work packages (WPs) can take place.

3. Performance Management. While the work is being performed, we need to measure our progress against the plan. This measurement should be tangible, not just an opinion. The best tangible evidence is confirmation that the planned outcome of each work package actually occurred at the planned time for the planned budget.

Figure 1.1 summarizes the principles, practices, and drivers and their functions. As we proceed with this chapter, we will explore each in greater detail.

Project success depends on doing many things right, each of which must operate as a close-knit system, supporting each other in order to deliver a successful project. It all begins with the drivers of the Five Immutable Principles of project management and the Five Practices that implement these principles. They and their relationship to one another are illustrated in Figure 1.2. Without understanding the drivers, there is no real way to check the validity of the principles or practices. These drivers are found in any project, in any business, in any technical domain, using any project management or product development method.

FIGURE 1.1 The foundation of project success starts with the ten drivers.

The Immutable Principles and Practices of Project Success

There is an unspoken question in the project management community: How can we integrate strategic, technical, and managerial processes into a framework based on sound principles, while providing practices that can be applied in a wide variety of domains?

There are numerous approaches to managing projects. Many can be found in books like A Guide to the Project Management Body of Knowledge (PMBOK^® Guide), in Prince2^®, and in agile software development books. These describe the technical and operational side of project management. The management of cost, schedule, and technical performance can be extracted from these descriptions. Human actions relevant to the management of projects—such as communications, the intent of the leaders, understanding, uncertainty, and the tacit knowledge required to successfully deliver the project’s value to the stakeholders—are also taken into account in these descriptions. A recurring theme in all these methods is that good project management practices need to be built on principles. “Best practices” alone are necessary, but they are not sufficient. Practices, even ones built on sound principles, must be effective in the face of uncertainty, confusion, and ever-present change. With this in mind, we need to search for the drivers that are the foundation of the Five Principles. The Five Practices are then built on these Five Principles. These drivers are the source of both project difficulties and project success. When the driver is absent, the project is missing information needed for success. When the driver is present, it is connected to a principle, which in turn is connected to a practice to increase the probability of success. Without understanding of what “drives” success or failure, the project manager has no insight into how to manage the project to produce success. The project manager is unable to “connect the dots” between what is happening in the project and what should be happening to increase the probability of the project’s success.

FIGURE 1.2 How the ten drivers relate to one another.

Traditionally, a set of project management activities (e.g., product or service integration, cost, communication, scope, quality, risk, time, human resources, and procurement) is applied throughout the management of the project. These activities focus on the execution of the project.

This approach has shortcomings in our quest to increase the probability of project success. For example, the previous list of project activities does not include project strategy, creation of value from the project, measurement of effectiveness of the resulting outcomes, or measures of performance of the work activities in units meaningful to the decision makers.

The Basis of the Five Immutable Principles

Some people in the field talk about the “basic tenets” of project management. But where do these come from? Some say they come from hands-on experience, anecdotal “best practices,” and the good old “school of hard knocks.”

According to Webster’s Dictionary, a principle is a “general truth, a law on which other laws are founded or from which others are derived.” In the project management domain, a principle can be further defined as:¹

A rule or law of action based on desirable ends or objectives based on a fundamental set of actions. Principles are the basis of policies or procedures that govern the behavior of the people, processes, and tools used on a project. One common principle is, “time is money.” In all project work this is the case. If work is being done, time is passing, and people must be paid for their time.

A fundamental truth that can explain the relationship between project variables—usually cost, time, or technical attributes. These can be independent and dependent variables in this relationship. This fundamental truth can be descriptive, explaining what will happen, or it can be prescriptive, indicating what a person, a process, or a tool should do based on some known standard. The principle can also reflect a scale of values, such as efficiency, reliability, availability, or other “. . . ilities.” In this case, . . . ilities imply value judgments as well as actual measurements. In another example, cost and schedule are directly related through some multiplicative factor. The more time the project takes, assuming constant productivity of the labor, the larger the cost will be for that labor. Quality, cost, and schedule performance can be described in the same way, with the same productivity factors. Technical performance of the planned deliverables is also related to cost and schedule in the same way.

For the principles of project management to be effective, Max Wideman suggests they must do the following:²

“Express a general or fundamental truth, a basic concept . . .

“Make for a high probability of project success. The corollary is that the absence of the condition will render project success on a majority of the key criteria as being highly improbable.

“Provide the basis for establishing logical processes and supporting practices that can be proven through research, analysis, and practical testing . . .

“Be universal to all areas of project management application.

“Be capable of straightforward expression in one or two sentences.

“Be self-evident to experienced project management personnel, and

“Carry a concise label reflecting its content.”

Max Wideman’s PM Glossary (www.maxwideman.com) is a great source of information about project management terminology.

The Five Principles

The Five Immutable Principles of Performance-Based Project Management are designed to meet both the definitions of a principle and Wideman’s requirement that they be effective. Here, they are stated as questions that need to be answered by the project manager:

1. Where are we going?

2. How are we going to get there?

3. Do we have everything we need?

4. What impediments will we encounter, and how will we remove them?

5. How are we going to measure our progress?

These questions can be applied to projects just as they can be applied to any endeavor from flying to Mars to taking a family vacation. If we use the dictionary definition of immutable, “not subject or susceptible to change or variation in form or quality or nature,” we can apply these principles to any project in any business or technical domain.

The Five Practices

The Five Practices, which are derived from the Five Immutable Principles, are used to keep the project on track:

1. Identify needed capabilities.

2. Define a requirements baseline.

3. Develop a Performance Measurement Baseline.

4. Execute the Performance Measurement Baseline.

5. Apply Continuous Risk Management.

The Ten Drivers of the Principles That Enable the Practices

Let’s look at the ten drivers shown in Figure 1.2 that are the foundation for the immutable principles and practices of project success.

1. Capabilities drive system requirements. Capabilities provide the customer with the means to generate business or mission value. With these capabilities in hand, the mission or business need can be carried out and the desired beneficial outcome produced from the project. If we understand what capabilities are needed to produce business value or satisfy a mission, we can then identify what technical or operation requirements are needed to deliver those capabilities.

2. Requirements are defined in work packages. Requirements are derived from the needed capabilities by asking and answering the question, “How can this capability be delivered using the technical or operational solutions at hand?” The mechanisms for implementing a capability are described in a requirement. Requirements state the “shalls” of the solution in support of a capability. The requirements are implemented in work packages (WPs), which produce deliverables that are assembled into the capability that produces the products or services needed by the customer.

3. Work packages produce the deliverables. This is where labor and materials come together; it is where the work needed to produce the components of products or services is done.

4. The Performance Measurement Baseline (PMB) describes the work sequence. The PMB is the time-phased arrangement of the work packages that produce usable results in a planned order to produce the desired product or service.

5. Measures of physical percent complete define “done” for each work package. Working software, usable products or services, all measured in predefined units of “physical percent complete,” provide the evidence needed to demonstrate that work is progressing according to plan.

6. Work authorization assures proper delivery of value. Keeping the work flowing to maximize the delivered product or service requires a well-structured schedule.

7. Produced and measurable value defines progress. Measurement in units of effectiveness and performance for the user is the definition of value that all projects require.

8. All measures are adjusted for technical performance compliance. Performance to plan is adjusted for the technical and operational aspects of the project, not just the passage of time and consumption of resources. These adjustments are necessary to correct our measures of effectiveness of our cost and schedule. If we planned to complete a deliverable in a specific amount of time for a specific amount of money and that deliverable was not technically compliant, we would have to spend more money and time to finish it. Therefore, we would be over budget and late on the planned day of completion of our deliverable.

9. Fulfilled requirements produce delivered capabilities. With the requirement fulfilled by products or services, the capabilities can be deployed to the customer.

10. Past performance is a forecast of future performance. For all measurements of future performance, what happened before is a good starting point.

The ten “driving” elements shown in Figure 1.2 illustrate the various activities applied across the life cycle of a project or program. They start at the inception of the project (Driver 1) and the initial assessment of the business’s or system’s capabilities and continue through requirements elicitation (Driver 2) and the creation of the PMB describing the time phased work and its budget (Driver 3 and 4), to the execution of the baseline (Drivers 6, 7, and 8) and project close-out (Drivers 9 and 10).

The drivers of Performance-Based Project Management provide feedback loops to assure that subsequent activities provide measurable information about the corrective actions needed to increase the probability of success. This repeated step-by-step approach to project management assures that the periods of assessment provided for corrective actions are appropriately spaced to minimize risk and maximize the delivered value to the project.

The ten drivers are the basis of the principles and practices of Performance-Based Project Management, and each is present in every project domain, every business paradigm, and in every project management method. If the driver is not recognized and dealt with, it will still “drive” the project outcome, whether the project manager looks after its performance or not. For example, if the work is performed out of sequence, the project is missing Driver 6: Work Authorization, and the work products may need rework. If we install the wallboard in the house before the electrical wiring, we will have to cut the wallboard to pull the wiring.

Putting the Ten Drivers to Work

Let’s look in more detail at each driver and see how addressing it with the Five Immutable Principles and Five Practices can increase the probability of project success.

Capabilities Drive System Requirements

The first driver of project success is the principle that all technical and operational requirements must be derived from the needed capabilities.

We hear all the time about bloated software products, with features no one uses. But what we don’t hear about is how to address this supposed issue. It turns out all the capabilities in those products are needed by someone—maybe not us, but someone. They are there for a purpose. Maybe not the right purpose, but they didn’t get there by accident. Knowing up front what capabilities are needed for a product is not an accident, either. This is the role of capabilities-based planning. What capabilities do we need for the project to be successful?

Defining a capability creates the flexibility needed to ensure system responsiveness and sustainability in the presence of constant change.³ At the same time, we need to deliver tangible benefits to the user. These capabilities may include:

Agility. Adapting to emerging situations that had not been planned for or even foreseen.

Tailorability. Changing the behavior of the product or service to meet emerging needs.

Architecture. Measuring the coupling and cohesion (interrelationships) between the business processes that support agility and tailorability with the least amount of disruption to previously developed project outcomes.⁴

Project governance provides the guidance needed to institutionalize a capabilities-based approach. Project governance requires continued assessment and evolution in support of the tangible benefits:

Enforcement of rules and responsibilities on the organization and its members

Guidance of the flow of work to sustain the needed performance of the business or mission

Continuous improvement of the people, processes, and tools

Facilitation of transformation from the current state to some desired future state

The core concept of capabilities-based planning is its focus on the delivery of business or mission value, or “value-focused thinking,” which, in turn, is based on two methods for making decisions: the first focuses on competitive analysis of the various alternatives, and the second on attaining organizational values as the fundamental objective of any decision-making process.⁵

In order to describe each capability, assumptions must be made without any specific technical and operational information. To avoid unwelcome surprises, some form of assumptions-based planning is needed. This requires taking five actions:

1. Make operational plans about how we are going to use the capabilities that result from the project (“What would we do with the products or services if they showed up tomorrow and were free?”).

2. Describe plausible events—that is, the things we know have a chance of happening.

3. Identify the signposts for potential problems that can then be used to monitor the things that can go wrong with our project.

4. Discover shaping actions that shore up uncertain assumptions about the future. We can’t control the weather, but we can control whether we are going to eat outside or stay in.

5. Take hedging actions to better prepare for the possibility that an assumption will fail by thinking through plausible scenarios to test the assumptions. This what-if approach is at the core of good project risk management.⁶

Capabilities-based planning makes use of these assumption-development processes to describe system capabilities when there are no specific technical or operational requirements. These development processes allow project managers to do the following:

Discover what is not known by reaching a sufficient basic level of knowledge of the parameters of the problem.

Identify problems by understanding the current process, along with the people and technology involved.

The next step establishes boundaries and the elements of the solution. These are grouped into three types of principles:

1. Orientation principles align the development process on a sound theoretical basis using generally accepted practices in the areas of engineering, modeling, and acquisition. These principles include: Capability Thinking, Architecture Models, Evolutionary Development, and Deliverables-Centric Planning. When we think of capabilities, we can ask, “What do I need to get the job done?” “I need to process transactions for $0.07 each, rather than the current $0.11.” When thinking about architecture, an external framework is the starting point. “We must be SOA compliant for this project to be successful.” Evolutionary development establishes the sequence of capabilities to be delivered over time. “Enroll all members using the new system and process them using the legacy system. With them all enrolled, we can then migrate to the second phase of using a third–party processing system.” Deliverables-centric orientation is the basis of all project success. The customer bought the deliverable, not the work efforts—actually, not even the technology. The customer bought the ability to “do something.”

2. Communication principles enforce the standardization of vocabulary and structure of information to be exchanged within or outside the system. These include standardized formats and common terminology to describe the system capabilities. The semantics used to describe what “done” looks like need to be shared between the provider and the consumer. Without this commonality, it will be difficult to determine if the needed capabilities have actually been provided at the end of the project.

3. Collaboration principles enable active and timely participation of all stakeholders involved in the production of a capability. These include collaborative engineering and information sharing between the contributors of the system capability elements. Development of solution is a collaborative effort guided by the shared understanding of what “done” looks like. There must be information exchanged between the provider and the consumer to ensure that each is using the same units of measure. An Interface Control Document (ICO) is an example of this shared understanding. It states the protocols and format of data, processes, and outcomes on both sides of the interface.

Requirements Identify Technical and Operational Outcomes

Inadequate requirements engineering is a common problem in the development of any complex system.⁷ A “requirement” is an attribute of the resulting product or service. It is a statement of a capability or a quality needed to provide value to the buyer. Without proper requirements, neither the provider nor the customer can know what “done” looks like in any meaningful way. The result is confusion, rework, missing features, or less-than-acceptable outcomes. Although there are many resources that explain how to capture requirements, each requirement needs a home, a reason for existing. When a requirement is fulfilled, the outcome is a capability, which means the users can now do something with it. They can put it to work.

There are many issues associated with requirements engineering, including failure to define the scope of the system in terms of capabilities. Failure to foster understanding among the communities affected by the development of a given system often starts because the needs for these requirements are missing or not fully explained. These are elicitation issues. They occur before the requirements engineering process starts and are at the heart of poor systems requirements. The industry average investment in a requirements process is 2 to 3 percent of the total project cost.⁸ This investment is trivial compared to the risk of delivering a less than acceptable outcome from the project. The classic example is the enterprise IT project, where the users don’t actually know what they want the system to do. Instead, they have the developers start producing software, hoping to discover the final outcomes as they proceed. With a small investment for the total project, clarity can be produced to guide the development effort. We would never start building a custom kitchen remodel without some understanding of what “done” looks like.

This problem leads to the creation of poor requirements and burdens the development process. The system developed will later be judged unsatisfactory or unacceptable, as a result of high maintenance costs and frequent changes.⁹ By improving the process by which requirements are obtained, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system.

After requirements elicitation, requirements engineering is deconstructed into the activities of requirements elicitation, specification, and validation. Most of today’s requirements techniques and tools focus on specification (i.e., the way in which the requirements are described). The Five Principles and Practices of the Performance-Based Project Management approach concentrate on elicitation concerns, those problems with requirements engineering that are not adequately addressed by specification techniques. Cristel provides one elicitation methodology to handle these concerns: A conversation takes place between designers, customers, and implementers in which they pool their perspective expertise and viewpoints to resolve design issues.¹⁰ The details of this approach will be developed in Chapter 3.

When we get to Chapter 3’s requirements process, we will use these universal process steps:¹¹

1. Elicitation. Identify who the sources of information about the system are, and find out the requirements from them.

2. Analysis. Understand the requirements; look for where they overlap and where areas of conflict might exist.

3. Validation. Go back to the system stakeholders to determine if the requirements really do meet their needs.

4. Negotiation. Inevitably, stakeholders’ views will differ, and proposed requirements might conflict. Try to reconcile conflicting views and generate a consistent set of requirements.

5. Documentation. Write the requirements in a way that stakeholders and product developers can understand them.

6. Management. Control the inevitable changes to the requirements changes through a formal change control process, documenting the baseline requirements and all changes to this baseline.

Work Packages Produce Project Deliverables

Project success requires staying focused on separating the various system capabilities into clearly defined streams based on their function defined by the requirements elicitation process. This effort decouples the technical functionality from the system capabilities, increasing cohesion and reducing coupling between each stream.

This deconstruction process is almost never optimal the first time around. The false sense of urgency to deconstruct the system requirements into a work breakdown structure (WBS) will cause extra work later on. Investing in a carefully developed WBS will pay back later in the project by isolating the work processes into supporting value streams.

In the world of agile software development, the WBS may appear to be an odd artifact. In fact, agile methods employ WBSs as well. They are called storyboards, use cases, and other organizing paradigms. The key to all project success is to know the structure of the delivered capabilities, how the components of these capabilities interact with each other, and what the dependencies and the hierarchy of the components are. Without some form of product and service deconstruction, it is difficult to know what “done” looks like.

There is no set of instructions for how to do this. But starting the WBS in a graphical form, putting that diagram on the wall, and asking the coupling and cohesion questions about the terminal nodes in the WBS is one way. (An example of the terminal nodes can be found in Figure 4.3.) This “sticky notes on the wall” approach is found in many other project management processes, not just Agile.

The construction of the WBS and the resulting work packages starts with breaking down the requirements into collections of deliverables. Focusing on the deliverables is critical for the following reasons:

All resources—internal and external, their dependents, and any other items needed to produce the deliverables—are defined in the work packages. The work package manager is accountable for managing all of these resources.

The work packages that result from this deconstruction are the vehicles for producing the deliverables.

When these deliverables exist, they provide the capabilities the system needs to perform its function.

If resources are not controlled by the work package manager, the risk to the success of the deliverables is greatly increased:

Accountability is no longer traceable to a single person, violating the principles of the Responsibility Assignment Matrix (RAM) (as shown in Figure 4.3).

Performance reporting for physical percent complete is no longer represented by tangible items within the work package.

Each work package produces one deliverable. This deliverable may have a Technical Performance Measure (TPM) attached—a Measure of Performance (MoP) or Measure of Effectiveness (MoE). Measures of Performance characterize the physical and functional attributes relating to the operation of the system operation, measured or estimated under specific testing and/or operational environmental conditions. MoEs are operational measures closely related to the achievement of the mission or operational objective being evaluated, in its intended operational environment under a specified set of conditions. MoEs state how well the system achieves its intended purpose. The Technical Performance Measures connect the dots between cost, schedule, and the technical maturity of the deliverable.¹²

In the absence of Technical Performance Measures, the Performance Measurement Baseline lacks the ability to connect the physical percent complete with the increasing maturity of the product or service.

The Master Schedule Sequences the Outcomes of Work Packages

Arranging the work packages in a logical network is an iterative process. It should be obvious which major deliverables come first, second, and so on. Building an initial network, plotting that network on a big visible chart,¹³ hanging that chart on the wall, and standing in front of it with all the work package managers is part of developing a credible plan for the project.

The plan is the strategy for delivering the business capabilities the customer asked for. With a big visible chart, the strategy is able to be seen—or at least is more easily seen—than a list of work packages would be.¹⁴ The strategy for delivering the project can be mapped out in a wall-walk manner to make the connections obvious. The wall-walk is a process where sticky notes or any type of temporary documents are placed on a wall and participants “walk” these notes and talk about their contents and how that content describes the outcomes of the project. The project members then try to convince the other members that they have the needed information to start their work. This hands-on approach is much better than burying the descriptions of the project’s outcome in a project plan or spreadsheet. This process ensures that each project member has a clear and concise description of what he or she is to produce and what is to be received from the other members. This agreement on the exchange of information and the exchange of artifacts ensures that the proper order of work is established. (Chapter 4 will provide more detail on planning, scheduling, and budgeting this work.)

Creating the first cut of a credible plan and its schedule using the work packages is a hands-on process. It starts with six simple rules:

1. All relationships between WPs are “finish to start.” This initial arrangement provides visibility into which parts of the work are dependent on other parts of the work being completed. This, in turn, drives schedule compression. Non–finish-to-start relationships lead to partially complete work being used in future efforts, which results in “rework,” because the earlier work was incomplete.

2. There should be no “lead” or “lag” arrangements between WPs. These create hidden dependencies and hidden schedule compression, and produce partially complete work products for consumption that need to be updated when the work package is completed.

3. The only constraints on the network should be a must start on (MSO) for the start date and an as soon as possible (ASAP) for all other activities. Any other constraints create hidden dependencies. This may appear hard to do, but it is the basis for an “ideal” schedule. Other constraints may be added later, but only for necessary reasons to control the flow of work in the schedule. External dependencies are the primary reasons for these constraints. The arrival of material or waiting for the completion of an external activity are simple examples.

4. The flow of WPs should create a description of the increasing maturity of the products or services produced by the project, not just an account of which resources were consumed and what deliverables were produced. The description of maturity should be meaningful to the customer in terms of business capabilities or mission fulfillment attributes resulting from the completion of each WP. This maturity is measured by the ability to perform a capability. Throughput of a process can be a measure of maturity. The “preliminary” capability is for small batches of recycling containers from the neighborhood trash collection service. The final capability can be for the full-rate production of the batch processing of the entire city’s trash. As the processing plant “matures,” the process details can be worked out.

5. Describing the plan and schedule in these terms gives the customer insight into the actual progress of the project. Describing them in terms of consumption of resources, production of products, or passage of milestones is not meaningful to the customer.

6. Single point estimates of cost and schedule are meaningless without providing the range of values, the level of confidence in achieving each value, and an analysis of how these estimates will impact the credibility of the project being completed on time, on schedule, and with the planned technical performance.

These rules appear very detailed, but, in fact, they are only a hint of how detailed a project manager must be to produce a credible, ultimately successful, plan and schedule, and they are critical success factors for all projects. They must be addressed up front and throughout the project. The project manager must understand all the dependencies between work activities and must be able to foresee conflicts, roadblocks, and risks if there is any chance of completing on time and on budget.

Work Package Progress Measured as Physical Percent Complete

Measures of “progress to plan” can only be done with measures that describe tangible evidence of progress. Any other measure of progress cannot be connected to the delivery of business value to the customer. This is the basis of earned value, management agile software development methodologies, and the principles of capabilities-based planning.

At the work activity level, using the 0 percent/100 percent assessment is the best approach. Either we are done or we are not done. It’s as simple as that. When these work activities are collected in a work package, we can now measure the physical percent complete by summing the completeness of the work activities for that WP. The cumulative value of the physical percent complete of each activity is the indicator of how much progress is being made.

There is no need to ask people where they are in their plan. Simply ask, “What work have we accomplished against our planned work as of the status date?” In other words, “Did we do what we planned to do by a given date?” If not, then, “When will we actually do it?” It is the old cliché, “Plan the work and work the plan.” It might sound trite, but it is a critical success factor in any project management method.

There are eight simple steps for measuring progress to plan, using physical percent complete:

1. Use each work activity in the WP to provide some form of progress toward producing the deliverable.

2. Use this progress as an incremental measure of the overall progress of the WP.

3. Predefine how each work effort contributes to the overall progress of the WP.

4. Have the owner of the WP describe the incremental physical percent complete in terms of tangible evidence of progress to plan.

5. Ensure that what “done” looks like is defined in terms of the physical percent complete of the work package, Measures of Effectiveness (MoE), and Measures of Performance (MoP).

6. Capture this definition in the WP documentation.

7. Ask this question: How long are we willing to wait before we find out we are late?

8. Measure physical progress to plan before that period of performance arrives, leaving enough lead time so management corrections can be made to stay on cost and schedule, and meet technical performance requirements.

Work Authorization Assures Delivery as Planned

A work authorization system assures that the proper sequence of work is conveyed to those performing the work. We would not want to install the furniture before we installed the carpet in our new home. The same is true of software projects, building projects, or training projects. There is a natural sequence for doing the work that provides a logical progression and produces value for the project.

It is important for project managers to be aware of how they convey the work authorization to their staff. To ensure that spoken words are not misinterpreted, written directions provide this explicit guidance for each work package.

The work package can be anything that might need to be accomplished to produce a deliverable. By providing a written work authorization, those in project management can be assured that their wish to have the job done by the right people, at the correct time, and in the right order can be executed.

The project manager needs to be cautious when writing out the exact steps on the work authorization to prevent misunderstandings and mistakes along the line. For the work to be done correctly the first time, the manager must be able to communicate well. This applies to both the writing of the authorization and the oral answers to any questions that might arise. Proper direction given to staff in the work-authorization directive will ensure that the task is completed in the expected manner.

Controlling the sequence of work has measurable benefits for the project:

Executing the work packages in the agreed sequence ensures that the project will proceed as planned.

• This approach starts with a work authorization and control processes and requires the continual monitoring of late starts, late finishes, schedule margin erosion, and TPM compliance.

• The work authorization ensures that work is performed in the planned sequence, employing the planned programmatic risk reduction, to continuously increase the maturity of the product or service.

“Out of sequence work” creates programmatic and technical risks.

• It disrupts the measures of physical percent complete—work without a plan and a plan without the work hide project performance.

• It disrupts the strategy developed for sequencing work to increase the maturity of the product or service.

Produced Value Defines Project Progress

Measuring the consumption of budget against the production of value is the role of any Performance-Based Project Management system. In Chapter 5, the concept of Earned Value Management (EVM) is examined in more detail.

For now, it is important to know that there are seven principles of EVM that are applicable to all project performance measurement:

1. Plan the scope of all the work required for the project from inception to completion. This doesn’t mean “plan at the detailed level.” It means “have a plan,” know what capabilities are needed, and have a notion of how to deliver them.

2. Break down the project work scope into finite pieces that can be assigned to a responsible person or organization for control of technical, schedule, and cost objectives.

3. Integrate project work scope, schedule, and cost objectives into a Performance Measurement Baseline plan against which accomplishments may be measured. Control changes to this baseline.

4. Use actual costs incurred and recorded in accomplishing the work performed.

5. Objectively assess—using tangible evidence of physical percent complete—accomplishments at the work performance level.

6. Analyze significant variances from the plan and how these affect forecasts, and prepare an estimate of completion based on performance to date and work to be performed.

7. Use this performance information in the organization’s management processes.

Adjust Value with Technical Performance Measures

Technical Performance Measures are defined and evaluated to assess how well a system is achieving its performance requirements. A TPM tells us what the product or service should be doing when it is working correctly. It can be an attribute of the product—size, weight, speed, reliability—or it can be a measure of the business value—reduced cost, improved throughput, increased profit margin.

Typically, dozens of TPMs are defined for a system. Yet, although they generate useful information and data about a system’s performance, little is available in the project management community on how to integrate these measures into a meaningful assessment of the system’s overall technical and programmatic performance risk. The TPMs are connected to the deliverables from the project. The programmatic performance assesses the effectiveness of cost and schedule in producing those deliverables.

TPMs can be combined to measure and monitor the overall performance risk of a system by integrating individual TPMs in a way that produces an overall risk index.

The project manager must be cognizant of three basic project risk elements (baselines):

1. Cost

2. Schedule

3. Technical performance

Cost and schedule are tracked through cost and schedule control systems (earned value). Technical performance is tracked using the TPM system, which is the project manager’s early warning system when correlated to cost and schedule reports to provide the complete status of the project.

The TPM method selects technical performance parameters, assigning weights, linking to WBS, planning progress over time, getting data, evaluating variances, and taking corrective action as needed. Variances indicate the level of risk and detect new risks before their effects on cost/schedule are irrevocable.

The TPM approach involves:

Assessing technical characteristics of the system and identifying problems through tests/analyses

Surfacing inadequacies in time and dollars

Matching cost against schedule performance

Providing a basis for cost/schedule revisions

Facilitating the verification of results achieved against technical requirements and what remaining technical work can be accomplished within established budgets

Performance Feedback Adjusts Schedule and Resource Allocation

Project management performance measurements must integrate cost and schedule parameters with the assessment of technical outcomes in order to assess the future performance of the project and act as an early warning system in the event something is going wrong.

As far back as 1997, the discussion centered on integrating cost, schedule, and technical performance. Robust project performance management processes must provide technical performance measures and exit criteria for assessing technical maturity that are quantitatively linked to measures of cost and schedule.

These measures of TPM compliance adjust our measures of future performance and our estimates of the final cost and completion dates when there is less-than-planned-for technical performance, such as poor quality, missing scope, delayed scope, or combinations of these.

These TPMs tell us how well a system is achieving its performance requirements. Technical Performance Measurement uses actual or predicted values from engineering measurements, tests, experiments, or prototypes.

To provide feedback for adjusting the forecasted cost and schedule we need to:

Include systems engineering activities in the schedule and the Performance Measurement Baseline (PMB)

Establish thresholds or parameters for TPM in the project plan

Specify objective measures of progress as base measures for EVM for development maturity to date, product’s ability to satisfy requirements, and product metrics, including TPM achievement to date

Review the project’s plans, activities, work products, and PMB for consistency with the requirements and the changes made to the requirements baseline

Incorporate risk mitigation plans in the project plan, including changes to the PMB

Include quantified risk assessments in the estimate at completion (EAC), depending on the probability of risk occurrence and the impact on cost objectives

Past Performance Forecasts Future Performance

Employing measures of cost, schedule, and technical performance provides the project manager with data needed to take corrective actions. Learn from the past to correct the future. This is a critical role of the project manager. Two metrics are particularly useful in the management of any project, program, or portfolio of projects.¹⁵

The Cost Performance Index (CPI) is a reflection of a project’s cost efficiency. The CPI tells us how much physical work was accomplished, expressed as the budgeted value, against how much actual cost has been incurred to accomplish the performed work.

The question: Is the project staying on target, underrunning, or perhaps overrunning costs?

Perfect cost performance would be defined as CPI = 1.0: For every dollar we spend, we get an outcome worth one dollar. Sometimes we do better, sometimes worse. The CPI is an indicator of past cost performance. The second metric, To Complete Performance Index (TCPI), focuses on future performance.

The question: What will it take to meet the goals set by management? The TCPI works in conjunction with the CPI:

TCPI = Cost of the work remaining / Funds remaining

Looking Back

The ten drivers of project success form the basis of the Five Immutable Principles of project management and can be applied to every project in every business and technical domain.

They will be developed in detail in the coming chapters, but it is worth a quick review here, before moving on:

1. Do we know what “done” looks like?

2. Do we know how we are going to reach “done”?

3. Do we have all the resources needed to reach “done”?

4. What impediments are we going to encounter along the way and how are we going to handle them?

5. How are we going to measure progress in units of measure meaningful to the decision makers?

These Five Immutable Principles are applicable to every project in every business and technical domain. That is the definition of immutable—they never change and are universally applicable.

What’s Ahead?

In the coming chapters, we’ll examine how each of the Five Principles guides the application of the practices needed for project success and how each principle depends on the other four. We’ll also explore the five work processes needed to provide information to make decisions about the progress of any project.

These Five Immutable Principles, their practices, and the work processes will then be assembled into a Project Management Method, which, when applied, increases the probability of a project’s success. This is the result of simple attributes of Performance-Based Project Management that are not found in any other approach to managing projects:

A plan is defined that shows what capabilities are needed at what point in the project life cycle to produce continuous delivery of business value to the stakeholders. This plan shows:

• The “value flow” of delivered capabilities

• The evaluation points to ensure progress is being made as planned in the delivery of this value

Work is performed in the proper sequence to ensure that this value is actually delivered.

• The capacity for work and the sequence of that work is managed to produce benefits with maximum efficiency and minimum variance.

Measures of progress to plan in units of physical percent complete.

• Tangible evidence of “working products” or “acceptable service” must be produced at planned intervals, short enough to take corrective actions when variances appear.

Risks are “managed” using standard approaches.

• All numbers—cost, schedule, technical performance—are considered random numbers with known variance.

• Managing in the presence of the variances is the foundation of any credible risk management plan.