Change management is critical – if you are a project leader, your
success will depend on your ability to understand what it is, how to distinguish
between good and bad change management and how to determine when you need change
management..
In boardrooms, management meetings and project meetings, the term
“Change Management” is frequently bandied about. This is very different to the
situation in the early 90’s, when the field was largely unfamiliar to business
leaders. Back then, introducing a change management component into a project was
a rare feat.
Today, Change Management as a discipline has become part of
mainstream business. As a matter of fact, today it will be difficult (and a
substantial career risk) to motivate the exclusion of Change Management from any
large project.
So Change Management has come a long way in the last 15 years.
But is it really taken seriously?
Many senior business leaders and project managers will tell you
that they are able to “do” Change Management as well as any so-called change
management specialist. When questioned further about the source of their
Change Management expertise, it becomes apparent that the reasoning underlying
this assertion is often as follows: Change management is about people. I am a
person, and I know about people (been dealing with them for years). Ergo, I know
Change Management.
Others – particularly in the project environment - believe that
Change Management is an “HR thing”, and as “HR rarely delivers anything critical
on a project anyway”, why bother with “yet another fuzzy
HR idea”…
Well, let me give you my perspective. I am a “techie”, and have
worked as an experienced project manager and Consulting Services Director on
large projects before I started my career in the field of Change Management. If
you count yourself among one of those who think Change Management is a fuzzy
concept, or is something that you just “pick up” as a management skill along the
way, I have news for you…
Don’t take my word for it. Have a look at the statistics of
project successes and project failures. Look past the many arguments about
what a project really is, and when a project is considered to be a success and
when it is considered to be a failure. Focus just on seeing how many
projects are actually completed, delivering on the initial promises and with
happy users and sponsors, and I guarantee that you will find some shocking
statistics.
Then also look at the top reasons for ERP system failures, or the
reasons why implementations of frameworks such as ITIL or COBIT do not always
meet their objectives – many studies in this regard have been done… if you read
four or five, you’ll have the gist of it. Interesting reading matter!
Well, what did you find? (If you really did do some
independent research, well done!) If not, here is a summary of what you would
have found: The majority of projects fail to deliver on their initial
objectives. Typical reasons for such failures are NOT usually
project-related variables like technical complexity, lack of adequate budget, or
poor quality – the most common reasons that are cited are “people” things -
resistance to change, inadequate sponsorship, unrealistic expectations, problems
with training and poor adoption of changes. These “fuzzy” things are the
REAL reasons for projects not achieving success!
Now go check the plethora of project management methodologies and
frameworks. See in how many of them you find any reference to Change
Management, or if it is there, what focus it is given. The answer?
At most, you will find they pay very little attention to it.
Any wonder then why these projects are not meeting their objectives to the
extent that they should?
So what should you do about this? Well, here’s a 4-step
strategy for success.
Step 1. First make sure you understand what change management is.
Do not confuse the term Change Management with IT change
management - keeping track of various IT objects.
Also, do not confuse it with the term change management where one
tries to keep track with the ever-changing requirements of users when you try to
implement a system. The management of a “rubber baseline” is also called
change management, but has almost nothing to do with the Change Management we
are considering in this document.
Step 2: Ensure that the right people are involved.
This means you need people who have done this before, who
actually know how to do it again. Roping in that “nice guy” from HR or
Marketing who happens to have some spare time for your project will almost
certainly prove to be a very bad decision – firstly for the poor roped-in soul
who will rapidly discover that he is in very deep water much more quickly than
he expected, but secondly it will mislead you into thinking you have it covered.
Change Management is a bit like building a dam wall – you can show good progress
even when you do it poorly, and by the time your work is really put to the test,
it is too late to fix it…
Step 3. Make sure you pitch your Change Management at the correct
level.
On some projects, it makes sense to have your Change Management
specialist as part of the project team, but in most cases, better results are
achieved by having this person at the same level as the project manager.
While the project manager still takes overall responsibility for the project,
they should both report to the project sponsor, as they both address different
aspects of the same project. (Of course, this leads to a discussion on the
differences between project management and project leadership, but this a topic
which will be covered in a separate article.)
Step 4: Ensure that your designated Change Management specialist
has a sound Change Management strategy, with a solid Change Management plan to
implement it.
Let the Change Management specialist explained the strategy and
plan to you – do not accept it if it does not make complete sense to you. Also,
keep on asking how this will impact on the outcome of the project - only those
activities that make a real contribution to the outcome of a project should be
undertaken. Keep in mind that the change management activities that become part
of the approved plan will take up time of other project resources too.
That’s it! Of course the topic is quite complex and there are
many other issues that we could discuss, but that will be the focus of other
papers.
***
To potentially offended HR readers of this
paper, my apologies, I am quoting the prejudices of others here, not providing
my own opinion!
