Is this scenario familiar to you ? Someone in the organisation comes up with an idea.

"It would a good idea" they say, to implement a CRM system or an ERP system or an order management system or a significant new web site. Or "if we introduce CMM/CMMI our software process will be better or if we adopt PRINCE2, our project management will be more systematic and successful because we'll be using 'best practice'".

Your CEO, Managing Director or other senior officer may have read about a new technology or sat next to someone on a recent air flight who told them about the new IT system or methodology they were implementing. "We must have that" your senior officer announces upon their triumphal return.

Sometimes the process that follows is as simple as: propose the project, get the go-ahead and... we have a project! Sometimes it's not quite as simple as that.

We need a Business Case
Although a senior manager has asked you to take on this project, they most probably added "Oh, and could you come up with the business case so we can get it through the financial approvals". Internal procedures may insist that when a significant spend or use of resources is involved, then a written Business Case must be submitted for review and approval before the go-ahead is given.

Now we need a Justification
But in order to build a Business Case, we need to understand the justification for the project. Is the project expected to result in the organisation making money or will it enable the organisation to save money?

Or, is it anticipated that the justification is to be non-financial benefits? For example, improved quality, improved management control, better customer service, better management information?

Are we all guilty?
What frequently happens at this stage (based on guilty personal experience and observation of many commercial and public sector organisations), is that the Finance Department is called upon for help.

Discussions take place along the lines of... "surely if we do this project, we could save 10% here and 5% there. Perhaps we could expect a 10% increase in customer orders because our customer service (say) will be better or we would be more efficient"?

And if all goes well, the collection of savings and other benefits we happen upon add up to big enough figures in the Business Case to cover the costs and predict a pay-back within the time scale stipulated by our organisation's investment procedures. We have a justified project!

Did we get what we paid for?
Further, procedures may call for some assurance that the promised project benefits will be reviewed and confirmed as having been achieved at some decent interval after completion of the project. The occasion for examining the actual benefits delivered may be the Post Implementation Review (PIR) called for by project management methods such as PRINCE2.

PIRs are most frequently observed in the breach rather than in actuality. Few organisations carry them out as intended, if at all.

With good intentions, some project managers or their teams may write-up a "lessons learned" document. That document will normally detail what worked or did not whilst carrying out the project. It will be dutifully filed. However, it isn't intended as a review of the business benefits received in return for the expenditure of funds and resources, and the time invested.

The obvious approach is to compare the project's actual outcomes with those anticipated in its Business Case. Obvious yes, but easier said than done.

In the case of PRINCE2 and similar methodologies, the PIR is the first occasion upon which Business Case theory and the real world encounter each other. The usefulness or otherwise, of this occasion will be discussed in a moment.

In some organisations it's not clearly established as to which function has the responsibility for carrying out PIRs and... PIRs can be a sensitive subject. There's the question of accountability for the organisational resources consumed in return for the outcomes promised by those who sponsored the projects.

But who is Accountable?
Accountability for the success of a project may be a difficult concept to apply these days. Conventional project life-cycles are of many months or years which in these times of rapid organisational change, means the original sponsors have probably moved on in the interim, bequeathing their projects to their successors.

It may be that the most senior person with the longest association to the project ends up being the project manager. However, project managers whilst accountable for day-to-day execution of the project, are rarely (in conventional project management theory) responsible for the project's business success or otherwise.

In organisations undertaking many projects, success and status can become indicated (unofficially at least) by a manager's ability to acquire capital to fund projects rather than by the value returned to the organisation by those projects. The lengthy times scales of conventional project life-cycles coupled with career mobility within organisations, sometimes means the accountable person is no longer around... particularly if the project has turned ugly.

How would we know?
So how would we know whether a project has been successful or not? PRINCE2 recommends carrying out a PIR  to determine whether the project delivered the promised benefits or not. The only problem with a Post-Implementation Review... is that it's too late to be of any use. The project has been completed and closed.

The project may or may not have returned useful benefits in relation to the organisation's investment. Perhaps, few organisations know one way or the other. Frequently quoted statistics by industry analysts suggest most (70-80% or so) projects fail. Disappointing projects tend to be quietly forgotten and melt away into the corporate background. 

Apart from earnest pledges to "learn the lessons" ready for the next projects, PIRs would appear to have little if any value to offer especially in discouraging the traditional Business Case games played to justify projects.

On Project Failure
It's also worth noting that the decision to justify, approve and carry out a project in an organisation is a sequence of steps, any of which could be the weakest link in that chain.

There is much criticism of the perceived high failure rate of projects (eg. IT system development, system implementation, business change. etc). The 'usual suspect' for project failure is the implementation stage.

However,  it is clear from the processes sketched above, that a poor business justification can doom the project to business failure before it leaves the drawing board, no matter how brilliant the project manager or the implementation work.

Is there a better way?
You may have noticed the fundamental weakness in this traditional approach - an approach which despite its fundamental weakness has been practiced for many decades and continues to be practiced in commercial businesses and public sectors across the world.

The fundamental weakness of the traditional process you may have noticed is that... it's backwards. It starts with a proposed solution - and then sets out in search of a problem. Perhaps managers don't realise that the techniques for a more effective approach are available.

Is there a better way? Of course. We have a set of articles on their way explaining it.

 _____________________________