Product and Project Change Management
Scope Change and Failure
Change happens in that there can be no doubt. Projects must contend with this pitching deck of an operating environment while achieving the end objective. A significant negative impact can be change. Even controlled change can have a detrimental effect on the project success. To fit the classification of controlled change we assess the tasks, time and cost of the change prior to accepting the consequences. After this critique we plan the introduction of this change. Uncontrolled project (product) change happens when we accept the consequences without knowledge of what those consequences may be. Consider a project that is already over budget and late. This project has already failed these two constraints. Yet we still entertain and acquiesce to changes, bound to make an already bad situation worse. We must articulate the state of the project, including the original over spend and time issues as well as inform the project sponsor of this increase due to the changes for their acceptance. We should say no until we understand the consequences of the change and can account for the resources, time and money required.
Change Not Communicated
Another failure comes from uncontrolled changes. In the product development environment, this may originate from engineers that are responsible for portions of a system. Those engineers may find a need for a change in the system. The need may in fact be quite necessary. One engineer calls the other engineer responsible for the interfacing component to make this seemingly innocuous alteration. Ultimately the entire system goes together and the system does not work as expected. The change had consequences on other parts of the system of which these team members were not cognizant. This is not change management. We should instruct our team members to say no to change without this level of exploration with other areas of the project to determine all those implicated in the change.
Change Management Solutions
Change management within the context of the project need not be a long lead time or logistical challenge. Collocating team members, constant interaction between the team members, the project manager and project sponsor can go far in reducing the adverse impact of change. A constant review of the design, even if manual can be very helpful. Product lifecycle management tools that allow all team members visibility into the present state of the individual subsystem parts facilitates communicating the design direction to the team. To some this may seem like an ad hoc approach, but that would not be true. Stripping away the clutter and maintaining a system that provides quick adjustments and response to change is not necessarily ad hoc but can follow more of an agile approach.
Of course, an organizationally adopted change management process is an effective approach. This may be less responsive to change, however this often comes with institutionalizing the organizations approach to change – less neglect. To arrive at this level of institutionalization we must train and instill in our talent our approach to change management.