Change Management: Why take it seriously?
Thys Stassen, ChangeWright Consulting
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”[1], 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.
***
[1] To potentially offended HR readers of this paper, my apologies, I am quoting the prejudices of others here, not providing my own opinion!