Solve the Right Problem

Teams don’t struggle with solving problems but figuring out what the problems are.

Table of Contents

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:

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:

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:

And are:

Understanding who is affected and how

To analyze if a problem would be useful to enough people, you need to:

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.

Source : https://www.mindtools.com/pages/article/newPPM_07.htm

This area is well covered by multiple sources. Some of the notable ones are listed below:

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.

Crossing the chasm, by Geoffrey More

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.

Source : https://www.lucidchart.com/blog/root-cause-analysis

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.

Source: Government Office for Science 2017

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:

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:

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:

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

If the problem is a caused by a change in the external environment, the model may also need to explain:

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:

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

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:

Project Management Institute has made significant contributions in this area and suggests that there are broadly two types of success criteria

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:

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

Before embarking on solution design, teams should

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

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.”

Reference

The Startup

Get smarter at building your thing. Join The Startup’s +746K followers.