Rocket Science! – Yes or No?
The topic of change management caused some controversy in the discussion of my last BPX related blog -> click here. I had stated that change management is not rocket science, what created a detailed written dialogue about this topic. Besides the fact that change management is very important for the success of most projects, the mentioned dialogue motivated me even more to write about this interesting topic. First, let me tell you that I am sticking to my guns: Despite the importance of change management and the fact that it can make the difference in a project, it is not rocket science! And this means nothing else than: If you realize its significance and apply a good mix of tools from the change management bag of tricks plus the necessary attention to this topic, you will get it done! – Please read on to find out how. In this blog I will first look at the importance of management of change (MOC). Then I will give you a look into the change management bag of tricks I will provide a long list of tips, tools and how-tos. Finally, I will conclude with the desired outcomes.
1 – Importance of Change Management
System implementation projects cause many changes of different type and severity. How you deal which each of these changes depends heavily on the following factors:
- subjective severity,
- groups and number of people affected,
- risk of ignoring, and
- the time window the change appears until it impacts the organization.
Figure 1 elaborates this with an exemplary list from an real HR conversion project. The first column shows actual changes that occurred during this project. Next column is your subjective assessment of the severity of the change. Severity is a function of the change itself, the groups and size of group affected, as well as the risks to the project. As I said, it is a subjective assessment and it helps you to create a priority of your change management activities. After all, the risk/cost ratio of one or several changes may not be high enough to justify dealing with them. Some risks just need to be documented and accepted, what is very different from overseeing or not dealing with them at all. Figure 1: Exemplary list of changes in SAP HR conversion project Next column are risks. Please have a close look at the examples and you will know why MOC is so important. The severity of the risks shown in the table should make the importance of well planned and executed management of change (MOC) clear. The project team needs to understand that MOC is not secondary to completing the last few lines of code. A lack in MOC can make a project fail much more quickly and easily than one or a few lacking software features. So never say you are too busy wrapping up the project and rolling it out and you dont have time to work on MOC now. The timing column also helps you with prioritizing your activities over the course of a project. Hence, it helps you to build your MOC project plan. There are two elements to the timing: When do you discover a change and when will it impact the affected groups. If this window is large, you have time to plan. If the window is small, you may have to improvise and manage the change ad hoc. In general, most of the changes will come into effect at go-live. Therefore, you want to make sure that you have the right targeted responses at or around this time. The last column, responses, really leads us to the next section in this blog. What are my tools to make sure none of the changes are affecting the outcome of my project negatively?
2 Responses OR Change Management Bag of Tricks
Change management is fun! – Most changes are unique and for each change you need to decide how best to respond to it. And not all changes make things better. Sometimes a specific function may have been implemented in a more streamlined approach in the custom build legacy application than in the standard software package; or at least it appears that way. Here is an example: In the above HR conversion project, there was a perception that with SAPs R/3 HR and its concept of info types, the usability of the system and the user experience would suffer. Info types are pre-defined SAP screens which house a set of related data like org assignments, address or basic pay. In the legacy application, however, the users were used to highly customized screens, combining many data element. Therefore, the user had to go to a smaller number of screens and had many data elements in sight. Hence, we had to deal with the notion that SAP was less flexible and the final SAP HR solution may be inferior in look, feel and ultimately functionality compared to the old tool. When prototyping SAP HR we actually found that having these well defined blocks of information, or info types, was a very powerful architecture. It was easy to combine them and string them into processes. It was easy to model an employee file with different validity periods for different type records (your address rarely changes but you have a new salary every year hopefully). All these findings, summarized in some simple pictures (a cylindrical container on a flip chart with rectangles showing the info types; we then virtually picked them and strung HR processes together) we then used during an all HR kick-off meeting at corporate as well as during a kick-off with the international team. The explanations were well received and this was never brought up as an issue any longer. We had turned a negative into a positive! As you can see in this example, communication of the change in this example early on during the kick-off meeting is one important tool/activity. Here is a more or less complete list of all the high level tools/activities:
- Training and Involvement
- Strategy and Tools
Lets look at each of these areas one at a time. Communication Communicate, communicate, communicate! But do not get onto peoples nerves. Therefore, use several ways and channels of communication in a well balanced mix, both formal and informal. Formal channels are:
- Frequent sponsor meetings Make sure you are in touch with your sponsors all the way through the project, for example via a bi-weekly or monthly sponsor meeting. Show them the progress in regards to the timeline and the milestones. Present achievements and challenges and do not forget to get their input also.
- Weekly status meetings with your project team This is a given. Still, some project managers are afraid wasting peoples time and even apologize. This is the wrong approach. Use the time wisely to share important information (and changes) and have peoples share amongst themselves. In this meeting you should discover many of the issues and changes that need to be taken care of via MOC.
- Kick-off or town hall meetings Get your stakeholders and future users involved and excited. If feasible, a life all-hands kick-off meeting is an excellent way to do this. Otherwise do a virtual kick-off via teleconference or have several smaller meetings in different locations if there is budget for this. To make this meeting worth the effort and cost, get people informed and thinking about the project and new solution. Introduce high level concepts, show prototypes and tell people when and/or how they can get involved, for example with testing.
- Project website or monthly project newsletter A project website or a newsletter is a good way to cover basic information and questions about the project, for example for the use of interfacing partner applications. Publishing this information will enable others to comply with your timelines and changes and will keep your email inbox clean of basic requests (IDEA: Make the URL for the project homepage part of your email signature).
Do not consider the examples above as a complete list or as the master list. Be creative and find the right communication mix for your project. And do not only count on official communication channels. The in-official ones may be as important, or sometimes even more important. Here are some in-official communication channels:
- Change Management by walking around Be visible and approachable and talk to people about the project at every opportunity you get. Of course, if you like doing this and it is not only a chore, the message will come over best. If people see you being excited about your project and the new tool, they will be more likely to join the program, go with the flow and accept or promote the change.
- Influence the influencers OR Opinion Leaders The opinion leader is the agent who interprets the meaning of content for lower-end media users. Typically the opinion leader is held in high esteem by those that accept their opinions. (Source: http://en.wikipedia.org/wiki/Opinion_leader) Get opinion leaders on your side: Identify them, inform and involve them and get them to support and promote your project. – Your sponsor or team members from the business side are best to identify opinion leaders.
- Open door policy Besides you visiting your stakeholders and walking around, invite them to join you and your team, ideally in some kind of project war room. Few people will actually show up, but many people may wander by the room or area just to see what is going on. If you are working well together as a team and that shows, through the open door, people will believe in the project, the team and the new solution.
Lets move on and look at how training and involvement of people will help you with your change management efforts. Training and Involvement Training and involvement is really focused around the macro change of system A being replaced by system B resulting in new processes and/or new tasks. Micro changes, like the change of office location in the table above, do not require training; they only need documentation and communication (plus a brief mention or reference in the training materials). Lets look at some different types of training:
- Team member training Make sure that all team members have the right qualifications. Look at each individual player as well as the whole team. If a skill is lacking overall in the team, you may have to get some outside training. If a skill exists within the team but is not spread well through the team, also consider cross training, what will help to bond the team together.
- Super user training Super user involvement and training during the project is an excellent approach to getting your software prototypes unit tested and validated early on. Get some interested people involved and try recruiting one of the opinion leaders (just make sure you tool is up to snuff at this point). At or after go-live time, the super users will be part of an official and/or in-official support structure for the new application. Again, find the right point in time when to involve super users, not too early and not too late.
- End user training This is a major task and other than the two first types of training needs to be well planned and orchestrated. Assess the skill level and training needs of the organization. Have they had experience with other SAP applications and know the basic navigation or not? Secondly, look at the business need that the new users have to solve. Is it enough to just train on the new application or is there any related tools that would help them in their job. In the example of the above SAP HR implementation, like with most systems, reporting was a key need. While we had a good flexible reporting tool, we had experimented with Pivot tables in Excel and realized their power. Hence we proposed to send everybody in HR to a one day customized Excel class a little ahead of the SAP HR training. This may have been the best decision of the entire project. Lastly, you need to get sponsor buy in as well as department manager buy in that their employees will be allowed to attend a x day SAP training class (in our case 3 days) without them having to interrupt for other business related events. This caused some excitement in the management team meeting when we proposed it, but finally everybody agreed and we had virtually 100% attendance in our classes. Start the preparation of your training materials early. To facilitate this, have your content developer join as many design and prototype meetings as possible. This will improve the content quality. For delivery of the training, I think a co-teach of a technical systems person together with a business person, for example one of the super users, is ideal. This way, you will be able to put the system into the context of business policy.
Strategy and Tools
- Strategy One specific and important strategy in a systems project is the cut-over approach. While in a small project you may be able to cut over to the new system in a weekend and almost literally turn off the old system after the weekend (in reality you definitely need to keep it around for a few weeks in case of disaster or a needed data validation), this will not be possible in a large multi national corporation with multiple legacy environments. In this situation it is key that you have strong ties to the business and you have an agreed upon migration plan in place that moves the system over time from technical live to business live in all countries and regions. This may be a project in itself. As a rule of thumb, you want to have aggressive, yet realistic plans to move all your business onto the new platform. The longer you delay the harder it will get and it is possible for some parts of the business to resist altogether.
- Tools Tools can range from simple to sophisticated. A simple, yet effective tool is a cheat sheet for the business users handed out at go-live that shows the most important menu path or transaction codes as well as tips and tricks around printing, reporting, etc. A laminated letter size sheet printed on both sides has proven successful in my projects. Much more sophisticated tools may be needed if you change the product structure significantly and sales operations needs to be able to convert from old to new structure on the fly for instance. A small web based tool may help with such a transition. While all tools come at a cost, if justified and designed well, they should be worth their cost, especially if you count the cost of frustrated users and lost business.
- Go-live support Make sure to let people know how to get support during the first hours and days of a new systems implementation. Again, depending on the size of the company and project, consider some of the following approaches: – Have a few team members or super users present within the business department to respond flexibly and quickly to questions, possibly assigned to different business functions. – Setup and monitor a dedicated phone support hotline. Publish the phone number for this service as well as the overall support approach, including the future on-going support as part of the training. Since there will always be some issues that you could not foresee or that will not end up in your support system, stay in close touch with the sponsors and opinion leaders during the first days.
- On-going support After a pre-defined time of a few days to a few weeks, integrate support of the new system with the regular support model and organization. Of course, this needs to be planned and negotiated with the companies support organization. Depending on the support model, knowledge transfer or training will be needed that should be part of your training plan (see above).
3 Desired Outcomes of Change Management
Change management is an enabler to a project: it is supposed to make a good project great! And what is the difference between good and great? The difference is users that feel taken care off and know where to find help with un-avoidable learning curves with the new system. Users that are interested to learn about the new system because they were able to give input during development as a super user or during early testing. Users that know the ultimate benefits of the system, even though they are not apparent at the moment since everything seems harder right now. And sponsors that hear good things from their users about the new system. Sponsors that may even be interested enough to try it out themselves (offer them to take them through the key features again, especially the dashboards). If the news and buzz around the system are mostly positive and people are willing and excited to use it, you just completed a great project. The difference between the good or the great project is not in the extra line of code, it is truly in the results achieved by your effective and efficient change management effort. And the payback for all the extra effort will be happy customers, hopefully like the ones from the SAP HR conversion project that I used for examples throughout this blog (figure 2). Figure 2: Happy customers from the SAP HR conversion project
I hope you now understand the importance of change management and how to go about it. The last thing I like to emphasize is that MOC is part of your project, and not a totally separate project. Therefore, I am afraid about setting up a MOC organization that is too separate and independent of the main project. I really see change management as an organic extension of the main project with all or most of the key team members, including the system configurators and developers, involved. This is the only way that the most up to date and relevant information makes it to the end-user. While this first hand information needs filtering and formatting, it is the source for success of your change management effort within your project.