How to Effectively Manage a Change in IT Projects

We all know this phrase well, that the only sure thing while delivering projects is change. Most experienced project managers say that changes within the projects are, as inevitable as death and taxes, and they are right.

Moreover, changes in projects are generally associated with problems that affect mainly time and budget. What is worse, if improperly managed, they may also affect day to day cooperation with the client. But do they always have to give us reasons for frustration?

Well, we cannot merely run away from changes in the projects and, in particular, when it comes to the IT area, but we can prepare ourselves for upcoming change requests. In this article, I want to draw your attention to 5 areas, which, in my opinion, are extremely important to review before we start the project, as well as in its realization phase. I hope that it will give you a more unobstructed view of how to approach changes in IT projects and even turn them into benefits, but first, let us find out what a change is.

There are many different definitions of change but in the simplest terms, a change is something that does not comply with the first client requirements, included in the project specification. Changes can also be derivatives of a wrongly implemented functionality or a bug in the code but mainly changes are associated with deviations from the originally agreed upon project scope. The causes for changes can be different but the most common ones are:

• Unclear definition of done
• Client’s requirements modifications
• Mistakes in the specification

There are many areas that can be affected by improperly managed changes but in this article, I will focus on the top five, which in my opinion should be always considered when thinking of change management

1. Contract

That is the very early stage where we need to signalize to the client that when changes occur, we have a plan in place of how to approach them, and we are ready for them the moment they happen.
Therefore, when formulating the entries in the contract, there must be a piece of information about the change requests alignments, which should include the following information:

1.1 Change definition

1.2 Change request implementation procedure including:

• Who may request a change
• Impact on the project goals and project timeline
• Realization timeframe
• Fee

1.3 Changes requests testing (especially regression testing)

1.4 Change requests production release

The main aim of such entries is to, on the one hand, assure the client that the risks of changes may impact the project will be under control and, on the other hand, show the solution provider’s mature attitude to the quality assurance process.

2. Project Analysis

A quite popular approach that used to be applied, especially in the waterfall methodologies, was to try to analyze and plan all work needed to deliver a project goal far in advance. In practice, that means the project team would focus on analyzing as many details as possible to make sure nothing new would come up within the realization phase and surprise them. That, however, sometimes would turn out to be more expensive than short, high-level planning.  

Currently, it is the agile approach that is in use more commonly. Its advocates say not to plan and analyze everything in the initial stage because change is inevitable. Therefore, it is better to assume from the very beginning, that we cannot predict everything in advance, and it is better to prepare for any potential changes before we even start the project. That can help us avoid situations such as coming up against the wall at the end of the project, with a whole bunch of changes to be implemented, with no budget and time to do it. If we acknowledge that change will happen and have a “change plan” at the “ready” stage, then we can react faster and smoother with less negative impact on the project when changes are requested.

3. Change backlog

It happened. Our client requested a change, unfortunately not one, but a couple of them. Now, it is not only about being ready to react and cooperate with a client when the change is requested, but it is crucial to keep the change backlog. It can be tracked even with the simplest tools such as an excel sheet or a confluence if you use one. What is essential is always to keep such a change diary.

During the project implementation, there can be stages where no previously aligned work is delivered to the client for one week or more because we are working only on the analysis of changes requests. On a status call with a client, we can easily explain the reasons behind the works stoppages or delays, referring to the change backlog we created. Apart from that, such a backlog, together with time estimation, gives our clients a clear view of what impact changes they may have on the timeline. 

It can also help to make a decision on which changes are significant to implement now and which ones can get added after project closing.   

4. Clients engagement

That is another very critical area to focus on when thinking of good change management practices. Let us think of a situation when, sprint by sprint, we deliver a particular solution to the client, and we receive no negative feedback. Then suddenly, during one of the demos, the product owner, who was absent for a couple of sprints, appears and says that some components do not meet the client’s requirements and have to get redesigned and newly implemented. Why did we not receive this information earlier? Because we forgot to keep him engaged on each demo call. Positive feedback only from the client’s Project Manager not always can be enough. Therefore, it is very important to identify the most critical stakeholders and always involve them in project status meetings, such as demo calls or sprint plannings. Receiving their feedback is vital in as early stage as possible because the changes introduced in the middle of the works can cause a lot of changes in previously implemented code and, as a result, always cost more than if we introduced them in the beginning.

5. Common sense approach

Both waterfall project management methodologies, including PMI, PRINCE, or IPMA and the Agile ones such as Scrum, refer to change management and emphasize its importance in the project management process. It, however, does not necessarily mean we need to implement each change that was requested straight away. It frequently happens that proper analysis vs. real market expectations can make our client realize that the change is not needed anymore, as it lost its business justification, or it is not so urgent. It can wait until more critical tasks get implemented. Sometimes, the opposite situation may happen. It is the client that comes with the new idea. As a result, it lets us improve one of the modules and its performance, as well as inspires the project team to introduce some further modifications. 

Here again, it is all about analyzing the particular change, clearly stating its impact on the base plan and the most critical project parameters, and reviewing priorities together with the client.                                                                                                              

It is true to say that changes are something we cannot avoid when working on IT projects, and we always need to be proactive when we react to them. I hope that these tips will help you get a better and more effective approach to changes that happen in your projects.

Follow us on Twitter and Facebook and stay tuned for more articles.