Change Management and Project Management

Change Management and Project Management

One of the questions which comes up regularly when talking change management is ‘how does it differ with project management?’ But the question really should be ‘how does it fit into project management’, because change management is a sub-discipline which is integrated into project management.

I say ‘is’, but in many cases, it is instead ‘should’. That’s because change management is all too often glossed over as a ‘nice to have’ rather than the essential item it is. But here’s the thing. Ignore change management and the entire project is imperilled.

Let’s start with the formal definition of project management. The PMBOK Guide (third edition) notes that it is ‘the application of knowledge, skills, tools and techniques to project activities to meet project requirements’. Project management, the Guide adds, is accomplished ‘through the application and integration of the project management processes of initiating, planning, executing, monitoring and controlling, and closing’.

This shouldn’t be too far from your own understanding of the discipline; we could simply say it’s keeping a close eye on the many moving parts involved in delivering a complex undertaking. And while the one with the eye is the project manager, paying close attention should be incumbent on all involved so even small issues are readily identified and corrected, before they become big issues. (Issues in a project are a bit like rust or a leak in your radiator. It doesn’t get better by itself; it gets worse).

And then we have change management. It’s a strikingly similar definition: it is ‘the process, tools and techniques to manage the people side of change to achieve the required business outcome’.

Managing people is hard. Managing change is about managing people

Note the bold. Project management concerns itself with ‘everything’, change management with ‘the people side’. And it incorporates organisational tools to help individuals make successful personal transitions resulting in the adoption and realisation of change.

These definitions are enlightening because we know managing ‘hard facts’ like budgets, timelines, deliverables, milestones, technical delivery, etc is if not binary 1s and 0s then certainly pretty easy to stay on top of. A CRM module is either implemented and configured or it is not (yes, there is something of a continuum here, but even that can be managed quite readily: we’re connected to two out of three databases and the final one requires some transformation before its compatible).

The people side of things is a little trickier. After all, we’re unpredictable sorts at the best of times and we’re also creatures of habit (and the older we get, the less…pliable…we tend to be). Add to that the sheer scale of what people have to deal with when major changes happen – as in the changes which must follow the implementation of an Enterprise Resource Planning or other enterprise software solution.

Following, or preferably during and also following, such a project, you’re impacting multiple aspects of how business is done. That includes processes, systems, organisational structure and job roles. Fiddling with even one of these is distressing for people (and make no mistake, change is distressing, even if it is conscious; for most employees, change isn’t voluntary or conscious, it is something they are required to do).

Delivering benefits takes effort

Of course, unless you’ve found yourself in the invidious and pointless situation of ‘technology for technology’s sake’ (something we’d never advise, let alone carry out for any of our customers!), change isn’t done in an effort to shake things up or personally offend anyone. It’s done because there’s a benefit which should follow. An enterprise project is generally initiated either because a problem of some sort is identified, or a deficiency noted, or an advantage identified.

The benefit is often improved productivity, better efficiency, reduced manual processing and labour, increased visibility, better customer service, reduced cost of production or service.

We’re often asked why ERP (and other) projects are so costly; part of that comes down to the fact that no two are quite the same. That doesn’t just mean from a technological point of view, but also a project management and change management point of view. Even these aspects of the project must be configured specifically for your organisation, considering your business, your industry, the company culture and history, and the specific software or services being deployed.

Doing all this is crucial because that’s how you get the desired benefits. They will only follow if sound change management is absolutely baked into your project management discipline.

It’s why we’ve made change management an integral component of every implementation we do, with an approach we’ve developed over multiple years and hundreds of successful project deployments.

In other words, when you engage Verde for an enterprise software deployment, we leave nothing to chance. After all, your success is our goal – and our success rests on yours.



Five ways to keep your culture growing in line with business success

Read five tips on how to maintain a vibrant, effective working culture that supports ongoing growth.

Download Now

Stephen Galvin

Stephen Galvin

Stephen offers top class skills in implementing continuous improvement initiatives that result in increased operational productivity. He has more than 20 years of experience underpinned by a Master in Business Administration. His ability to build a bridge between the operational and strategic level of an organisation allows him to manage the details, while at the same time communicating with other executives regarding the overall strategy and vision of the wider business. His change management experience encompasses technological, cultural and structural change, as well as developing training and knowledge management programs.

More posts by Stephen Galvin

Latest Posts

Get the Latest from Verde

Recent Tweets