Better Results in IT Projects through Change Management

Your IT project started well, but now you have hit an impasse. Did your supplier’s new update turn out not to be what you were expecting? Does it look like the delivery of part of the project will be significantly delayed?

Clients and suppliers often do not want to sit around negotiating these kinds of situations beforehand, but these issues can often escalate into full-blown IT disputes.

IT disputes can often be avoided through agreed collaboration mechanisms, such as change management and steering group processes.


When we talk about changes in this context, we mean changes to the agreed outputs of a project. Changes usually lead to more work, increased budgets and delayed timetables.

The purpose of change management is to identify, discuss and plan for significant change needs that will have an impact on the goals of the IT project and that have been agreed in the specifications. Change management is worth using in both traditional and agile software development models in order to stay on top of potential changes to the timetable, goals or budget of a project.

Clear change management processes can contribute significantly getting a project across the finish line flexibly and without disputes. Change management practices can be used to curb excessive desires for changes, to analyse changes better and assess their necessity more thoroughly. 


If the scope and details of a project are unclear when entering into the agreement, you should expect trouble. The parties may have very different ideas of what the project is trying to achieve. The client may think they are getting a tailored set of ‘emperor’s new clothes’ suitable for all normal purposes and conditions. In contrast, the supplier may have come away thinking that the clothes have to be chic and practical, but may not have realised that they also have to be warm and waterproof.

When these kind of situations arise, the attempted solution is often for the project managers to agree on new deliverables and a new timetable for the project, despite the fact that the agreement may state that only valid way to decide on changes is for the steering group to make a decision and record in the minutes of a meeting. At worst, this can lead to a situation where, months down the road, the parties discover the discrepancy between what had been agreed and what was delivered, or at least find themselves with fundamentally different views of what had been agreed. A ‘flexible shortcut’ taken with the best of intentions could ultimately lead to the courtroom.


There is no getting around the importance of the parties taking the time to carefully draft the specifications for the project when trying to avoid disputes caused by differing expectations. The parties also need to have procedure for taking the client’s changing needs into account. This procedure needs to set forth how the parties agree on changes to the scope of the agreement while the agreement is in force in a manner that is binding on the parties.

Once you sign the agreement, do not just leave it to collect dust in your archives. If the agreement contains clear clauses on change management, it is worth writing up straightforward change management instructions for the client’s and supplier’s project teams. Even the best agreement cannot prevent disputes if it is not complied with in practice.