Do not underestimate changes, because in essence any project is launched in order to change something in the organization. In this post I want to share the methods of preparing for change, we will discuss why change is a little death, what the Valley of Tears is, and we will also trace the entire path of a person's acceptance of change. This is very important because, ultimately, the success of implementing changes depends on whether they become part of the new way of thinking of the team or not.
When it comes to changes, project management usually highlights two aspects of working with them - implementation and control. At first glance, everything is clear with the introduction of changes - something needs to be changed, and we are working on it. But what is control for?
It is necessary to control changes when we are working on a complex and complex project, when you have many tasks and stakeholders, when the project is characterized by complex approval procedures and requirements, the company uses resource management practices, and any change can significantly affect the project implementation plan.
Imagine NASA is designing a space module. But suddenly one of the engineers suggests replacing one part with another, safer one. No matter how good the intentions are, this cannot be done right away, because at the construction stage, the design documentation is already ready, the budget is drawn up. If deep changes are started, the date for the departure of the astronauts may have to be shifted, which could affect many related projects. But is it permissible? And how do you control the changes you make?
One of the approaches may be proposed by PMI (Project Management Institute) specialists. The institute's books contain the practice and knowledge accumulated by a large number of professionals, and if you need to control change, they can be used as a direct guide.
The PMBOK (as the PMI Body of Knowledge is called) offers a ready-made set of best practices for making and managing change in an organization. One of them is the creation of a Change Control Board, which is a group of people with sufficient authority to make decisions.
The council for making a decision can order expert opinions and discussions. After the council's work, a log of proposed changes is created at the exit, a list of approved requests, and of course the project documentation and the general project management plan are updated.
I often encounter change control at Acronis as well, because it is a familiar process for a mature company with a lot of development. For example, for each release, a scope is formed that includes all planned features. When the scope is approved, nothing can be added to the project - after all, after calculating all the risks and labor costs, we publish the release date.
But the world is unpredictable, and business-critical changes can be requested at any time. In this case, an inexperienced manager can follow one of the following scenarios:
- « “”», . , , ?
- , , . .
Practice shows that the best approach in this case can be characterized by the phrase "it depends": on each specific case, let the management make decisions, having previously conducted an assessment of the consequences of the change with the involvement of experts. After all, the vast majority of changes are possible, just each will require certain “sacrifices”: for example, new functions can be added if something is thrown out of the release, the delivery dates are shifted or outsourcers are hired (agreeing to higher costs).
And if the final decision to make changes is made, then a good insurance for the manager will be an official document signed by all parties. So that in a few months, when a lot is forgotten and the leader will come with the question: "Why are we moving the deadlines?" there was something to justify their position.
Of course, on small projects and in very small companies, the entire process described above can go unnoticed, but the larger the project and the higher the maturity of the company, the more formalized the processes of implementing changes should be.
Implementing changes
But if change control is inherent mainly in large companies and projects, then the implementation of changes is a process that even startups have to deal with.
I am sure that if you distributed to all employees of the company a short questionnaire with one single question “Would you like your company to work more efficiently”, the overwhelming majority would answer “Yes”. But at the same time, changes in the work of the company are always associated with certain difficulties: instinctively, most employees resist changes, because change is when “ someone else asks us to do something new”.
The degree of inertia in any team is great. And if you've never implemented a new teamwork process, then you probably underestimate this power.
Leaders and managers are often better than staff at seeing opportunities, understanding strategies and risks. And it is the managers who have a very important task - to explain to everyone why changes are necessary.
One model for understanding human motives was described by psychologist Kurt Lewin, who worked at MIT in the 1940s. His model “Field of the force of change” assumes that a set of opposing forces act on each individual (or organization): impelling and limiting. It is on the balance of these forces that the current state depends.
If we look a little deeper at this model, we can conclude that the key to successful implementation of changes is working with people, their motives and internal constraints. For example, a new incentive in the form of a motivated leader can move an organization out of stagnation, but over time it will weaken or face resistance, establishing a new status quo.
Change is like death
This comparison is not accidental, because if you believe the approach of Elisabeth Kübler-Ross, a person reacts in a similar way to any significant changes, be it a personal tragedy or simply changes in the organizational structure of the department. Elizabeth, in the process of working with patients who suffered from incurable diseases, identified the following stages of making changes:
- — , “ , ”. -, - -, —
- — : “ ? ! !” , , , , -
- — , , . , ,
- — , , ,
- — , . , , . « ». , , . ,
- Solution - New models of behavior have been found, they are being developed, and best practices are being formed. At this stage, people make less and less mistakes, new patterns are created, the company is approaching the updated status of the Quo.
- Integration - If we are talking about introducing changes in the company, then after all this, embedding changes in the corporate culture is required
All these stages can be roughly divided into three larger categories:
- Defrost - Disappointment with current settings
- Movement - Finding New Approaches
- Freezing - Fixation of working practices
But how a project manager should behave at each of the stages, how to achieve maximum acceptance, which employees to work with and how to accelerate the implementation of changes, I will tell in the next post. We will also get acquainted with the models of implementation of changes and the methodology for assessing the probability of success of the implemented changes. So don't forget to subscribe to our blog if you haven't already. And I will be very happy if you tell in the comments about the experience of implementing changes in your company.