What is change management in software development and how to identify change?

At first sight, defining what is a change order is quite simple - it’s a request for something different than what was agreed on at the beginning of the project, sprint, phase etc. (e.g. in a contract with a client). It’s as simple as that, and yet there are many traps to watch out for.

Changes can be applied in a few software development project areas:

1. Business requirements (BR's) defined by the product owner, client or other stakeholders
2. Approved UI and UX designs
3. Project timeline
4. The scope of the project or particular features

All points above refer to different areas of the project and various stakeholders responsible for them (developers, account managers, QA specialists, designers, business analysts). To even start evaluating the potential impact of the change, at first it has to be defined as a change. That said, often Project Managers also have to serve as Change Managers of their projects since they are the main point of contact between project team members through various project phases.

Project Manager acting partially as a Change Manager allows fulfillment of one more crucial dependency - timing. Have you ever tried to inform a client or a stakeholder that there was a change order implemented one month ago that will increase the cost or time of the project but was not identified as such back then? Me neither.

The described situation is very likely to happen without proper change management in software development.  I can easily imagine a scenario where the account manager approves the scope of the project and then during the development, designers and developers take some parts of the features (originally not included in the scope) as obvious and implement them. When the changes are identified (e.g. when presented on a demo meeting) sometimes it is too late to properly adjust to them.

We identified the change, yay! But what's next?

Depending on the contract in place, there are a few things you might want to do, but in most cases, before any other actions, you should first get approval for change implementation.

Once change order is at least defined as a valuable one (by the client, project team or other stakeholders), here are potential actions to be taken:

1. Define how and what parts of the system will be affected by the change
2. Specify what will be the impact of the change taking into account:

• Project timeline (can or should it be extended)
• Pricing (that will be communicated to the stakeholders)
• Scope (are there any features that can be removed to include the new one)

The list above is just a rough guide but probably these are the essentials that you will have to know to proceed with a change order approval or implementation.

Keep in mind that not all changes are worth the time and effort to be put into to get answers to the questions above. Before diving into a detailed analysis, make sure it’s something worth investigating.

One of the main points in the change order process might be the approval process. To avoid misunderstandings in the future project phases, each change should be presented for approval with respective price, scope, timeline, and system impact. Proceeding with change implementation without approval basing just on your assumptions that it will or should be confirmed might lead to unnecessary project risk. The good practice is also to provide stakeholders with a list of approved changes every now and then (e.g. every sprint or two with burn up chart attached).

The changes were identified and approved. So now the question is - how to keep track of all of them?

The first go-to solution is with a proper Project Management tool. Personally, I’m used to Jira, but I’m sure there are many tools which can handle similar jobs. Proper task management and marking the tickets consequently will help you to keep track of the changes and their impact. A few easy habits that may pay off later in the project would be:

1. Start the name of the task with \[Change Order] or other similar prefixes. That way everyone working on the task will know the business context. Additionally, It might help with proper time logging (in case of time is not logged per issues) and then billing client for changes accordingly.
2. Add separate “change” component or label in Project management tool (e.g. Jira). That way you’ll be able to quickly export all of the change related tickets and prepare most of the reports in no time. (p.s. Spreadsheets with a high-level summary of change orders (and e.g. pricing for each one) are very useful if you don't want to export data each time and start from the scratch)
3. Add a brief explanation of what has been changed in comparison to the initial agreements in the ticket description. I guarantee that you will not remember such details one month later but your stakeholders might ask for it.

All of the above seems quite straightforward, doesn't it?

Well, it’s usually not. I’ve encountered numerous situations when something that’s clearly seemed to me and my team as a change was something expected as a part of the scope by the client. Besides obvious changes (like the addition of totally new features), mostly it’s down to the addition of various minor functionalities or tasks not included in the project contract (e.g. sophisticated validations, complicated filtering, UI animations, additional documentation creation etc.). Even if the changes are small, there is a risk that they will add up during the project duration and in the end, they’ll result in exceeding budget and timeline.

Additionally, part of the successful change management process is clear and consequent communication. At the beginning of the project, when the team is focused on UI design and business requirements gathering it’s up to the Project Manager to make sure that those items are signed-off by proper stakeholders. The good practice is to make sure that all of the decisions made in the meetings or calls with clients are summarized in emails or Project management tools and approved by the proper stakeholder. Above will let you accomplish the following:

1. Everyone has the same state of knowledge, so the client expectations can be met (you are making sure nothing was misunderstood or missed by any of the sides).
2. There is a documentation of approved UI/UX (including wireframes or mockups of the product) and BR’s that will serve as a fundament for further development
3. In case there are requests to add some items or tweaks (e.g. after Demo meeting), you have a clear reference point that will serve you as a base for starting the change process if needed.

Keep in mind that often from the initial UI/UX or BR’s approval, and until the presentation of the feature, there is a time gap of at least 2 weeks (often much more). Some stakeholders might simply forget details of what was approved - your job is to make sure there is a source of truth that everyone can refer to.

Chance

Changes are inevitable. They will come up and you can’t do anything about it (well, you can minimize their number but not exclude them completely). So the question is, how will you handle them?

Most of the people dislike changes and that’s completely normal - you worked hard on your project plan, code, test cases, and BR’s.  Now it has to be updated due to the changes - of course, it might be frustrating (especially if there are a ton of them).

But there is a completely different side to be highlighted here - opportunities waiting to be taken advantage of!

The most important gain here is a will to develop great, good-looking, functional products that end users will use. Make no mistake, it is not an easy task. And because of that, your assumptions and designs will change over time once you dive deeper into each feature or flow since it is really hard to define everything correctly in the discover/preparation phase of the project, especially in the complex projects. Your job is to make sure that valuable changes discovered along the way are presented to the stakeholders with proper reasoning behind it - regardless if they are or aren't accepted in the end.