I was looking at this HBR article from year 1969 about How to Deal With Resistance to Change and you would also agree, that things are still the same. Any significant change in an organization has to face resistance from people. The article goes by referring to typical situations/conversation between Engineer and Operator to explain resistance to change.
So the question is why do we resist the change? Is it pretty natural, or there are specific aspects if we can understand and work-on-them so that we can appropriately deal with change? In the context of project change request management, it is important to understand typical reasons why people resist. It enables project managers to get buy-in from project sponsors, customers, team and other stakeholders; and drive the project forward to meet project objectives.
Let’s look at five reasons why we resist to project change request or any change for that matter.
Not surprising to see that people with conservative mindset would not agree that the problem even exists. More often than not, it is the easiest and basic form to oppose proposed solution.
If you have been following ZilicusPM blog you would recollect this post about effective project management wherein I correlated ‘Six Blind Men and Elephant’ analogy. The point is, if everyone has limited perspective to their own department, career aspirations, we tend to ignore the larger picture. We do not agree that the problem even exists.
A coordination group of formulated with champions/representatives from different department who can collaborate with other department and focus on larger problem than department/project specific problems.
Once all of us agree that there is a problem, there is a chance that we can move forward for a solution. The second major hurdle in project change management is conflict over the priority.
If the problem has been there for quite some time and is without any solution, it clearly means - people perceive the severity of problem differently i.e. conflict. That means the problem might have differential impact on different department / people / stakeholders. And this causes conflict over priority to devise solution. I think example will make it easier to understand.
Technology team thinks whether a given issue/feature is supported in the existing architecture or not, or it may be a small problem from customer stand-point but may involve significant technical work. According to sales team the same problem would become make-or-break deal for customer but customer may not openly acknowledge it or alternatively, potential business from customer will multiply if we address a given issue (or provide a given feature), hence sales guys would like to have the solution in place at earliest. This is a conflict of priorities.
The solution is not so easy in case of for such conflicts, since it requires flexibility from each stakeholder to address problem and approach towards the solution. We need to check the assumptions judiciously.
Let’s say stakeholder’s agreed that there is a problem and also agreed towards the direction of solution to address the problem. The next challenge in managing project change request is - agreement over completeness of a given solution i.e. ‘this particular’ solution will solve the problem and would even argue that this solution might create another set of problems.
Sometimes project stakeholder simply brush-off a given solution without looking into the details or the real-solution. The logical demonstration, proposing multiple-options of solutions, evaluating pros-cons for each, effort-impact/ cost-benefit analysis will help you get agreement.
The solution also has to acknowledge the concerns raised by stakeholders, highlighting how a given solution address their concern will get you buy-in.
Now comes the implementation part. Stakeholders agree a given project change request is really problem for us and this solution offers greater-benefit for project/organization; but how do we do it?
Not surprisingly, we will hear, 'My team is extremely busy, I don’t have x-professional/skilled person, we don’t have x technology and so on'.
The solution is step-by-step resolution of each concern, address the implementation related problems in structured and logical manner. You have already done lot of conflict resolution and convincing stakeholders; the implementations obstacles / roadblocks can be removed too.
Yet you will keep hearing If It Ain’t Breaking, Don’t Fix It, or some kind of pessimism/paranoia. This is mostly because of venerated feelings for doing something totally new. This is where the champions from each department can collaborate with their team and address their fear/worries, inspire them to start working wholeheartedly.