Top Ten Reasons Why Projects Fail – Reason #10
Reason #10 – Monitoring and Controlling
Perhaps one of the less well understood facts about projects is that they need to be monitored and controlled. Basically what this means is that in a project you create baselines. (Let’s deal only with the schedule baseline for sake of argument). That baseline is an approved snapshot of the tasks with dates and milestones that you have agreed you will reach. So in the best case, the entire team agrees on the schedule before executing. Once they agree, the project manager is then able to assign resources and truly kick off the project.
In the government, they use a concept called Earned Value to track progress. So they report on the cost and schedule efficiency of the team in regards to the project. Once they determine if the team is working efficiently, they can then use those efficiency ratings to forecast. So, will the original budget be met or must we work to a new one? Is the schedule still viable? While this is a worthy technique, unfortunately it has not made its way much out of the federal government. And so private corporations must come up with ways of mimicking what EV provides.
Let’s say that we have a hypothetical one year project and it has now been running for two months. And the project manager as part of her job now has to report progress to her manager or even a steering committee. And as part of that she has to report actuals vs. planned. And this is the heart and soul of what monitoring and controlling is all about. Basically you are comparing planned to actual and, if need be, taking some corrective action. And so the PM must now decide how she’s going to record actuals. (We’ll use Microsoft Project here as an example. Not only am I fairly conversant in it but it is a de facto standard).
So what happens in this process is that the PM approaches the team member and asks a question. The question is frequently, “How done are you on this task or on this series of tasks?” And the team member, stuck for an answer, says, “Oh, about 50% done.” Let’s look at that statement. What does it really mean? Let’s say the team member had ten systems to upgrade.
If he completed four out of ten systems is he 40% done?
If he has worked two out of four weeks is he 50% done?
If planning showed that he had 1000 hours do to this and he spent 600 is he 60% done?
So this whole “percent done” thing is not easily quantifiable or even well understood. In Microsoft Project, you can easily record percent done as reported by a team member. But the problem on one level is that when you do that it assumes that the task started on time and has the specified remaining duration. But what if it started late? And what if the team member underestimated it and the remaining duration will be longer than he thought? Better is to record three other pieces of information, namely the actual start date, the actual time spent and the actual remaining duration. Then Project will calculate the percent complete for you. You can now compare the Tracking Gantt to the Gantt chart. If your critical path was pushed out, you can now make decisions about whether and how to pull it back in.
So you can now decide if crashing (adding resources to the critical path) or fast tracking (overlapping tasks or phases) will be the appropriate corrective action. Or can the team member work on the tasks more quickly or put in overtime. Lastly you can always decide to cut scope.
There is more to say about monitoring and controlling especially with regards to milestone monitoring. But I’ve decided to save that for a future post.
So this is the end of my series on Why Projects Fail. And if you’ve read through it in its entirety, you’ll note that it isn’t just one thing or another that will salvage a project or prevent it from failing. Rather a cornerstone of why projects fail is simple: Education. And not just education of the PM but also education of management and incorporation of project management philosophies into the company. Because unless companies shift wholesale into full understanding and adoption of project management techniques, many of their projects will continue to fail. And they will continue to wonder why.
(Next up – my multi-part series on Considerations in becoming a PMP. Wherein I try to demystify certification and answer every single question I’ve ever been asked on this subject.)