What is Change Management? How to manage changes in Projects? And in general, how Changes and Project Management go along together?
Hey Crizpers, there are many chats and talks about Change Management. I have even faced a confusion when people believe this competence has nothing in common with Project Management. Well of course, this depends on what changes and where we need to manage. For instance, if the internal workflow or procedure requires changes, this would most likely be the area of Operations Management responsibility. However, as we are here to talk about Projects and Project Management, let’s look into the Change Management from the Projects perspective.
Why Changes Happen
This is a fair question. We have the requirements, the scope of work is built and the work has been started. Where the changes come from and why do we need to accept them?
If we consider that changes come only externally from the customer, or from the government or any other entity that may influence the overall situation and force us to change the plan, can we hide somewhere?
Well, should we live in an incubation with no external impact, this would either not save the project from the internal changes. Should we experience a lack of resources, or should someone decide to leave the team, or maybe a person simply got sick, this will demand us to change our plan and to adapt to the circumstances.
Thus, changes is something we need to accept as is – changes happen. Another question is how to accept them and how to implement them in a project. Or, in other words, how to manage changes?
What Change Management is
My strong belief is that Change Management goes along closely together with Risk Management. If we look at risks from a position of changes, every risk should it become an issue, would force us to change our plan of work. Therefore, the initial calling of the Changes Art is to plan Risks and consider them as possible changes.
From the Risk Management perspective, a result we are aiming to get is to build a Risk Management Plan – a strategy of how to respond to risks that are likely to occur.
To align with this attitude, we may perceive a Change Management desired result as a strategy of how to respond to changes that are happening on projects.
And now, how to clearly separate changes and risks?
Changes vs Risks
As for me, this is a reasonable point. Thereby, let’s try to reflect on how these two instances differ from each other and how the administration of these items should very.
From Risk Management we recall that initially risks to be forecasted through the assumptions and expert judgment. We note them and record in the Risk Register, we prioritize them to allow having a short list of Risks that are most likely to happen, Risks with a high probability. However, this is still a possibility of happening, not the factual occurrence.
As for Changes, the most common situation is when Changes are requested directly. Let’s say, a client has decided to change the functionality of the application that is currently being developed. Or a customer who has ordered to paint the walls suddenly has chosen another color instead of the initially approved one. Another situation is if during the delivery some law was modified and this forces us to change the way of the implementation.
To sum up the above, the difference is that during the Risk forecasting we may assume such alternatives as the requested Changes. However, they would most likely be risks with a low probability.
Changes on Projects
Now a days with the modern adaptive methodologies we do not perceive changes as something negative. Vice versa, in Agile projects changes are welcomed. We are focused on the efficient implementation and on the prompt feedback from the stakeholders. We are happy to apply the required changes in order to improve the product.
From the Agile point of view we should be ready for changes, we should anticipate them and they would be not risks but the expected flow. Thus we are here to make the process of changes implementation open and transparent and to help with it.
There are a couple of project management tools and techniques that we are able to utilize for managing Changes and we are going to look into them now.
Manage Changes
TeamWork
What we need to do first, is to work with the team. We are to put in the ground rules that changes are possible and they can happen on a project. Let the team know about it and make them prepared to accept changes.
Next, the changes implementation workflow should be clearly outlined and announced. We need to have a pure plan of how to process changes. Should changes be addressed everybody needs to be aware of how to react.
For the changes implementation procedure, make sure all the addressed changes are recorded and documented. That will help to keep the track of requests and actions made. Therefore we need to accurately trace the Change log and to timely update the actual Changes state.
Besides, this will allow us to understand how the initial idea of the project was updates, and what impact on the budget and time did we get.
In other words, Change Management process could be outlined in the following actions.
Changes Workflow
First of all, we need to get the request. Once the Change inquiry was communicated, give feedback and let the customer know that he or she was heard.
Record and document it. Our Change Requests Log should be updated timely and accurately. This will be extremely helpful on a project should we face any further issues in communication regarding the Project KPIs. Besides, this is an evident visualization of the Project Scope evaluation.
Work with the request as with a part of the Project Scope. All new requests to be estimated and scheduled. We need to identify Success Criteria for the new portion of work. That will be used for assuring the output Quality. Define Resources that are going to be allocated for the work to be done.
Once all the relevant information is gathered and configured in the eatable presentation, push it to stakeholders for approval. This is a paramount activity, otherwise changes might be perceived as Scope Creep or even as Gold Plating. We obviously do not want both.
And the final stroke, push the addressed changes to work afterwards, OR keep it in the record if declined by the stakeholders.
Tell me your thoughts on the Changes Management approach suggested above. What do you usually do when a new Change Request is addressed?
Cheers!