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.
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
To my mind this is one of the most critical facets of change management. Users generally do not like change - although there are exceptions. One key to project success it to appropriately manage the users transition from one state to another. This includes items such as : Including the end users in decisions regarding the new process; Allocating user representatives to be on the project team; Ensuring user views are communicated to the project team in a timely fashion; Responding to comments and questions from the users; Communicating the scope, timeline, impact and responsibilities to the user to help set and manage expectations.
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 is, possibly, the key item that can cause major problems with a project. Imagine you are a user and have been told at the project kick-off meeting that you are going to have a completed implementation within 6 months that will replace your existing software. Your expectation, naturally, would be that the incoming software package will completely replicate the functionality of your outgoing package. Otherwise that would be seen as a retrograde step for you. Unfortunately a large proportion of new systems are different to existing systems and will, therefore not work either the same way, or with as much specific functionality as before. You will, therefore, not have your expectations met as a result of this. This is an example of bad expectation management on behalf of the project team. If the expectation is set in advance that the functionality will be different - or similar but focused in different areas - then the user will be less inclined to feel the system is a failure than if the expectation is not met.
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.
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
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