The concepts of "product delay" and "customer requirements" in new product development (NPD) can be reframed beyond the typical perspective of some practitioners.
This post was inspired by a December 2012 question in the NPD In-the-Know Linked in group. The question was "A leading cause of product delay is the late discovery of customer requirements. Shouldn't this be done in detail prior to development?"
One of the reasons for new product development is to attain future successes (reflected in metrics related to financial return on investment, market share,... or to increase knowledge, solve a customer's problem, ...). When I reflected on this, my perspectives of two terms, "Requirements" and "Delays," evolved.
Requirements
All of the requirements can not be discovered at the beginning of a development effort. There are uncertainties associated with the scope of the project.
Most products have very few requirements. For example, an electronic product must conform to regulations (such as electromagnetic compatibility and safety) in specific geographies at the time of product introduction. Even these regulations may evolve. There may be other contractual requirements.
Other development parameters are unvalidated opinions (guesses, forecasts, preferences,...) about what features and price points will be embraced in an uncertain future. Often, these unvalidated opinions provide faux confidence. Success is determined by the interaction of these parameters with an evolving, future system that includes competition, new technology, and emergent trends.
Successful products integrate combinations of many choices with a few requirements to provide a solution to a customer's problem.
Delays
Schedules and associated delays are artifacts of the development effort. Typically, they can be gamed within a context that includes negotiations and biases in forecasts. Compliance with a bureaucratic schedule or budget will not guarantee development success.
Forecasts about the viability of future product development efforts are always subject to errors because of problems that include the lack of awareness.
Phillip G Armour described Five orders of Ignorance. These include:
- 1st Order Ignorance — Lack of Knowledge.
You know what you don't know, you have the question.
- 2nd Order Ignorance — Lack of Awareness.
You don't know what you don't know. Unknown unknowns (unk unks)
Schedules and requirements are based on guesses about the future. They can be helpful to facilitate cooperation within a development environment but they are only artifacts of the development effort.
Causes of Delay
This post began by summarizing a question from a LinkedIn NPD group. The structure of the question implied that the "discovery of customer requirements" should be "done in detail prior to development." This suggests that some practitioners recommend that NPD efforts should follow a sequence of steps with pre-defined handoffs.
There are many alternative to this serial approach.
What is the mismatch between your current development progress and success? Which delays can be reduced? Which delays are unnecessary or unwanted?
In Software Engineering Economics, Barry Boehn stated that the most important factor regarding productivity was team capability.
Another approach to improve team performance is described in my Deliberate Practice - Pursuing Perfect Product Launch article. The article includes a comparison of explicit coordination and implicit coordination through team situation models.
Development approaches
It is rather easy to develop a product that meets some set of requirements and is delivered on-time. Some managers are rewarded for meeting the milestones associated with these projects. Often, metrics and milestones are proxies for success.
It is much more difficult to develop a fantastic product that provides the appropriate solution at the appropriate time that is embraced by an abundant number of customers and provides abundant profits (or some other desirable metric) to those that made the investments.
When a development effort conforms to what Cynefin refers to as a "Simple" or "Complicated" domain, one may achieve success while embracing beliefs about discovering all requirements and avoiding delays.
In most development contexts, the Cynefin domain is "Complex," and other development approaches are more likely to produce development success.
Maximizing the potential for success involves more than contrasting waterfall [or BDUF (big design up front)] approaches and agile approaches. It requires a focus on improving the skills of individual contributors and the quality of their interactions within new product development networks. It includes efforts to improve individual and network capabilities such as:
- Agility
- Adaptability: Power to adjust or change in order to cope with new or unforeseen circumstances
- Cooperation
- Cohesion
- Collaboration
- Harmony: Interaction of apparently disconnected events or entities in a connected way
When the fitness of the development network improves, this facilitates the discovery of better solutions in shorter amounts of time. This inspires individuals to enthusiastically take action as informed contributors to achive the desired goal — the development and delivery of a fantastic new product.
Recent Comments