Purging Risk in Product Development: How the Earliest Development Phases Make or Break a Product

While many organizations perform extensive verification of their products, such activities often occur late in the development cycle, and narrowly are focused on details of the product’s functional behavior. Unfortunately, the issues and risks that occur early in the development cycle often cause the biggest headaches and typically go unnoticed until they are deeply entangled with dozens of other decisions.
A rigorous process applied early in development is needed to mitigate problems before they become compounded. However, few organizations invest time and effort in early verification and risk reduction activities as issues lack clarity, problems are not yet apparent, and product release seems a long way off. This is why problem and solution approaches must be verified early as decisions or omissions can have a cascading effect, making them very difficult to address later on without major schedule or cost implications.

Dispelling Myths
Let’s start by addressing a few myths that inhibit many executives from making early issue detection and problem prevention a high priority.

1. Myth: Prior experience with existing products is a sure indicator of success when adding new features or implementing next generation technologies.
The design and implementation of the previous generation product is the solution to yesterday’s crossword puzzle. While the domain and technical knowledge of the product creators establishes their ability to solve challenging crossword puzzles, today’s problems encompass different customer expectations, competitive threats and technologies.

2. Myth: Being late to market with a new product or major product enhancement may delay revenue, but doesn’t have a long-term effect on market share.
There are a few cases where being late to market does not diminish market share. However, if your company is in a competitive market and is preparing to release an innovative new product, or a set of innovative enhancements for an existing product, then time to market matters a great deal. Motorola, Nokia and Research in Motion (BlackBerry) each have lost significant market share in the cell phone industry by being late. Word Perfect and Lotus each forfeited their leadership position to Microsoft when their release of a Windows-based product was delayed.

3. Myth: There’s ample time to compensate for omissions or incorrect assumptions made early in the product development process.
During the lifetime of a project, hundreds of thousands of project, architectural and requirements decisions are made. These decisions form a complex, highly interdependent web. When an important consideration is omitted from an early decision, or an early decision is incorrect, a domino effect ensues. This impact cascades throughout the system, directly affecting other decisions and the decisions that depend on them. Uncovering and addressing early errors or omissions is critical.

4. Myth: Requirements are statements about the problem and can be written independently of the solution.
Requirements are a necessary element of product development. They specify what is to be built, and what outcomes must be verified to accept the final system as complete. During the earlier stages of product development, requirements are dominated by uncertainty in marketing, technology, resourcing and timing. To define effective requirements, risks must be assessed, well-informed tradeoffs must be made and external forces addressed.

Risk Reduction Rate
Removing residual risk early in the development process isn’t easy, but it definitely is necessary. At this stage, the focus is more on intended outcomes and what actions will be needed to achieve them. Concerns lack clarity, other potential problems may not yet be apparent, and risk management is perceived to divert resources from forward progress.

Figure 1 illustrates a repeating pattern of activity in product development.

Figure 1: Pattern of Activity at all Life Cycle Stages

This pattern is commonplace in the implementation stage. Use cases and goals are the drivers or requirements for development. Analysis of these drivers reveals challenges in the form of constraints, barriers and risks that must be overcome. The design and implementation decisions made by mechanical, electrical and software engineers result in the product. At the same time, these use cases and goals motivate verification tests, which try to establish that the output of product development process addresses all of the drivers. The effectiveness of the verification process is determined by how completely it covers all of the key challenges.

It is important to recognize that this pattern is not restricted to the implementation stage. As Figure 2 illustrates, the pattern of drivers, challenges, decisions and verification is applicable throughout all stages of product development.

Figure 2: Stages of Product Development

This pattern highlights the following interdependencies among stages:

1. Decisions in upper stages become drivers in lower stages;
2. Product development stages are in alignment when drivers, challenges, decisions, and verifications are consistent from upper stages to lower; and
3. Residual risk accumulates in a product when challenges are not properly accounted for in an upper stage.

Scenarios for Systematic Risk Reduction
A scenario is a self-contained environment that can be envisioned and analyzed in-depth. Scenarios are useful for verifying decisions and identifying risk at all stages of product development. In fact, their value is highest in the earliest stages. There are two conditions for using scenarios to verify decisions and identify risk:

1. Each scenario must capture the following variables:

• The expected outcomes, with supplemental information to assess tradeoffs; and
• The conditions and situation, including the kinds of forces they impose on the problem and how they impart meaning to the desired outcomes.

Attributes that can be used for subsequent grouping and analysis, such as the scenario’s level of importance, likelihood of occurrence, and labels to identify the context, conditions and situations.

2. The full set of scenarios must cover all relevant forces. Like test wells drilled in a potential oil field, the scenarios need to form a representative sample.

Depending on the life cycle stage and the particulars of the scenario, verification can take different forms, such as hypothetical reasoning, spreadsheet models, simulations or prototypes/proofs of concept. Whichever method is used to test a scenario, it is important to capture each unverified decision that affects the outcome of a scenario and record it as a hypothesis. Recording the list of hypotheses in a scenario provides a rationale and audit trail.

Hypotheses are vital because they often are necessary to make tentative decisions that in turn, advance the development process.

This especially is true in early life cycle stages, where uncertainty is highest. An effective way to flag risky decisions is by tagging each hypothesis with:

• The nature of the impact—positive or negative and what magnitude;
• The confidence level of the impact, from wishful thinking to virtual certainty; and
• It is important to highlight decisions that are linked to the most important or urgent outcomes and also have a high degree of uncertainty, so that the supporting investigations can be accelerated. In addition, it is prudent to try to isolate downstream decisions that depend on these high-risk, high-impact decisions.

Challenges as Cornerstones
A challenge is a constraint, uncertainty or force that affects how well a decision (or set of related decisions) achieves its goal. Challenges and requirements are different. Requirements are outcomes that a product or system must satisfy; they are decisions. Challenges, by contrast, are barriers or forces that make requirements difficult to achieve. Product developers must overcome challenges in order to satisfy significant requirements.

Challenges are the glue that link drivers, decisions and scenarios. From a risk reduction perspective, the critical question is, “what gives you confidence that your list of drivers is complete and your list of scenarios covers all of the important conditions and situations?” The unknowns and uncertainties that are identified late usually are the most hard-hitting.

The above question is a difficult one for most organizations to answer with confidence. Embracing the following four approaches, however, can greatly improve confidence levels:

1. Recognition and understanding of challenges often is subject matter-dependent. As a result, it is imperative to have strong, deeply experienced subject-matter expertise participating in challenge discovery, especially as related to the customer;
2. Prioritize challenges according to importance, difficulty and centrality, and use this prioritized list to verify coverage of the identified scenarios;
3. As you start to construct scenarios, develop a feel or sense for how difficult it will be to satisfy each one. Insights into why a scenario may be difficult to achieve helps to identify hidden challenges; and
4. Some high-risk decisions need deeper investigation and the simulations and prototypes used for analysis will uncover new challenges not originally envisioned. It is these challenges that if left undiscovered, will derail a project.

* * *
Product development, for the most part, is about managing risk throughout the entire development life cycle. However, most organizations do not employ active risk management practices until late in the development cycle when risks can be calcified by the ineffective decisions made early in the process. Early decisions cascade into later decisions and exponentially can grow in magnitude as the development process progresses.

Some amount of risk in product development is unavoidable, but too much is toxic. Risk is difficult to see and may or may not be realized; if manifested, its impact may be difficult to predict. The greatest problem with decision risk in product development is the cascading effect one decision has on another and the highly complex recovery matrix that ensues. When risk is allowed to linger to long, its effects propagate widely, and its cost mushrooms.

Proper use of scenarios as sounding boards to verify decisions and to flag hypotheses is critical, as is using challenges to ensure that scenarios effectively are addressed. By using the approach outlined, organizations can effectively employ formal risk management at the very onset of the product development life cycle. Through the use of these techniques, development teams continually can assess and verify the “goodness” of their decisions and actively manage the uncertainties found early in the development process when their impact is manageable and less costly.


Charlie Alfred is a vice president with Foliage Inc., a Burlington, Mass.-based product development services firm. He has more than 30 years of experience as a software engineer, working in a wide range of application areas including: medical devices, semiconductor control systems and workflow management. He is a leader in the development of software architecture formulation and evaluation methods and has published several white papers in these areas. Christopher Miles serves as vice president of the Consulting Services group of Foliage. With more than 20 years of experience in the research, design, development and management of complex medical and biotechnology products, Miles has contributed to numerous U.S. patents, and directly collaborated on the commercialization of more than 20 new medical and biotechnology products. Foliage, Inc., a privately held company based in Burlington, Massachusetts was founded in 1991 to address the challenges faced by companies developing complex software intensive systems. The company provides clients with critical insight into their product development processes to help them develop and deliver the products their customers want, when they want them. With a full complement of services aligned to business needs and applied over the entire life cycle, Foliage ensures successful product development programs for companies, including multi-national Fortune 500 corporations and venture-backed startups in the medical and life sciences, aerospace and defense, and industrial equipment industries. For more information, visit foliage.com.