Don't confuse project outcomes with business outcomes

As the new year approaches, here's one resolution that will pay you back big time if you stick with it through 2017.

Don't confuse project outcomes with business outcomes. It's amazing how many really good CIOs, project managers, sponsors and stakeholders do!

In their 2016 Pulse of the Profession report, 83 percent of organizations lacked maturity with what the Project Management Institute (PMI) calls "benefits realization" and only about half indicated that project benefits are well aligned with business strategic goals.

Unpicking these statistics reveals something of a trend. It seems a lot of IT projects are either failing or not reaching their full potential because key people are wearing what I'm going to call "outcome blinkers."

I'll give you an example.

Earlier this year I was called by a CIO friend asking for me to take a look at a project that he didn't "feel" was delivering. When I asked how it wasn't delivering, the answer was a bit vague. It wasn't late and it wasn't over budget, and the governance was sound. Morale was not a problem and the project was amply resourced, the methodology was textbook. It was more of gut feeling that something wasn't right. So I had a look.

"What's the intended outcome?" I asked.

My friend walked me through the software program and app that was being designed.

"What's the intended outcome?" I repeated, adding, "... the business outcome?"

"I told you!" he said and talked me through the software again adding a little more detail about how it would work, how it would look and when it would be ready.

As he talked I think a light came on because he stopped and looked thoughtful for a moment.

"I guess ... faster order processing. We have had a lot of complaints about it, so fewer complaints too. And our website was a bit clunky so I figure we could get more orders and more online activity by being a bit more current."

After this, I didn't need to look at the project. Once the "outcome blinkers" were off, that gut feeling that something wasn't right was replaced by a firm confidence that, with a few small tweaks, they had a winner.

The fog and doubt had been caused by focusing on project outputs rather than business outcomes, and it happens a lot.

The software was just a deliverable, an "output," it was a tangible product of the project, but in and of itself, not the reason why the project had been signed off. The project had been approved because there was a business need to get more orders and online activity, get better at processing them and reduce complaints but this had been forgotten in the mission statement. The why had been replaced by the how.

Truth is, the software was always going to deliver these objectives but more because the software solution chosen was right and the project manager running the show is a governance legend! Often though focusing on outputs can lead projects down the wrong road and in this case (and so many others) it's done without anyone even realizing — until it's too late!

This is the project management equivalent of the old sales maxim "sell the sizzle, not the steak" which encourages salespeople to focus on the experience of a product rather than simply the product itself. You'll have experience of a sales pitch that triggered your senses and created an emotional connection with you, it's these things that motivate most people's point of purchase selections.

The sizzle is also the important bit of the IT project.

"What's the sizzle?" or “What is the objective of this project?” should be the first question you ask when you embark on a new project.

It's not just project managers who should be asking. CIOs, stakeholders, sponsors ... anyone who touches or interacts with the project should have this question burned into their subconscious. That way it becomes part of your DNA and comes naturally to mind in any decision making.

Often, having an independent pair of eyes take a look at your project or even entire portfolio can help you differentiate the sizzle from the steak!

It may help to think of business outcomes as the benefits enjoyed by you, your end-users and your clients as a result of your IT project. Simply delivering a project, even on budget and on-time doesn’t guarantee realization of these benefits and it doesn't guarantee the necessary ROI either but when you align identification of intended business outcomes with IT project initiation and management you increase your potential for success. When you make this a shared responsibility across executive leaders, project professionals and business sponsors the road to success is less cluttered by uncertainty.

Unsurprisingly, the PMI Pulse report concludes that organizations with "high maturity in benefits realization" (businesses that identify business outcomes and align them with IT Projects) get greater bang for their buck and also less waste (putting the figure at $112 million saved for every $1 billion invested in IT projects).

So how do you make sure that you don't confuse project outcomes with business outcomes? How do you get to the sizzle?

I think starting with the end in mind is really important. How many Olympic gold medal winners this summer spoke of visualizing the finish line and how it will feel to cross the line first? For us, the gold is the business outcome ... the better order processing, the improved quality control, the faster customer service. When you start your project with your intended benefits in mind (and keep focused on them during your project lifecycle) you have a greater chance of not being distracted by project outcomes and outputs. 

Asking these questions will help too.

Six great IT project sizzle identifying questions

  1. What are the business drivers? Why are we doing this IT project?
  2. How will success be measured? What are the measurable business outcomes?
  3. Who signs off on what the business outcomes will be before we start?
  4. Who is accountable for ensuring the IT project stays on track to achieve the business outcomes?
  5. Who signs off to confirm that they have been delivered at the end?
  6. Who is responsible for ensuring that the IT project's business outcomes are aligned with the business strategic goals?

We have covered number one in some depth but I think that the second question is as important. In the example, I gave you earlier success would be measured by more online hits, more orders, fewer complaints and measurably faster processing. You should agree on the metrics of success, and celebrate when you tick each of them off! The one thing that I did recommend to my CIO friend (and to you) is to be brave and put some numbers on each of the measures. I mean, two extra sales would meet a vague "more orders" intended business outcome but won't have your CEO dancing a jig around the boardroom.

You will notice that there are four who questions too. In many projects, the answer to each is the same person but in some cases having a different stakeholder sign off on intended outcomes at the start, during and after a project can add extra layers of governance. More eyes ensuring that IT projects remain aligned to business strategy is never a bad thing!

When business outcomes are identified and managed well, your organization will enjoy the greatest possible return on your investment. This process of identifying business outcomes (as opposed to project outputs) though is a low priority for many and if that is the case you may be missing a great opportunity to maximize strategic impact and drive organisational success through IT.

Finally, identifying and achieving business outcomes sounds like a great excuse to pop open a bottle of champagne. During the festive season, I do rather develop a taste for that so more excuses for champagne popping in the year ahead sounds good to me.

Have a happy holiday, and here's to a 2017 of business outcomes achieved through IT projects.

This article is published as part of the IDG Contributor Network. Want to Join?

NEW! Download the Fall 2018 digital issue of CIO