Teams don’t struggle with solving problems but figuring out what the problems are.
Table of Contents
- The real reason why digital technology projects fail and how to fix it
- Solve the right problem
- Find a good solution to the problem
Summary
Though many factors contribute to a project’s failure, nothing is more certain to cause a project to fail than solving the wrong problem or realizing too late that the problem was misunderstood.
A common misconception is that identifying the right problem is an innate ability that only a select few visionaries like Henry Ford or Steve Jobs possess. Their quotes,
“If I asked people what they wanted, they would say “a faster horse”,
and,
“Its really hard to design products by focus groups, as people don’t know what they want until you show it to them”,
have propagated this myth.
Identifying, analyzing and defining problems is a process and its accessible to anyone that is passionate about doing so.
The rigor with which a problem is defined is the most important factor in finding a suitable solution.
Founders and Organizations investing in projects don’t spend enough time defining the most important problem they’re attempting to solve. Many have considerable difficulty even identifying which problems are crucial to their missions and strategies. This results in too many pivots, shifting business requirements, missing deadlines and re-work as teams go back to the drawing board. This eventually results in schedule and budget overruns or project cancelation.
Teams speed toward a solution, fearing that if they spend too much time defining the problem, they will lose the window of opportunity or get scolded by corporate leadership for taking too long to leave the starting line.
Many times, projects go down the wrong path and end up implementing the wrong system. They discover too late, that they didn’t solve the “right problem”, or they didn’t solve the “whole problem”. They only realize in hindsight the right problem to focus on and which path to follow.
Projects also fail when they start with the solution first. Often referred to as “Solutions in search for a problem”. This happens frequently when new technologies such as Artificial Intelligence and Blockchain come on the scene and teams are adamantly attached to building with it. Teams often end up shoe-horning problems instead of objectively evaluating the situation and using the right solution to solve it.
Most teams are not proficient at articulating their problems clearly and concisely. They need to ask the right questions earlier and not start building solutions too soon.
Teams need to get a lot better at:
- Identifying the right problem to solve
- Being sure the problem is worth solving
- Understanding who is affected and how
- Understanding the root causes of the problem and breaking down large problems into many smaller ones
- Asking why it hasn’t yet been solved and understanding the most difficult parts of the problem
- Defining the problem clearly and concisely
- Validating the economics — the costs, benefits and payback
- Asking how we will know when the problem is solved and whose opinions count
Identify the right problem to solve
Where do the ideas for the right problems (or opportunities) come from?
Life is problematic and solving challenges is an integral part of our everyday lives. So ideas for problems are everywhere.
Whilst there is no shortage of problems to find, there are limits on what we as individuals or corporations can take on. Therefore, the process starts with asking the right question — “What does the world want changed, that I am, or we are, passionate about solving and are uniquely qualified to tackle?”
Simon Sinek puts this as “Do what inspires you”. Simon explains that to do what inspires, start with the “Why”. Start by understanding and explaining why the problem matters to you. If you can answer that question, you will not only inspire more people to use the solution, but you will also inspire yourself to get out of bed each morning and push through difficult tasks.
Simon goes onto explain that searching for why the problem matters, requires you to examine the significant moments from your past to understand your why. This process also applies to corporations, who must look to their history so that they can understand why its important to their mission.
Another less used, but powerful technique to gaining clarity on what matters to you is to write your own obituary or for a corporation, a bankruptcy filing. Although it sounds a bit macabre, writing your own ending, can be an excellent way to gain clarity on how you want to use your time.
Be sure the problem is worth solving
Not all problems can be solved viably. Some problems are not economical to solve because:
- The solution would cost more to build or sell than its benefits
- The solution would take too long to pay back the investors or the corporation.
Some problems are not economical to solve right now, because the conditions for success are not yet ripe.
But how can we predict if a problem is worth solving and the timing is right?
Significant contributions on answering this question come from the Tech Startup Community — these insights also apply to problems faced by corporations.
Problems are worth solving when they:
- Matter deeply to the founders (if it’s a Startup), or to a corporation’s mission
- Are useful to enough people
And are:
- Growing or getting worse with time compared to other problems these people face
- Urgent and needs to be solved quickly
- Hard to solve and the people impacted don’t have good enough alternatives or the solution is not immediately obvious
- Mandatory and not just a nice to have
- Caused by changes in the environment
- Frequent and affects people often
Understanding who is affected and how
To analyze if a problem would be useful to enough people, you need to:
- Identify who and how many people might be impacted by this project the most or have influence over this project
- Prioritize the people based on their interest and influence
- Understand how they are impacted or how they will impact you
Enterprise IT / transformation projects often refer to this analysis as “Stakeholder Analysis” and charts such as the one below is created to visualize the Power-Interest of each stakeholder.
This area is well covered by multiple sources. Some of the notable ones are listed below:
- Design Thinking: Getting Started with Empathy
- Stakeholder Analysis
- What is a Stakeholder Analysis? — Leading Successful Projects
The Technology Startup community has a rich body of knowledge on finding potential users. Geoffrey Moore describes the various segments in his book “Crossing the Chasm”. The central idea of the book is that Startups should focus first finding innovators, then target early adopters and so fourth as the company matures.
Understand the root causes of the problem and break down large problems into many smaller ones
Problems often start out “fuzzy” — vague, formless thoughts. A problem is fuzzy if the founders and project teams struggle to explain the problem concisely and precisely. Its often said, that if you cannot explain the problem you are working on to your partner or parents, you haven’t understood the problem well enough yourself.
Root cause analysis is about digging beneath the surface understanding of a problem. The goal is look beyond trying to find one singular cause, and instead uncover the system, or network of causes. A Root Cause Network Map is a simple visual explanation of all the causes that contributed to the problem.
5 Whys
This method encourages you to keep going deeper as you examine an issue. Ask “Why?” at least five times until you’ve uncovered all potential causal factors and determined the real reasons this problem occurred in the first place. 5 Fives is well established technique with detailed steps and tips.
Using a root cause analysis, teams can break fuzzy large problems into multiple well-defined smaller pones. In doing so they can also identify the sources of a problem. This level of understanding will later help to implement permanent and lasting solutions.
How to deal with complex root causes
The root cause network map is often a simplified view of the true nature of the issue. Most real-world issues have a more far more complex causal chain. For example, the diagram below depicts the behavioral and societal factors that contribute to the cause of obesity.
Analyzing the root cause when the causes are complex are covered by the complexity theory field of study. Teams facing complex causes should look to tools and techniques used by complexity analysts, such as graph analysis.
Ask why it hasn’t yet been solved and understand the most difficult parts of the problem
With a clearer view of the problem and the network of causes, teams can then ask these questions:
- “Why hasn’t each of the smaller problems been solved?”
- “Which of these smaller problems are the hardest to solve”?
Difficult problems remain unsolved, generally because somewhere in the network of causes is a “Mini-Wicked problem” that’s hard to solve, because it is:
- Not economical to solve
- The problem is highly interconnected with too many other problems
- The technology doesn’t exist yet to effectively solve the problem
- No obvious solution exists
If viable solutions cannot be found to these wicked problems, project failure is imminent.
Define the scope of the problem
Teams must solve a root cause completely and better than an alternative to be successful. However, teams often don’t have the resources to solve all the root causes of a problem. Therefore, teams must decide which of these ones they wish to undertake and include within the project.
The list of root causes that the team chooses to include within a project is referred to as the “Scope” of the project.
Various frameworks exist for defining the scope of the problem and teams must select one that works best for their situation.
The Concise Scope Definition (“The Elevator Pitch”)
This type of scope definition is a few sentences that describe:
- Current State — who is facing the issue, what is today’s reality, when, how and why, do they face the issue today
- The loss — the frequency and impact of that this issue is having on users today
- Ideal End State — the users experience once the problem is solved
Example:
Managers are spending 20% of their time each week receiving and compiling sales reports for upper management, reducing the number of hours spent on mentoring sales staff, lead generation, and closing business. This is a productivity issue, and ignoring it results in decreased sales and missed revenue targets over the past 3 months. XYZ Company is committed to reducing the time spent compiling reports to no more than 10% of the sales manager’s time in any week.
Scope Modeling Frameworks
Some scope definitions need more information to set the stage and define where the problem exists and which problem is being tackled. In such situations the problem definition often requires several pages, several PowerPoint slides, various diagrams or even more formal models.
The scope definition must help explain the impacted
- Business units
- Business processes
- Business capabilities
- Data
- Applications
- Projects
- Infrastructure
If the problem is a caused by a change in the external environment, the model may also need to explain:
- The Influencers — trends, competitors or legislations that are causing this change
- The SWOT — strengths, weaknesses, opportunities and threats to the business because of these external changes
- The drivers — the main reasons why this is a problem and why it’s a problem now
If the problem is a so severe that it requires the business to change direction or morph into a different business to survive, the problem definition may need to explain:
- The business model — the most fundamental building blocks of the business that are impacted such as Customer segments, Value proposition, Revenue streams, Channels the business uses to interact with customers, Customer relationships, Key activities, Key resources, Key partners, Cost structure
Teams can refer to frameworks such as the business model canvas.
This framework is also useful to Startups as they are often invent new business models.
Validate the economics
Teams often asked the question “How much will this project cost?”. Teams should resist responding only with the cost “this project will cost $1 Million” as it offers no frame of reference to understand if this cost is too high or just right.
Teams need to get better at providing both the cost, the benefit and the return on investment — for example “This project will cost $1 Million, and will deliver $5 Million in Benefits over 3 years”.
Even at the early stage of the project, teams should strive to envision ballpark return on investment figures.
Creating business cases has been extensively written about. Some notable references include
- 5 Steps to Develop a Solid Business Case
- How to write a business case
How will we know when the problem is solved and whose opinions count
The big problem with assessing project success is that is no consistent way to define “project success.” There is a great deal of diversity in terms of what is considered as the project success criteria, and worse they change over time. Projects that struggle to define success or aim for moving targets, risk the odds that the project will be viewed as a failure in the end.
Getting project success criteria is sometimes so hard, that a popular practice has simply been to ignore it. Many project teams never ask the two fundamental questions at the beginning of their projects:
- Who declares success?
- What are the criteria that will be used to determine success or failure?
Project Management Institute has made significant contributions in this area and suggests that there are broadly two types of success criteria
- Project management success — the team’s ability to meet the projects budget and schedule and deliver a product of acceptable quality
- Product success — the outward view of success of such as revenue and customer adoption, customer satisfaction and so fourth.
Whether the project will be judged more so by project management success or product success will largely dependent on the power-influence mix of the project’s stakeholders and if they are more focused on project management success or product success or some combination of the two.
Conclusion
Projects succeed when teams solve the right problem and solve the whole problem. To do this, teams must resist the urge to speed toward a solution, and spend more time upfront, identifying and defining the problem.
To find the right problems, individuals and corporations must be selective in which problems they choose to take on. They should prioritize those that:
- Could have a big impact on people
- They are uniquely qualified to tackle
- Can be solved viably — i.e. the solution has greater benefits than the cost to build and sell it
- Have an acceptable pay back period for the investors or corporation.
Teams must identify the users that will be impacted or have an influence over the success of the projects and assess if there are enough people that will benefit from this project to make it worthwhile.
Root cause analysis is an essential step to help teams
- Break down fuzzy large problems into multiple well-defined smaller ones
- Identify and visualize the multiple causes of a problem.
Before embarking on solution design, teams should
- Try to understand why the problem hasn’t yet been solved, and
- Where in the network of causes is the hardest part of the problem to solve.
The list of root causes that the team chooses to include within a project is referred to as the “Scope” of the project. There are various frameworks for defining the scope of the problem and teams must select one that works best for their situation.
Teams need to get better at
- Validating the project’s economics by understanding the cost, the benefits and the return on investment.
- Uncovering at an early stage, who declares success and what criteria will be used to determine success.
Teams don’t struggle with solving problems but figuring out what the problems are. Identifying, analyzing and defining the problem is the key to project success. Einstein summarized it best by saying:
“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.”
