Projects should add value, not just cost money

Save for later

Favourite

I suppose it is not much of a surprise to hear that here, at the Value Management Special interest Group (SIG), we've become quite interested in noticing where value comes from. 

In simple terms, the project includes a 'business case', and I know we all know this, but let's spell it out anyway, that business case sets out what we'll get for the capital money and time and effort we are about to expend. The return. The 'return on investment'. (ROI). The APM Programme Management SIG and Benefits Management SIG have refined this further. To: the benefits that'll be realised. We at the Value Management SIG say:

Value is a ratio of benefit / divided by the resource required.

And we lend our smaller voice to that of Her Majesty's Treasury, who set out this goal for Government projects in their publication, "Investment Appraisal", also known as the green book, (it has a green cover!)

Regrettably, some projects don't add value. An audit of public sector projects by the OGC in 2005 (now the Efficiency and Reform group of the cabinet office) found that 45% of projects offered no benefit. Before we apply a public sector stereotype speculation to the possible cause, we ought to bear in mind, that public projects are available to a transparent audit, while commercial sector ones are not.  It's not likely to be any better in the commercial sector. 

What we might also notice is that the OGC is auditing projects by whether they added benefit, not the previous method of charting whether they hit their budgets of: time, cost, quality.  A project might reasonably increase its costs (and do this via change control) in the pursuit of a better value outcome. 

More recently the ISO55000 for asset management also placed the emphasis for asset maintenance on 'value', value that arises when pieces of plant and equipment are replaced or upgraded to offer cheaper running costs, in spares, downtime and energy. Or indeed better performance for the business, in something such as: faster production.

We think this is important, because will think projects should add value, not just spend money. And it is this value goal that sets project work apart from other types of work.  Not that other types of work don't add value, but that in a project the value goal is explicitly focused. So if projects don't add value, it's a project management failing.

And this might offer some clues as to why projects, when they all too often did, failed to deliver benefit. As Reiss points out in his book "Programme Management Demystified"...

"...projects might be considered to deliver 'products' which merely offer the potential for new capability, which only when that capability is exploited might it create benefit."

This illustrates how projects are some way distant from the benefit realisation case that got them started off. 

Some folk say that this benefit management malarkey is the sole province of the programme office, and not the project manager.  But it rather appears that value is at the centre of the project management task, not a thing prior to the delivery activity and post commissioning that is left to someone else. The potential disconnect appears too great a risk to lose the continuity. 

So instead of 'business case', I wonder if we might adopt the term 'value or benefits case'?

 

default

Posted by John Heathcote on 18th Feb 2016

About the Author
I have a 22 year work experience in projects ranging from asset management to civil engineering to business change. I am course leader of the MSc in Strategic Project Management & the MSc Project Management at Leeds Metropolitan University.

{{comments.length}}CommentComments
{{item.AuthorName}}

{{item.AuthorName}} {{item.AuthorName}} says on {{item.DateFormattedString}}:

Share this page

Login or Register to leave a comment:

Recommended Blogs

View

Save for later

Favourite

Back to bite you

4 October 2016

View

Save for later

Favourite

Recommended News

View

Save for later

Favourite

Join APM

Sign up to the APM Newsletter.