CHAPTER 6

Monitoring and Control of Projects

WILLIAM P. ATHAYDE, JD, PMP, PM COLLEGE

Project control promotes the achievement of project goals by analyzing project information, monitoring the variation from the plan, and responding to variations as appropriate. Project managers should commence their monitoring and control by ascertaining the quality of the existing project management plan and its myriad parts.

Today, a large percentage of projects approach planning and controlling in ways very different from traditional project management. Many organizations are trying to apply project management tools and techniques that were developed for projects with clear specifications and detailed scope statements to situations where neither exists. Worse yet, some senior managers don’t seem to understand why those tools fail to provide the quality of insights and predictability in non-construction projects that can be achieved in construction projects, and they blame project managers and their teams when the results don’t match management’s expectations.

One of the most common examples of this problem is seen in projects that largely entail the creative activities of thinking, problem solving, and design. Innovation and new product development projects do not always start with a complete set of specifications or a clear understanding of the final result. They often have goals of finding a major breakthrough in a material, design, or process with strategic goals of being faster to market, manufacturing more efficiently, and utilizing less expensive raw materials. Estimating with any precision how long it will take to develop an idea or approach is often extremely difficult if not impossible, and the activities leading to completion of certain deliverables or milestones are not easily measured.

How projects are monitored and controlled depends on the type of project, the project management approach being employed, and the level of experience with both the project methodology and the project subject matter. The ability to monitor and control (i.e., “manage”) the project depends on the foundation laid at the beginning of the project, and on all the subsequent actions, decisions, and outcomes that are built on that foundation. The documentation of those activities and outcomes is our window on what has occurred. Critical to understanding the foundation is the transparency of the time and cost estimating and the risk management systems in use. If project managers have a clear understanding of the basis-of-estimate and well-informed insights into the risk profile for each activity, they can assess the value of that information, develop appropriate options, and use the information to make reasonable decisions or to provide good information and advice to the other decision makers.

Part of the problem with the project foundation is that project managers are often tasked to “execute” projects that have not had any formal project initiation or planning activities. Those projects arrive “ready” for the execution phase based on what someone promised to a customer or to senior management without a project team ever being asked for any inputs. The schedule and budgets for such projects are often arbitrary numbers, and the scope is often vague or incomplete. In such situations, project managers joining those projects frequently have to go back and fill in the project foundation by conducting activities that should have happened in the initiation and planning phases. So before they can effectively monitor and control the project, they have to start over or rework part of the project, resulting in at least an unplanned delay and frequently resulting in discovery of increased project scope and the need for increased budget and schedule duration.

To do proper monitoring and controlling requires good project management, which, in turn, requires the participation of proper resources from the start. Shortcuts in the initiation and planning phases can condemn even the best project manager’s chances of success. This issue is raised to emphasize how pervasive it is and how strongly it undermines the project manager’s ability to control the project.

Monitoring and controlling activities in a project should be an “umbrella-like” function covering the entire project from start to finish; it should start as soon as the project does. We immediately are comparing the actual situation with the desired future state. For instance, if you inherit a project and discover that nothing has been done, although the “late start” date was a month ago, you immediately see a warning signal. Even when taking on a project at its inception, we often see a disconnect between the desired completion date and what our experience tells us about how long it usually takes to complete a similar project. From the outset, project managers need to assess how realistic the schedule and budget are based on all available information and on their experience.

Clearly, some underlying principles guide the thought and action processes when we approach the tasks of monitoring and control a project. First, that the system employed must include an ongoing process that will apply throughout the project (standardization). Second, the system should be the minimum necessary to achieve the desired results (efficiency). Third, we have to focus on measuring the right things in the right way (focus, efficiency, intensity, and process). Fourth, the system must be understood by all staff members who have to interface with it (simplicity and logic). Fifth, in order to convert the raw outputs from any system of measurement to meaningful information, one must apply experience and judgment. As a way to further conceptualize and unify the entire project control process, many authors have cited Shewhart’s Plan–Do–Check–Act model (made popular by Deming) as a way to illustrate the overall methodology that must apply, thereby placing emphasis on the iterative nature of the entire project control process (Figure 6-1). With these ideas in mind, let’s consider more of the details of the realities of project monitoring and control.

FIGURE 6-1. THE SHEWHART CYCLE

Adapted from multiple sources; for examples, see http://www.citelighter.com/business/management/knowledgecards/pdca-plan-do-check-adjust.

Critical to any tracking effort is this basic question: How accurate and realistic are your estimates? Clearly, if estimates were “pulled from the air” instead of based on data and experience, they are suspect, and relying on them may set us up for failure. Another problem is when “padding” (also called “contingency”) has been included in the estimates and not disclosed.

The accuracy and realism of the estimates are functions of the quality of the data, the tools used to collect and analyze the data, the team’s experience with those tools, and whether the team had adequate time to properly conduct the process. Good estimates are like good cooking—they require good ingredients (data), the right tools, the ability to use those tools, and the time to do the work correctly. Often, one or more of those elements are missing from an estimate’s life history!

PROJECT TYPE: A STARTING POINT

Because the construction industry typically has established engineering principles, centuries of experience, clear standards, physical control of the raw materials and final product, known effort, and predictable costs, its projects tend to be easier to monitor and control than projects in many other industries. In addition, construction projects normally have clear requirements, detailed plans, and standard processes for estimating and conducting the work, so their high success rate is understandable.

Much of that industry’s world revolves around “go–no go” standards. The projects typically have a complete and detailed work breakdown structure, accurate estimates, and reporting systems that minimize the ability to “spin” or shade the data. In contrast, intellectual activity is much harder to estimate. Asking a scientist how long it will take to develop a new medical device, employing yet-to-be-developed technology, is not likely to elicit a precise answer.

New product development or innovation projects seem to be almost polar opposites of construction projects in aspects such as having clear requirements and having well-tested, detailed processes for completing the specific product. Many software development projects, while designing the desired functionality within the boundaries of an existing IT system, are plagued by an extraordinary number of scope change requests, which can require reworking and sometimes redesigning the underlying system. When not well controlled, such changes have inadvertently caused projects to grow to three or four times their original size, requiring a total redesign of the product and resulting in massive budget and schedule overruns.

Some of these scope change problems can be attributed to changes in technology or in the customer environment, but a large percentage are the result of key stakeholders not participating fully in the requirements gathering processes, and the failure of the project manager or the organization to have firm cut-off dates for changes to the project. Thus, project managers must exercise available control in this area, and even if they lack the ability to exercise control over late changes being forced upon the project, they must communicate to upper management the impacts on schedule, budget, quality, and customer satisfaction of each proposed change. Upper management must then decide whether or not to agree to those changes. Should management approve the changes, but not approve the extra time or resources to accomplish the added work, then management is responsible for the overrun(s).

While the manner in which the estimates were “nurtured” may be a critical consideration, we need to revisit the project’s “nature.” For projects that have new discoveries or innovations as their goal, it is very difficult to estimate or even to develop detailed work breakdown structures during the initiation phase. Many of the project leaders and subject matter experts are hesitant to get locked into a schedule for things they cannot predict. These projects often require a “rolling-wave” approach to planning and estimating because unexpected failures and new discoveries create an ever-changing landscape for the project. Thus, such projects must be planned a phase at a time based on what has been learned in the project.

Interestingly, one major manufacturer of medical devices looked at this issue several years ago, and after analyzing many past projects concluded that there was a pattern in its projects that could assist in estimating even those projects that had traditionally only been estimated one phase at a time. While their scientists and engineers were unwilling (and maybe unable) to commit to estimates for completion of an entire research and development (R&D) or new product development project, they were able to accurately estimate the duration of the first phase of the project—the feasibility study. And, surprisingly, the manufacturer discovered that there was a very high correlation between the length of the feasibility study phase and the overall length of the project. The manufacturer found that multiplying the time estimate for the feasibility study by a factor of four usually arrived at an accurate estimate of the overall duration of the project (within 10 to 15 percent)! Not a perfect solution, but a reasonably effective one for estimating even those new product development projects.

THE MONITORING AND CONTROL PROCESS: AN OVERVIEW

The ability to control a project starts with stakeholder identification—the ability to understand who the stakeholders are and specifically what they need (in both project outcomes and communications during the project). The “voice of the customer” provides the requirements that are communicated in the scope statement and achieved through the work detailed in work breakdown structure (WBS). The WBS must be decomposed to the appropriate level to create accurate estimates and for the appropriate level of monitoring. The work packages become the activities and are sequenced to start the schedule development. Available resources will then be applied to determine the schedule. The schedule, along with the scope and cost, will create the “baseline” against which the project’s performance will be compared.

Sadly, many organizations do not adequately decompose the project work, which reduces the ability to make an accurate estimate and to track and control the work. Some new product and innovation organizations create product breakdown structures (PBS) and assign the work using that approach. Their process usually delegates the creation of the WBS and the estimate to the functional areas responsible for the PBS deliverable(s), without the project manager having any details or responsibility to track progress except at the highest levels. Such approaches distance the project manager from understanding the basis of estimates, and usually prevent close tracking of any elements so delegated.

Prior to, or simultaneous with, the WBS development, the project control system needs to be established. The system sets up procedures and criteria for collecting data, establishing and tracking milestones, and determining what metrics will be applied. As the project progresses, cost and performance data will be collected and evaluated in comparison to the baseline. Corrective action may or not be taken depending on the extent of deviation from the plan.

One of the big questions in many projects is how progress will be tracked. Part of the work to be scheduled is the creation of the system/structure for monitoring and control. That system needs to be easily understood by all of the people involved in it. Questions that need to be answered include the following:

• Is the information to be gathered worth the effort?

• Does it tell us what we need to know?

• What metrics will be used, and are they clear and concise?

• Can we get the information on a timely basis so that we can effectively react to it?

• When and how and by whom is the data collected?

• What is the quality of the data (or observations) to be gathered? Is it objective or subjective?

Factors Affecting Monitoring and Controlling

Throughout the process of monitoring and control, the project manager should keep in mind and be on the lookout for the top five causes of troubled projects:

1. Lack of sponsor or customer involvement

2. Failure to follow a project management methodology

3. Poorly defined or incomplete requirements

4. Not establishing or not following a change management process

5. Not establishing or not following a risk management process¹

Resource Availability and Ability

Are we using dedicated resources? Multitasking, which is promoted by many organizations, undermines focus and productivity, and is a root cause of many project delays. We all know that by focusing on one activity we can get it done more efficiently. There are also much more extreme examples of the dangers of multitasking, such as the higher automobile accident rate for drivers who are texting while driving. By addressing multitasking, many organizations not only reduce delay in projects, but also, even more importantly, have been able to cut project cycle times by 20 to 50 percent by using critical chain project management. The critical chain approach, which uses the theory of constraints, promotes worker focus by eliminating multitasking and clearly prioritizing work. It also uses 50 percent probability estimates, and controls schedule contingency (buffer) at the project level. While the use of critical chain requires a corporate cultural change, when correctly implemented the results are remarkable. Its approach is applicable across a much wider range of projects and industries than is commonly understood.²

In addition to multitasking, there are other important resource considerations when monitoring and controlling projects:

• Are we relying on “superstars” to do some of the work on the project? Our most capable resources are frequently stretched thin and are often pulled away to assist troubled projects. The more skilled the resource, the more likely that it will be lost to higher priority work.

• Planning task durations based on high skill level is risky. Best practice dictates that estimates should be based on average skill levels, unless you know that you have new or lesser skilled workers who made take longer and may also need coaching or mentoring from more experienced or outsourced resources. Those situations would require longer than average durations and longer estimates of how much time the coaches or mentors would be involved.

Availability and Accuracy of Information

Many readers will be surprised to learn that another issue to be decided is whether or not timesheets will be kept. Many organizations, especially those doing R&D, product development, and innovation projects, don’t track resource hours expended. They recognize that creative activity is not easy to measure in minutes and hours. Much of that work requires collaborative activity that is not tied to a clock. Other organizations direct employees not to report more than the nominal workday on their time records! But if timesheets are inputs to your control process, then it is important that they be kept accurately. Recording time once a week for resources that are not 100 percent dedicated to a single project is an invitation for problems. Can you recall in adequate detail all of the projects and issues that you dealt with last week? Most of us cannot! So, for resources that are not 100 percent dedicated to a single project, daily time recording is necessary, and unpaid overtime hours need to be part of that record! If all hours are not recorded, you really don’t know what the project is costing in time and budget, and you lack accurate information to use in future estimating.

A major organizational culture issue that must be considered is whether your project information system promotes inaccurate reporting or delayed information sharing. If reporting a negative or less-than-expected status results in negative consequences, the reporting parties will usually find a way to report in a most favorable light or may withhold some of the bad news in hopes of turning the situation around before the next reporting interval. Sometimes the sources of the inaccurate reporting are intermediate managers who block, change, or reinterpret some of the reports in order to serve their own goals. A historical example of this problem is the overruling of subordinates regarding O-ring risks before the Space Shuttle Challenger disaster.^3,4

Analysis of many situations where management was “surprised” by the project dashboard suddenly going to “red” has verified that many project stakeholders engage in inaccurate status reporting. The best defense against this is a culture of open and honest communication where the priorities focus on determining how we can remedy the current problem and achieve our responsibilities to the project, and are not focused on affixing blame. Control requires accurate information on the status of work, and it is surprising how often the very systems developed to obtain and report that information encourages either reporting misinformation or withholding information.

Keeping all of the above issues and considerations in mind, we now discuss a tool for monitoring the progress of the project. Whether you are using a Gantt chart or a system such as Earned Value Management (EVM; see Chapter 33), most systems develop their outputs by using a “percentage complete” analysis and compare that information to what the project plan predicted at a given point in time. Points must be established throughout the project where the value of the work is a given in our project plan. While we noted that tracking the percentage of work completed in a construction project seems relatively easy, it is much harder in other fields. The most common approach is to establish milestones throughout the project and set values for those milestones.

The metrics report the project history, but that’s only half of the story! We could predict the future of a project based only on the progress to a specific point in time, but that is not a complete view of the path ahead. In addition to metrics of past activities, we also need the benefit of team members’ observations and intuition. Their experience and insights regarding the meaning of the data as well as those regarding upcoming activities need to be considered by the project manager. Team members usually have the best insight into the risk picture that awaits the project. It is crucial for the monitoring and controlling processes to take that information into account. How do you promote this information flow while not making it overwhelming for those reporting and receiving the information? One approach is to institute a standard reporting format that is simple to use, that communicates essential information, and that serves as a basis for determining the lessons learned. By requiring reports of completions, successes, and problems that briefly answer the following five questions within 24 hours of an event, the project manager not only promotes information flow, but also has the feedback for the lessons learned process:

1. What happened?

2. What did our plan say to do about it?

3. What did we really do about it?

4. How did it work?

5. What are the recommendations for the next time the problem occurs?

These answers can be archived, and, where appropriate, applied to the lessons learned process, which should be part of each phase of the project. These lessons can be learned even if the team members have moved on to other projects.

Communication of project status is a critical element of any successful project control process. The receipt and reporting of timely and accurate information are essential. Any reporting system must meet these criteria. The project team should consider the value of graphical representations in enhancing communications. Gantt charts are easily understood and quickly communicate a lot of information upon completion of the work. Communicating the project’s status based on work progress and actual costs as compared to the project plan is a particular benefit of the charts used in EVM.

Monitoring and control starts at the beginning of the project and extends until it is done. We have discussed some of the issues to consider, but only the project team can fully assess the many factors in each project situation.

REFERENCES

¹ James S. Pennypacker, Troubled Projects: Project Failure or Project Recovery (Glen Mills, PA: Center for Business Practices, 2006).

² Numerous examples can be found at websites for ProChain Solutions (http://www.prochain.com/clients/results.html), and the Goldratt Institute (http://www.goldratt.com/resultsoverview.shtml) or in the third edition of this handbook, Chapter 29.

³ Malcolm McConnell, Challenger: A Major Malfunction, A True Story of Politics, Greed, and the Wrong Stuff (Garden City, New York: Doubleday, 1987).

⁴ Joseph Trento, Prescription for Disaster (New York: Crown, 1987).