The Green Book is, for some, akin to a Bible. It’s 118 pages of guidance on how to work through the costs of a project (not to mention 130 pages of guidance available on how to move from SBC to OBC to FBC – you get the ideas).
Across government, departmental approval bodies revere the Green Book with its detail on NPV, risk assessment, Monte Carlo models and benefits realisation. The Green Book is for all projects covering whatever kind of policy outcomes are relevant – providing benefits to the right people, improving water quality, connecting communities and, of course, IT.
Despite all of the comprehensive guidance contained within it, the outcome of many projects suggests that risks aren’t properly evaluated, that costs are not fully calculated and that the outcomes expected don’t always occur. Recent experience with ever inflating HS2 numbers demonstrate that only too clearly. That said, trying to forecast costs many years out has never been easy (and the error bars increase with every year) – and in case you think government doesn’t think long term, the Green Book contains a table that shows how you would discount cost of cash out 500 years.
Some paragraphs in the Green Book show how far we have to change to make the move from traditional project delivery to an approach that is faster, lighter and more agile:
5.61 There is a demonstrated, systematic, tendency for project appraisers to be overly optimistic. This is a worldwide phenomenon that affects both the private and public sectors.Many project parameters are affected by optimism – appraisers tend to overstate benefits, and understate timings and costs, both capital and operational.
Optimistic? Really?
Or how about this:
6.23 Implementation plans should be sufficiently complete to enable decisions to be taken on whether or not to proceed. So that evaluations can be completed satisfactorily later on, it is important that during implementation, performance is tracked and measured, and data captured for later analysis
Perhaps the get out here is “sufficiently complete” – one man’s sufficient is another person’s hopelessly inadequate. But entire business cases are routinely laid before approval bodies right across government that claim to have looked ahead 10 years and figured out what will happen year to year at a sufficiently detailed level to forecast costs and benefits, albeit with inevitable optimism. Only recently – perhaps the Olympics and, now, HS2 – has contingency been a visible and public part of budgets. It will be interesting how the spending of it is reported and tracked
And then this:
6.33 Benefits realisation management is the identification of potential benefits, their planning, modelling and tracking, the assignment of responsibilities and authorities and their actual realisation. In many cases, benefits realisation management should be carried out as a duty separate from day to day project management.
Generally the people delivering the programme are not the ones who have to make it work on the ground and so achieve the cost savings that the approval body has been promised. As it says above, “realising the benefits” is a separate duty from day to day project management. That is, then, part of the problem – delivery being isolated from the business means decisions can be taken for the good of the programme that are not for the good of the business.
None of the above is intended to be critical of the Green Book – it was very much a product of its time and perhaps where contruction of vast architectural feats such as dams and, indeed, railways that go from South to North (and back again) are being planned, it still makes enormous sense.
With a desire that IT projects be agile, flexible, iterative and
responsive to the ever-evolving user need, the guidance looks
increasingly anachronistic. If you’re not sure what functionality
you’re going to deliver when because you might replace A for B or drop C
altogether, how do you calculate either costs or benefit with any
reasonable confidence only a few months out? The best you might be able
to do is calculate the likely cost of the team – but what if it needs
to grow suddenly to deliver an identified need?
The Green Book is doubtless being refreshed now by a combination of GDS, Cabinet Office and HMT but, and it’s a big but, convincing finance directors across government that 200 page business cases with all of the options mapped out and separately costed are a thing of the past will be challenging. And interesting to watch.
“Minister, there are three options … the first two pretty much lead to nuclear war, the third will be explosive and there will be terrible consequences, but I think we will survive … I recommend the third option … do you concur?”
I think the last paragraph is the key. For IT most cases are written after the decision has been made. We know what we want to do and now we have to do the paperwork to justify the position. The key then is to only present the options you know won't pass and the one you want. Then you score it in a non transparent way and present to your approvals process. They of course have to rely upon a properly filled out case.This is an inevitable reaction to such a process. What the original process was meant to do (I assume) was ensure that the use of tax payer's money was suitably scrutinised and not frivolously wasted. Clearly the business case approach fails. The issue is that:1) They are written by a programme lead (typically) who wants the programme to progress.2) The person who submits the business case is rarely the person who has to live with the consequences.3) There is no accountability for those who approve business cases, only those who deliver them.You are spot on re benefits. I have yet to see an effective benefits tracking capability in any organisation. Interesting exercise. Take all the business case submitted to government and add up all the benefits. The savings will no doubt far exceed GDP.