Every experienced project manager knows that at some point in the lifecycle of a project, if not throughout the whole lifecycle, there will be requests for changes: changes to the specification, functionality or design. Whilst a lot of effort will have gone into discussing what is needed, interviewing users and stakeholders, brainstorming, storyboarding, analysis and all sorts of other techniques, formal and informal, in order to assist with documenting the requirements, there will always be something missing or not quite right. Formal business requirements documents can be lengthy, detailed tomes and have much value but the simple fact of human nature is that sometimes people know what they want but can’t articulate or document it or, conversely, they don’t really know what they want, but will know if it isn’t right when they see it.
Inexperienced project managers may try to keep the project within the scope of the formal requirements, but such resistance is futile; it can cause additional delays and, worse, end up with a final product that does not meet the needs of the user.
So, if changes can be expected to occur in a project then we must be able to, and need to, manage that fact. Managing change should not be viewed as a way to prevent those involved in the project from messing up the schedule and altering what they want; instead it is the opportunity to modify a project as it progresses to be sure that it delivers what the client wants, which almost invariably is not exactly what was documented at the start of the project.
Planning for simplicity, managing for change
So, you might ask, if all requirements are flawed in some way why bother at all with detailed analysis and requirements gathering – and all that documentation with it’s endless revisions?
Well, every project needs a starting point and a solid foundation on which to start building. It is often only by documenting something that you can elicit what is really required later on so the necessity for change management processes certainly does not obviate the need for a thorough analysis and requirements phase but involves the processes by which the requirements can be refined over time until they are truly a detailed reflection of what is required.
Managing change, at its very least, will require a formal procedure to control the changes that are likely to be requested from various individuals, teams and departments. The change requests should be submitted to a central repository where they are prioritised by the project manager, client and stakeholders and either approved or rejected. The approval or rejection should be based on the business case and potential benefit of the change and not on how easy, difficult or inconvenient such a change would be.
Handling change requests
It is essential that a change request should not be seen as the reporting of a problem but the opportunity to improve on the final deliverable. However, the nature of some change requests will invariably cause a problem if the parties involved cannot agree on exactly what is needed and if there is a lack of understanding as to the impact on the whole project. Some requested changes can seem trivial to a client but could be technically difficult and have a knock-on effect on other parts of the project. Typically, many change requests are filling the gaps in the requirements where assumptions were made by certain parties but were not communicated to the analysts (or the analysts did not elicit the right information, depending on what side of the fence you sit).
And, of course, the biggest problem with change requests is the impact on the cost of a project. Assumed features may not be trivial to implement and there may be neither the time not resources allocated in the project or even in the contingency fund. Putting the case for additional resources is a normal part of a project manager’s role but one that does not always produce the goods so sometimes part of the change management process is to trade-off certain features or functionality already included in the specification in order to include any changes that have been approved and have good business justification.
Controlling change requests
But a word of warning about change requests and controlling and managing them; many clients will view the change request process as an opportunity to add a “nice-to-have” feature that they knew would never have got past the more rigorous analytics and requirements documenting phase. This is why it is so important to have clearly established criteria for determining the business case and business benefits of implementing a particular change.
Changes in a project are a natural part of managing a project but it is the way in which they are dealt with that determines how problematic they become. Having too lax a change management procedure will result in a project spiralling out of control but too rigid a process will result in the final deliverable not fully meeting the requirements of the client. As in so many projects it is getting the balance right that will determine success or not.