The first rule of change management

Don’t break my job!

frustrationChange management is popular these days, and it seems the Project Management Institute (PMI) is especially interested in driving this aspect of the project management discipline lately; with good reason.  75% of initiatives fail to achieve the projected ROI(1), and a 2002 study by McKinsey found that on large projects there was a gap of 108 percentage points between those with excellent change management and those with no program or a poor change management program(2).

As with many things, the right way to do it is also the common sense approach.  I was doing a large scale operating system migration and deployment several years ago.  As part of the process we would gather users in an auditorium on the weekend before the migration and tell them what was going to happen, how to back up files, and what to expect on Monday when they returned to work.  At the conclusion of these events there was always a question and answer period, and on one occasion a guy in the audience raised his hand to ask a question.  When he received the microphone his question was simple…”you’re not going to screw us are you?”

I had no idea what he was talking about, and when asked to clarify he said “here at <abc company> I.T. is done to us, not for us.”

Perfectly stated.

This guy just wanted to be able to do his job on Monday morning. Not hassling with computers that don’t boot or recovering files that were supposed to be migrated but were not; and he certainly did not want to have to figure out a whole new set of processes that would allow him to get his job done.  In essence this guy was saying “okay – upgrade the computers, but don’t break my job”

Don’t break my job – this is the first rule of managing change with end users.  Violate this rule and it will be a scarlet letter to be worn for all time.

Want to know more, read 3 steps to not breaking the process.

1. PwC’s Human Change Management: Herding Cats

2. Helping Employees Embrace Change: LaClair, J & Rao, R. (McKinsey Quarterly); 11/2002

Share this Post