Predictability, and the pursuit thereof, is a common theme we encounter when working with large company clients and their Product Development teams. The concept is understandable, as big business must have some mechanism of predicting future performance and communicating this to its stakeholders and shareholders.
However, many of the traditional steps companies take in the pursuit of predictability, in combination with the pursuit of speed, are counterproductive and ultimately lead to less predictable outcomes and reduced speed due to rework and back tracking.
Let me give you an example. The pursuit of predictability often manifests itself in the form of a design freeze at a certain point in the process. Beyond this point the business does not want any open questions or changes to design in order to allow other functions to kick off their activities in earnest (Operations, Regulatory, QA etc.). Theoretically, the idea of a design freeze makes good business sense and should drive and focus the development teams to ensure that all of the open design questions have been resolved by a particular point in time, thus giving certainty to downstream activity planning.
That theory is fine when the decisions are made well. But when the quest for speed and predictability, and a rigid focus on deadlines, leads to a lack of vigour in the closure of knowledge gaps, the result is often the making of decisions that have unacknowledged assumptions.
“Unacknowledged assumptions breed unmitigated risk.”
The criteria for making decisions, and the level of knowledge required to make each decision, is often not well defined and the business is reliant on ad hoc inquisitions at a stage gate review to unearth hidden assumptions and unresolved knowledge gaps. Unacknowledged assumptions in key decisions which have been made represent risks to the project that will lead to a significant reduction in the ability to accurately predict future performance, hence the paradox.
Happily resolving, or at least reducing, the risk associated with hidden assumptions does not require a root and branch redesign of your product development processes and relatively simple changes to the execution of a project can have transformative results.
Here are five critical elements to an approach which minimizes risk and improves overall predictability;
- Define the project Key Decisions and who needs to be involved in order to make them
- Document what needs to be learned in order to make each decision
- When making a Key Decision, forensically examine whether or not the prescribed level of learning has been achieved
- Where knowledge gaps still exist, commit to learn more or proceed with an acknowledged level of assumption
- Treat all assumptions associated with Key Decisions as risks, and plan to mitigate the risk through further action
It is not correct to suggest that product development is inherently unpredictable. Nor is it correct to suggest that it is predictable. Treat each endeavour on its own merits and make a determination about the level of predictability based on the level of risk. Only then can your teams have the confidence that they are moving forward with their eyes fully open, and only then should you communicate to others about what is likely to occur.
You did a great job forming your original hypothesis. It was reasonable, testable, and you secured the funding and approval you needed to embark on a journey of innovation, maybe seed commercial success, maybe take a leap forward in human knowledge. So why does it...
Uncertainty makes us uncomfortable. When we are leading innovation, and our world is by its nature laced with unknowns, we naturally want to minimise uncertainty and we tend to tackle it with planning. When we write business cases, project justifications,...
The problem with asking for something, is that you often get what you ask for. When you're writing to Santa Claus, that's good. But if you're managing a mission critical process and you're the one who has to figure out the key performance metrics that will...