Projects keep failing, so what’s the problem?
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.
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.
What’s a Rich Text element?
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
Static and dynamic content editing
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
How to customize formatting for each rich text
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.