When product development goes sideways (and how to fix it)

Product development going wrong? You may need a tiger team. 

Jeff Champagne and Eric Claude, MPR Associates

We would all like for product development projects to go smoothly and predictably, but you know what they say about “the best-laid plans.” Robert Burns aside, when needed technologies do not integrate as easily as planned, hardware or software bugs crop up at the last minute (or worse, cause failures in the field), or project teams struggle to complete work on schedule, forward progress is stalled. Fixed costs stay the same but time to launch date deadlines are compressed. This is only one example of when things go sideways.

Recovering from situations like these involves tough choices. Options can include:

• Do nothing and keep trying to slog it out (wishful thinking is sometimes successful but is not a guaranteed success path).
• Pivot the team to a new direction that avoids the problems that are being experienced.
• Bring in additional resources with a fresh perspective and perhaps additional knowledge to help out.

The consequences of failure can often be high, but it’s not the end of the world. Often failing early can help to avoid:

• Staff reductions until the problem is solved.
• Furloughs.
• Abandon ship.

Often, groups are hesitant to bring in an independent perspective in the midst of an on-going project. But getting outside help can be the most effective approach to get back on track. A “red team” or “tiger team” approach leverages an independent team of experts to question assumptions, validate (or refute) previous findings, and identify new paths to investigate. The key is to quickly get to the root of the problem so that it becomes clear what needs to be done to recover.

Albert Einstein put it this way: “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Once the problem is known, the solution is more easily revealed. Too often, people jump to unsubstantiated conclusions in search of quick fixes. This usually leads to a prolonged period of trial and error iterations; rarely is it a trial and solution.

Coming into a problem situation is a little like looking at a crime scene. Things that the team might do include:

• Observe the environment involved in the situation. Are there aspects of the environment that might contribute to the problem?
• Meet with the people involved. What are their skill sets and perspectives? Are there any gaps with regard to working with the relevant technologies?
• Construct a timeline of events leading up to problems that have occurred. There are often subtleties in the sequence of events that can cause unexpected interactions and issues.
• Examine the evidence by collecting the relevant data. Some useful tools can also be employed to help with the problem investigation process:
• The “five-whys” technique. This involves a series of questions are posed to determine the cause and effect of situations that ultimately lead to the problem. The goal is to dig deep to find the underlying reason as well as the sequence of events. With such insight, solutions become apparent.
• A fishbone or Ishikawa diagram which is a visual way to depict issues that potentially could lead to the problem. Typically, branches of the diagram cover several main categories of causal factors which are each broken down into further details:
  o People – including skills, training, or motivations.
  o Equipment – considering potential functional or performance limitations, wear, reliability issues, or other failures.
  o Materials – including variability in raw materials.
  o Environment – considering the impact of noise, lighting, temperature, etc.
  o Methods/processes – covering the sequence of operations, maintenance, set-up.
• FMEA or fault tree analysis to systematically identify potential causes of failure.
• Engineering analysis to determine safety factors and margin to failure in a design.
• Scenario evaluation or “what if” analysis to walk through different sequences of events and postulate consequences, considering the potential cascading effect (often a series of individually unlikely events can ultimately lead to real trouble).
• Testing of known good and faulty devices to characterize behaviors.

Ultimately, getting back on track requires fact-based decision making – using evidence to understand the likely root cause of the observed problems. It is a good practice to tabulate the potential causes along with the data that supports the potential cause and any data that would refute it. The key is to ensure that the supporting and refuting evidence is factual and not opinion.

Once the suspected root cause or causes are identified on the basis of all the data, the next step is to plan and execute a series of tests to confirm the conclusion. For example, if a component failure on a circuit board is suspected of causing the problem, a known good board can be modified to simulate the component failure and then tested to determine if it replicates the behavior of known faulty devices.

Jeff Champagne is director of business development, and Eric Claude is VP of product development at MPR Associates.