Managing and Monitoring our Project – how do we know it’s on track?

AbleSim’s Andrew Bell wrote an entertaining article about project baselines which has surfaced recently. It says that we use plans and actuals to decide where to take corrective action.

Bell’s article was about cost and time. That’s a simple way of looking at it. A project that’s running late could be under cost at a specific time, and the project manager could be congratulated for being under budget, when in reality it's because s/he hasn’t done anything.

Costs and Earned Value

Earned Value (EV) is one way to measure progress. Earned Value (at its simplest) is a value assigned to each phase or milestone of a project – often the budget for that stage. There are nuances, but it’s a start point.

Now we can compare progress against plan, as well as costs against plan. Where they differ, we have a problem.

In the chart above, costs are below planned costs in Jan, Feb and March. But Earned Value is worse. The project manager shouldn’t be congratulated – this project is late!

Earned Value is a measure of progress. The crucial question is WHY - why are we doing this project? (CLUE – it’s in the business case).

The WHY of projects – Benefits

We do projects to get benefits:  

• New opportunity (get an idea to market; or save costs with technology).
• Overcome an obstacle (new regulations mean that we can’t trade unless we change).
• Politics (if the money is spent in my department then my department becomes bigger which makes me more important) but let’s not talk about the politics benefit in this article.

Sometimes one big benefit isn’t sufficient, and other benefits are needed to justify a project. An “A-List” of benefits (planned benefits) makes up the business case. The benefits should add up to more than the cost, otherwise the investment isn’t justified. In the author’s opinion, the organisation making the investment should count direct benefits to itself – in the case of government, increased revenue from tax (which may result from the improved quality of life or increased economic activity) – when justifying investment. There may be other benefits, valuable to other stakeholders. Dis-benefits or negative benefits also fit in.

Value and Return on Investment vs Benefits

Value is usually calculated as a ratio – Benefits / Cost, or how many times we get our money back from this project. It can also be calculated as an excess – Benefits minus Cost.

Benefits may not all be financial (although there are ways to prepare financial figures for soft benefits for example using SROI), and the costs may not all be financial either, so Value can be nuanced.

Return on Investment can be either the Value ratio above, or more usually, the length of time before we get our money back. Eg we invest ￡100,000 today, and it takes 20 months before the benefits add up to over ￡100,000. Our return on investment is 20 months.

All of the above should be adjusted for risk – risk to the organisation (eg from cash flow challenges or reputational damage); risk to delivery of the project (what could go wrong); and risk to benefits (did we estimate them correctly in the plan? Did we realise them optimally?).

Let’s assume that the benefits are planned and calculated correctly (which is a whole subject in itself – see for example this excellent guide by Kenn Dolan). With good systems, we can track whether benefits are being realised or likely to be realised. In other words, we can tell at each review whether it’s worth continuing to invest resource, or whether the project should be stopped.

Benefits take time. An IT project starts with spending money - buying new computer equipment and software, customising the software, and training users (see cash flow in the chart below). Then the new system starts being used. After this, we (should) get cost savings (and measure them). 

During the project, we can forecast benefits using ‘Lead Indicators’. Functional reviews say how well the new IT system meets the need, and focus groups tell us how acceptable it is to users. We haven’t got actual savings, but we still have time to take corrective action based on our forecast.

In the cost example above, there are probably lots of separate costs. There’s a budget and a profile over time for each cost. Benefits are the same: there’s a total benefit, and a profile over time for each benefit, made up of lead (forecast) and lag (actual) measures of benefits.

Benefits (see presentation by Kik Piney) are (arguably) a more useful way to measure project progress than Earned Value, but they come later, which is why many organisations continue to use Earned Value for the earlier phases of a project.

Benefit Profiles and Benefits Registers

A benefit profile is a template to record information about each benefit. It should include

• how we are measuring,
• what the planned measurements should be, and
• what they mean for the success of the organisation. 

It should have a space to record what is actually happening. 

The difference between the plan and actual tells us whether we need to take corrective action and how. Dolan’s book gives examples of templates for benefits profiles.

A Benefits Register contains a summary of each Benefits profile, in effect it’s the sum of all the Benefits. It may have a profile of all the benefits added together.

Understanding Benefits means understanding success

This gives a table with a minimum of 6 columns:

• Costs – planned and actual
• Earned Value (amount of project delivered) – planned and actual
• Benefits (what’s being achieved by the project) – planned and actual

It should end up looking like this (using cumulative values) (note that costs have been shown as negative and benefits as positive):

The purple line, Planned Cash Flow, shows how much money we need to borrow at any one time. Once the benefits start, then they reduce the amount of money borrowed. In this example, Return on Investment (when the money from benefits is at least as much as the costs) is at 20 months (August 2020). For longer periods we may need to use NPV (Net Present Value) calculations, but the adjustment is usually fairly small.

Is it starting to look complicated?

Once upon a time, we could see how much money we had by counting it. That was always a fairy tale: we had to take into account how much money we owed, how much money was owed to us, to get the real picture.

It’s the same with delivering a project. When are we spending, and when are we earning? What’s actually happening, and how does that compare with the plan? The above table of 7 columns (including cash flow) is about as simple as it can get, unless we skip Earned Value.

Forecasts and Corrective Action

Using the above information, a skilled benefits manager can show what would happen if one part slipped a bit. If something is running late, all benefits that depend on it will probably be delayed. How much is it going to “cost” (lost benefits)? Therefore how much resource to focus on bringing the project back up to plan? See two of my other articles: <prioritisation> and <scenario planning>.

Using an Excel spreadsheet

Many organisations use an Excel spreadsheet to manage all of this information. A competent Excel user can create a series of Excel spreadsheets that record the information for the cost of each part of the project, and add them together. They can even add them together for each month or quarter, allowing for changes to the plans. They can do the same for the benefits – how each one is performing or delayed, and add them together.

But this costs – sometimes a lot. First, there’s the cost of maintaining the spreadsheets for each project, and sometimes very complicated changes when new costs or benefits emerge. Benefit profiles may need to be recorded for years after delivery. Then there’s the risk that an error creeps in, and that nobody spots the error (because of complicated formulae – “0” could mean no data or it could mean a number 0, which are fundamentally different). And it’s highly likely that the spreadsheets for one project can’t be reused for another because it’s too complicated – more expense with each project.

Conclusion

To run a project successfully, it’s no longer sufficient to be a strong leader; a good project team needs to manage information, and lots of it. They should be able to compare what’s actually happening with a plan. They will track what’s happening with costs, with project progress (summarised in this example as Earned Value), and with benefits.

For successful projects, this is pretty much the minimum information needed.

Benefits should be recorded in one or more Benefit Profiles, and summarised in a Benefits Register. A single project or programme may create a number of benefits, and each will have a planned, and actual, return profile. 

When part of the project is running late, any dependent benefits will be delayed. This should show up on a forecast. With the right information, the project team can correct it; small spend for minor consequences, larger spend for greater consequences.

Getting it right leads to greater success. Getting it wrong can be costly.

Dr Hugo Minney is a transformation and change specialist, who writes thought leadership on benefits management.