Mobilizing Change

  • Written By:
  • Published:

People Are Resistant to Change

It's not news that people are resistant to change. Inertia, one of the rules of the universe, applies to people as well as to objects.

Many organizations, seeking to improve performance, have come unstuck by under-estimating the amount of resistance that will be offered by people. Sometimes the resistance is active, deliberately undermining the efforts of those implementing the change. Sometimes the resistance is passive, where people mouth the right words but keep on doing things the old way. And why not? Making changes is hard. It's uncomfortable. And it takes a lot of effort.

Consciousness and Competency

I often think of a model relating to learning that I saw years ago when I think about change.

We start as "unconsciously incompetent"—we don't know what we don't know, and progress along in blissful ignorance. When we find out about the new knowledge, or a different skill, we are "consciously incompetent"—we know the gap. As we learn and train, our skill or knowledge develops to a point where we are "consciously competent"—we know what to do and how to do it, but we must focus our attention to ensure that we get it right. It is only when we are comfortable in the skill or application of the knowledge that we become "unconsciously competent"—we can do it without paying attention to the fine details of what we are doing.

And so it is with making a change in the organization. Most people have developed to a state of unconscious competence in their job role. They know what they have to do and they can just get on with it without paying attention to the mechanics of what they are doing. When we ask them to change, we are asking them to step down the ladder, learn and then focus their attention on doing something differently. We're pushing them back to a level of "conscious incompetence" and then "conscious competence." That means a lot more effort for them to expend.

Try It Yourself

I saw someone demonstrate this beautifully a few weeks ago. Try this now. Pick up a pen and write your name on a piece of paper. Easy? I bet you didn't think about the way you held the pen, or how you formed the letters. Now, let's try something different. Change the pen to your unnatural writing hand and repeat the exercise.

Apart from not doing a great job of it, I would guess that you had to pay a lot more attention to what you were doing. The pen probably felt awkward and you had to work out how to hold it properly. You probably had to write much slower so you could focus on how you formed the letters.

If I now told you to transcribe this document using your unnatural hand, you'd probably decide not to do so. If I was in a position of authority and could demand that you do it, you'd probably be resentful or try to find a way to get out of it.

But if I gave you a point to the exercise, i.e., I'm researching how quickly people can adapt to a change of writing hand and whether I can develop ambidextrality, then you might be prepared to push on. Or maybe I have to offer you an incentive to undertake the task. Different people respond to different triggers.

This is Part One of a two-part article.

Part Two will detail the approach to the proposed method.

Previewing the Case for Action

The above is a simple analogy that explains why we can't just expect people to change because we told them to. The focus is on helping people understand the rationale for the change, so that they have a reason to make the shift. Generally, you'll need to attack the issue from a number of angles, and keep reinforcing. This paper addresses just one of those ways, the creation of a Case for Action.

Typically, a business case is required for approval of any significant project within an organization. This is often a dry document that provides facts and figures. It is often used once (i.e. to get approval) and filed, never to see the light of day again. The anticipated benefits often show financial objectives that are treated with a degree of scepticism and often not reviewed after the project has been implemented.

A Case for Action is different from a business case because its intended audience is the organization and other key stakeholders (such as vendors in the case of a software implementation). Its purpose is to paint a picture of the intended end point of the project—showing the path forward. We consider it a necessary and critical precursor to any significant change undertaking in an organization—and particularly so in the case of the evaluation and implementation of enterprise software.

After all, if you don't know where you're going, any path will get you there!

Creating the Case for Action

For the purposes of this discussion, we will reference a project to implement enterprise software, typically a significant, organization-wide undertaking. Using a specific example helps to understand the issues and the approach. The concepts and approach are relevant to any project or change initiative.

For our example, we suggest developing a preliminary case for action as the starting point of an evaluation project. Note that we are talking about the evaluation project this is the point before a solution has been identified. At this point, all we know is that there is a problem or opportunity to be solved.

We use the preliminary case for action to guide the software evaluation to make sure that appropriate attention is paid to specific requirements—there's no point focusing on detailed financial system requirements if there's not a lot of benefit to be accrued in this area. Ensure you have the functionality you need to do the job, but don't agonize over this or make it a weighty decision criterion.

After a vendor is selected, then the preliminary case for action should be revisited, with the benefit of the knowledge accrued during the evaluation and the input of the vendor. This should fine tune the previously anticipated benefits and identify any new areas of benefit uncovered during the evaluation. Further, at this stage, it is possible to better detail the cost side of the equation.

This concludes Part One of a two-part article. Part Two will detail the approach to the proposed method.

About the Author

Bronwyn Evans has worked in the IT industry for over twenty years, working with vendors and in IT management roles. Most recently, she is a principal at Tethys Consulting and has authored the Software Evaluation Methodology, a step by step approach to enterprise software evaluation. Contact Tethys Consulting on +61 2 9416 0423 or via For more information, please refer to

comments powered by Disqus