2 THE INTEGRATED PROCESS
“Time is money,” to quote Benjamin Franklin, and that is no more true than when trying to control the cost and schedule of a project. This is why it is so essential to understand the processes, techniques, and tools of defining a project based on the cost of the time it will take to produce the overall deliverable of the project.
In this chapter we will introduce the integrated project processes, the balancing technique crucial for cost and schedule control, the binding structure tool that will be used throughout the integrated processes for cost and schedule control, and the idea of having a baseline and steering the cost and schedule of the project within a predefined tolerance threshold. We will also take a look at the process of integrated cost and schedule control in the U.S. federal government.
THE INTEGRATED COST AND SCHEDULE CONTROL PROCESSES
As defined in the PMBOK® Guide, the process of project management entails five subprocesses. These individual processes are called many different names by different organizations, but it is the understanding of what happens during each that is important. Using PMI’s terminology, the subprocesses are the initiating process, the planning process, the executing process, the controlling process, and the closing process:
The initiating process is where decisions are made about whether something truly will take care of the need and can be afforded in light of the customer’s budget. This decision authorizes the “parts” of the deliverable or service of the project, which in turn define what is in the scope of the project and what is not. This is where the customer’s or stakeholder’s expectations of what they will receive are balanced, based on the money they have in their budget. Setting these expectations allows control over the project’s cost and schedule. We will explore this process in depth in Part 2, because it is the most important and most misunderstood process in project management.
The planning process is where the best method of accomplishing the work in time for the customer to use the deliverable (identified during the initiating process as the agreed-to scope) is explored. Too often this process gets started without the initiating process having been performed, and project plans that are not balanced go forward into execution. These imbalanced plans have little or no chance of success. Carrying out the planning process effectively requires a basic understanding of network analysis and statistical analysis. These techniques are presented in a straightforward fashion in Part 3.
The executing process is where the work gets done. This process relies less on management techniques and more on leadership abilities. Some of the management techniques that are involved in the other processes, such as including the team in the initiating and planning processes and guiding the project toward a successful completion, put the project manager in a “leadership” position with the project team.
The controlling process establishes a guidance system for the performance of the work, in terms of both time and cost, and redirects the planned work, where required, to stay within the control area of that system to a successful completion. This is where earned value analysis is so useful; we address how this analysis is performed in Part 4.
The closing process puts accomplishments “on the shelf” and analyzes them for lessons learned and their usefulness in the future. We address these techniques in Part 5.
Many unenlightened project managers see these subprocesses as distinct and separate phases. They envision the entire project plan as one big waterfall schedule through the lifecycle of the project, as shown in Figure 2-1.
Figure 2-1. Project Subprocesses Planned in a Waterfall Schedule
This type of schedule often becomes “very expensive wallpaper,” because the schedule doesn’t realistically show how the subprocesses are performed in real life. In the real performance of any project, the subprocesses tend to overlap through the lifecycle of the project, as shown in Figure 2-2.
Figure 2-2. How the Subprocesses Overlap during the Project Lifecycle
Understanding how information passes from one process to another allows the project to be planned in an iterative process that more closely emulates real life. Another way of saying this is that to get to the point where we have truly defined the work of the project, we need to have done a lot of the work of the project.
BALANCING THE TRIPLE CONSTRAINT
The key to being able to control the cost and schedule is having a plan that balances the scope of the deliverable of the project with the customer’s budget and has the right resources assigned at the right time to perform all the work in time for the customer to be able to use the deliverable. This is called the triple constraint (see Figure 2-3).
Figure 2-3. The Triple Constraint
This triple constraint must be balanced during the initiation and planning processes if the cost and schedule of the project are to be controlled through the execution and closeout processes. It is a delicate balance because some of the time and money are expended just to get to the point where the initiation and planning are complete. To maintain this balance throughout the project, the project manager must always be aware of where the project is in each process.
To maintain this balance, terms such as “quality” or “resources” come into play. The idea of quality has to do with defining the scope that fits the customer’s budget and will be able to accomplish what the customer plans to do with the deliverable. For example, the customer may want a Cadillac but not be able to afford one. The need that is being addressed is the fact that the customer needs transportation and a car is a “class” of deliverable that can fulfill that need. The quality (attributes) of the deliverable (scope) has to be balanced with the customer’s budget. If the customer demands the quality of a Cadillac, then the need to have transportation cannot be met until the budget for the Cadillac is available.
Resources take time to get work done. Two resources can usually get a job done faster than one if they have the proper skills and the scope of the work has been unambiguously defined. If there are not enough resources to get all the scope of the deliverable completed in time for the customer to use it, one option is to reduce the size or the quality of the scope to something that the resources can complete and the customer can still use.
As the project plan is time-scaled, the costs involved to complete the work can increase as a result of factors such as escalation. This is why incremental planning, with budgets defined for each increment, is used on many projects. Incrementally funding the project based on defined releases of the deliverable has mitigated some of the risk involved in balancing the triple constraint of large, multiyear projects.
This is all one big balancing act. Those projects that are not balanced are virtually impossible to control no matter how much earned value analysis is done.
THE WORK BREAKDOWN STRUCTURE
The one binding tool through the entire integrated process of cost and schedule control is the deliverable-oriented work breakdown structure (WBS). The deliverable-oriented WBS is a tool used in every process. It is built during the initiating process by recording the decomposition of the deliverable and helping determine the work items required to build the deliverable that will take time and effort to accomplish.
The effort of these work items translates into money that will help balance the scope of the work to the customer’s budget. Like with my She Sails catalog mentioned in the Preface, my expectations, like any customer’s, were not set until I was presented with how much each part cost and I realized that I could not afford everything I originally wanted.
The time required to complete each work item, which is identified using the WBS for the agreed-upon scope, will then become part of the schedule. That schedule will then be used to plan how each of these work items will need to be accomplished for all of them to be done in time during the planning process.
Because these work items are “children” of the parts of the scope, the WBS/schedule shows the progress of the project during the execution process. The WBS also presents the information for performing the analysis that will help us control the work items during the controlling process. This approach of using earned value information presented in the WBS will also help us isolate issues while they are small and can be resolved during the controlling process.
It is important to understand that a deliverable-oriented WBS is a tool for integrated cost and schedule control. Too often project managers use other methods of developing a WBS, such as a time-oriented or task-oriented structure.
The time-oriented WBS has the tendency to set up the first level of the WBS based on “milestones.” For example:
Each major part of this time-oriented WBS is an ambiguous term that can neither show the customer what they are going to get at the end of the project nor help the project team figure out the work that will need to be planned for the project. In most cases, when this method is used, the only opportunity to see that the triple constraint is not balanced comes toward the end of the project when the only recourse is to eliminate testing.
It is true that a good practice, especially when a project is very large and will expend a lot of budget, is to break a project down into phases of time. Each of these phases, however, must be identified as a subproject and a deliverable that needs to be produced. The WBS needs to focus on that deliverable and all the subdeliverables that make up that deliverable to be produced for that phase.
Keeping in mind the first, basic understanding of success, work to define the project and everything you think might happen on the project as clearly and realistically as possible.
U.S. Department of Transportation Headquarters Relocation Project
Back in 2001 I was asked by a student to look over a WBS for a new building planned for the rehabilitation of Southeast Washington, D.C. The manager of this project showed me something that reminded me of the many schedules I’ve seen in the past that were filled with ambiguous terms and claimed to be work breakdown structures. He told me he had paid a consultant quite a bit of money to help put it together (what I like to call “very expensive wallpaper”).
He happened to have a small whiteboard hanging on the wall of his office, which I used. “Arnold, you’re building a building,” I said and proceeded to put a box at the top of the board that said “Building.” “If there is just one building, then you break that down into subground, walls, floors, etc. If there is more than one building, you break it down into west wing, east wing, guard shack, and then proceed to break each down as though it is a separate subproject.”
I sat through many sessions with the project team creating the WBS. It was interesting when the contractor in charge of installing all the IT hardware presented a WBS that was based on the typical milestones with ambiguous terms (e.g., preliminary design). We refused to accept it and had the contractor redo it based on the breakdown of the building. They claimed to have never constructed a WBS in that way, but agreed that it (1) made sense and (2) would be far easier to estimate the costs.
When I explained to all the team members how this deliverable-oriented WBS would serve as a better management tool during the actual construction of the building, I had them all converted. If the budget for 2007 gets cut in half, for example, then the building WBS can be prioritized to identify a possibly usable portion of the building (say the east wing) that can be completed for the 2007 budget. The rest can be rescheduled, with all the tasks that are associated with completing the rest of the building, to the following years.
It takes time and effort to develop a project work breakdown structure. The requirements have to be known before you can complete the WBS, but the WBS serves as a tool that records the decisions of the requirements analysis and focuses the analysis to smaller and smaller components of the project. The customer should see exactly what they are going to get in the WBS.
To this day, Arnold still carries that whiteboard around with him.
THE GUIDANCE SYSTEM
Using the integrated cost and schedule control tools and techniques during the subprocesses of initiating and planning the project results in a project plan that ultimately is locked in as a baseline. This baseline then serves as the guidance system of the project because it points to the goal of getting the agreed-upon scope completed within the customer’s budget and in time for the customer to use it.
This project baseline is similar to a flight plan that the pilot of any airplane must submit before the flight. The pilot charts a course that points to the destination of the flight. If you ask a pilot how often he or she is exactly on the flight plan, they will likely tell you that they are on the plan at take-off and at landing; in between, they might happen to fly through it. Yet, they all seem to be able to fly to their destination with very few problems.
If the plane is not exactly on the flight plan, the pilot can usually steer the plane back. If not, the charts are brought out to develop a new flight plan. Hovering close to the flight plan is what allows the plane to reach its destination.
In project management, it’s not being exactly on the baseline of the plan that counts—it’s that you can steer the project team back toward the baseline. Using the tools and techniques of integrated cost and schedule control allows the project team to identify “control areas” around the baseline (like flight control lanes for a pilot) both on the positive side and on the negative side that the project status should stay in to be successful.
If a pilot finds him-or herself outside the control lane, with no possibility to steer the plane back in, the pilot would need to contact someone to make them aware of the situation and to be directed out of the way of other traffic, determine a new flight plan and submit it for approval, check the fuel to see if they will need more than what they have (budget), and report to the passengers, “We’ll try to make up as much time as we can.”
Projects go through the same process. If the project status is outside the threshold of the control area and, no matter what the project team tries to do, the status is doomed to stay outside the control threshold, the baseline of the project is no longer serving as a guidance system. The project should be replanned and the baseline should be changed via a change control process. Someone needs to be made aware of the situation (through a change request) and the impact to the scope, budget, and/or schedule must be determined. If approved, more budget or resources should be added to the project or the due date of the project should be adjusted, all of which will change the baseline so that it serves as a truer guidance system for the rest of the project.
INTEGRATED COST AND SCHEDULE CONTROL IN
THE FEDERAL GOVERNMENT
When I started working with the U.S. federal government and decided to focus on integrated cost and schedule control, my “bible” was the Cost/Schedule Control System Criteria (C/SCSC) first issued the U.S. Department of Defense in 1967. This set of criteria made so much sense to me as a guide to managing any project. The C/SCSC later evolved into ANSI/ EIA-748 (the latest version is B), available at http://webstore.ansi.org/ RecordDetail.aspx?sku=ANSI%2FEIA-748-B. The National Defense Industrial Association (NDIA) Intent Guide provides an excellent (free) explanation of the 32 criteria at http://www.ndia.org/Divisions/Divisions/Procurement/Documents/PMSCommittee/ CommitteeDocuments/ComplementsANSI/PMSC_Application_ Guide_March2007_Release.pdf. I took it upon myself to try to get my colleagues to understand the benefit of using the criteria on any project in any department of any size, but most directives required that the criteria be followed only on major ($20 million or more) Defense Department contracts.
In 1993 Congress passed the Government Performance Results Act (GPRA), http://www.whitehouse.gov/omb/mgmt-gpra_ gplaw2m/, which mandated the establishment of strategic planning and performance measurement across the entire federal government. The purposes of GPRA were to:
Improve the confidence of the American people in the capability of the federal government by systematically holding federal agencies accountable for achieving program results
Initiate program performance reform with a series of pilot projects in setting program goals, measuring program performance against those goals, and reporting publicly on their progress
Improve federal program effectiveness and public accountability by promoting a new focus on results, service quality, and customer satisfaction
Help federal managers improve service delivery by requiring that they plan for meeting program objectives and by providing them with information about program results and service quality
Improve congressional decision making by providing more objective information on achieving statutory objectives and on the relative effectiveness and efficiency of federal programs and spending
Improve internal management within the federal government.
Those government agencies that didn’t think they had to do it found themselves struggling to get up to speed on cost and schedule control and earned value management.
Today more and more government agencies are getting on the “earned value management wagon” and appreciating how this invaluable performance measurement and predictive tool helps the project management process.
Now that we have a basic idea of the process, the triple constraint, the WBS, the guidance system, and the emphasis in the federal government, let’s see how these processes of integrated cost and schedule control really work.