Projects keep failing, so what’s the
problem?

Projects
are about delivering an outcome that fixes a business need. Others suggest
projects are to take advantage of an opportunity. Those opportunities usually
are to fix a perceived problem. Those perceptions to fix that future problems still
needs a project to implement them and solve it. Those projects still need to be
justified.

Projects
fail for many reasons, building on shaky foundations will usually end in failure.
That foundation is a well-defined and explained problem. Problems need to be
clearly identified, stating how the proposed solution will fix it, and showing
a value proposition to the organisation, customer or both. A quantifiable and
demonstratable benefit, as most businesses are there to make money or provide
better services, why would you be doing it?

Projects
need to argue the logic for investing both time and money, more importantly
what the pay back will be. Business is about making money, providing a service,
or both. Funds are usually limited, rarely having a lack of opportunity to be
spent on the many challenges facing organisations.

What is the Business Case for this
project?

At
first, an organisation wants to understand the why of a project. Closely after
that is the how will it be achieved, and how much. But there needs to be a
compelling reason for carrying out the project. Often projects put the cart
before the horse. In other words, they have a new or updated product that will
future proof their organisation, addressing many of the perceived issues that
could be addressed by the many of the new features on offer all presenting
sound arguments. In a world of unlimited resources and funds that would not be
a problem, but that is not the case. Money and resources are a factor of every
business and they are not always limitless.

Projects
that fail are usually proposed with all the good intents, the arguments of the
new features all sound good. The biggest issue is that no one hears the same
benefits. This results in different stakeholders with different expectations.
As the projects progress it becomes a feature fest. More is better, right? But
time elapses, costs increase, expectations having been ill defined results in
no one being happy. Time and money start to run out, results are not achieved
and the project grinds to a halt. Does this sound familiar?

Questions are raised

Why
are these projects failing? What went wrong? We had all the governance in place
and it seemed to be working fine, then it all went south. I just don’t understand
what happened?

The
problem is there was no real problem being addressed, or that problem was
perceived and not correctly identified. Problems form the foundations of a business
case, needing to be clearly identified, quantified and expressed in a manner
that all parties can agree. Business cases need to clearly explain the intended
problem to be addressed. Identifying problems and explaining the consequences if
they were not addressed. Then describing the benefits that would result in
fixing them, more importantly how that would be proved.

When
defining the problems and proposed benefit, there needs to be an understanding of
the following:

·        
Why invest? – Describe how this investment will benefit the
organisation

·        
The Rational – What is the logic for this investment, how
will it be tested and proved that it has delivered the expected results

·        
Who feels that this is a problem – gather views from all
appropriate stakeholders within the organisation through discussion with the
subject matter experts.

Defining the problem

Often
what is perceived as a problem is usually not the problem. To find the real
problem you will need to carry out “root cause analysis”. A good example of
this is a technique commonly referred to as the “5 Whys”. This is an iterative
interrogative technique used to explore the cause and affect relationships
underlying a problem.

What sort of questions should you be
asking?

A
famous quote of Einstein was:

“If
I had an hour to solve a problem and my life depended on the solution, I would
spend the first 55 minutes determining the proper question to ask…
for once I know the proper question, I could solve the problem in less than
five minutes.”

What
stakeholder say is a problem does not necessarily reflect the root cause that
created the problem. Every stakeholder potentially will have different issues
which they consider a problem. Your job is to dig, finding the root cause. You
need to identify both the cause and the consequence to any issue raised as
potential problems. A simple test is called the “so what?”, Similar to the “5
Whys”, which will be covered a little later.

Is
there any evidence that confirms the cause and effect of the identified
problem? What is the priority? Does it need to be addressed now or could it
wait? Is the issue specific to what you are looking at, or should that
perspective be broader?

Example of 5 Whys

“..
the finance director could not understand why his maintenance costs were
increasing on the factory floor. He had sent a directive to the department to
cut costs. He decided to venture down to the factory floor to speak with the
manager and better understand these increases. (His perceived problem)

..
as the finance director was walking through the factory he noticed a pool of
water on the floor. He called a maintenance staff member to inquire about the
water.

·        
Why is there a pool of water here on the floor? The staff
member pointed out that one of the pipes above was faulty and leaking. (Maintenance
perceived problem) The director then asked for the manager,

·        
Why was that pipe leaking? The manager pointed out the
replacement washer had not sealed properly. Again, the director then asked,

·        
Why did the washer not seal properly? The manager suggested the
washer had possibly failed. The director then asked,

·        
Why did it fail. The manager then suggested the washers were
cheap and that they had a tendency not to last too long. Again, the director
asked,

·        
Why were we using cheap washers? I was following the budget directive
to cut my maintenance costs. We then sourced alternatives as our previous
washers were too expensive.

The
director had found the root cause. In this case there were several perceived
problems. The director had a problem with his costs of maintenance, the staff
member had a faulty pipe and the manager had issues with cheap washers. At
first replacing the pipe potentially could have fixed the problem. But as it
was not the root cause it would have resulted in an expensive fix and the pipe
potentially would have leaked again because of the washer. The root cause for
the pipe was the use of a cheaper alternative. It also highlighted the cost
increase to maintenance had indirectly been because of a cost cutting
directive.”

To
define a problem, you will need to consider the downstream effects of what you
and other stakeholders consider to be the problem and what it means to your
organisation. There are two parts to a problem what has caused it and what are
its consequence? Understanding these causes will help you chose how you
respond. The consequences of a problem will help in identifying relevant
benefits. Showing that investment can work to the objectives in this case,
those objectives will later provide an opportunity to identify alternatives.

Problems
that are not well-defined make it harder for decision makers, reducing the
chance of success. This can result in projects that results in less than fit
for purpose results. Either too little in the way of funds and resources, or
too many working on low-priorities. The worst case is lack of resources to
solve a major challenge.

Success
is through clearly understanding the problem and benefits from the beginning. This
will enable everyone to be on the same page, agreeing to the same expectations
and results. Aligning results to the organisations priorities and effectively
addressing the right problem. The idea of a well understood problem is that it
will potentially highlight an opportunity for better results.

Explaining the problem

This
is the elevator pitch, if you were trapped in the elevator with the key
stakeholder who was the approver of the funds needed. How do you relate the
issue in 90 seconds? That pitch needs to clearly identify the issue, providing
the evidence that supports your statement and the solution with definable
measure of success.

Problems
that are ill defined can result in benefits that do not align and undermine your
entire argument for the case. Businesses want to understand how much of a
problem it is? The goal being a call to action. It should have both cause and
consequence, answering both the ‘Why?’ And…’ Questions logically linked. A
great starting point is identifying the consequences of doing nothing?

Your
pitch will never be perfect, potentially changing as more information is
gathered. It will be tested against evidence and morph from its original state,
be prepared for change. The challenge is to go into this exercise without any preconceived
solutions. As further evidence is presented it will develop your understanding
and result in a better result, and a stronger foundation to build your case.

Mistakes in identifying problems

Many
people go into identifying problems sure of the solution, especially when it
comes to technology. In the technology space providers and IT specialist believe
their solutions will provide the answers to any problem. Its just a matter of
shoe-horning those problems into that solution.

Avoid
simply identifying the problem as a system failure, this has a tendency to drive
the results which usually does not align to the facts and the issue. Again, go
back to “so what?”. What is the evidence that will give you a confidence that a
problem exists? You must present that evidence to explain your rational.

Always
note where you found the evidence as you develop your pitch, it’s always harder
if you try to retrofit a problem with evidence. One of the best tests I would
use is called the “Mum Test”, find someone who is not related to the case to
read the pitch and benefits, ask them, “Does this make sense?”. For me, when I
was an interface designer I would as my mother if she could carry out a specific
task using that interface. With no instructions, I would see what she would do
to achieve the results. The idea is to remove the element of assumption, as we
don’t always know who the audience will be, we need to make sure it is clear
without having to be there to explain.

Benefits, what are they?

When
you understand the problem and its consequence most people will understand the
benefit of doing something about it. A benefit gives a measurable improvement,
showing the value gained. The consequence of a problem helps to identifying the
relevant benefit that lead to your objective.

They
should clearly align to the problem that links to the results your organisation
is looking to achieve. Explain the impact which credits to the solutions.
Justify the cost of both money and effort which are supported by demonstratable
returns.

Measuring those returns

The
best way to show a return is by having a measure based on current and future states.
Everyone will have a different measure of value, so there needs to be some more
good questions.

This
is the old “WIIFM”, (What’s in it for me). How are you going to show the value
you are declaring?

·        
What will be the return to the organisation or its customers?

·        
How will you measure and prove that benefit?

·        
How will you show the connection of the benefit to the results?

These
are just a few points to consider when defining and showing benefits in a
project. These measures are to be defined with your stakeholders as they are
the people who will confirm the returns on investment (ROI). They need to be
identifiable, measurable and proven.

Prioritisation

As
you define your problems and benefits there is a need to priorities each of
them. It’s not an exercise in the level of investment is directed to fix the
problem but more enabling better decisions between available alternatives,
making sure you get the best bang for your buck. This will enable focus and to
direct both funds and effort in future, more importantly you can control scope.

These
priorities will enable better and more directed decisions when you may not get
all the funds you expect. A small problem which has Signiant results for an
organisation or its customers, compared to a large problem which has limited
impact will give a signal of investment. But it raises the question to the
larger problem, has it been clearly identified? And are the consequences fully understood.

All
of these are good questions and will need further examination. This is not an
exact science, but it is a major step in the right direction.

What tool can help with this process?

A
technique used to ensure robust discussion and thinking is carried out up-front
in a project is Investment Logic Mapping (ILM). It is a great tool to use
before a solution is identified and before any investment decision is made.

ILM
provides a way of identifying problems that need to be addressed. This will
identifying benefits hoped to be gained, more importantly how the project will confirm
the rational, showing the realisation of those benefits. The ILM tool is used
for complex investments but is recommended for any project and will enable the
ability to communicate that information on a single page.

Should you use ILM?

Many
organisations trigger this process based on the investment. It is something
that is not compulsory but is recommended especially for complex, high-risk or multiparty
proposals.

In
practice it should form the start of all projects, as the output forms the
foundation of your entire business case. The degree and level that you engage
is determined on the size, complexity and value of the project, but the format
and principles will always be useful to defining your problems and how the
benefits will address them.

As
the project progresses it will increase the project focus and clarity, helping
in defining an agreed scope and result, which will save debate and discussion
later in the project. It will become a powerful tool that will provide you
leverage in justifying your expenses of both funds and effort.

How does it work?

Using
a facilitator, key stakeholders in a couple of workshops will discover:

·        
Your problems and consequences, then

·        
The outcomes and benefits.

·        
These workshops will build an alignment on the purpose of the
investment, it may not necessarily lead to an agreement, but it will be a
start.

What can you expect from an ILM
workshop?

You
should expect to have a single page flowchart that will be written in plain
English. It will define your problems to be addressed, potential benefits of
your investment, and how you will confirm those benefits. It will become the
underpinning logic around your project investment.

ILM
workshops will be a series of time-limited engagements up to two hours each. It
will bring together the accountable stakeholders for the benefits realisation.
It should be low-cost and low-effort that will produce new information. It will
bring together all available information to enable a better understanding,
leading to better results.

Problem
owners need to prepare by checking their evidence, identifying the right
stakeholders for the workshops and offering their opinion and expertise. The
right stakeholders are those who have identified and understood the business
problems, provide the evidence the problem is real, and is responsible for
delivering the benefits. Other stakeholders are those people responsible for
giving advise around the investment to the project. This will increase the
value of the workshops, avoiding the risk of having to start again. Most would
have already been engaged from the start.

The
problem owner needs to drive the effort, talking with the right stakeholders
and their willingness to contribute will lead the to the right pitch when
presenting your case.