Author: Mike Morton

But no! The same KPMG study tells us that only 9% of organizations regard completing projects within budget as their most important success measurement. And just 21% are driven by a need to finish a project on time. You begin to wonder what are their criteria for success, if time and money don’t enter the picture.

That was back in 2002. Sixty-seven per cent of respondents in the survey mentioned that their program management function was “in need of improvement or immature” and only 44% rated project performance against any established measures. I wonder what we’d find it KPMG were to undertake the same study today, five years later.

But let’s go back to the figure of $1.7 billion in project failures that I mentioned earlier. I would submit to you that the number grossly underestimates the financial impact of failed projects. Let me explain.

Self-reporting and the definition of failure

For starters, project performance is usually estimated by surveying managers and executives, often the very people responsible for the failed project they are asked to talk about. It is reasonable to assume that self-reported project failures and the associated cost implications are somewhat muted. That’s is just human nature.

The next question is, of course, what exactly constitutes failure? Is it a project that is admitted by management to be a complete failure? Is it a project that failed to address the full scope?

The latter definition would probably include most of the projects out there, while the former will only include a small percentage of projects, since it usually really takes a spectacular failure for a project to become deemed as such. I am sure many of us have experienced a situation when a barely passable project was proclaimed a huge victory. Sound familiar?

Given this, I believe that the number of failed projects is wildly understated right across the board.

Opportunity costs

Let’s now consider a project on which an organization spent one million dollars and decided to close with no salvage value to its assets or deliverables. What would you say that project cost the organization? One million, right?

Well, I think this is how many failed project costs are reported in surveys. However, this number only represents a small part of costs incurred by an organization when a project fails. I am talking about opportunity costs.

Opportunity costs are the costs of foregoing something given the selected course of action. For instance, if a working individual elects to pursue a two-year university degree full time, the cost of this decision will not only include the tuition and auxiliary fees but also the lost employment income for this period, the latter being the opportunity cost of this decision.

In projects, opportunity costs come in two fashions.

To start with, it is fair to say that projects are often undertaken in order to realize a business opportunity, such as to enter new market, to develop new product or service or to improve existing product or service in anticipation of higher profits. If such a project bombs…none of this will happen. The unrealized business benefits may easily dwarf any direct costs associated with this project.

Then, there is another consideration. No organization can execute an infinite number of projects at the same time. Various limitations exist to prevent that from happening, the organization’s capacity to absorb change being one of them. Because of this, some projects considered by an organization, all with their costs and merits, have to wait their turn in the pipeline. Often, they never come get started because, by the time the organization is ready to execute them, the business opportunity is no longer there. Let’s say project A is executed before project B, but project B is dependent on the success of project A. If project A fails, project B is no longer valid. Thus, the cost of the lost benefits that project B might have delivered should also be counted in the costs of project A.

It is quite clear that lost opportunity costs, however substantial, are not included in reported failed projects’ costs. They are not as easy to arrive at as direct project costs and, frankly, it is simply outside of many managers’ skill set. But maybe it’s time that this capability became part of the manager’s essential qualifications

So, how much are all these failed projects costing the world economy? I think that the number is much higher than what we’re being told…and the exact number of failed projects…will we ever know?

The more likely scenario is that the project is being promoted by one or two groups within the organization, who feel a burning need for it, and a much larger number of people who feel they will be affected by the deployment, and want to get their requests for functionality or control into the project before early on. This makes deploying a “vanilla” install or a default system less desirable in their eyes.

The clues that this is what we will be facing often come early. A Request for Proposal (RFP) arrives and, as we dissect it to try to determine what the client really needs, we find lists of functionality that don’t seem to have any consistency. There are similar or identical functions listed more than once, but written in a different language each time. There are requests for functionality that are diametrically opposed. (e.g. “All data in the system must be completely centralized.” and “The system must allow for data to be autonomously managed in a decentralized fashion”) When we see this sort of thing we know how the RFP was created: By committee!

For those who may never have suffered through this kind of exercise, you can only imagine how tough it is for the person heading the committee. They have probably been with the project since the early days and are committed to see the new enterprise system deployed within the organization. When the project started it was a small group of like-minded people but, as the project progressed, more and more divergent points of view arrived. Just to construct the RFP, numerous points of view now had to be represented – and this is the document that is sent out to happy contractors like ourselves!

When we arrive to do the work, this can be a tremendous challenge. First, we have several perspectives to satisfy before the project can be declared complete. If we’re doing a timesheet system, we may have the project management department, the payroll department, the HR department, the IT department and senior management, all lobbying for their particular interests. What if some of these interests are in conflict?

So, we start from the vanilla perspective. What would this system look like if it were installed as delivered? The publisher, after all, has likely spent a fair amount of time making sure the system has some usefulness from the moment it’s installed.

This is the baseline install. The closer we can keep to this baseline, the easier it will be to do upgrades, create training material and generally, to deploy the product. The more “vanilla” it is, the more materials we’ll find from more suppliers that can help with training, configuring, third party assistance, and more. The more we customize what we’re working on, the closer it will get to the vision of each of the interested parties. It’s a series of trade-offs that have to be negotiated.

It’s easy to see the result when the implementation goes too close to one extreme or the other. If you go to close to the default install and your users are unlikely to adopt. The system may not be close enough to what’s familiar. If you go too much on the customized side, the system may never deploy. The further you get from the default install, the more effort is required just to get the system functional. Moreover, when you then turn to the publisher for assistance, they’re handcuffed. The system gets to be so far away from the baseline that the technical support people are hard-pressed to know how to answer any questions on it.

So, how far along the flavored path should you travel away from the baseline vanilla?

You can start the conversation at either end and work towards the middle. For an organization that is interested in long-term deployments, the best place to start is at the highly flavored end of the conversation. You’ll find plenty of people in this corner convinced that their way is the best way, and only want to hear how you’ll do it their way. In the ultimate scenario, you’ll be able to place numerous programmers for an extended amount of time to write the perfectly matched EPM or Enterprise timesheet system.

At our firm, what we train our technical people to do is to start at the other end; from the vanilla end of the scale. We start with a default system and then look to justification for each change. We let the client and each faction know that we’re prepared to adapt to anything they require, so that we don’t generate resistance on the first day, but every change needs to have some business purpose. Note that I didn’t say some “functional design”. No, it’s got to serve a business purpose. So, when a future user says “I need a dashboard that shows this data color coded by age”, we ask “What business decision will you be able to make or be able to make easier if you had that?” Often the reply is “We’ve always done things that way” which is not, of course, a good business reason.

A couple of years ago during an EPM configuration, I was presented with a collection of reports and told that the client expected all these reports to be represented in the new system. It was an intimidating list of 212 reports and I’m sure just collecting the report samples must have been a significant task. I looked at the several inch thick pile of paper samples with some dismay imagining the weeks it was going to take us to recreate them all.

My response to the client was this, “We’ll be delighted to do these reports for you. But, first, would you please arrange it so I can speak to the readers of these reports to determine what business purpose they’re used for.”

Needless to say, finding such people was a challenge.

In the end, we did only 12 of the 212 reports. We couldn’t find an audience for the rest. ‘Why were there 212 report samples then?’ you ask. ‘It’s the way it’s always been done and the way we want to do it forever,’ is the answer.

Should project managers take note? You bet! The role of the BA is fast becoming the key to successful project management. A project manager who thinks he or she can do it all – without the aid of the BA – is old school. And I think the organizations that think the PM can do it all are not only old school, but in danger of loosing good PMs as well.

For years we have been asking PMs what hurts you the most? The answers were always, ‘lack of executive support’ and ‘lousy specs’. The former problem is still a work in progress. The latter should be going away as we type and read. Enter the business analyst. This is the architect – the designer. This is the one who will discover and document the client’s requirements, run through a series of designs and produce the detailed specifications for the PM to build from. Finally!

Where to from here? The role of the BA will become more and more important. The BA will become more senior within an organization. The Business Analysis Body of Knowledge will go through a series of versions over the coming years and soon ‘Certified BAs’ will be in high demand.