CHAPTER 4

The Five Governing Processes of Project Management

With the Five Principles and Five Practices under our belts, we are almost ready to start managing projects. First, we need the process management framework to help us apply these principles and practices. To be useful, this framework has to be general purpose; that is, it must be applicable to any type of project in any domain. We approach this process framework through project governance,¹ which is the mechanism that defines the decision rights for the project and determines how those decisions are made using the principles and practices. Decision rights set the “rules” for how choices pertaining to planning, developing, and executing the project are made by the project’s participants. Once the project is initiated, capabilities, requirements, planning, budget, control, and management all create situations in which someone has to decide. The decision rights process is the mechanism for making those decisions. In the absence of decision rights, the project participants have few mechanisms for resolving the conflicts that normally arise.

Project governance is concerned with five areas: Business success, customer impact, team impact, project efficiency, and preparation for the future² are critical factors in the success of all projects. While the principles and practices are necessary for project success, we also need processes to guide us in how to apply them. Governance tells us what processes, principles, and practices are needed and how they are to be implemented within a process framework. Project governance tells us how to make decisions, including how to decide what capabilities are needed at the start of the project. These decisions also tell us how to determine what requirements are appropriate for fulfilling the needed business capabilities, how to ascertain which risks are applicable to what parts of the project and how to handle these risks, and in what order the functionality of the project should be delivered to meet the business needs. Project governance fills the gap between the business users, who are the recipients, and the producers, who are the creators, of the project’s capabilities and requirements.³

Implementing the Five Processes

In traditional project management, the white space between the project’s technology development activities and the project’s business processes, which use this technology, is often missing. This white space exists only when gaps are created between the project mission, the strategy that fulfills this mission, the project execution, and the project’s delivery of value to the stakeholders. When there is white space in the project, there is no clear connection between the mission of the project and the technical or operational solutions that are supposed to deliver value to the business. There is no “line of sight” visibility from the need to the solution. When this happens, the gaps are many times filled in by unneeded or even undesired features.

Alignment gaps appear when business investments in the project are not traceable to the business strategy. An alignment gap appears when there is no connection between behavior of the system and the business policies that guide the system. The users of the system don’t know “why” they are doing what they are doing. To close these gaps and deliver the business capabilities we need to identify what “done” looks like. Execution gaps appear when those tasked with delivering products and services do not have a clear “line of sight” to the business strategy. To close these gaps, we need to identify the needed capabilities, the technical and operational requirements, the Performance Measurement Baseline, and the risk-handling strategies we are going to apply to the project. In other words, the gaps are closed using the principles, practices, and processes of Performance-Based Project Management, which are illustrated in Figure 4.1.

As project managers, we are technocrats managing the construction of products or the delivery of services. Our connection to the business world usually “flows down” through documents in the form of specifications or Statements of Work. If we think of the Five Principles and Five Practices as the bricks and mortar of the project, it becomes obvious that we need one more thing before we can proceed. Using our principles and practices, we need a set of rules to guide the project architecture—these rules are called governance,⁴ and they apply to five areas: business success, customer impact, team impact, project efficiency, and preparation for the future. Together, they connect the principles, practices, and processes. Their relationship is illustrated in Figure 4.2. We will not further discuss the governance areas here, because they are outside the domain of this book, but we will use them to tie the principles, practices, and processes together to form the basis of Performance-Based Project Management.⁵

FIGURE 4.1 The gaps between each process.

FIGURE 4.2 Governance, principles, practices, and processes are required for success.

Deploying the Five Processes

We are now ready to implement the five processes needed to increase the probability of project success:

1. Organize the project. Define the work, determine who is going to do the work, and document these in some manner for others to see. The result is a work breakdown structure (WBS) and an organizational breakdown structure (OBS), which describe the relationships among the participants in the project—the engineers, managers, and supervisors—and the roles they play on the project. The OBS is the “roster” of participants on the project and their individual capabilities. The intersection of the WBS and OBS defines the person accountable for delivering project outcomes. This can be a single individual or several individuals, accountable to each other and to the project manager.

2. Plan, schedule, and budget. Plan the order of the deliverables for the project, schedule the work needed to produce those deliverables, and develop the budget for the work. These three items are the least amount of information needed to manage the project. Anything less lowers the probability of project success.

3. Execute project accounting. Capture the actual costs of doing the planned work and compare these costs to the budgeted costs. This information and the measures of physical percent complete are used to assess the performance of the project and identify corrective actions needed to keep on schedule, on budget, and in technical compliance with the planned outcomes that provide the needed capabilities for the customer, while the technical and operational requirements are being implemented.

4. Execute project performance analysis. With the project plan and the actual work on the project, we can now assess cost and schedule performance and technical outcomes. This analysis allows us to determine variances, so that we can take corrective action to keep the project going as planned.

5. Record revisions and maintain data. When there are changes to cost, schedule, capabilities, and technical performance requirements, we must record these changes so we don’t forget what changes we made and why we made them.

With these five processes we can assemble a project management method that will increase the probability of success of projects in a wide variety of business and technical domains.

Organize the Project

“Projects are performed by people, constrained by limited resources and have to be planned, executed, and controlled.”⁶ Projects are executed by people, against a plan for the work to be performed, to produce outcomes implemented by the deliverables, using the tools and processes to manage and control the project outcomes. We need to know how the elements of the project are organized. Who’s in charge? Who is assigned to what work? What resources are available to the project for performing the work? What skills are needed to perform this work? What is being produced by these work efforts? How these products or services related to each other? All these questions are answered using the organizing processes that follow.

For project success, the participants need a mutual understanding of the answers to each of these questions. The answer to, “What are we delivering to the customer?” is provided by the work breakdown structure. The answer to, “Who is doing the work that delivers the outcomes from each element of the WBS?” is provided by the organizational breakdown structure. Figure 4.3 illustrates what the answers to the “what” questions for a hypothetical kitchen renovation might be. The answers to the “who” questions for this renovation are contained in the OBS section of Figure 4.4. We will use this WBS and OBS, along with the intersections that create the work packages, in the coming chapters, along with other examples, to show how to apply the principles, practices, and processes.

FIGURE 4.3 Work breakdown structure for kitchen renovation.

FIGURE 4.4 People do the work that delivers the outcomes.

Define the Deliverable Outcomes

All work breakdown structures are not alike.⁷ It can be a formal WBS, such as those found in construction⁸ and defense programs.⁹ Or it can be a less formal deconstruction of the work by simply listing the outcomes of the project on a white board in your office. The PMBOK® Guide says the WBS is “a deliverable-oriented hierarchical deconstruction of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.”¹⁰ In the agile paradigm, each user story represents work that produces a deconstruction. Like formal approaches to the WBS, Agile organizes project outcomes around features and functions that result from the work efforts. No matter the domain, complexity of the problem, or the method for developing products, some type of deconstruction of the deliverables is mandatory. Without this deconstruction, there is no way to determine what is to be built, who is supposed to build it, and what “done” looks like.

The WBS is the foundation for initiating, planning, executing, monitoring, and controlling the work to produce the desired outcomes of the project. It is the representation of the work scope of the project, documenting the hierarchy and describing the deliverables to be produced by the work efforts and their relationships to the final outcome of the project. It “breaks down” all the work into deliverable elements for planning, budgeting, scheduling, cost accounting, work authorization, measuring progress, and management control. This sounds like a lot of work, but if we are going to determine the project’s final cost and schedule, we need to know what it is we are supposed to be delivering. We can then develop the WBS dictionary—the narrative description of the deliverables, their defined outcomes, and their units of measure for success—to define the work scope for each unique element in the WBS.

Identify the Resources Performing the Work

With the defined work shown in the WBS, we can now assign the organizational responsibility for this work. An OBS does this. The organizational breakdown structure shows the responsibility, accountability, and authority for all tasks to be performed. It is a direct representation of the organizational hierarchy and describes the organizational elements that provide resources, plan, and perform the work. It identifies the organization responsible for each segment of work, including subcontracted and intraorganizational efforts. The assignment of lower-level work segments to responsible managers provides key control points for managing the project. When effort is subcontracted, the applicable subcontractor is identified and related to the appropriate WBS element(s) or organization accountable for acquiring the subcontracted item.

Integrate the Work with the Resources Performing the Work

Integrating the WBS and OBS creates connections between the resources doing the work and the work itself; this is illustrated in Figure 4.4. The “intersection” of WBS and OBS is where we assign the budget needed to do the work and collect costs for the labor and materials needed to produce the project’s outcome. It is the point where a single functional organization or integrated product team has responsibility for work that delivers to a single WBS element. This intersection is called a control account. It is also where we examine the status of our work efforts. This process is always focused on physical percent complete, rather than on simple cost and schedule reporting. Progress toward “done” is the primary measure of success.

A Checklist for Organizing the Project

A checklist is vital to any project; it ensures that we don’t forget anything along the way. Here are some questions that need answers before we move on:

Does the WBS contain all the project work? If the planned work is not in the WBS, why are we doing it? If we are doing it, where can I find the work in the WBS and the WBS dictionary?

If we are subcontracting any of the work, is that work in the WBS as well? When we say “all in,” it means all the work, not just the work we want to do.

Is there a target budget for all of the work? Has this budget been developed bottom up by resources accountable for the work? Top-down budgets may be easy to do, but they lay the groundwork for project failure. Only after the bottom-up budget is developed can the project manager and business management have something to say about it. If the budget is flowed down from the top, then the bottom-up estimate needs to confirm the credibility of the budget.

Are all the elements of work in the WBS assigned to the proper organizations or resources? We need to know “who is doing what” so there is no overlap or gap in our resource plan.

Do we know the total target budget for this project? With the complete list of deliverables, do we know all the work needed to produce those deliverables and the estimated budget for that work?

Do we know who is accountable for the budgets, the technical, and the managerial aspects of the project? This list is represented in the OBS (see Figure 4.4).

Is there a single person accountable for each deliverable? Collective accountability lays the groundwork for project difficulties. Without a single voice for “progress to plan,” business management gets confused.

Plan, Schedule, and Budget the Project

For every project, no matter the domain, we need to plan, schedule, and budget for the work. This seems like an obvious set of activities, a tautology. But there are many times when the “proper” planning, scheduling, and budgeting don’t happen and the project is set on the wrong course from day one. Let’s look at the details for how to do this right the first time.

Plan the Work

Planning is not the same as scheduling. Most projects start with scheduling and fail to plan. The plan tells us where we are going. It tells us when our capabilities are needed and in what order they are needed. Figure 4.5 shows the relationship between the plan and the schedule. The plan is a strategy for accomplishing some outcome. It describes where we are going, the various paths we can take to reach our destination, and the performance assessment points along the way to ensure that we are on the right path. These assessment points measure the “maturity” of the product or service against the planned maturity. This is the only real measure of progress. Progress is not measured by the passage of time or the consumption of money. Figure 4.5 illustrates the relationship between the project plan and project schedule and the work packages, which produce the outcomes that deliver accomplishments that meet criteria toward milestones, which measure physical percent complete.

As you can see, the plan and the schedule are not the same thing and must be looked at separately. The plan is a procedure used to achieve an objective. It is a set of intended actions through which one expects to achieve a goal. The schedule is the sequence of the intended actions needed to implement the plan. The plan is the strategy for the successful completion of the project. In the strategic planning domain, a plan is a hypothesis that needs to be tested along the way to confirm where we’re headed.¹¹ The schedule is the order in which the work required to execute the plan will be performed. We need both. Plans without schedules are not executable. Schedules without plans have no stated mission, vision, or description of success other than the execution of the work.

The elements in Figure 4.5 are used to construct the plan and schedule for the delivery of the outcomes of the project. These elements are connected in a single document as the Performance Measurement Baseline, which is used by the project manager:

The milestones show the availability of one or more capabilities. We showed how to develop these capabilities in Chapter 3. This is where we put them in the proper order for delivering business value to the customer. The name of the milestone in the plan represents its capability. Figure 2.2 is an example of the increasing capabilities provided by a project for the customer.

FIGURE 4.5 Relationship between the project plan and schedule.

The accomplishments and the acceptance criteria for these accomplishments are needed for each of the capabilities delivered to the customer that generates business value. To measure this value, we need to know what accomplishments must be delivered by the project to produce the capability. For each accomplishment, we need to know its measurement criteria. “How will we recognize that the accomplishment is meeting its goal?”

The accomplishments are preconditions that must be met before the capability is ready to deliver its value. When all the accomplishments are complete and confirmed by their criteria, then the capability is ready to provide value to the customer.

The performance of the work activities is always measured in units of physical percent complete. These activities include those inside the work packages, criteria, accomplishments, and milestones representing the capabilities. We can answer the question, “Where are we in the project?” with a description of what accomplishments have been completed, using the criteria as the measure of physical percent complete against the date for the planned capability being ready to provide business value.

Schedule the Work

Work must be performed in the proper sequence for the technical and business value to be produced by our project. This is demonstrated in Figure 4.5. Defining the right sequence is a “scheduling” activity. No matter what project domain we are working in, doing the right work in the right order is a requirement for success. Imagine what would happen if we install the wallboard in our home and then start to install the electrical wiring. That would be nonsense. The same thing can occur on an IT project or a landscaping project, or any project. The order of work is described in a schedule, with resources and the cost of those resources assigned.

The schedule elements shown in Figure 4.5 are referred to as work packages.

Work packages represent units of work at the level where the work is performed. They collect the work tasks into a single “package of work” with a single output from that work.

Their implementation is assignable to a single organization. The work package manager is accountable for the outcomes from the work effort.

They have a scheduled start and finish date and they produce a tangible outcome. The activities within the work package are not dependent on any external connections. No partially completed work can be a predecessor to another work package.

They have budget assigned to them for the performance of the work.

Their duration is limited to a short span of time, which reduces the risk of discovering that the work effort is late and there is no time to take corrective action.

Budget the Work

The assignment of budget to scheduled work results in a “spend plan” for the project. This “spend plan” and the work that is budgeted is the PMB. The creation, maintenance, and use of the PMB are critical for effective project performance management. The PMB connects the planned work with the budget needed to produce the work, so those funding the work can see not only how much it is going to cost but also how much money will be needed at a specific time—this is the cash demand for the project.

A Checklist for Planning, Scheduling, and Budgeting

Planning, scheduling, and budgeting the work have to take place in a specific order. First, we need a plan showing how the deliverables are going to be developed and what the measures of their progress will be. The schedule for actually doing the work comes next. With these two in place, we can determine the budget needed for the labor and materials. Here are some questions to ask yourself as you do this:

Does our plan (see the upper half of Figure 4.5) describe the order of the accomplishments that deliver the capabilities needed by the customer?

Does our schedule (see lower half of Figure 4.5) describe the order of the work packages required to complete the criteria needed to produce the accomplishments?

Does this schedule define the duration of the work activities inside work packages in some risk-adjusted way? Schedules without duration margin are late before they start. Nothing ever goes as planned, so building in margin is needed for the schedule to be credible.

Does the schedule have hard dates forced on the project by management? If so, the project is late before it starts.

Are significant decision points, constraints, and interfaces to the internal and external activities defined in the schedule? Like the WBS, the schedule must be an “all-in” representation of the project.

Can we measure “physical percent complete” for each work package and status the schedule with this information to show our actual progress to plan? Without tangible evidence of progress, the schedule is just a “notional picture” and adds very little to the success of the project.

Are there meaningful indicators for measures of schedule progress? The passage of time and consumption of resources are not meaningful. Only the production of tangible outcomes that meet the requirements is meaningful.

Is there a time-phased budget for the scheduled work? Does this budget include labor as well as materials and other direct costs so the project’s management can determine what the overall funding needs are? Are these time-phased budgets assigned to the organizational elements of the project so they can flow the budget down to the resources performing the work?

Have we planned our project in discrete, short-duration work packages?

Execute Project Accounting

Someone has to keep track of the money, especially if it is not our own money. No matter if it is our money or someone else’s money, knowing how much money we need, how much money we have now, and how much money we have spent so far is important to everyone on the project. All projects require money for labor and materials. Project accounting is responsible for identifying how much money will be needed, how that money is being spent, who is spending it, and how much money will be needed to complete the project. Other costs to the project are usually considered “indirects,” and generally they are not in the purview of project management but are part of the larger business management process. These indirects include “overhead,” “benefits,” “fringe.” These are all costs not directly related to producing the outcomes from the project, but they must be in place for the project to be successful.

We can’t keep track of the money in any meaningful way until we have some knowledge of how much money we are going to need. No matter the domain or context, accounting for cost starts with the WBS. If we are managing the “functions” inside a project instead of the products, we can use the functional organization—the OBS—to account for the money. In this chapter, we are managing the development and delivery of “products” or “services,” so we will focus on the work breakdown structure. The WBS section of Figure 4.4 is derived from the current military standard for building the WBS, MIL-STD-881C. This sounds a bit heavyweight, but this “standard” includes examples for hardware as well as software and is a good starting point for what a “credible” WBS looks like.

Capture Project Costs

With our time-phased “spend plan” shown in Figure 3.2 (Performance Measurement Baseline), we can collect the direct costs using the accounting system consistent with the way the work is budgeted. The allocation of costs is guided by the lowest level of the WBS in Figure 4.4; for example, 1.3.1, the Power Panel. These costs include the direct labor, materials, and other direct costs (ODC) such as travel, equipment in support of the project, engineering, special tooling, and packaging. These are direct costs to the project so they need to be to be budgeted and later captured.

We can now determine our actual costs versus our planned costs. This does not tell us about the value that was produced by expending these costs for the work effort. That has to be done by measuring the physical percent complete produced by the work effort. We measure the project’s progress against our budget using some simple ideas:

The value that we are earning equals our budget multiplied by the physical percent complete at the time of the measurement. This is the literal definition of earned value in a more formal domain. It is also a useful measure for any project performance assessment. The question that needs to be answered is, “What value did I get from my investment (budget)?”

We can ask and answer a simple question to make this clear: “If we invested $100, did we get $100 of value back on the day we planned to get it back?” The question can be asked for project work, too: “Did we complete the work for the planned budget using the 100 percent complete criteria?” In other words, is the work 100 percent “done”? If it is, we “earned” our budgeted cost. If not, we only “earned” a portion of the budgeted cost and are likely behind schedule and over budget, because we have more work to do and someone has to pay for that work.

Summarize All the Costs by Elements of Work

Capturing the costs is our starting point, but we also need to organize these costs by the WBS to compare them against the budgeted cost for each of these WBS elements. In Figure 4.4, we can summarize these costs at the intersection of the WBS and the OBS. This is the place in the Responsibility Assignment Matrix where a person is assigned accountability for producing the deliverables for that WBS element at the planned cost.¹² This is the single point of integrative responsibility for that work and the place where the focus is on managing the project.¹³ The assessment of the performance of this work includes the hours consumed by the labor and the cost of the materials needed to produce the outcomes. This information is used in the next step to determine any variances in cost and schedule, and will answer such questions as “What did you do with my money?” and “Did you produce what you planned to produce for the budget you planned to spend?” These are serious questions for any project manager, more so when we are spending other people’s money.

A Checklist for Project Accounting

If we are spending other people’s money, we need to account for the money and how we are spending it. If it is our own money, we probably should do the same thing. Here are some questions to ask to determine how to be good stewards of the money we have been given for the project:

Do we have access to cost data from a reliable source? The time card system or the accounting system is the logical choice. If we don’t have a time-keeping system, how can we determine the work effort applied to the work packages? This information is important to determine our future capacity for work.

Do we account for cost in the same way we budget for cost? This means we can separate labor from material. If we have material, when do we pay our invoices and record that payment against our budget?

Can we assign costs—both budgeted and actual—to a specific work package defined in the schedule with a WBS number and a specific organizational element? Both are needed to assess how we are spending the money.

Do all our individual budgets at the WP level add up to the project budget? We are back to the all-in concept.

Do we keep records to show accountability for all the material purchased for the project, including any leftover inventory?

Execute Project Performance Analysis

Now that we have a budget for the planned project, we can collect the actual costs for performing the work using that budget, guided by the schedule for the work in the planned sequence. We can measure progress to our plan using physical percent complete and the cost to reach that physical percent complete. We will use this information to make management decisions, which is what project management is all about. Because manage is a verb, we need to take actions to keep the project going as planned or change how the project is planned.

Determine Variances for the Work Processes

We need to ensure that both significant schedule and cost variances are analyzed, at least monthly, at a level of detail required to manage the effort. This “at least monthly” answers the question, “How long are you willing to wait before you find out you are late?” If you don’t know you are late in enough time to take corrective actions, you are late. This periodic analysis must be done to enable management decision making and to take corrective actions in timely manner. Comparing the budget value of work completed to the budget value of work planned during a given period of time provides a valuable indication of schedule status in terms of dollars of work accomplished. If we are looking for a motivation for this approach, simply answer the question, “How long are we willing to wait before we find out we are late?” The assessment of the project’s performance needs to be at intervals short enough to take corrective action before we are actually late.

The analysis of the project’s performance usually begins at the cost level. This is an easy approach, and it is tangible evidence of performance. Looking at each work package in Figure 4.4, we can determine the cost performance of this work against the planned cost. If we are “on budget,” there is hope that we might be “on schedule.” If we are “off budget,” it is an indication there is something unfavorable about our performance and we need to look further. This budget assessment comes directly from the accounting system—the time cards, invoices, expenses, labor reports, material costs, all the things that come from the accounting system for the actual costs that are compared to the budgeted cost for the planned work. Reconciling the budget with the actual costs gives us the cost variance we need to assess the cost performance of the project.

Cost variance (CV) starts with a comparison of the planned cost with the actual cost for a period of performance. We should not use the total cost or the cumulative CV as our first measure of performance. We should start with the variances for the current period. This variance is an indication of how well we are managing costs in the short term. The cumulative variance masks the variability we need to make management decisions. We have all experienced the result of ignoring the short-term results, assuming we will make it up in the long run. For example, we have decided to lose two pounds a week for the next fifteen weeks for a target loss of thirty pounds. In the first four weeks, we are close to our goal, two pounds every week. But in week five, we only lose one pound. Our first thought is that we will lose three pounds in week six to get back on track. Probably won’t happen. Staying on budget requires continuous vigilance. Focus on the short term and the long term will be easier to adhere to. In the late 1970s, a mentor told me, “The project is lost a day at a time. Get off by a week, and you’ll never make it up.” It changed my view of the world.

The next step is the analysis of our schedule variance. The first thing we must face up to is that spending money as planned is not the same as staying on schedule as planned. The measure of schedule performance—and this can’t be said enough—must use tangible evidence of physical progress to plan. One approach is to create milestones, stating what is to be delivered at a particular point in time.¹⁴ This schedule variance (SV) may not clearly indicate whether scheduled milestones are being met because some work may have been performed out of sequence or ahead of schedule while other work has been delayed. This out-of-sequence work will not match up with the planned budget for that work. As well, the products from the out-of-sequence work may “age” as other parts of the project change requirements that would have been used to build the outcomes. Now rework is needed to correct this. Schedule variance does not indicate whether a completed activity is a critical event or if delays in completing an activity will affect the completion date of the project. If we think of milestones as deadlines, we are going to be disappointed in our ability to manage the project. We need to remember Douglas Adams’s statement from The Salmon of Doubt, “I love deadlines. I love the whooshing noise they make as they go by.”¹⁵ So we need measures of physical percent complete on the planned day and should not use these fixed rocks on the side of the road as signs of progress. They can be passed much too easily.

Here’s an example of how to measure physical percent complete:

We have a kitchen-remodeling project and our initial efforts are in the drafting shop, making drawings for this remodel based on the customer’s requirements. Figure 4.3 is a “notional” WBS for this project.

We have four weeks to produce twenty drawings for the kitchen renovation.

Each drawing has the same level of difficulty and should take the same effort and duration to produce. Our cost is directly related to effort: hours worked equal labor costs.

We plan to produce these drawings at an equal pace, over the four weeks, twenty drawings total, five drawings per week.

We have a budget of $1,000 for all twenty drawings, with a budget per drawing of $50 a drawing.

We assume that one person is doing this work, and this person is available 100 percent over the four-week period of performance.

There are three measures for the performance of the drawings for our kitchen remodeling project:

1. We have a planned value for this project effort. This is the budgeted cost for the planned outcomes for the work efforts at the time of assessment. The spending profile is linear, $250 per week for the four weeks, to produce five drawings each week, costing $50 each.

2. We have the actual cost of the work performed at the time of assessment. We can measure that cost by looking at the number of hours spent by the one person doing the work.

3. We know the physical percent complete for the work efforts by looking at the number of drawings produced at the end of some measurement period and comparing it against the planned number of drawings for that same period.

Notice the phrase, “at the time of assessment.” This is critical. If we plan to spend $1,000 as the total budget for the work over a four-week period, this is the planned value. This is the budget to produce our twenty drawings with a cost of $50 per drawing. When we assess the performance of our efforts, we do that at a specific point in time. This point in time has a cumulative budget, and, we need to assess our cumulative performance and our cumulative actual costs all at the same time. Let’s measure our progress at the halfway point, week two.

Our plan says we should have spent 50 percent of our budgeted cost: $500. This is naïve, of course, but it makes our calculations simple. This means that after two weeks of work, we planned to have spent $500 for ten drawings at $50 each. We can also assume—again naïvely—that over the course of the four weeks, the actual value of the product—the drawings—we are producing is growing linearly. So at the two-week point, our product should be worth 50 percent of the planned cost, or $500. We earned our budget in this simple-minded example. So now it’s Friday of the second week of our four-week project. We planned to spend $500 and to “earn” $500 of value from the ten drawings at $50 each.

But on Friday of the second week, we delivered only eight of the planned ten drawings. We are clearly behind schedule. We also discover that for that first two weeks, we spent $50 each for the first seven drawings and $70 for the eighth drawing, and failed to produce drawings nine and ten. So we underspent our budget to produce less than our planned outcome. For these eight drawings, we spent $420 (seven times $50 plus one drawing at $70). Our planned cost was $500, so we are $80 under budget.

Let us do some calculations:

Our cost variance (CV) for the two weeks is $500 – $420, or $80 favorable. We underspent by $80 for the current period of performance.

But we really want to know what we got for the money we spent. So just measuring the budget compared to the actual doesn’t tell us much. We need to measure how much we spent compared to how much “value” we produced.

At the start of the project, we planned to spend $50 for each drawing. We assume that when we spend $50 for each drawing, they are “worth” $50 of value. This is not the business value; that’s a different topic. The $50 is the sunk cost value. We planned to pay $50 each, let’s just call their value $50.

For our total of ten drawings, we should have “earned” $500: ten drawings at $50 budget and $50 value.

At the end of the two weeks, this is not the case. We produced only eight drawings, so we “earned” only $400 worth of value compared to our planned $500. We also spent $420 to produce those eight drawings. If we had produced the eight drawings at our planned cost, it would have cost us $400—eight drawings at $50 each, but we actually spent $420 to get our eight drawings.

Not only did we not produce the planned number of drawings, but the ones we did produce cost more than we planned.

This type of analysis is much different from the simple cost and schedule assessment found on many projects. It is focused on measuring the production of value. This value is “earned” by measuring physical percent complete against the budget for that planned completion at the point in time when the assessment of progress is planned.

Take Corrective Action

These data and the calculations are interesting, but as project managers what we really need is the ability to forecast the future performance of our project given our past performance. To do this, we need to use additional measures. The first forecast calculation we need to perform is the Estimate at Completion (EAC), which is an estimate of how much the project is going to cost and how long it will take to reach done if we don’t change anything we are currently doing. To arrive at our EAC, we first need to calculate the Cost Performance Index (CPI) using the following equation:

CPI = Value we “earned” / Actual cost to earn that value

= $400 / $420 = 0.95

This says we are earning only 95 percent of our investment in the work effort. For every dollar we spend, we get only 95 cents in “value” back. This is not a great way to run a project.

Once we have the CPI, we can calculate the EAC:

EAC = [Actual cost + (Budget at completion – Earned value)] / CPI

 = [$420 + ($ 1,000 – $400)] / 0.95

 = $1,073

This tells us that if we keep going at our current rate, we will overrun our original budget by $73.

But that’s not the real problem. Let’s see how late we are going to be. Let’s calculate our Schedule Performance Index (SPI):

SPI = Earned value / Planned budget for the project

= $420 / $500

= 0.84

This says our schedule efficiency is only 84 percent of what it needs to be to complete on our planned four-week schedule. Let us look at the impact of this forecast on our planned completion date. We had planned four weeks for the total project, twenty working days, so the forecast completion duration can be calculated using the SPI:

Estimated completion duration = Planned duration / SPI

                                       = 20 days / 0.84

                                       = 23 days

We are forecasting we will be three days late and $73 over budget if we don’t make changes to how the drawing project is executed.

Here’s a quick summary of the management report we owe to the customer:

At the end of two weeks—halfway through—we are missing two of the ten planned drawings.

We spent more than our planned budget for the eight drawings we did deliver. For those eight drawings, we should have spent $400. But we spent $420 because the last drawing cost $70 instead of the planned $50.

We produced fewer drawings than we planned. We were supposed to produce ten drawings in the first two weeks. But we produced only eight drawings during that period.

We produced less than planned and spent more for what we produced than we planned.

We are now late—eight drawings instead of ten—and we are over budget $420 instead of our planned $400 for those eight drawings.

If we don’t do anything, we will be over budget by $73 and late by three days. What are our options? As project manager, these are our logical choices:

We can catch up by producing more drawings at a lower cost. This means producing the remaining twelve drawings for the remaining $580; or $48 for each of the remaining drawings instead of the planned $50 each.

We can keep on the current schedule, overrun by three days, and spend more money.

There is no way to both get back on budget and back on schedule unless we produce the remaining drawings for less than we had planned and at the same time produce more drawings than we planned in the remaining weeks.

We need to become more efficient at producing the drawings at a lower cost to stay on schedule and stay on budget.

This is also the conversation that, as project managers, we need to have periodically with the project team. By periodically, I mean weekly on any project of small to moderate size like this one; monthly is an absolute minimum for a project of any size. Measuring efficiency is the best indicator of project performance and should be done before measuring cost and schedule performance. Using this measure of efficiency, we can calculate schedule delays and budget overages from the assessment of physical percent complete.

Conduct a Performance Analysis Checklist

Once we have our baselined project schedule and budget and measurements of the cost and schedule performance of this baseline, we can look at the variances and take corrective actions to keep the project going as planned. Here are the questions you need to ask to do just that:

1. Do we analyze our performance in a consistent and systematic manner? Or do we use ad hoc processes to determine if we are on budget, on schedule, and meeting specifications?

2. Do we use objective results from our work to assess the performance of that work? Is there tangible evidence from each work package that the result met the requirements for the singular outcome?

3. Can we evaluate the impact of variances on cost and schedule in a way that provides actionable information to the decision makers? Without actionable information, it might be nice to know something, but we won’t know what to do about it.

4. Do we have visibility to the root cause of the variance so we can take action to prevent it in the future? Once the root cause has been determined, do we have the ability to track the changes needed through resolution to be certain the cause of the variance has been eliminated?

5. With the current performance data, can we forecast our Estimate to Complete for the schedule and our Estimate at Completion for the total project cost? Are these estimates based on our performance to date, actual cost to date, knowledgeable projections of our future performance, and any estimates of cost for the remaining work?

Record Revisions and Maintain Data

Continuing with our simple kitchen remodeling drawing production project, let us look at the data we have gathered and how we can manage changes to our work activities now that we know we are late and possibly over budget:

Planned cost from our WBS for each deliverable includes labor and materials. The schedule for the production of the outcomes needs to be adjusted to either stay on budget or stay on schedule, but probably not both.

Any changes to the schedule must assess the impact on the promised dates and the cost to produce those deliverables.

Measures of Performance are assigned to each of the deliverables to confirm they are compliant with the technical requirements. Variances that result from this assessment require corrective actions to put the project back on schedule and on budget.

The corrective actions we need to take must be recorded so that all participants understand what we are going to do next. Approval for these changes may involve the customer; it will certainly involve the project manager and those accountable for producing the outcomes. All must agree that any changes that result from the corrective actions will produce the desired outcome.

Performance forecasts from the calculations for our new cost and schedule estimates must be published, reviewed, and approved by the project participants. There can be no surprises, or “I told you so,” or worse yet, “I told you but you didn’t understand.”

This is the raw material needed for making management decisions. To make credible decisions, the data must have integrity. The data must be trustworthy. To be trustworthy, we need to know the provenance of the data. Where did the data come from, how was the information collected, how was it changed, who changed it, and why was it changed? Can we trace these changes through the life of the data?

Once we make a management decision to do something about our unfavorable performance to date, a change of some kind is needed. This can be a change in the schedule, a change in the budget, a change in the scope of the project, or even a change in the technical performance of the outcomes from our work effort. Whatever the change is, we must document it using a Change Control Management process, which entails asking ourselves the following questions:

1. Are authorized changes incorporated in a timely manner?

2. Are all the budgets, schedules, and other elements updated to reflect the approved change?

3. Are all the changes in budget and schedule reconciled with the customer’s expectations?

4. If the approved changes result in schedule or budget overruns, has the customer acknowledged this outcome?

Looking Back

The five processes needed for the governance of the project provide the framework for applying the principles and practices. These process areas have specific outcomes that must be in place for success:

Organizing the project requires that we define the deliverables with a work breakdown structure (WBS) and an organizational breakdown structure (OBS) for the resources performing the work.

Planning and budgeting for the work requires that we assign the budget at the intersection of the OBS and WBS, as shown in Figure 4.4. With this budget and the defined work from the WBS dictionary, we can schedule the work in the proper sequence to produce our desired outcomes. This schedule and the assigned budget identify the physical products. We need meaningful indicators of progress using milestones and technical performance goals to measure physical percent complete. The result of this effort is the Performance Measurement Baseline (PMB).

With the PMB, we can capture the cost of performing the work. With this information, our next step is to assess these costs and the measures of physical percent complete to determine our progress to plan. This analysis of cost, schedule, and technical performance must be performed frequently to allow time to take corrective actions.

With our measures of physical percent complete, we can forecast the final cost and completion dates using simple algebra. This provides information not available with traditional cost and schedule assessments.

What’s Ahead?

With our principles, practices, and processes in place, we can now go to work. In the coming chapters, we will apply them to three projects that are simplified versions of actual projects. We will start with the needed capabilities; develop the requirement, then the plan and the schedule, and the measures of performance; identify risks and their handling; and establish the Performance Measurement Baseline. With everything in place, we will execute the project, generate some variances, and take corrective actions to put the project back on track.

These three projects will cover a broad range of domains:

Remodel a home kitchen.

Deploy an enterprise IT system that needs integration with legacy systems.

Develop a new product that integrates hardware and software.