To evaluate when most of the product requirements are determined in a specific new product development (NPD) context, evaluate the domain according to the Cynefin framework.
To evaluate when most of the product requirements are determined in a specific new product development (NPD) context, invest the time to discern characteristics of the product domain.
Simple Domain
In Dave Snowden's Cynefin framework, when the domain is characterized as "simple," it is reasonable to enlist proficient individuals to specify most of the requirements in the early stages of a project.
In the 'simple' domain:
There is a direct, easy-to-understand relationship between cause and effect
The concept of best practices is likely to be adopted
Complicated Domain
If the Cynefin domain is characterized as "complicated," more specialists and more analyses are required.
In the 'complicated' domain:
Analyses are required to determine the relationship between cause and effect
Typically, there are several good practices that are likely to produce acceptable results
Complex Domain
If the Cynefin domain is characterized as "complex," properties will emerge as the project progresses. Over time, the system will impact the contributors. The contributors will impact the system.
In the complex domain, contributors strive to learn as the project progresses. This requires hypotheses and experimentation. Unknowns emerge. Requirements evolve. The Lean Startup methodology embraces this evolution with build-measure-learn cycles.
The system is likely to be a complex adaptive system.
Determining what to do about requirements
The question of "Which is better?" is not the most insightful requirements inquiry. The wise product development practitioner discerns the domain and proceeds with the correct approach for the context. This assessment will provide guidance regarding the capabilities of the contributors that will be required for a successful engagement.
After one has insights about the domain and the capabilities of the contributors, another issue can be addressed.
Beyond the Iron Triangle
In many new product development environments, there is a common belief that trade-offs of product functionality, quality, and price are inevitable. This model is known as the Iron Triangle, Triple Constraint, or Project Management Triangle.
The wise product development practitioner consistently attains the appropriate levels of functionality, quality, and price because they enlist individual contributors to the project with better capabilities for the context of the project. They do not need to compromise on requirements in a 'painful' or 'desperate' manner because an informed, shared orientation enables them to consistently make appropriate design and development decisions and implement their plans efficiently and effectively.
In the 1982 book Software Engineering Economics, Barry Boehn stated that the most important factor regarding productivity was team capability. Characteristics of the domain determine specifics of the team capability. When the project domain is simple or complicated, there can be more reliance on explicit procedures and processes. When the project domain is complex, additional capabilities are needed.
Day-to-day development activities
Some product requirements evolve throughout the project. There are more changes later in projects when the domain is complex. The probability of success for any new product development network (team) improves as their adaptability increases.
According to John Boyd in Patterns of Conflict (#125, 1986),
Adaptability: Power to adjust or change in order to cope with new or unforeseen circumstances
Regardless of the primary domain characterization of a project, typical day-to-day activities will present tasks that can be characterized as simple, complicated, complex, chaotic, or disordered domains. Individual efforts and group efforts should be able to adapt appropriately to maintain a cohesive development effort.
A sufficiently adaptable new product development network can deliver great products and user experiences that meet requirements. In addition, these projects are likely to be completed on-time and on-budget.
Chaotic Domain
There is alway some chaos in every new product development effort. In the Cynefin framework, this domain is charaterized by the lack of a relationship between cause and effect.
To be productive during times of chaos during development, individuals may consider engaging in other activities such as organizing their workspace or taking a professional development class.
Decisions about product requirements should be delayed until more is learned about the domain. Consider crafting additional experiments. Often, this may be an appropriate time to enlist help from other individuals who can provide new insights.
Disorder
If everyone contributing to the project does not know how to characterize the domain, the domain is Cynefin's fifth domain, disorder. In this domain, there will be confusion about when to determine the product requirements.
Additional information
Other posts will provide insights on how individuals and group can improve their capability and adaptability. For additional information, visit the OpLaunch website.