Why Projects Fail: Part Three, Wrong Targets

Boral is now the largest brick manufacturer in the USA. To achieve this they have had to build many brick making factories. Initially, this is what they commissioned to be built #8212 a brick making factory.

Then they realized that this was not actually what they really wanted, it was the wrong target.

What they really wanted was a "factory making bricks".

The big difference between the 'brick making factory' and the 'factory making bricks' is that the latter is meeting the real objective of having a brick factory amp;#8212 generating revenue

This change in target changed the end point of the project. Whereas previously the team finished when the factory was built and equipped, now they were only finished when the factory was operational.

This meant the team had to live with their decisions and compromises and get the factory working with the material flows, information flows, trained staff, and so on.

Now, it is interesting when we describe this change in target to project managers. Inexperienced project managers tend not to understand the difference. Experienced project managers tend to say: "Gee, that would change the dynamic of the project!" Suddenly, the measures of success have changed and these change the impacts of the decisions made along the way. You no longer have to deliver a solution, you have to make it work too.

This additional "make it work too" does colour how the project is actioned. I remember putting up a business case for a business venture to my CEO who said: "Of course, if this goes ahead, you'll be running it." Suddenly these revenue and cost figures in the business case took on a new meaning!

Over the past three years we have conducted extensive research into over 60 projects to discover their delivered value, and what caused the loss in value from that envisaged by the organization. This research found that every project was focused on the wrong targets. They were all building "brick making factories" which is not what was really required.

But organizations do not have effective processes to identify and specify their true targets #8212 what we call "desired business outcomes". What then tends to give projects success is the outcome that they think or assume will give them what they really want. However, because they have not been well thought through, they usually miss the mark.

The big difference between the 'brick making factory' and the 'factory making bricks' is that the latter is meeting the real objective of having a brick factory #8212 generating revenue.

A simple example to show the difference. A B2B project was changing the vendor numbers of all the vendors #8212 but only on certain documents and from a certain date. The project output was a letter to all vendors advising them of their new number and when and where the new number was to be used. Once the letter had been sent out the project team saw its job as done. The business disagreed. What they saw as the target/desired business outcome was that the vendors were using their new numbers correctly and consistently.

The difference between these two perspectives is the root of many levels of dissatisfaction with projects and perceptions of failure. Project teams see their job as done when the output is delivered (in this case, the letter is sent). However, the business has defined the desired outcome as something much more (in this case, making the objective of the letter work in day-to-day operations).

Now this is not the project's fault in that the organization often defines its targets incorrectly up front. But what it (and you) needs is a process to identify the project's true desired business outcomes/targets, so you all have a common understanding of the true objectives of the project from the beginning.

For example, where the organization defines its target outcome as, say, "To have a single financial system" this is the wrong target. No organization exists to have single financial system.

So the question is, "Why is this important to you?" The answer may be: "To reduce the overlap, duplication and time delays involved in having multiple financial systems." Then the same question is asked: "Why is this important to you?" The answer this time may be: "To eliminate the errors involved and to give management faster and easier access to the information required to manage the firm."

Again: "Why is this important to you?" Answered: "To regain a competitive edge as we cannot rely on the figures we are getting at Executive and Board meetings due to the variety of sources and data definitions. We're missing real opportunities to expand the business and respond to market changes due to poor information flows."

So, in this case, success will be "We have a single information flow that provides the Executive and Board with the appropriate, timely information they rely on to make critical decisions while reducing by 20 percent the workload, cost and risk of this information's creation, capture and delivery." (This can be measured, "Do we or don't we?" and "Have we or haven't we?")

When you compare this measure of success with "To have a single financial system" you can see how just delivering a single financial system will not deliver 'success' (but would be seen as another 'failed' IT project).

Importantly, our research has found that any increase in costs between a project that delivers a "single financial system" and one that delivers "appropriate timely information flows" is usually less than 10 percent; but the increase in value generated is usually well excess of 100%. Now, you're being seen to deliver real value.

Page Break

Project Manager's take away

Talk to the organization as to its measures of success for your project. If you're getting "single financial system" type replies, take them through the "Why is that important to you?" questioning process, and from the answers ask them to define what "success" will look like. This defines what they really want from your project.

This does not mean you need to deliver each and every aspect of the definitions of success, but you can now sit down with your Project Sponsor and discuss how much of this new definition of the business's desired outcomes the project will deliver and how much the organization will deliver. But having defined the true measures of success, the right targets, all work within the project and the organization can be focused on achieving these measures of success.

NB The average project has between 8 and 12 such "desired business outcomes" measures of success.

To read Jed's second column, Why Projects Fail: Part Two, Poor Business Requirements, click here

Jed Simms is CIO magazine's weekly project management columnist. Simms, founder of projects and benefits delivery research firm Capability Management, is also the developer of specialized project management and project governance Web site www.project-sponsor.com

Copyright © 2007 IDG Communications, Inc.

6 digital transformation success stories