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? rbrenZLkFdSHmlHvCaSsuner@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.
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:
- Should I Keep Bailing or Start Plugging the Leaks?
- When we're flooded with problems, and the rowboat is taking on water, we tend to bail with buckets,
rather than take time out to plug the leaks. Here are some tips for dealing with floods of problems.
- Problem-Solving Ambassadors
- In dispersed teams, we often hold meetings to which we send delegations to work out issues of mutual
interest. These working sessions are a mix of problem solving and negotiation. People who are masters
of both are problem-solving ambassadors, and they're especially valuable to dispersed or global teams.
- Clueless on the Concept
- When a team member seems not to understand something basic and important, setting him or her straight
risks embarrassment and humiliation. It's even worse when the person attempting the "straightening"
is wrong, too. How can we deal with people we believe are clueless on the concept?
- Reactance and Decision Making
- Some decisions are easy. Some are difficult. Some decisions that we think will be easy turn out to be
very, very difficult. What makes decisions difficult?
- What Are the Chances?
- When estimating the probabilities of success of different strategies, we must often estimate the probability
of multiple events occurring. People make a common mistake when forming such estimates. They assume
that events are independent when they are not.
Forthcoming issues of Point Lookout
- Coming February 8: Kerfuffles That Seem Like Something More
- Much of what we regard as political conflict is a series of squabbles commonly called kerfuffles. They captivate us while they're underway, but after a month or two they're forgotten. Why do they happen? Why do they persist? Available here and by RSS on February 8.
- And on February 15: Four Razors for Organizational Behavior
- Deviant organizational behavior can harm the people and the organization. In choosing responses, we consider what drives the perpetrators. Considering Malice, Incompetence, Ignorance, and Greed, we can devise four guidelines for making these choices. Available here and by RSS on February 15.
I offer email and telephone coaching at both corporate and individual rates. Contact Rick for details at rbrenZLkFdSHmlHvCaSsuner@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