here are three types of problems: ordinary, strong, and wicked. Ordinary problems are trivial, and solutions are easy with a simple tool, some time, and some money.
Strong problems can be partially solved, but a complete solution demands enormous effort.
Wicked problems demand several generations and hundreds of thousands of people to be involved.
Principle: A strong problem becomes very expensive to complete as you approach the point of a 100% solution.
Key concepts: Strong problem, problem strength, fortress siege curve
Applied in: Estimating cost of a project
Main result: Cost-Question clarified — What is the cost of our solution?
Being hungry may appear an ordinary problem, with acquiring an apple or a milkshake being an ordinary solution.
If you are hungry and you are on a desert island, that is a strong problem. Not only must you find potable water and food to satisfy your immediate hunger, but also you need a persisting source for the forthcoming days and weeks.
If you want to save people from starving in an undeveloped country, it is a wicked problem.
On your Quest, you are most likely to be facing strong problems.
Why strong problems are important
Ordinary problems are widely considered in traditional management. These problems that can be solved with a certain amount of effort — perhaps a little more, a little less. The usual expectation is that if you have solved similar problems before, you will be able to estimate the necessary costs. So it is for Delivery projects. Even if there is uncertainty, the cost varies by 10–25%.
Here are examples of ordinary problems: traveling to a neighboring town, cooking dinner, building a bridge over a river, and hiring a worker for an ordinary position.
Ordinary problems are not necessarily cheap to solve. They are just quite predictable and almost linear: 80% of effort gives approximately 80% of the result. If you put a little more effort, you’ll obtain a complete 100% or at least 95% solution. Estimating the cost of solving such problems is a common operation that any experienced captain can perform.
At the opposite end of the spectrum we have wicked problems. They cannot be solved at the current level of technology even at the cost of the efforts of thousands of people, despite the fact that many generations have tried to find a solution.
Here are examples of wicked problems: cities on the Moon, cheap energy, peace on Earth, and cures for all diseases.
These problems are infinitely expensive to be solved at a level of 100% or even 90%. It is absurd to demand a 100% completion for such goals from a quest team. However, a well-funded crew of researchers can approach a narrow and very partial solution — not for all people and not for all situations, but for 1-10% of people, or for 30-60% of situations.
For example: an orbital station for several astronauts, clean solar energy for 50 houses in a valley with 300 sunny days a year, and a cheap cure for one particular disease. When such a partial and narrow challenge is set, it becomes nearlysolvable, or in other words, strong.
Strong problems stand in the middle of the spectrum between the ordinary and the wicked, and they are extremely important to us. Although we meet with them all the time, few people know how to distinguish and correctly evaluate them.
It is in strong problems that 20% of the effort gives 80% of the result.
The first part of the journey is similar to an ordinary problem and the cost of progress is almost linear, however the further we go, the more effort is required to make progress and as a result, huge resources are needed to get through the last 20% of completion.
Examples of strong problems: launching a profitable startup, becoming a world champion, finding an ideal place to live in a nearby city, inventing a new technology, and composing a popular song.
It is important that these problems are in theory solvable, as they are not wicked. We know a few successful startups, we have seen people who have become world champions, and neighbors who are satisfied with their housing in a new place. If someone else did it, why don’t we have a chance?
However, can we set ourselves the hard commitment of achieving these goals by a certain date, the next month, the new year, or even 5 years from now? Can we clearly predict the required budget?
No, we can not.
Although 100% or near-100% achievement is possible in theory, it is unpredictable in practice and will require a large number of efforts and attempts. Grandmasters can play a hundred thousands games in their life without ever becoming a world champion.
Estimating and budgeting for strong problems
The rule is: To avoid disappointment, with strong problems, never promise or demand 100% completion.
If we want to solve a strong problem, and make realistic commitments, we need to search for a limited narrow solution, give up some edge cases, sacrifice a few percent of accuracy, and be ready for compromises.
When facing a strong problem, aim to find a partial economically-viable solution, as a 100% complete solution is well beyond your budget.
If you are a captain who must evaluate the cost of solving a major problem, your job is to find a partial economically-viable solution and convince the quest givers of its advantage, even though they usually want a 100% complete solution.
If you are a guest giver, you should admit that the universal 100% solution is a good dream, but a bad objective, as it will require an enormous amount of time and money, which you can not afford. It is not the caprice or incompetence of the captain to negotiate a limited partial solution, it is the only productive way of planning and budgeting.
There are good reasons why the last 20% of a strong problem is much harder to pass than the first 20%. Initial rapid progress is fueled by low-hanging fruits and simple partial solutions to the pieces of the problems with the highest impact. But as we go further, there is more and more work, the costs go up, while progress inevitably slows down.
It becomes more and more difficult and expensive to collect and de-noise additional data, more and more experiments are required to gain statistically significant improvements, and you become more and more dependent on rare events, randomness, and luck.
For example, for a company, it becomes harder and harder to find new clients and increase the market share, for a researcher it becomes harder and more expensive to capture rare events to obtain statistical significance, for a grandmaster it becomes harder to compete against the the best players in the world and the victory may need a really rare and unpredictable series of events during the tournament, not only in the grandmaster’s matches, but also the results of matches of the other challengers.
Traditional management, and theory of quality teaches us that 100%, 99%, or 95% are good numbers, but 80% or 70% are “incomplete” and “imperfect”. But ask yourself, is 80% market share a bad thing to have? Is a 70% win rate in chess games a poor result? Is a 20% conversion rate of a website unworthy? There are many real business cases where you don’t need 99.9% even if you were advised so by a book on total quality management.
There are cases, however, that do require 99% or near 100% success rate, and they are usually related to security and mission critical applications. Those cases are usually in Delivery, not Discovery processes, and they have a very long history of trials, errors, corrections, and adjustments. If you happen to face a strong mission-critical problem that does require a 99% or higher success rate, don’t be surprised with the billion-scale budget and a very long “siege” of the problem. This is where the “fortress siege curve” goes. Several examples are pharma, the car industry, the airlines — they do require near 100% safety but they are ready to spend billions to ensure it.
Most likely, you don’t have billions for your next quest. That means your strong problem will require a partial solution and may not work in 100% of cases. In the next chapter we will discuss how to evaluate the cost and take commitments in the world of uncertainty and why Low-Fidelity solution does not mean Low-Quality solution.