CHAPTER 6

Tailoring the Principles and Practices for Project Success

Now that the principles are in place and the processes to implement those practices have been defined, we can examine the details of these practices to determine how to successfully manage different types of projects. In the last chapter, we looked at three sample projects; now we need to go deeper to gain an understanding of why certain things were done and others were skipped over. We need to learn how we can adapt the practices to various kinds of projects.

For a quick review, let’s look at the three elements of Performance-Based Project Management needed for project success:

1. Principles. We need to know what a project’s final deliverables look like through the eyes of the customer or end user. We need to know what products or services we will be providing and how they will be used to fulfill a mission or business case. We need to understand how we will recognize these deliverables when they arrive and how we can we reduce any risks to the successful completion of the project.

2. Practices. Once we understand the capabilities the project will deliver, we need to know what technical and operational requirements are needed to enable these capabilities, how the project will be staffed, what the impediments to progress are, and how we will measure progress to our plan.

3. Processes. We need a set of governing processes to guide us in the work of managing the project. This includes organizing the project; planning, budgeting, and scheduling the work; accounting for the money and time required for that work; analyzing the variances that are part of the normal project processes; and maintaining and managing the changes to our plans, budgets, or deliverables.

These principles, practices, and processes are essential to the success of any project, no matter the domain. But the details of each of these can be applied in a graded manner to the project.

Tailoring the Practices to Fit the Project

It’s time now to address the practical issue that one-size-does-not-fit-all project management situations. We need a way to tailor the elements of Performance-Based Project Management to fit the needs of the project and its participants. We cannot ignore or replace any of these elements because they are all needed for project success, but we need to recognize that the “fidelity” of the details may be different for different projects, domains, and contexts within each domain. We need a mechanism to distinguish between the levels of management rigor to be applied to various projects.

The principles should be obvious to anyone working on a project: We need to know what “done” looks like, how we are going to get there, what we need to reach our goal, what problems we are going to encounter, and how we are going to measure progress to our plan. The processes are straightforward as well, but the levels of detail can vary.

Let’s focus first on tailoring the practices to the project. In the previous chapters, we developed the elements of the principles, practices, and processes, but let’s summarize them here in preparation for the tailoring activities. We will then look at each practice and decide how to tailor it for three classes of projects:

1. Identify the needed system capabilities—what will we do with the results of the project in our business?

2. Establish the requirements baseline—what technical and operational requirements are needed to deliver the needed capabilities?

3. Establish the Performance Measurement Baseline—show the sequence of work and the cost of that work to produce the technical and operational products that fulfill the needed capabilities.

4. Execute this Performance Measurement Baseline—perform the work in the planned sequence to deliver the needed capabilities to the customer.

5. Performance Continuous Risk Management—during the execution of each of the four practices above, manage the risks that will inhibit their success.

Figures 6.1(a) and 6.1(b) contain the details of the first four practices. These figures can be used as a checklist to ensure that practices are being properly applied.

FIGURE 6.1(a) Activities needed to deliver capabilities and requirements baseline.

Define Capabilities as Operational Concepts

Partition system capabilities into classes of service within operational scenarios or use cases.

Connect capabilities to system requirements in some traceable form to ensure that no capabilities are implemented by a requirement.

Define Measures of Effectiveness (MoE) for each capability in units meaningful to the decision makers.

Define through the master schedule the achievement of technical performance that fulfills each capability.

Define Operational Concepts with Scenarios or Use Cases

Define scenarios for each system capability to confirm the business case is being met or the mission requirements are being fulfilled.

Connect these scenarios to a map of how value is being delivered by the project.

Assess value flow through the map for each needed capability.

Identify capability mismatches and make corrections to improve overall value flow.

Assess Needs, Cost, and Risk of the Capability Simultaneously

Assign costs to each system element using a value process model. Ensure that risk, probabilistic cost, and benefit performance attributes are defined.

Use cost, schedule, and technical performance probabilistic models to forecast potential risks to program performance.

Define Explicit, Balanced, and Feasible Alternatives

Make tradeoffs that connect cost, schedule, and technical performance in a single “trade space” model.

Measures of Effectiveness and Measures of Performance are the raw materials for these tradeoffs.

Perform Fact-Finding

Produce an overall statement of the problem in the operational context.

Develop the overall operational and technical objectives of the target system through Measures of Performance (MoP) for the requirements.

Define the boundaries and interfaces of the target system.

Gather and Classify the Requirements

Gather required operational capabilities; functional, nonfunctional, and environmental requirements; and design constraints.

Build a top-down capabilities and functional deconstruction of the requirements in a flow-down tree using a requirements tool.

Evaluate and Rationalize Requirements

Answer the question “Why do we need this?” in terms of operational benefits.

Build a cost/benefit model using probabilistic assessments of all variables and dependencies.

For technical requirements, perform a risk assessment of the cost and schedule.

Prioritize Requirements

Determine the criticality of the functions to the system’s mission.

Determine tradeoff relations for all requirements to be used when option decisions are made.

For technical items, prioritize the costs and dependencies.

Integrate and Validate Requirements

Address completeness of requirements by removing all TBD items.

Validate that requirements agree and are traceable to capabilities, goals, and the mission.

Resolve any requirement inconsistencies and conflicts.

FIGURE 6.1(b) Activities for developing and executing the Performance Measurement Baseline.

Deconstruct Requirements into Work Packages and Planning Packages.

Deconstruct the program scope into a product based work breakdown structure (WBS).

Deconstruct the WBS into work packages describing the production of all deliverables and processes traceable to the requirements.

Assign Accountability for the Deliverables from Each Work Package

Assign accountability for work packages for the management of resource allocation, cost baseline, and technical delivery to a named owner.

Arrange Work Packages in a Logical Order

Arrange work packages in a network with defined deliverables, milestones, internal and external dependencies, appropriate schedule, and cost margin.

Develop the Budgeted Cost for Work Scheduled (BCWS) for Each Work Package and Planning Package

Develop a time-phased Budgeted Cost for Work Scheduled (BCWS) for labor and material costs in each work package.

Develop a time-phased Budgeted Cost for Work Scheduled (BCWS) for the program as a whole.

Ensure that proper resource allocations can be met and budget profiles match expectations of the program sponsor.

Assign Measures of Performance (MoP), Key Performance Parameters (KPP), and Technical Performance Measures (TPM)

Assign an objective Measure of Performance (MoP) for each critical work package’s deliverables.

Trace critical deliverables to the Measure of Effectiveness (MoE) defined in the capabilities baseline.

Summarize these Measures of Performance (MoP) and Measures of Effectiveness (MoE) for the program as a whole.

Assign measures of physical percent complete for each work package.

Assign measures of physical percent complete for the program as a whole.

Set the Performance Measurement Baseline (PMB)

Establish a Performance Measurement Baseline (PMB) to forecast work package and project ongoing and completion cost and schedule metrics.

Perform Authorized Work in the Planned Sequence

Using the work package sequencing, release work to be performed as planned. With the RACI-based RAM, the accountable delivery manager guides the development of the products or services for each work package.

Accumulate and Report Work Package Physical Performance

Using physical percent complete or apportioned milestones, capture the measures of “progress to plan” for each work package.

Report the physical percent complete in a centralized system for each work package and the program as a whole.

Analyze Work Package Performance

Compare the actual percent complete against the planned percent complete for each period of performance.

Construct cost and schedule performance indices from this information and the physical percent complete measures.

Take Corrective Management Action for Any Variance in Work Package Performance

With the cost and schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance.

Take management actions for any work packages not performing as planned.

Maintain Performance Measurement Baseline’s Integrity

Record past performance based on work package completion criteria.

Record previous future performance estimates in a historical database.

Forecast future performance against the Performance Measurement Baseline.

Report the future performance estimate to the program stakeholders.

Levels of Implementation

There is a long history of tailoring processes and practices to suit the needs of the project.¹ The notion that we can select a set of practices and processes and apply them to everything that comes our way is simply poor management. For all projects, one approach to categorizing the levels of tailoring is to look at the components of the project:

Business Risk. The value at risk might affect how the practices are applied.

Project Requirements. These are the “ilities” of the project, like reliability, maintainability, operability, interfaceability, sustain-ability, compatibilities, and others are aspects of complexity, and will affect how the practices are tailored.

Approach to Execution. The procurement strategy, the complexity of the deliverables, the control of cost, schedule, and technical deliverables, resource planning and management, the physical sites, and other tangible differences affect the needed outcomes practices, and will affect how the practices are applied.

We must understand not only the practices and processes but also how they effect the success of the project. Tailoring provides the ability to integrate, consolidate, incorporate, and streamline the practices and processes. This results in streamlining to the maximum extent possible, consistent with the principles of the project management activities, to deliver the needed capabilities most efficiently and effectively. To determine the level of tailoring, the project manager must decide how much practice and process is enough for the project.

The tailoring process must ensure that:

The practices and processes deliver the project in the shortest practical time

Risk is balanced against technical and operational outcomes

Adequate information is provided to the decision makers

Tailoring of the Performance-Based Project Management practices and processes has three levels:

1. Level 1: Minimal implementation of the practices. The project is small, the desired outcomes are known, the users are identified, and they agree on the outcomes. The technology or processes are known to work. The “value at risk” is low. There is high confidence in the budget and schedule. This type of project is common in all business domains; for example, it is the type of project that adds some feature to an existing system; it upgrades or updates an existing product to service; it installs an expanded service or capability, or performs some analysis and produces a report in an area that is understood.

2. Level 2: Moderate implementation of the practices. The project is developing something new within a known technical or operational domain. Teams of people who have the right skills and experience but may have not worked with each other before create issues that go beyond just the technical risks.

3. Level 3: Major implementation of the practices. When the project is complex and risky, we must apply all of the elements of each practice to the project.

Level 1: Minimal Implementation

For minimal implementation projects, we will use a lightweight communication process as a starting point. Minimal implementation affects each of the practices.

Define Capabilities

We can define the capabilities through operational concepts by constructing a short narrative of what the system is supposed to do. This can be treated as an elevator pitch, with short, to-the-point descriptions that define the outcomes and benefits of each capability. These capabilities can easily be described with nouns and verbs identifying the “what” and the “how” of the capability. We can assess the needs, costs, and risks of each capability by making a list of each capability and assigning the costs and risk to each element in the list. Once we have this information, we can discover the alternatives. Any redundancies in the capabilities will become clear when we examine the capabilities side-by-side, and we can remove them by combining or eliminating the capability.

Establish the Requirements Baseline

A simple list of the requirements will work here. This list can be a few sentences for each requirement, with each one connected to a capability to ensure that the reader understands that both—not just the requirement, but also the capability that will support the business strategy—are needed. Once the list of requirements is complete, we can start to partition them into classes for further assessment by the stakeholders, who can confirm the need, see the connection to the capability, and agree that each requirement should move forward to the planning, scheduling, and budgeting step. For example there may be technical performance requirements—throughput, size, weight, power capacity. Or human interface requirements—fit to a person’s hand, desirable colors for a car, or readability of text size on a display. These classes of requirements can then be grouped and assessed together for impacts on cost, schedule, and risk.

The activities for the minimal requirements implementation are:

Prioritize a list of requirements containing a short narrative with the project’s participants. This should be done in a face-to-face manner.

Name the person accountable for each requirement and ensure that there are sufficient resources to deliver the solution to the requirement.

Connect a capability to the requirement that it supports through the list of requirements, so the project participants can confirm that all the capabilities are being developed through the requirements.

Establish the Performance Measurement Baseline

The Performance Measurement Baseline can be a simple cost and schedule worksheet describing what work will be performed, the budget for that work, and the name of the person accountable for producing the outcomes of the work.

The activities for the minimal PMB develop are:

List the outcomes of the project.

Assign a person responsible for producing those outcomes.

Create a schedule showing when the outcomes will be delivered. This schedule can be notional, meaning informal. No need to put together a fancy schedule using a scheduling tool. A drawing on the whiteboard or sticky notes on the wall will do—anything that shows the order of the work and the order of the outcomes.

Create a top-level budget for all the work to be performed.

Create a defined way of measuring progress to plan. The simplest is to count the features, requirements, and capabilities and use percent complete.

Set the baseline for the project so everyone knows what “done” looks like for the planned work. Maintain this baseline by updating the whiteboard or sticky notes and recording the current date somewhere visible.

Execute the Performance Measurement Baseline

With the capabilities understood, the requirements defined for those capabilities, the schedule in place, the people assigned, and the budget committed, it is time to start executing the project. The project participants should know what they are assigned to do, so executing the work means doing the planned work in the planned order.

The activities for the minimal PMB execution are:

Look at the sequence of the planned work and do it. In the agile world, or in this minimal implementation where sticky notes are used, take the note from the planned column and move it to the “doing work” column. It’s really that easy.

With the work under way, record the actual costs. This includes labor and materials. This can be done using a simple spreadsheet, but it is important to capture these costs in order to tell if we’re on budget or not.

For the work performed at the cost absorbed, look at the outcomes and confirm they meet the agreed-upon specifications. The simplest way for this to happen is to ask the user of the features, products, or services if they agree we are “done.”

When there are gaps, bring everyone together and determine the next steps to put things right.

The project manager is accountable for the overall performance of the project, and, where implementation is minimal, the project manager is likely directly engaged in hands-on oversight of the project’s activities.

Perform Continuous Risk Management

Risks are prevalent in all projects, even in small projects. Managing risk is the primary role of project management. No matter the size or complexity of the project, we need to address risks up front and apply Continuous Risk Management throughout the project’s life cycle. Remember that risk comes from uncertainty, so start by answering the question, “What are we uncertain about?” Write the answers down and post them on the wall. Our five steps in Continuous Risk Management for the minimal application are:

1. Identify. Make a list, post it on the wall, have the team stand in front of this list and confirm these are the things that need to be addressed.

2. Analyze. For each of the risks, determine the impact on the project and the overall project outcome and devise a handling strategy.

3. Plan. Make a plan for how to handle the risk. This means discussing with the team what to do about the technical, cost, and schedule impacts should the risk occur. Or better, what actions can be taken to reduce the uncertainty associated with the risk and/or to make it go away.

4. Track. Report on the progress of the risk-handling activities periodically in the same way you report on the progress of the features and functions being developed. This periodic risk assessment cycle is why it is called “Continuous” Risk Management.

5. Control. As the risks become issues, or the risk-reduction activities don’t produce the desired results, deal with them as they occur. Don’t wait. As Colin Powell and others have said, “Bad news is not like wine. It doesn’t improve with age.”

Level 2: Moderate Implementation

Projects with moderate implementation needs usually have a project team, a customer, and a written set of needs and requirements. The complexity of such a project can involve something new, something created from an existing system, or a different business domain, or different technology, where what to do is not as obvious as it is in a project requiring minimal implementation. It involves more communication and more risks, and it is more difficult to discover what “done” looks like. It may include distributed teams and customers who may not be in the same room or as easily accessible.

Define Capabilities

We need to define the capabilities in a form that matches the business case and the vocabulary of the business or mission sponsors. This starts with Concept of Operations (ConOps), a Statement of Objectives (SOO), or a Statement of Work (SOW) that uses the language of the buyer. These documents, whichever one is chosen, provide traceability of the project’s needs in some hierarchical structure so the user of the resulting system can see how the capabilities are related to each other. This can be done using a “tree” structure, where each top-level capability has “children” (the lower-level capabilities) that support it. This approach is the foundation for a more formal requirements elicitation process, as we’ll see next. The key here is to provide a narrative that everyone can agree on and understand. This narrative describes what “done” looks like in units of measure meaningful to the decision makers.

Establish the Requirements Baseline

Requirements at the moderate level need to be stated in more detail than those at a minimal level. This means we need measures of performance that can be assessed during development and confirmed by the users when the system is delivered. A simple form of “requirements management” can be used. This can be a list, with the attributes of the requirements. It needs to include the priorities, of course, but more important, this list needs confirmable connection to the capabilities. The confirmation process ensures that there is no redundancy, duplication, or gaps and that each requirement is stand-alone. The fancy term for this is Mutually Exclusive and Collectively Exhaustive (MECE).² This means there are no overlaps and no gaps in the requirements. No overlaps means the requirements are grouped so that there is no “double counting” of the requirement. No gaps means all the requirements taken together cover all the possible options for the project’s capabilities. This helps ensure that nothing was overlooked when developing the requirements from the list of capabilities.

The activities for moderate implementation of the requirements baseline include the following:

Manage the requirements in a way that connects the dots between the capabilities of the technical and operational requirements.

Make further partitions on the list of requirements to reveal how they are coupled and how cohesive they are.

Capture the requirements and put them where everyone can look at them and comment on them. You can use simple notes on the wall, a spreadsheet, or a database.

Assign a business value to each requirement. This will help answer the question, “Why do we need this?” and allow us to assess the impact of the requirement if we decide not to deliver it.

Connect the requirements to an assessment of their cost to develop and the schedule for that development. We can’t make a credible assessment of a requirement’s worth without knowing its cost and schedule impact on the project.

Establish the Performance Measurement Baseline

With the capabilities defined and the requirements that will implement those capabilities identified, we need to develop the schedule and cost for the work needed to produce the outcomes from the project. We’ve developed the connections between capabilities and the requirements. In moderate implementation, we will use the notion of a work package. These are the activities for the moderate implementation needed to complete the Performance Measurement Baseline:

Deconstruct the work into work packages, each of which produces only a single tangible outcome with a measure of physical percent complete attached to it. If this measure is a performance measure, it needs to be a technical performance measure. How fast, how high, how reliable, how much does it weigh, and how much capacity are all measures of performance. Define something that the customer can look at and say, “Yep, that’s what I wanted.”

Build a formal Responsibility Assignment Matrix (RAM) for the major deliverables of the project, which clearly and concisely states “who” is accountable for producing the outcomes. Although the name of the matrix includes the word responsible, the matrix also includes accountable, consulted, and informed, which together with responsible are known as RACI.³ Make the connection to the person accountable and the other three will follow.

Arrange the work packages in the order that produces the best value to the customers—the order that allows the customers to receive the needed capabilities in the order of priority, so they can put these capabilities to work. The customer gets to say what this order is, not the project team. There are constraints, of course, with the physical limitations. No installing the carpet before the painting is done. But the customers have the final say, since it is their money.

Assign the budget for the total project to the individual accountable for performing the work using your RAM. This moves the accountability down from the project manager to those actually performing the work. They should be able to determine how to best spend this budget. Without this transfer, those doing the work become simply labor.

Measure the performance of each work package. Since the work package has a single outcome, we can assign some tangible measure of compliance to the requirement and its support of the capability. Write this down, use it in the conversations with the person accountable, and always use it as the basis for measuring progress toward “done.” The passage of time and consumption of time and money is never a measure of progress.

“Baseline” this information. Do this once you collect the work packages, the requirements, who is accountable for delivering the requirements, the sequence of the work packages, and the assigned budget for each work package. The primary purpose for baselining this—or anything, for that matter—is that we can’t manage a project without knowing the variances in our performance. We can’t determine variances if we don’t have something to compare our current status to, and that is the baseline.

Execute the Performance Measurement Baseline

Now that we have the work packages, the assigned people, a budget, and a schedule, and we know what “done” looks like for each outcome of the project in units meaningful to the decision makers, it is time to actually do the work.

Albert Einstein once asked, “What is the purpose of time?” The answer is, “Time keeps everything from happening at once.” The order of execution is defined in the Integrated Master Schedule (IMS). It is called “integrated” because it contains everything we need to manage the project—cost, schedule, assigned resources, descriptions of the outcomes, and measures of performance. It is a single place to look to see what “done” looks like.

Executing the Performance Measurement Baseline means:

Performing the authorized work in the planned order. When there is a need to perform the work out of order, assess the impact on the overall project’s cost and schedule.

Maintaining the budget performance to plan at the work package (WP) level. Keeping on budget at the lowest level of the project prevents the accumulation of poor budget performance from leaking into other work packages.

Examining the cost and schedule performance at the WP level. By focusing your management efforts lower down in the project plan, you can also prevent leakage into other portions of the projects. Also, focusing on the work efforts that produce the tangible outcomes provides insight into what is actually happening rather than just a summary of performance that many times hides the details.

Taking managerial action at the WP level to correct cost, schedule, and technical performance issues before they leak into other parts of the project. A phrase to remember is “keep it GREEN.” That way you’ll never have a RED and rarely a YELLOW condition.

Maintaining the overall cost and performance schedule for which the project manager is accountable. The WP managers are accountable for their individual work packages. This relationship between the project manager and the work package managers separates the concerns of the project’s participants.⁴

Perform Continuous Risk Management

Like our minimal project, risk is present here as well—only more so. The same five steps for managing this risk are applied:

1. Identify. Develop a list of risks at the WP level and review it during the periodic project performance meetings. Focus at the WP level, so coupling can be minimized and cohesion maximized⁵ The assignment of risk to the work package starts at the project level with the work breakdown structure (WBS). The terminal nodes of the WBS are usually the work packages performing the work, so this is a natural process of “flowing down” risk to the location of the work.

2. Analyze. Determine the impact of each risk on the outcome at the WP level and provide one of the four handling strategies: (1) Risk Avoidance, which includes not performing an activity that could carry risk; (2) Risk Reduction, which involves reducing the severity of the loss or the likelihood of the loss from occurring; (3) Sharing, which involves sharing with another party the burden of loss or the benefit of gain that results from a risk, and the measures to reduce a risk; and (4) Retention, which involves accepting the loss or benefit of a risk when it occurs.

3. Plan. The project manager guides the risk-handling processes using the activities illustrated in Figure 3.3.

4. Track. Tracking these processes can be achieved by monitoring the residual risk to determine the potential impact on the project. As the risk-handling processes are executed, the risk should be reduced and the residual risk reduced as well. Once this residual risk reaches some agreed-on level, the risk can be considered “under control.” The actual measurement is highly project dependent, so continuous review of the risk, its reduction, and the remaining risk value is part of the periodic conversation with the customer.

5. Control. The risks can be controlled by performing the handling processes to address the emerging risk impact and the resulting residual risk.

Level 3: Major Implementation

In Level 3 projects, we have more at risk, more complexity, more technology, more of everything. Level 3 projects require more formality. It is likely many of the participants in the project are not directly accessible to the project team. In the modern enterprise, locations may be spread around the world. Also, people working in these large and distributed organizations have day jobs and cannot be easily dedicated to the project or easily respond to a set of questions. The first solution to this situation—it can’t be a problem, since that is the way things work—is to manage the project through a set of formal process and practices, based on documentation. This documentation-centric project management paradigm is our “major” project management approach.

Define Capabilities

We can now apply more formal capabilities development processes. Capabilities start with the mission level analysis of what “done” looks like. These capabilities needed to be developed through a formal process shown in Figure 6.2. This process starts with the needs of the customer. The priorities of these needs are documented through a selection process and scenarios describing the capabilities. The capabilities are partitioned into classes—technology, operations, customer facing, internal, maintenance, and so on—so we can sort them out later. The future environment is added to ensure that we are not building an “instant legacy” system. The capabilities are assembled into a capabilities goal.

The operational concepts described through scenarios or use cases provide insight into the assessment of these concepts compared to the current planned capabilities. Any mismatches are revealed so they can be closed. From this process, we are able to define the “solution space” for our capabilities, and with it we can start asking questions about the return on our investment in the capabilities—when we earn back our money if we possess this capability. This can be answered using a balancing process among our resources, the mission or business case priorities, and the “affordability” plan for producing the capability.

Establish the Requirements Baseline

In large, complex systems, there are two fundamental classes of requirements—process performance requirements and product performance requirements. Figure 6.3 shows how these are related. Our requirements elicitation process must separate these if it is to have any integrity. Mixing them creates confusion about what is important for products and what is important for processes.

FIGURE 6.2 Formal process for identifying capabilities.

FIGURE 6.3 Process and product performance requirements.

Process performance requirements define what the system must do when it is complete and how well it must do those things from the point of view of the customer’s business or mission needs.

Product performance requirements define how the system must behave at the product level, while fulfilling the process performance requirements.

Establish the Performance Measurement Baseline

With the process and product requirements in place, we can start to build the Performance Measurement Baseline. As shown in Figure 6.4, the PMB has three baselines:

The Technical Performance Baseline is the requirements flow-down and traceability map for each deliverable in the program. A critical performance measure of the Technical Performance Baseline is the stability of requirements. The expected technical achievement for the actual progress is compared using periodic measurements or test starts against the Technical Performance Baseline. An important function of the Technical Performance Baseline is to define the units of measurement for each deliverable in order to define what “done” looks like at each incremental assessment of maturity.

The Schedule Performance Baseline is the sequence of work packages and planning packages that produce the products or services to be generated by the project.

The Cost Performance Baseline is the “authorized time–phased budget used to measure, monitor, and control overall cost performance on the program.” This budget (BCWS) is held in the control accounts, the work packages and planning packages owned by the work package managers.

FIGURE 6.4 The Performance Measurement Baseline has three baselines.

Execute the Performance Measurement Baseline

With the baseline established, we now need to execute it in a manner that increases the probability of project success. There are five steps in this execution process:

1. Authorize and perform the work according to the plan described in the network of work packages held in a scheduling tool. The formality of using a scheduling tool provides both control and visibility for managing the authorized work. The schedule shows when work is planned to start and complete. The project manager can use this to confirm work is being performed in the agreed order.

2. Accumulate and report performance data about cost and physical percent complete for the deliverables from the work packages.

3. Analyze the performance data derived from the performance metrics and make any adjustments to the network of work packages.

4. Take management actions for any variances to ensure on-time, on-budget, and on-specification of all deliverables produced by the work packages.

5. Maintain the Performance Management Baseline throughout the program’s duration for all earned value parameters.

These five steps are repeated periodically throughout the life of the project. They are the business rhythm of the project management process.

Perform Continuous Risk Management

Our Continuous Risk Management process for the major implementation uses the same framework as the other two implementations. This is shown in more detail in Figure 6.5. These processes are applied in greater detail in the major implementation than in the others, but we still must identify, analyze, plan, track, and control the risks as well as communicate everything we are doing about risk management to all the stakeholders.

FIGURE 6.5 Continuous Risk Management process.

Looking Back

With the three tailored project paradigms, we can see the principles are always the same, the practices are adjusted to provide the appropriate level of detail needed to manage the project, and the processes are tailored to fit the needs of the project’s planning, cost, resource management, reporting, and risk management needs. Figures 6.2 through 6.5 summarize the practices of Performance-Based Project Management. These practices can be tailored in a variety of ways but must always adhere to the principles and processes. Tailoring the practices starts with the question, “What is the value at risk?” The answer to this will lead you to consider how much detail to apply. If the value at risk is small, then tailor the practices in a small way. If the value at risk is large, then take appropriate actions to ensure that value is protected with the proper practice implementation.

What’s Ahead?

In Chapter 7, we will see what elements need to be in place for Performance-Based Project Management to succeed. Like the tailored practices, these components can be tailored, but at minimum they will include:

The Statement of Work

The Integrated Master Schedule

The Risk Management Plan

A staffing plan

A testing plan

A delivery plan