Change is inevitable during projects. Many Project Managers, and Customers, wrongly interpret scope and change control procedure as methods of limiting the change, when can actually be tools to facilitate change, while maintaining control over the project. The change control plan is developed since the startup of the project and it is a good idea to communicate with the client at the kick-off meeting how change will be addressed during the project.
During project implementation, priorities change, new elements can occur that during the analysis were omitted, that are implicit requirements or that no one thought of. If you choose to implement using an iterative method (e.g. Agile), which implies presenting periodically the application / product to the client, changes will occur earlier. If the approach is sequential, meaning to show the client only the end result, these changes will be deferred until final acceptance, which increases the risk of the project. In an iterative approach, the client sees an intermediate product and is able to work with it (even for testing purposes), so they can tell when some functionality was forgotten.
As change is inevitable (many say it is even recommended) under the pressure of the business environment today, which is in constant motion, why is Project Management sticking to the old, un-flexible way of doing business? Why not admit that change will happen and plan for it ? What can be done about it?
First, consider how being unflexible about change might cause tensions with the client. And we can identify two cases:
• The client failed to include important functionality but allocated all budget. They want the missing functionality to be included, or the system will not be useful for them, but the zero budget constraint blocks any change;
• The review of the project scope has "grey" areas that lead to interpretation.
One solution in such cases is to introduce the new requirements and remove the less important features not yet implemented, so that efforts to implement the new functionality will be equal to the ones out. This means to have (or will have to create) a list of product functionality, ranked by their importance. It will be much easier for the customer to decide what features can be removed, starting with the end of the list. This is called a MOSCOW list in Agile. Agile can help with spotting implicit requirements as well, early in the project, by exposing the customer to the product in early stages of the project, so that the client can pin-point if something important is forgotten.
Another important method by which we can prepare for change is to advise the client that they keep a part of the budget for the times when extremely important features are found but were not expressed in the initial scope. A good rule of thumb is to have this contingency at about 10% of the project. This will create a comfort for the project team from both the client and the provider that there is a solution for crisis situations and the whole team will focus on achieving all project objectives and carefully using this contingency, and not searching for ways to defend their position. In my experience, fully allocated budget with the assumption that everything will go according to plan ranks among top 5 reasons for project failure. That is why, when in a project that is in difficulty, I always advise the client to budget 10-20% for change requests. It is not a lot, after all the work and the struggle of the project, and lifts a lot of tension from both the client and the provider, leading to a normal working environment and quality results.
Finally, a Project Manager should introduce these mechanisms at the proper time. The easiest method is to discuss this possibility with customers early in the project, namely during the kick-off meeting, or even earlier if possible.