Organizational Change Management: The Most Critical Requirement of All!

From the Requirements Blog
Effective requirements collection, management and traceability plus smart PM practices equals project success.

About this Blog


Recent Posts

Caution: Agile Surface May be Hot

Organizational Change Management: The Most Critical Requirement of All!

Rethink Requirements: The Natural Language Processing Approach

Quality - Consider it in all Knowledge Areas!

Don't get COT[s] by your package!

You have all heard disaster stories of computer systems going into production that are over budget, over time, and deliver less than the expected scope. And we have all heard of the new mantra: Business Value/Benefits, Benefits Management, Benefits Realization. This is all good and a step in the right direction to carry us forward from the days of the Iron Triangle of Time, Scope and Cost that some of us may feel is like the fabled albatross hanging round our necks.

BUT - what about new systems, whether those are automated or manual, that when implemented actually damage the business? You can probably think of some and if you do, please comment. This is a situation where something is implemented and everything goes to that hot place in a hand basket, costing sometimes more than the original system cost to repair.

Let's consider the recent implementation of a payroll system in a large organization in a somewhat cold country - the warming of which should not be from the heat generated by systems crashing and burning. The system went in, and it didn't even cover the core functionality of the packaged solution. What was that core functionality? Well, to grossly trivialize it, the system was meant to pay people. What does that mean? In most situations there are categories of people you pay, for example employees (Gross Pay - multiple, sometimes complex deduction = Net Pay) and contractors (Hours claimed X hourly rate from timesheets or invoices = Gross Pay - Deductions = Net Pay). As I said, this is a gross simplification, but I often find this approach serves to raise the real issues to the surface.

What I am really trying to say here is that the technical part of this implementation was, if not a piece of cake, at least very understandable and relatively easy to implement. I mean, really, have we ever paid people before? Have there been payroll and benefits systems flogged by vendors for more than a few weeks? Well, of course! When were computers invented? And before computers, haven't we been paying employees for hundreds of years? This is not rocket science or virgin territory. It takes me back to when managed the implementation of upgrades to the MSA Payroll system at Nova Corporation in Calgary decades ago. I think we can all agree that the technical solution is quite simple.

So what caused all the issues? Aside from the obvious questions we won't get into (but someone should) like "Was there a parallel run?" and "Was there a backout plan in case it didn't work?", one has to delve deeper into the underlying issues.

First of all, how was the contracting managed for this job? Was it competitive such that the job went to the lowest bidder? To that I say "You get what you pay for". Was there an algorithm for selection that put the important things at a higher priority over price, such as "Turn Key solution.", "Includes comprehensive training.", "Guarantees the system will not be implemented until it is proven to work across the organization both technically and organizationally."? These sorts of questions seem to be common sense, yet we all know the rarity of that type of sense, despite its description.

And what type of contract was it? Fixed Price? If so, was everything known at the time of the bid so that vendors can make a reasonable financial proposal? Or did they have to load their proposal down with change order ready assumptions because they didn't know enough to provide a fixed price bid?

Or was the procurement based upon the reputation of the vendor with some sort of executive order to hand them the work based on how they had performed in the past, and based perhaps on possibly unfounded assertions that it had to be done this way to avoid a lengthy procurement cycle in a "burning platform" situation?

And where did responsibility lie for successful implementation?

Now we get to the crux of the matter. IT vendors are usually very good at the technical solutions, but not so good at the human side of things - organization and process, fear of job loss, future expectation for advancement and so on. Often this is shuffled off to the client. Ever hear of the "Train the trainer" solution? You see it in so many proposals, once might say it has become a standard approach.

So far we have talked about the ease of implementing a technical solution and the methods used by large organizations to choose vendors. Now let's talk about the real subject of this article - Organizational Change Management (OCM).

There are many models for change expressed by organizations like ACMP, PMI and Prosci, and from authors like John Kotter and Jeffrey Hiatt. And these are all excellent approaches to OCM, but I have to ask: Are IT companies reading them? Are they putting deliverables and activities into their proposals to account for the steps required to manage change? Or are they weaseling out of it and transferring the responsibility to budget strapped naive clients? And are clients reading these well-founded missives of change management? If so, are they making them an integral part of a bid request? More to the point, are they willing to pay for it?

Change has to come in a package. First we start with the reason for the change strategically. Why are we making the change? What is the change exactly? Who will support the change at various levels (including the top) in the organization? Who be involved in making the change? Who will be impacted by the change? Who will see change on the receiving end? Who will be "right sized" out of a job as a result? Who will be given completely new activities to do in their job and what level of expertise will be required? How will they gain that expertise? How will you know if they have actually gained it? How will the change be woven into the fabric of the organization so that it becomes an integral part of it? How will organization structures be altered as a result of this change? Will there be support for the organizational change? Is a distributed function being centralized? Will there be resistance? How will compliance be achieved? Where will the change be implemented? How will it be implemented? Why? Who? Where? Why? What? How? Kipling and his serving men come to mind.

If you ask questions like these, you will be led down the road of good Organizational Change Management, and you will take into account all of the human factors involved in such a change. Choose the right projects, consider how you will enlighten the organization about what is coming, how you will persuade all levels of the organization to take part, how you will instruct them in the change and confirm that there was a positive effect, how you will weave it into the organization so it becomes an expected part of organizational life. And above all, how you will ensure the benefits you so diligently defined when you started all this have been or will be realized.

So, if you think of your next big contract going a vendor to make a substantial change within your organization, what forces do you have to muster? Organizational support from the top, filtering down through all parts of the organization that are impacted. Clear definition of business benefits. How communication will take place throughout the organization. How quality of the result will be ensured. How the PEOPLE in your organization will want to take part in the change to help you succeed.

Think of your next big change as a package. Strategic planning resulting in the right change being implemented. Selecting vendors who know about the technical machinations required to make your vision a reality, but are also keenly aware of the people side of things and will be there to help you through it if they are not going to do it for you. If your vendor shies away from discussions of communication, awareness, training, checking and operational institutionalization.... run in the opposite direction!

Make sure that the entire picture has been painted before you try to make your vision, your change, a successful reality.

Mike Frenette, PMP, I.S.P., CMC, SMC is a very experienced project manager who likes to post on controversial topics. For his paid job, he teaches Agile and PMP certification courses through his company, 


Posted on: February 08, 2017 10:56 AM | Permalink

Comments (15)

Please login or join to subscribe to this item
Interesting concepts Mike. I wonder if some people might argue that OCM shouldn't be part of their job. Can't wait to see the comments on this one!

Yes - some people have already argued that, much to the detriment of their failed projects.

I think a project plan with no change management is like ... well... Valentine's day with no flowers, chocolate or wine! Destined for failure. :)

Good blog Mike ! There is nothing constant in life but the change .Human behaviour resists change.But change is inevitable for successful performance progression.OCM should be seen as the critical requirement or a necessary evil on the growth trajectory.

How do we incorporate change management into the project plan?

Thank you Chandrashekhar. I appreciate the feedback. I like to think OCM is a critical requirement and not a necessary evil. :) In fact, if we all took a moment to step back and consider the people aspect of all our projects, I firmly believe project success levels would go up at least just a few notches.

And Rosemary, thanks for your question. I have been asked this many times.

I think we need to treat change management not only as a requirement that we must advise our clients to include, but as an important piece of the WBS for any project, just as we would any requirement. Change Management is part of the HR Knowledge area, and needs to be considered in many other knowledge areas too, such as Communication, Stakeholders, Risk, Cost, Scope... maybe they are all pertinent! :)

So how do change management deliverables get into the project plan? Of course, once they are in the WBS, they will migrate as work packages to the project schedule, deliverables will be defined as will associated activities and dependencies. Resources will be assigned, and their costs added to the project budget.

So what might be some CM deliverables? I'm glad you asked! ;)

I think there are some obvious ones like Organizational Readiness Assessments requiring activities like interviews and/or workshops, documents, and so on. And Communication Strategies and Plans to cover CM activities outlined in the Communication Plan. Then there is the infamous training materials.

Some that are not so obvious include workshops for those who have reports, who must reinforce that idea that the change is coming, and that complying is not optional. If fact, lack of compliance could be one of those CLMs. And maybe there are coaching and mentoring activities designed to make sure training delivered "sticks", and that after "whatever" is implemented, it is used.

I could go on, but I don't want to write another whole Blog in a reply. But thanks for giving me some fodder for my next blog!

Mike,I tend to see the OCM as a mandatory critical requirement as well as a necessary evil.OCM,in my opinion, must also focus on critical examination and review of current systems serving as a backbone or yard stick for good governance and functional management .The top or core decision makers/managers of the Organization have to take a hard look to bring about necessary and right changes as part and parcel of HR knowledge area apart from other knowledge areas which may even mean re-positioning /removal of key decision makers/managers who are not mentally prepared to realise the potential of new proposed changes or are averse to changes.Such changes are not easily digestible to many hence OCM is a necessary evil too.This is my personal view.

Thanks for the additional comments, Chandrashekhar.

I have a feeling that the examination of current systems might be more of a business analysis effort than a change management effort, with OCM come into play once a strategic decision for change is made.

Yes - some really tough decisions often have to be made during massive change, and restructuring often comes into it. We can't have naysayers in the ranks of key decision-makers and managers once strategic change is agreed by executive and management.

Mike,I agree with you that the examination of current systems is more of a business analysis effort .Many thanks for your comments !

OCM is vital but I have always experienced a "long-lead" to change or modify behavior. In essence, a time frame far beyond the project time frame and larger in scope. Getting it on the radar is essential and then a "hand-off" to an HR rep is in order? Also, how do we quantify change of behavior -- most employee surveys are done annually or semi-annually?

You are most welcome, Chandrashekhar. And thank you for YOUR comments!

And thanks for comments as well, Rosemary.

Very true that OCM may very well precede the project and extend beyond the project, and that a handoff is necessary once the project ends. Figuring out whether we have achieved expected benefits through monitoring employee behaviour is also critical. It is tough for PMs to have any say about a project before it starts, but maybe we can squeeze this in through frequent conversations about OCM with our contacts. It is something I emphasize with clients as soon as I can and as often as I can. That way, it has a better chance of being top of mind when they even start talking about a project at the portfolio stage and how to help ensure success.

As for the hand-off, I think any project needs a transition plan, and that hand-off, and involvement of the person and organization to which the products of the project are being transferred l long before the project ends, are an essential part of any transition plan. We often think of handing off to a technical authority so that a system can be maintained, enhanced and supported, but we often fail to consider hand off to the softer parts of an organization to make sure benefits are achieved and the new processes/products/methods the organization is expected to use are in fact being used.

And how do we determine whether the organization has changed? I would say surveys are probably only a small part of the answer. More important is observation by those who have been tasked with it in the transition plan.

And like any good project, measuring progress by what has been delivered rather than what has been done might also provide us some clues to how we might assess adoption. In other words, the change will have been done for a reason, and that change will probably affect the operational output of the organization. So, if we also watch output as well as behaviour, we will have a better measure of whether we have achieved our goals.

It becomes apparent that benefits realization monitoring and OCM monitoring are inextricably linked.

But I sense a ramble and some repetition in my response, so I think I'll stop. ;)

Thanks Mike.
Well for metrics, you can also measure employee engagement by "blogs", attendance at HR events, attendance, usage on "new systems", inquries into new programs, continuing education credits logged to show employee engagement. Just a few off the top of my head. OCM takes time and baselines need to be established like any good program to measure improvement. Does anyone have more metrics to suggest? [besides surveys].

P.S. I always have to come up with measurements of success in these areas -- so I'm always looking for new way to quantify this employee engagement or change management.

Great comments on metrics, Rosemary. Thanks for your contributions. Valuable, as always.

Please Login/Register to leave a comment.


What's so great about a mom and pop store? Let me tell you something, if my mom and pop ran a store I wouldn't shop there.

- George Costanza