CHAPTER 10
Monitoring and Controlling Your Project
by Raymond Sheen
Unlike processes—where the same people repeatedly perform the same activities—projects often involve unique activities (such as using new technologies, building new buildings, or writing new software) carried out by individuals who may be working together for the first time. So as a project leader, you’ll need to actively monitor progress to figure out whether your plan is really bringing the team closer to its objectives.
When monitoring and controlling a project, you’ll follow five basic steps:
1. Track Project Activities
It’s important to check in with team members regularly to make sure they’re completing their tasks and meeting quality standards. You can do this most effectively through team meetings if everyone works at the same location. However, given how common distributed teams are in today’s business environment, it can be difficult to get the entire group together. When that’s the case, I conduct separate working sessions with individuals or small groups needed for particular activities. For example, I recently participated in a “live meeting” conference call where engineers from three locations helped prepare a product-development proposal for a customer. If I had created a draft, sent it around for comments, and then tried to integrate all the feedback, it could easily have taken weeks to complete the document. Instead, I had the right engineers reviewing it over the phone for about three hours, until everybody agreed on the wording. After a working session like this, I loop the rest of the team in at a larger group meeting or through email.
I also use “buddy checks” to verify that tasks are done properly. When someone completes an activity, another team member looks at the results. This is not an in-depth technical analysis; it’s a quick check to confirm that the person who did the work hasn’t accidentally overlooked something or misunderstood the requirements. A team member checking a training plan for a new system, for example, would make certain that all departments in need of training have been included. If possible, have someone who will use the results of the activity do the buddy check. When I worked with a medical device company on developing a new product, I had its regulatory department review the design documentation and test data to flag any missing information that would be required later for regulatory submittal. If a team member with a stake in the activity’s result is not available, you can do the buddy check yourself—but make it clear that it’s not a performance appraisal. It’s just one team member looking out for another.
2. Collect Performance Data
A few companies have project management information systems that automatically generate reports. If you have access to one, by all means use it—but also seek out performance data through short pulse meetings, where team members share status updates on activities and assess risks, either face-to-face or virtually. I limit these to 10 minutes and discuss only the tasks started or finished since the last meeting. The purpose is to get a quick sense of where things are, not to roll up sleeves. If the team identifies any problems or risks, I resolve them in a separate working session with the appropriate individuals.
I normally pulse projects on a weekly basis, which allows me to track progress adequately and identify problems in time to respond to them. However, when a project is in crisis mode, the “pulse rate” quickens. I once managed a project in which the power system for a new facility failed three days before the building needed to be up and running. An important business objective hinged on that deadline. The team worked around the clock to identify the cause of the failure, replace the destroyed component, and bring the facility back on line. All that would normally have taken two to three months, but we had three days, so I pulsed the project every three hours.
3. Analyze Performance to Determine Whether the Plan Still Holds
Activities seldom go precisely as anticipated. They may take more or less time; they may overrun or underrun the budget. A departure from your plan isn’t a problem unless it’s likely to compromise the team’s objectives. On one project, I had an engineer report at a pulse meeting that a new mold would be two weeks late. But since the mold wasn’t on our critical path and we had nearly six weeks of slack time in that portion of the schedule, the team didn’t need to take special action. If the late deliverable had put us in danger of missing an important goal, I would have called a meeting with the appropriate team members to figure out a solution.
This is the time when careful project planning pays dividends. Knowing the critical path will help you decide which issues warrant a schedule change. If you’ve identified risks up front that could undermine your objectives, you can more easily recognize which snags are threats to the project’s success. Having estimated each activity’s duration and costs and carefully noted any uncertainties, you’ll be able to distinguish between variances that aren’t a big deal and those that suggest larger underlying problems.
When a plan does need revising, you may have to extend the end date, apply budget reserves, remove deliverables from the project’s scope, or even cancel the project. On one software development project I oversaw, we had an excessively “buggy” first release. Before trying to fix the software, I quickly checked the requirements document and realized that the developers were using an out-of-date version. We had to reschedule the software development task for that module, causing us to delay project completion by about a month, but the change clearly needed to be made.
4. Report Progress to Your Stakeholders
Some project managers and team members perceive stakeholder reviews—which involve preparing reports and conducting progress meetings—as wasted effort because they take time away from other activities. However, if managed properly, these reviews propel a project toward success. There are three types: management reviews, tollgate reviews, and technical reviews. For all three, record and circulate action items, and keep meeting minutes in the project file for future reference.
The purpose of the management review is to manage risk. Stakeholders may examine several projects at a time to see if the portfolio as a whole will generate the desired business performance and to identify systemic weaknesses. They’ll look at individual projects on their own merits as well. Such reviews are normally held at regular intervals—monthly, for instance. When conducting them, keep in mind that your stakeholders care about reaching business goals, not about following the team’s day-to-day activities. I recently attended a review where the project leader spent nearly 30 minutes describing technical designs the team was considering and testing, which only bored and frustrated the stakeholders. Instead, he should have spent five minutes telling them the project was on schedule (it was), that the team had made progress on its technical analysis (it had), and that no new risks had been identified.
Creating a project dashboard is a great way to summarize your objectives and show stakeholders whether the project, as currently planned and managed, will achieve them. (You can break it down into components such as schedule, cost, and performance.) This is often called a stoplight chart, since it usually indicates activity statuses in red, yellow, and green. Most companies have a standard format to help senior managers quickly and efficiently assess progress and risks on many projects. When using color coding, make sure everyone understands exactly what each color means. For example, do you list all incomplete tasks in red? Or are some of them green, because the plan for completion is approved and underway?
When you need to report bad news in a management review, always couch it in terms of risks to project objectives. Explain how certain task delays will prevent the team from realizing project goals on time, for instance, or how a resource shortage will reduce the rigor of an activity and thus the quality of its deliverable. When you present problems, also give options for responding to them and discuss the risks associated with each solution. The stakeholders will decide which risks they want the business to take.
The tollgate review (also called the stage-gate review, or phase-gate review) is a decision meeting, not a status check. It’s used when a business plans and executes projects in discrete phases. In it, the project team summarizes the results of the preceding phase and presents a plan for the next phase. The stakeholders assess the plan, options, and risks, and then decide whether to approve, redirect, or cancel the project. If they say to proceed to the next phase, they also provide the team with the necessary resources, including funding.
At a technical review (sometimes referred to as a peer review), an independent team of experts—internal or external consultants, say, or representatives from a regulatory agency—provides an in-depth analysis of project results. The purpose is to ensure that team members did the work accurately, completely, and to the right quality standard. Stakeholders may give a stamp of approval at this time: If the team has successfully completed one phase of the project, it can now proceed to a tollgate review for approval to begin the next phase.
5. Manage Changes to the Plan
When revising a plan, you may make major changes or just minor tweaks that will allow the team to meet its objectives.
If you propose major changes to your stakeholders, spell out the costs and risks of adopting them and those of sticking with the original plan. A defense contractor that I work with was asked by the Air Force to improve performance of a weapon-system component. After the Air Force reviewed the proposed options (which included costs, risks, and schedules) and selected one, the contractor synchronized updates to design documentation, manufacturing processes, supplier contracts, the project schedule, and the budget so the transition would be as seamless as possible. When making such large-scale revisions, record them (along with the rationale) on some type of change log in the project records. You can use your normal project-planning processes and techniques to revise your plan. Send the new plan to your team members, and explain any changes that affect them.
Minor changes may come up as you’re implementing a contingency plan or working out details of a portion of the project that was planned only at a high level. The project team can usually manage these on its own, without seeking stakeholder approval, unless the changes will directly affect stakeholders or their departments.
As you’re monitoring your project, remember that meeting your objectives trumps everything else. Don’t get hung up on compliance with the original plan. In my experience, almost every project plan must be revised at some point—especially when you’re developing new products or systems, because what you learn in the early stages sheds light on how later-stage tasks should take shape. Don’t be afraid to change course if it will bring you within reach of your goals.
__________
Raymond Sheen, PMP, is the president of Product & Process Innovation, a consulting firm specializing in project management, product development, and process improvement. He is the author, with Amy Gallo, of the HBR Guide to Building Your Business Case (Harvard Business Review Press, 2015).
Adapted from HBR Guide to Project Management (product #11184E), Harvard Business Review Press, 2013, pp. 127–134.