When I was seven I broke my left leg. I’d come home from a family visit, kicked the football in our backyard against the wall, ‘scored’ a great goal and celebrated by swinging on the washing line that was hung between two metal posts in the yard.

Now, washing lines in those days weren’t security-minded, childproof arrangements. That is to say, it was a bit of blue plastic slung between a couple of green posts concreted into the ground, so when I leapt up and grabbed it, it broke. By the laws of gravity I came down hard on the concrete and landed awkwardly on my leg, which ended up sticking out at an unnatural angle.

I don’t remember much after that except for being in the hospital for what seemed like 12 hours, before Dad picked me up (with my freshly plastered leg), insisting to the doctor on duty that ‘he’s not staying here’. I got to go home and stay up late and watch The Battle of Britain on TV. They were good days, apart from the broken leg of course.

So what does this trip down memory lane have to do with getting clear on the problem?

When I arrived at the hospital it would have been obvious to anyone that my leg was broken. Still, instead of simply giving me a painkilling injection and putting my leg in plaster (that’s what they did in 1977) the doctor did five things:

1. He asked for a detailed account of what happened, how I fell onto the leg and whether I’d had any previous leg injuries (Dad could answer the last one).
2. He asked me to stand up and put some weight on the leg and to tell him when and where it hurt (through the tears obviously — I was only seven!).
3. He poked different parts of my leg to find out which bits hurt and which didn’t and checked whether I still had feeling in my toes and heel.
4. He sent me off to X-ray for a picture of the leg, thigh and ankle.
5. He checked the X-ray carefully and consulted another doctor.

Only then did he decide on the course of action to be taken: 12 weeks in plaster, followed by exercises and regular check-ups at my local GP to get my leg working properly again and to resume my dreams of playing for Everton (which, at 50, I still have).

One of the big reasons that projects fail is we don’t take enough time to get clear — and I mean X-ray clear — on the problem to be addressed or the opportunity to be exploited. We rush headlong into building or buying something, then scratch our heads when the stakeholders don’t get what they were expecting.

Too often organisations and project sponsors start with a solution in mind, rather than focusing on resolving a problem. At one organisation I worked for, we had a finance system that didn’t produce the reports the finance team needed to be able to accurately analyse and forecast our operational spend. Our Chief Financial Officer had been to a sales presentation, fallen in love with the system demonstrated to him and insisted we buy it.

In total we spent around $500 000 on the project and even then the company had to write and code the reports that the original system would have provided. We could have spent a month and $20 000 to solve the actual problem we had. Instead the project became about buying a solution to problems we didn’t have. And of course we never did get the benefits promised in the business case to justify the spend in the first place.

To get everyone to buy into a project from the start you need to ensure the problem is clearly articulated and that you’re not creating more problems in doing the project. In traditional projects a person or persons will work with the stakeholders to collect information on what they need to solve the problem. It will be a series of questions designed to thoroughly challenge their thinking and ensure they’re focused on problem resolution.

For complex projects, this could (and should) be a lengthy exercise culminating in a clear, concise document that can act as a basis for building a good plan.

Often business analysts will use a method such as MoSCoW (Must, Should, Could, Would) to get clear on the priorities of the requirements in order to build only what’s needed. Only once it’s finished can you start looking at the possible solutions.

Other methods I’ve used include Scrum and design thinking. Scrum is a popular agile method, used largely on technology projects, where workable products are designed, built and shipped in short time frames (known as sprints). Its creation is credited to Jeff Sutherland in 1993, though the term itself was first used by Takeuchi and Nonaka in a 1986 study in which they likened high-performing, self-organising teams to rugby scrums.

Using this approach, the stakeholders work together to identify a wish list of requirements to fix the problem, which is called a product backlog. The product owner (who represents the users) ensures the requirements are understood and the list is prioritised, so the team can work on the most important things first. They then combine these into a sprint, which is a concentrated work package that is usually delivered in between two and four weeks.

The entire process is overseen by a scrum master, and your job as the sponsor is to ensure that the product owner and scrum master are doing what they need to do to ensure maximum value is delivered to the business. This approach works best where time frames and budgets aren’t fixed and teams are self-organising and motivated to deliver.

The design thinking method is generally credited to David M. Kelley, the founder of design consultancy IDEO in the US in the 1990s, and is a method for practical, creative resolution of problems and creation of solutions (courtesy of Wikipedia). The method has six phases: definition, research, interpretation, idea generation, prototyping and evaluation. The first three of these phases concentrate solely on defining the problem, challenge or opportunity. From defining the problem into a very clear statement, to researching, surveying and observing, to analysing data and looking for patterns.

Only once all these phases are completed can you begin the process of generating the ideas to solve the problem, address the challenge or exploit the opportunity.

Design thinking can be used in conjunction with traditional and agile project methods. If you’d like to know more, Emrah Yayici’s book Design Thinking Methodology is a great place to start.

Regardless of the approach you use, it’s critical that the stakeholders are involved from the start and that you make no assumptions as to what you think they want.

As the sponsor, it’s likely you’re the direct beneficiary of the post-project outcomes, so it’s absolutely critical that you ensure this exercise is done in the right way. Everyone needs to understand the problem and how it will be addressed before you start designing or building.

Once you understand the problem, you can define the benefits you expect. It’s always that way around.

The benefits (or outcomes) are the reasons we undertake projects in the first place and they need to be unambiguous, time-bound and achievable.

In a State of the CIO survey, 63 per cent of CEOs interviewed said they preferred projects to make money, while only 37 per cent preferred to save it. So you have to be able to demonstrate the tangible gains for the organisation and back this up with detailed analysis of how you’ll achieve that.

KPMG New Zealand estimate that only 21 per cent of projects consistently deliver the benefits they promise. Like most statistics around projects, this is appalling. A joint McKinsey/Oxford University study found that IT projects specifically deliver (on average) 56 per cent less value than initially expected.

The New Zealand ministerial inquiry into the Novopay project, an initiative to replace 2457 education payroll systems, predicted that the project ‘was unlikely to ever achieve the benefits it promised’, this despite spending over $100 million on the project.

There was a similar case at an organisation I once worked for. When I started I initiated a review of the benefits expected by the projects we had on the books. Half the benefit statements I read could have been written by the Brothers Grimm. Most of the numbers were pure fantasy, and new to the business though I was, even I knew they were unachievable and that as a (high-profile) business, we were setting ourselves up for failure.

So I did what anyone would have done. I asked the CFO to review them all and, where financial savings were declared, the executive responsible had to declare which budget line would be reduced the following year. Nine projects were immediately cancelled and we instilled a completely different mindset into those sponsoring projects.

Often projects lose steam because no one cares anymore. Maybe it was a good idea to begin with, but now it just feels like something someone else wants and the benefits don’t seem relevant — and I’m not just talking about the tangible numbers here, but also the intangibles, such as how it will make lives easier.

If you have continued business justification and a good ‘why’ statement, then don’t panic! You’re in good shape and just need to reassert your why, demonstrate the value the project offers and get the team back on board. What you can’t afford to do is hope they’ll eventually see the light and start supporting you again.

In their paper ‘What We Know about Leadership’, Hogan and Kaiser found that high-performing leaders who fought for what was right added significantly to their organisation’s value, in one case providing an additional $25 million. So you need to keep the faith, and help others to keep theirs too.

Solving a problem and realising the benefits are the reasons we undertake projects in the first place. If you’re not clear on them at the start, then it’s unlikely you’ll ever see a return on investment either financially or in the time you’ve invested. You’ve got to do it properly from the start.