by Adrian Reed

It's often said that organisations need to continually examine their environment and adapt to survive. This inevitably leads to a focus on implementing valuable and sustainable change within organisations. Change isn't always easy, and for many mid-size and large organisations with hundreds or thousands of employees, it can be extremely challenging indeed. Organisations will often, quite sensibly, take a project-driven approach to assessing, defining and implementing business change. They'll examine the status quo, establish what needs to change, execute that change and then measure the benefits.

 

If you say it quick enough, it sounds simple, doesn't it? As anyone who has ever worked on a change project will attest, it's anything but simple. Balancing varying stakeholder needs, managing risks and issues, and understanding what the business actually needs is easier said than done. There are many twists and turns along the way, and many places where projects could get de-railed. It's therefore quite understandable that senior managers and sponsors in organisations rely on dashboards showing them how their projects are performing. These dashboards help them to see whether their strategic programmes and projects on track and whether the deadlines will be met.

Projects sometimes go 'off the rails'... even when they are measured

Given this sensible focus on tracking project progress, I'm always amazed when I hear of projects that appear to have been on course to deliver until the very last minute. Everything was fine until the project hit 99% -- then there were so many complex problems  that all emerged at once. What on earth could have gone wrong so late in the project lifecycle? And, assuming progress reporting was in place, why wasn't it spotted earlier?  In some cases, there may be illusory status reporting taking place. Let me explain...

 

One dynamic that can affect reporting is ambiguity in reporting metrics. There can be subtle misunderstandings over what progress is being measured. In fact, one significant question that needs to be asked early on when a project is being defined is how will we measure progress?

 

Take the following examples:

• A task is x% complete: OK, that might be useful to know.  But what does x% represent?  Elapsed Time? Effort?  And how do we assess the difference between 95% and 99%? Is there an objective scale?   If not we might find that the final 1% takes longer than the rest of the task put together... and we'll get that sinking feeling that for the past three months we've been blind-sided by the illusion of progress.

• Milestone complete/deliverable: A useful measure.  But is the milestone correctly defined?  Is the person responsible for the milestone aware of the acceptance criteria and quality required for that delivery?  When under pressure, project teams might be tempted to tick the "Requirements delivered" milestone, even though the Business Analyst is raising serious concerns over the scope and objectives of the project...

• RAG Status: Red/Amber/Green; a useful and intuitive tool for reporting the status of tasks, risks and perhaps the overall project. Or is it? How can we be sure that my red is the same as your red?  Is there a definition?

Definition, objectivity and openness can help

Definitions clearly help.  It's also crucial to consider the human side of projects.  Some people on the project might be unconsciously optimistic, others might be more pessimistic.  There might be additional dynamics at play--in an extreme case groupthink might be a factor.  Whatever reporting mechanisms are put in place, it's vital to instil a culture where individuals feel empowered to speak up when they see problems.  Project difficulties are best solved early, and bad news doesn't get better with age!

 

Measuring project progress is clearly important, and I'm certainly not arguing for us to disregard it! However, for the most large, important and strategic projects, it is useful to supplement the type of traditional metrics mentioned above with something more objective.  Examples could include:

• Business & Customer Value delivered: For incremental/agile projects, how much demonstrable business and/or customer value have we actually delivered? Is it more or less than we planned?

• Effort spent vs effort planned/budget spent: Have we "over-spent" on effort and/or financial budget?  If so, why? There might be a good reason; if not, this could be an early warning sign that things are more complicated.  How does this compare against our overall project and the work we've delivered? Even if resource is internal, there's a significant opportunity cost with exceeding estimated.

• Projected benefits: Are we still on track to achieve all the benefits stated in the business case?  Every change to scope or delivery date should trigger a sense-check.

There are many other approaches we could take too. We could even branch into full earned value management, but that's well beyond the scope of this article. None of these measures are perfect, and the right approaches need to be selected for the project. Whichever metrics are chosen, thought should be put into how the data is collected and any analytic capability needed to work with it.

 

In summary: It's important to measure project progress. The precise metrics will vary depending on the project, and there is little point using a heavy-weight approach on a light-weight project. However, large projects need a more robust approach. It's important to consider the issue early rather than resulting to a default 'template', and it's vital to empower people to speak up when they see things going wrong.

 

What do you think? How do you measure project progress? I'd love to hear your thoughts and experiences, please add a comment below.

 

This blog was originally written by Adrian Reed as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. Adrian has been compensated to contribute to this program, but the opinions expressed in this post are his own and don't necessarily represent IBM's positions, strategies or opinions. You can read the blog on Adrian's website here.