Making sure that your deliverables’ benefits are realized

With all my recent scope management posts lately, here’s a timely post on benefits realization (here) at John Gough’s iJourneys blog (here).  I like the theme of his post, that “…benefit realisation does not start when the project ends.”   I also second his point that IT sees itself as apart from the “business” and often has a leadership void at the top.  John puts it plainly:

Get Out of the Comfort Zone — There is a view…that the IT project manager delivers the project (i.e. the delivery of outcomes) but the business is responsible for building capability and realising benefits.  CIOs complain that they are too often sidelined by the business, but they do not always have the balls to … declare that: “we have taken the project this far, now give us responsibility for the business change”.

I’m not very comfortable, however, with his suggestion to:

Ditch the Business Case — The Business Case is designed to justify the project, but too often towards the end of the project, the dusty document is retrieved to “see what the benefits were”. The benefits are the project, and should guide the process from beginning to end, whereas the Business Case is just a means to an end.

My experience is that ditching the business case is what happens too often.  It should inform deliverable definition, the expected outcomes of those deliverables, the relative priority of proposed scope changes, and the benefits expected from the outcomes.  Instead, projects deliver “whatever,” the outcomes and benefits aren’t what were expected, and IT wonders why IT is “sidelined” by the business. 

Hat tip: Elizabeth at Girl’s Guide to Project Management (here)

%d bloggers like this: