What and why and when: the secrets of benefits realisation
In 1902, Rudyard Kipling wrote:
‘I KEEP six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.’
Programmes frequently fail to deliver benefits because of too much focus on ‘what’ and ‘how’, and too little on ‘why’ and ‘who’.
The philosophy of questioning has been around since Roman times, and probably before then. It seems simple enough. Zachman’s framework draws upon this, intersecting the very same questions with a number of viewpoints that represent business, concepts, logic, physical design and so on. Just as it makes sense to clearly understand why change is needed before considering what to change and how to do it, so it also makes sense to look at business needs before focusing on common principles, semantic and logical models, or designing solutions. I appreciate a degree of iteration is usually required, and there are different ways of doing that. However, the more methods are relied upon (whether Agile, Waterfall or some hybridised Agile Waterfall, or Cascading Agile) the more attention is drawn away from the six honest serving-men. It’s necessary to keep coming back to them: why is this change programme being undertaken? What should it be focused on and improving? And keeping those questions in sight throughout.
The problem with waterfall methods, is that once the business case is done, why can go out the window. After all, it’s been agreed, we all know why we’re doing it, now we can crack on to the interesting stuff. Similarly, what needs to be addressed gets wrapped up early on, perhaps summarised in an Invitation to Tender if going through an OJEU route. The focus shifts to how change will be delivered, at what cost, and as soon as attention is taken away from why and what, Pandora’s Box begins to open.
I’ve done any number of project reviews, which come back to the same issues. The act of delivery has drifted away from why the project was embarked upon. Sometimes this happens because of spiralling complexity, or too many documents and technical deliverables. Sometimes it happens because of a shift in language and thinking, from business to technical, leaving sponsors struggling to understand the jargon. Sometimes it happens because of a shift to the project manager’s agenda, where success is measured by getting the job done and dusted and ticking the delivery box, rather than getting left holding the awkward ‘business benefits baby’ at the end.
There are essentially two ways to manage business benefits. One is by leaving the job to the end, and revisiting the business case, cross-checking what got delivered against what was (possibly) wanted. This is a common approach where contracted delivery is involved. The other way is to ensure the ‘honest serving-men’ are present throughout, doing their job properly. Which makes more sense? At this point, many will turn to their project management manuals, looking for guidance. None is needed. Instead, think about what questions you need to ask, and keep asking them. If the Invitation to Tender documentation doesn’t make clear why something is needed, or what it is needed for in business terms, there is probably a problem already. It is so common to encounter tender documentation where all the detail is concerned with how, who, where and when. Being unclear about why a change is being made, and failing to make that equally clear to a supplier, means that neither party really knows what they want to get out of the contract, and how life will be better afterward. If why and what are clearly thought through and set out, and can’t be drilled into any further, then they must be kept at the table throughout, constantly checking whether what is being done is going to meet those particular needs. This requires the ability to scan across and down (in Zachman terms), dealing with different levels of detail, and being able to ask really awkward questions whenever needed.
If benefits are tracked throughout all stages of the project, and continue to be tracked during adoption and performing (if those are not viewed as part of the project), there likely to be less surprises and stalling. How many projects make benefits realisation a work package or task that runs throughout, from the very outset? The six serving-men are needed at all times. So benefits realisation commences with an audit of the business case, the invitation to tender (ideally before it goes out), the responses and at all stages of delivery.
Because project sponsors tend to have much less involvement once the job is in hand, why and what questions get asked a lot less. Those concerned with how, who etc., want to get on with delivering and there is a natural reticence on their part, for questioning why they are doing something. Someone else needs to have that job, as part of the team, whether the project director, or an independent source of assurance.
There are lots of methods for how to go about analysing whether benefits are being realised, or have been realised. Some can be very detailed financial audits of every operational aspect before, during and after change, such as the CLG Financial Benefits Realisation Tool, which enables local authorities to estimate the savings to other departmental budgets generated by Supporting People services. Where benefits realisation has not been planned into the change process from start to finish, it will require retro-fitting and this can be an awkward process, disentangling why and what from the rest, rummaging through project and proposal documentation, and quite often, dealing with changed circumstances. Think of the different dimensions that comprise benefits. Hard, easily measured indices such as financial savings, and the more difficult to measure such as customer satisfaction, which may require surveys, and difficult to trace back directly to causes.
At the end of the day, the entire reason for undertaking any project, or any change initiative, is to realise benefits. These are the whole purpose of the endeavour, not new functionality, processes or ways of doing things which are merely a means to the end. For that reason, substantial attention should be paid to benefits realisation throughout and it should be seen as a fundamental driver of the overall management process, and not measuring for measurement’s sake.
Let me know your experience with benefits realisation, and your success stories.