
If you are already a subscriber to The Process Cafe you will receive these update automatically in your RSS reader or inbox. If you don’t already subscribe you might wish to do so by clicking the RSS icon on the right of this post.
Change Management
This post is going to focus on having appropriate Change Management during your project and after your processes have been changed..
Why is this important? I carried out a small (and unscientific) survey a short while back which asked people to identify the main cause of project failure. The overwhelming number one reason projects fail is that there is inadequate or inappropriate change management on them.
In this context 'change management' relates to the following items specifically:
- Managing scope.
- Managing users.
- Managing expectations.
This is what a lot of people equate to 'change management' in a project context: managing the change within the project. This includes understanding what a baseline is, what constitutes a change to the baseline and managing how that is defined, approved and implemented. One of the major causes of change management is scope creep. This is - of course - where the originally defined boundaries of the project start to expand to include items, functions or areas not originally identified. Scope creep is deadly in a project as it can undermine the whole basis of the project as well as setting inappropriate expectations with the user base
Managing Users

All of the above are vital in any project and the larger the project the more important they become. Traditional change management theory tells us to identify change agents from within the user base and utilise these to help push the project forward within the user base. I support this completely. I have mentioned elsewhere on this blog that one of my key early career challenges involved change management within a project: At the project kick-off meeting in Germany for a new ERP system (in an affiliate that was already running a well established - German - SAP implementation) we were introduced by the Finance Director as follows "Ladies and Gentlemen, Thank you for attending this kick-off meeting today. Gary and Luc are here to put this package in and replace our SAP system. We know that it isn't as good as SAP and we will lose a lot of functionality because of it, but let's let them explain it to us". He then turned around and sat down leaving my boss and I to try and salvage the situation. Needless to say we had to implement some strict change management principles to save that implementation. This involved - amongst other things - acknowledging that their existing implementation was a successful one, ensuring they understood that the functionality they would be receiving with the new system was as good as their current functionality but maybe focused in a different area, and stressing the benefits to the organisation as a whole in having a single, European-wide implementation of software.
We also identified a number of individuals in the organisation who would be able to assist us as 'change agents' and used them to work at the problem from the inside. We discovered that having a couple of ex-SAP guys from the affiliate promoting our solution helped to break down internal barriers and resistance far more effectively than trying to work at this as an external resource.
Managing Expectations

In the SAP example listed above we were careful to set the expectation that the new system would not be a 'like-for-like' replacement of the SAP system they already had. This would deflect a large number of the 'Our current system does this...' kind of questions.
Summary
Managing change in a project is a three faceted item. It is important to remember that users are key to making a project work and they need to be treated appropriately. Ignoring change management within your project is one of the quickest ways to ensure project failure.
The next post in this series will cover Process Ownership and will be released on Monday 14th December
For earlier posts in this series please click here:
Please feel free to comment using the new Disqus commenting system below
Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you.
Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below