By: Michael Fruhling
Product development requirements often change in the course of a project, sometimes for the most arbitrary of reasons. Too often, the executives who ask for these “tweaks” fail to understand the significant ripple effects these changes can cause in terms of manpower, resource allocation and time, warns Michael Fruhling.
Product development requirements often change in the course of a project, sometimes for the most arbitrary of reasons. Too often, the executives who ask for these “tweaks” fail to understand the significant ripple effects these changes can cause in terms of manpower, resource allocation and rework.
Here is an example that describes a typical, all-to-common scenario:
R&D manager Joe Smith was assigned to develop a new personal care product consistent with business strategy. The Marketing manager shared his product requirements with R&D, which enabled Joe to define technical needs and requirements and to allocate support resources.
Four months into his work, marketing contacted Joe to let him know that due to their CEO recently took an international shopping trip, and was “monumentally inspired” by a new product he saw. Therefore, the product requirements would need to change. In order to accommodate these changes, Joe’s team would need to invest considerable additional time and effort and incremental expense. They set to work to adjust to the change in plan and resurfaced a previously shelved technical development that now was more appropriate for the revised product definition.
This story highlights that needs frequently change during the course of managing projects, sometimes for reasons that aren’t always obvious or even understood by those who must react to them. The ripple effects of these changes on the efforts of others can be substantial, a fact not always recognized and or even appreciated by the parties who seem to casually trigger them with their often arbitrary decisions.
What does this story show us? Product needs and project requirements can be subject to change, sometime without notice. That’s why it’s necessary that technical organizations be sufficiently flexible about the suitability of alternate technical solutions and approaches – so they can accommodate such changes if and when they do occur.
By Michael Fruhling