Project Monitoring, Analytics, and Control

This chapter provides a detailed overview of the processes involved in monitoring and reporting project performance.

What to Monitor and When to Do It

When setting up monitoring and controlling systems for a new project, it's essential to keep in mind that not all projects are the same. What works for one project might not work for another, even if both projects seem similar. Also, the amount of monitoring and controlling required might vary with your personal experience. If you've never worked on a particular type of project before, the work involved in setting up a reliable monitoring and controlling system will typically be much greater than the up-front work required for a project that you've done many times before. For projects you repeat regularly, you'll typically have standard processes in place that will make it easy for you to keep an eye on the project's overall performance.

Learning-Based Project Reviews

Sometimes upper management owns the schedule of the project and requires ongoing assessment and monitoring in the form of project reviews, which typically have members of a board "sitting at a horseshoe-shaped table" while "a team member stands in front of them and launches a presentation". The problem with such reviews is two-fold: 1) they can be somewhat severe and punitive, and 2) they can tear team members away from working on the project itself.

In their book Becoming a Project Leader, Laufer et al. describe a learning-based project review, which makes reviews about troubleshooting problems rather than assessing performance. Laufer et al. describe the experience of Marty Davis, a project manager at NASA's Goddard Space Flight Center, who "developed a review process that provided feedback from independent, supportive experts and encouraged joint problem solving":

The first thing Marty Davis did was to unilaterally specify the composition of the review panel to fit the unique needs of his project, making sure that the panel members agreed with his concept of an effective review process. The second thing he did was change the structure of the sessions, devoting the first day to his team's presentations and the second day to one-on-one, in-depth discussions between the panel and the team members to come up with possible solutions to the problems identified on the first day. This modified process enabled Marty Davis to create a working climate based on trust and respect, in which his team members could safely share their doubts and concerns. The independent experts identified areas of concern, many of which, after one-on-one meetings with the specialized project staff and the review team's technical specialists, were resolved. The issues that remained open were assigned a Request for Action (RFA). Eventually, Marty Davis was left with just five RFAs.

This kind of approach to project reviews ensured a supportive, failure-tolerant environment, and with its emphasis on continuous learning, had long-term benefits for each team member.

Exactly which items you need to monitor will vary from project to project, and from one industry to another. But in any industry, you usually only need to monitor a handful of metrics. There's no need to over-complicate things. For example, when managing major construction projects for the Wisconsin Department of Transportation, Gary Whited, focused on these major items:

  • Schedule
  • Cost/budget
  • Issues specific to the project
  • Risk

He also recommends monitoring the following:

  • Quality
  • Safety
  • Production rates
  • Quantities

In other kinds of projects, you will probably need to monitor different issues. But it's always a good idea to focus on information that can serve as early warnings, allowing you to change course if necessary. This typically includes the following:

  • Current status of schedule and budget
  • Expected cost to complete
  • Expected date(s) of completion
  • Current/expected problems, impacts, and urgency
  • Causes for schedule/cost overruns

As Whited explains, the bottom line is this: "If it's important to the success of your project, you should be monitoring it".

Note that measuring the percent complete on individual tasks is useful in some industries, where tasks play out over a long period of time. But according to Dave Pagenkopf, in the IT world the percent complete of individual tasks is meaningless: "The task is either complete or not complete. At the project level, percent complete may mean something. You really do need to know which tasks/features are 100% complete. But sloppy progress reports can generate confusion on this point. 100% of the functions in a software product 80% complete is not the same as having 80% of the features 100% complete. A poorly designed progress report can make these look the same, when they most definitely are not".

In addition to deciding what to monitor, you need to decide how often to take a particular measurement. As a general rule, you should measure as often as you need to make meaningful course corrections. For some items, you'll need to monitor continuously; for others, a regular check-in is appropriate. Most projects include major milestones or phases that serve as a prime opportunity for monitoring important indicators. As Gary Whited notes, "The most important thing is to monitor your project while there is still time to react. That's the reason for taking measurements in the first place".