Rocket Science! - Yes or No?

昵称11256 2006-08-31

展开全文

Rocket Science! - Yes or No?

Introduction

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.

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.

HR Conversion Table

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 don’t 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 SAP’s 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: