How many times have you heard the usual “noes”?
You pitch a new product idea or solution to a problem to your boss, an executive, or a committee with decision making authority. What’s the likely response?
No, that won’t work. No, we’ve already tried it. In theory, it sounds good, but in the real world, no way; it’s a different story. No, it’s too risky, we don’t want to touch it. No, it’s not practical; it’ll take too long and cost too much to make it work.
I’ve heard them all in my more than three decades of professional experience. From bosses at corporations where I worked as well as from prospective investors of companies I’ve cofounded. And the word “no” is epitomized in the title of the recent bestselling book called “That Will Never Work” by Marc Randolph, a cofounder of Netflix.
Questions abound, justifiably, in the minds of decision makers about your idea. Will it solve a real problem of interest? Will it lead to a successful product in the market? Will it serve a public cause? Is it really as world changing as the originator of the idea claims? What does it take in terms of money and time to develop this project, and is it really worth it? Nobody, of course, has the answers to these questions at the ideation stage, not even the idea’s originator.
Few people want to risk investing in a new project. They don’t want to waste their resources—money and labor—in developing and testing a new idea that may eventually turn out to be a dud. Different people will have different reasons. But the root of a rejection usually lies in the technical uncertainty of the idea.
It’s this uncertainty that creates technical risk for the investment that many people are afraid of. If your idea is geared for external customers, of course there’s additional market risk of whether the product/solution will be commercially successful once it goes to market. The latter is an external risk over which we have little control. But the technical risk is internal, and therefore, we should be able to manage it more effectively.
Ambiguity risk
The technical risk can exist in different forms. First, you may be dealing with new, unproven technology. Second, the technical requirements for the new solution may not be clear up front but can evolve during the development process. Third, it can be a technically complex project. All these risks have one thing in common—ambiguity. So they’re called ambiguity risks. These exist because of imperfect knowledge or understanding. The ambiguity surrounds how the project will unfold.
Unproven technology
If you’re developing a new technology, you know from the get-go it may or may not be proven. You don’t know the exact outcome (success versus failure) until it goes through a series of prototypes and testing. When you’re developing a new drug, you don’t know whether it’ll be proven to be safe and efficacious. So conducting clinical trials will give you the answer.
Evolving requirements
If your project is building a bridge, you can define the exact requirements and work out the scope before starting the construction work. You can estimate your schedule and cost based on your work scope. But if you’re developing a new software application, you may not be able to capture all the requirements up front, so the project does not start with a clearly defined baseline scope. The requirements and scope will evolve as you work with your customer and explore their needs. As the scope expands and changes, so will the cost and schedule.
Technology complexity
Digital transformation projects are highly complex. They may involve emerging technologies such as artificial intelligence, machine learning, the internet of things, blockchain, etc. Adapting these technologies to business needs and integrating them into existing processes, especially legacy systems, is dauntingly complex. Capturing the totality of the scope of work at the project start in such rapidly changing technology landscape is virtually impossible.
Ambiguity risk is not new. Just ask the old-time wildcatters exploring oil fields. They know too well that drilling may lead to a completely dry well, a gusher, or a wet well that is something in between. They don’t know exactly what they’ll find until they actually drill.
Instead of risking a huge investment to drill right off the bat, a smart investor may try to reduce the uncertainty by spending a small amount initially to get more site information by taking seismic soundings. This gives the wildcatter clues about what kind of well he’ll likely end up with, so he can make a better go/no-go decision moving forward.
Today we have several such strategies and tools to analyze and reduce the uncertainty and mitigate ambiguity risks to achieve better ROIs.
Recognize the difference between scope ambiguity and scope creep
It’s not uncommon that project stakeholders and teams confuse scope ambiguity with scope creep, a common colloquial term in the industry. But they’re different. So, first, we need to understand the difference.
The latter characterizes the changes to the original or baseline work scope the executives have authorized along with a fixed budget and schedule. Scope creep is mostly undesired (unless you’re charging your client for the changes), because it’ll invariably cause project cost overruns and schedule slippage. It occurs because of many factors not the least of which include:
- The project sponsor or a key stakeholder(s) may change their minds as they learn more about their needs with project progress.
- The project team may not have done a good job in defining the “true” scope of work initially. So as the project progresses, they may have to make up for scope errors and omissions made earlier.
Scope ambiguity is inherent to certain types of projects in new product development, IT, software development, digital transformation, etc. This must be clearly understood from the start by all the key stakeholders. Alignment of stakeholders with this reality is paramount to project success.
If you cannot differentiate between scope creep and scope ambiguity, executives may make wrong go/no-go decisions and poor strategic choices. And project teams may apply the wrong project and risk management methodologies.
Avoid making all or nothing bets
One key strategy for managing ambiguity risk is to avoid all or nothing bets. Why go full force with the project investment and possibly lose it all? Or, alternatively, why totally shun the idea that may, given the chance, create tremendous future opportunities for you?
Ambiguity risk should be recognized at the ideation stage itself. Project teams must communicate ambiguity risks clearly to their executives. The key is to first develop a strategy to manage the risks.
Implement governance with phase-gates
You may avoid all or nothing bets by making incremental investments through a series of phases and gates. At the end of each phase, marked by a gate, you decide whether to move on to the next phase. Investment may continue into the next phase as long as the project meets predetermined benchmarks and still looks attractive. If not, it’s terminated or you pursue other options.
You define the scope of work in increasing detail as you go from one phase to the next through progressive elaboration. You plan the near term phases in greater detail than the later ones and continue this process in a rolling wave fashion (hence the term rolling wave planning).
Originally introduced as a “stage-gate” process by Robert Cooper, a product management expert for new product development, the phase-gate process is now commonly used in project management in industries such as IT, construction, manufacturing, biotech, and pharma. A robust phase-gate decision making process is an effective risk mitigation system.
Adapt iterative and incremental development
The traditional “water fall” methods are not effective for projects that involve ambiguity risk. Agile techniques involving iterative and incremental development offer you a better approach.
When ambiguity exists because of unproven technology, you can manage risk through iterative development. You may develop the project through multiple prototyping and testing iterations. An age-old time-tested technique, iterative prototyping can be applied to not only new product development and manufacturing but software development and other industries also.
Where ambiguity risk is due to evolving requirements or technical complexity, incremental development may be the key for risk mitigation. You can plan and develop the project in increments rather than all at once.
For instance, if your project involves a global roll out of a major ERP system, you may deploy it region by region rather than across the whole enterprise at the same time. Similarly, you may implement a complex digital transformation project in manageable increments rather than all at once.
Incremental development is not just meant for technology projects only. For example, if you’re remediating a hazardous waste-contaminated site, you may contain the spread of the contamination and treat the hot spots first rather than attempting to clean up the whole site at the same time.
Key advantages of iterative and incremental approaches include satisfying customer needs, early delivery of value, leveraging lessons learned from initial tests and deployments for later phases, shorter overall project cycle times, and reduced costs.
Utilize proper tools and techniques to evaluate uncertainty and risk
Several tools and techniques are available for quantifying the uncertainty and consequences of ambiguity risks even before the project “breaks ground.” These can help you gain better insights, so you can develop the right strategies at the right time as the project unfolds. Decision trees, scenario analysis, sensitivity analysis, simulations, stress testing, war games, and advanced real options analysis are a few examples.
The key to effective management of ambiguity risk lies in first recognizing the risk, understanding the possible outcomes, adjusting the project development approaches as needed, and following a robust risk-based decision making process. Equipped with these tools, organizations can explore more new ideas and bring more innovations to fruition. It could mean that you’ll hear less “noes.” Hopefully!
In the next blog, I’ll look at another type of risk—variability risk.
Santharam Adibhatla says
Very interesting and thought provoking. Looking forward to read more in upcoming blogs.