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 info@tethys.com.au.
For more information, please refer to www.tethys.com.au