Developing new products or new services often begins with recognizing the existence of a problem not previously noticed. Because new opportunities are rare, speed in bringing that new product or service to market is a critical element of success. And that requires that we find a solution to the problem as quickly as we can. We try to do so, but efforts to manage financial risk frequently lead to underfunding the problem definition phase, which causes delays and lengthens time-to-market.
People in modern organizations generally regard project teams as being the points where most of the work of problem solving occurs. When we consider ways of achieving ever higher-velocity problem solving, we tend to assume that the greater portion of velocity improvement lies in helping project teams solve their problems faster. But that point in the problem-solving life cycle might not be the place where improvements are most needed. Improving problem definition might yield even greater gains in velocity.
Why problem definition is so important
In the context of solving problems, velocity is only conceptual, because we cannot actually measure problem solving velocity. What we can measure is the time interval between conceiving an objective and achieving it. But for solving problems, that measurement is still a bit squishy. Solving a difficult, complex problem often entails adjusting the problem definition using the knowledge we gain from our initial problem solving attempts. The goal we finally achieve is often different from the goal we set out to achieve, because we re-define the goal based on what we learn from early attempts to reach it.
That's why higher-velocity problem definition can be critical to success.
Consider, for example, the problem of sending people to the Moon and back. One approach was clear by the early 1950s, as illustrated in a YouTube video narrated by Wernher von Braun. This early solution involved a rotating wheel-shaped space station with a crew of 50. Among other missions, the station was to act as a fuel depot for the lunar expedition vehicle, which was to carry a crew of 10. Compare this to the solution ultimately adopted by NASA, which had no space station. It had a lunar expedition vehicle with a crew of only three. NASA's approach had so little in common with the early solution that one might reasonably conclude that the two solutions were addressing two different problems. Between the early 1950s and the early 1960s the problem definition had sharpened. And that sharpening — that refining of the problem definition — is a pattern common to the solution histories of many complex problems.
Improving problem definition might yield gains in velocity even greater than improving problem solving. Those gains become available only if we're willing to invest consciously and directly in problem definition efforts. But we're rarely willing to invest at the needed levels because of what might be called the problem definition paradox.
The problem definition paradox
A fundamental We continue to try to solve
complex problems before
we've adequately refined
the problem definitionpractice of high-velocity problem solving is higher-velocity problem definition. And that's where the trouble now lies. We can solve complex problems more rapidly if we can find ways to accelerate the problem definition process. But we continue to try to solve complex problems before we've adequately refined the problem definition. This difficulty can be understood as a consequence of our paradoxical approach to funding the problem definition process.
In conventional new product development, the problem definition process establishes the goal. It defines in broad strokes what the new product (or service) will provide. When we feel that the definition has been sufficiently refined, only then do we apply resources to developing the new product or service in question.
But difficulties can arise, because we cannot truly understand complex problems until we try to solve them, or at least, until we try to solve less complex versions of them. These early attempts to solve problems, even in their early forms, are costly. And so we withhold serious investment until such time as we have a problem definition that meets our thresholds for stability and clarity.
Typically, we develop these problem definitions over months and sometimes years of endless meetings, repetitive debates, occasional prototypes, and much use of PowerPoint. Finally, we invest a little in a demonstration effort that we call a "proof of concept." If the investment in the demonstration is large enough, the sunk cost effect ensures that the concept will be declared proven, whatever the outcome of the proof-of-concept effort.
But therein lies the paradox. On a shoestring budget we cannot develop a problem definition that's sharp enough, focused enough, complete enough, and stable enough to support commitment of resources sufficient for success. Consequently, when we apply those resources to the problem solution effort, a significant fraction must be dedicated to problem redefinition. We end up spending the resources we thought we had saved. But they're spent instead on development dead ends that could have been avoided by investing more heavily in problem definition. And by limiting expenditures on problem definition, we pay the additional penalty of schedule slippage.
The paradox is that avoiding serious investment until we have what we think is an adequate problem definition prevents us from developing a truly adequate problem definition. This happens because for complex problems, developing an adequate problem definition requires serious investment.
Untangling the paradox
Here are four strategies for achieving higher-velocity problem definition.
- Regard problem definition refinement as investment
- Refining a problem definition is an investment. The return on that investment is more rapid development of the ultimate solution to the problem. And that can lead to shorter time-to-market overall.
- Avoiding investment in early problem definition refinement can lead to false starts when product development begins. The cost of those false starts can exceed by far any amounts saved by reducing investment in problem definition refinement.
- Replace the term "proof of concept"
- The term "proof of concept" — and its shorter cousin "POC" — biases those tasked with investigating the validity of the concept. The bias arises because the term suggests that the mission of the investigation task is providing proof that the concept is valid, rather than assessing the validity of the concept. Because the effort is biased, the team engaged in the work is at risk of finding that the concept is valid when it is not.
- What's actually needed is an objective assessment of the concept's ability to contribute to achieving the goal. Devise a term that more accurately describes the mission. Words like "investigation," "experiment," or "assessment" are more appropriate than "proof."
- Start investigating the problem before you're "ready"
- In many organizational cultures, the current definition of "readiness" for solving a problem sets too high a threshold for committing resources at levels needed for problem definition refinement.
- Unless you feel that the resource requests for problem definition refinement are premature or excessive given the current state of knowledge, you're probably thinking about committing those needed resources later than they're actually needed.
- Field multiple independent problem definition efforts
- Simultaneous independent problem definition efforts provide two valuable advantages. First, their independence enhances the probability of discovering important attributes of the problem. Second, because they proceed in parallel, their results are available more rapidly than a single effort could produce.
- With multiple parallel independent efforts underway, a spirit of competition could develop, which would also benefit the organization by motivating the competitors to address the problem creatively.
Finally, be willing to discard first efforts, even after they've entered service. A willingness to discard them is a way of mitigating the risk that problem solving was declared complete while problem definition was still underway. Top Next Issue
Are your projects always (or almost always) late and over budget? Are your project teams plagued by turnover, burnout, and high defect rates? Turn your culture around. Read 52 Tips for Leaders of Project-Oriented Organizations, filled with tips and techniques for organizational leaders. Order Now!
Your comments are welcomeWould you like to see your comments posted here? rbrenHoWzUJVeioCfozEIner@ChacbnsTPttsdDaRAswloCanyon.comSend me your comments by email, or by Web form.
About Point Lookout
Thank you for reading this article. I hope you enjoyed it and found it useful, and that you'll consider recommending it to a friend.
Point Lookout is a free weekly email newsletter. Browse the archive of past issues. Subscribe for free.
Support Point Lookout by joining the Friends of Point Lookout, as an individual or as an organization.
Do you face a complex interpersonal situation? Send it in, anonymously if you like, and I'll give you my two cents.
More articles on Problem Solving and Creativity:
- Figuring Out What to Do First
- Whether we belong to a small project team or to an executive team, we have limited resources and seemingly
unlimited problems to deal with. How do we decide which problems are important? How do we decide where
to focus our attention first?
- How to Foresee the Foreseeable: Preferences
- When people collaborate on complex projects, the most desirable work tends to go to those with highest
status. When people work alone, they tend to spend more time on the parts of the effort they enjoy.
In both cases, preferences rule. Preferences can lead us astray.
- What Keeps Things the Way They Are
- Changing processes can be challenging. Sometimes the difficulty arises from our tendency to overlook
other processes that work to keep things the way they are. If we begin by changing those "regulator
processes" the difficulty can sometimes vanish.
- Cassandra at Work
- When a team makes a wrong choice, and only a tiny minority advocated for what turned out to have been
the right choice, trouble can arise when the error at last becomes evident. Maintaining team cohesion
can be a difficult challenge for team leaders.
- On Reporting Noncompliance
- Regulating compliance with process design in organizations requires monitoring process usage. Typically,
process monitors depend on reports from process participants. In blame-oriented cultures, fear of retribution
can limit what these reports contain.
See also Problem Solving and Creativity and Project Management for more related articles.
Forthcoming issues of Point Lookout
- Coming June 14: Pseudo-Collaborations
- Most workplace collaborations produce results of value. But some collaborations — pseudo-collaborations — are inherently incapable of producing value, due to performance management systems, or lack of authority, or lack of access to information. Available here and by RSS on June 14.
- And on June 21: Asking Burning Questions
- When we suddenly realize that an important question needs answering, directly asking that question in a meeting might not be an effective way to focus the attention of the group. There are risks. Fortunately, there are also ways to manage those risks. Available here and by RSS on June 21.
I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenHoWzUJVeioCfozEIner@ChacbnsTPttsdDaRAswloCanyon.com or (650) 787-6475, or toll-free in the continental US at (866) 378-5470.
Get the ebook!
Past issues of Point Lookout are available in six ebooks:
- Get 2001-2 in Geese Don't Land on Twigs (PDF, )
- Get 2003-4 in Why Dogs Wag (PDF, )
- Get 2005-6 in Loopy Things We Do (PDF, )
- Get 2007-8 in Things We Believe That Maybe Aren't So True (PDF, )
- Get 2009-10 in The Questions Not Asked (PDF, )
- Get all of the first twelve years (2001-2012) in The Collected Issues of Point Lookout (PDF, )
Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info