Is Your Project Already In Trouble?

It’s Day 2 of Your Project—and It Is Probably Already in Trouble

The impetus for a project can come from various sources—your strategy, operational improvements, nagging problems or compulsory changes.

But once the need for project is crystallized (although technically the project may not yet be deemed to exist [1] ), it is likely to be heading off in the wrong direction if you don't take one simple step. 

Too many projects start with a “Problem Statement”.

“A problem statement is a concise description of the issues that need to be addressed by a problem solving team and should be presented to them (or created by them) before they try to solve the problem.” Wikipedia

If on Day 1, you create your problem statement, by Day 2 you’ll be in trouble.

Why is a problem statement a problem?

A problem may trigger the project to be created, but should never be the starting point for its definition.

Because when you define the ‘problem’ as your starting point, then the next logical step is to define your ‘solution’. And that heads your project off in the wrong direction.

So they defined their ‘obsolete systems problem’ and identified a systems solution for which they got funding.

THEN they started to define their business requirements—to fit the software (not the needs of the business).

Needless to say, the project ended up costing over three times the original estimate.

What should they have done?

For every project, you always need to start by defining where you want to end up, by identifying what you’re really trying to achieve—your ‘desired business outcomes’.

In our example, the company was not trying to achieve owning and using the selected software or even having up-to-date software. 

What it was trying to achieve, was to regain its competitiveness and reduce its operating costs so as to increase profitability and be able to expand market share. The software solution project ignored all this. Yes, the words ‘increase competitiveness’ and ‘reduce costs’ and alike were bandied about in the business case, but as general statements rather than as the driving forces of the project.

This project should have started by defining the desired business outcomes:

Clear, specific definitions of the future business-as-usual state when everything is operating just right - measurable with a True/False question—e.g. do we or don’t we?

Outcomes only take a few hours to define but they transform projects - they take everyone through the thinking process to answer the question "what are we really trying to achieve" and then puts this center stage in the project.

Making desired business outcomes the heart of the project

Instead of the vague general "motherhood" statements most often seen in business cases, desired business outcomes become the focal point of the project, driving all of its activities and its primary measures of success.

• The project's proposed solution now has to prove it can deliver the desired business outcomes.
• The workload now needs to include all of the activities required to realize the outcomes during and after the project.
• The costs include all the costs to realize the business outcomes, not just deliver the project.
• The benefits are also based on what the outcomes will deliver rather than just the benefits the project outputs will deliver.
• The whole language and focus of the project shifts from the language of projects, systems and cost to the language of business, outcomes and value.

Is your project in trouble?

If you have any project at any stage that does NOT have:

1. A list of clear, specific, true/false measurable desired business outcome statements
2. plus a change plan to deliver each outcome,
3. plus a list of benefits each outcome will deliver

your project is already in trouble. It may not fail, but it will deliver compromised results and value.

NB. Most projects miss, lose or destroy more than 50% of the available value. That's a massive amount of waste.

The good news is, you can define your outcomes at any stage of the project. Even if you are one year into a two-year project, it is not too late to define your desired business outcomes. We’ve done it for projects in their fifth year!

Clear specific and measurable definitions are crucial

Many projects will have defined "something" - ‘objectives’ or ‘goals’ or ‘capabilities’ - in the business case to outline what they are set up to deliver. The vast majority of projects do not define in clear specific measurable terms what they are intending to achieve. 

Even when they do define something measurable, they are often not specific enough. Your outcomes need to be specific enough to be measurable with a true/false question:

          Can we or can't we? Do we or don't we? Have we or haven't we?

This true/false requirement translates the achievement of an outcome into a black or white measure—you’ve either delivered it in full, or you haven’t. If you haven’t delivered the outcome in full, you have delivered a compromised result that reduces both your benefits and the value delivered. 

In Conclusion

When you take the small amount of time needed to define your project's desired business outcomes you then create the primary control to drive the project execution and the business value.

It's that simple.

How does your project definition stack up?

TOP defines 11 simple outcome rules for defining Desired outcome statements.

If your existing project's definition fails any of these rules, your project is most likely already in trouble.