Saying that CIO’s must master the human side of IT implementations is OK, but we need to be very aware of the illusions we reinforce with that statement.
Last week in the CIO report of the Wall Street Journal, Kathy Gersch discussed the people-part of a CIO’s role during IT implementations. Although the title ‘CIOs Must Master Human Side of IT Implementation‘ brings a statement that I can subscribe to, the content of the article suggests that CIO’s should not only master the human side; they should also lead it. This is a capital mistake that creates the same set of false expectations as those we have towards HR. But there is a reason for this mistake to occur so widely.
CIO’s – like any other stakeholder who is involved in a large scale IT implementation – should master the human side, but we should consider it as a minimum requirement to participate to the Olympics of the implementation, and not expect them to lead it. In short: the CIO is not an agent of change; they are agents of stability. In our 2007 book Managing Organizational Change during SAP Implementations (affiliate link) we pointed out this flaw. The below article is an updated excerpt of that part of the book.
Starting off on the Wrong Foot
When an IT implementation is labeled as a plain software installation, you start off on the wrong foot. Unwillingly, IT becomes owner of the effort and the attitude towards the initiative is often translated as follows: “SAP is complex software, so let the technical experts lead the way.” All of a sudden, the IT department is pushed into the driver’s seat and this creates the false illusion that they should be leading the organizational change – simply because the systems represent the largest part of the program’s budget.
But there is a good reason why that myth persists. Many times, IT is the challenger of the status quo. We often have seen that it is not the business but the IT department that encourages the organization to start the program. This remarkable fact goes against all theories and textbooks. However, in practice we see that IT managers are taking the lead and making innovative proposals in the earliest stage (program initiation).
And then comes the uh-ooh moment, because this is when they dive even further into business. In many organizations, it is the IT department that persistently communicates the need to have certain systems replaced, to increase integration, to install new technology platforms, etc. These professionals initiate change by asking the business executives to think concretely about how this impacts the way they do business in the future.
Most of the times, IT people are the first ones to ask: “Where do we want to go as an organization?” They know that the answer influences every single choice they will make system-wise, landscape-wise, configuration-wise, and procedure-wise.
This is when the crime is committed and the illusion of CIO-ownership of the initiative is created. Most IT people have a very good look on how processes in the organization work, the extent to which processes are fragmented or integrated, the extent to which legacy systems are fragmented, etc. But their scope of work is different, so you should be prepared to reframe their questions in the broader perspective of the future organization, linking them directly to clearly identified business benefits.
Not an Agent of Change
If we fail to debunk that false expectation in the early phases of an implementation we will end up with a ‘plain software implementation’ where the business people are spectators. In that case, you can forget about benefits realization, ROI and real business change. These are typically the organizations where the CIO leaves the company approximately one year after the implementation. Tired and most of all puzzled because he or she has not been able to bring the turnaround that was expected by the business.
Here is a dirty little secret: the CIO is not to blame; the operations people around the table are. From the very beginning they – and not the CIO – should be taking the lead in the design of the business case, the feasibility study and most of all: the benefits case. By the way, it is them – and not the CIO – that hold the degree of MBA. There is only one way for an organizational change program to be successful and that is when the operations people take full ownership of the change agent role. Not the HR-people. Not the IT-people.
Does this mean that the CIO (or the VPHR for that matter) have no role to play in a change management journey? Nope. Borrowing some wisdom from Kurt Lewin, we know change always happens in three phases: unfreezing, changing and refreezing. The key strength of IT is to stabilize the technical side of an organization during and after a transition by leading the refreezing stage.
If Not a Change Agent, Then What?
Ninety percent of the competent IT engineers are binary people: very competent at analyzing a program down to its bits and bytes and appreciating dimensions of algorithmic beauty that the outside world is unaware of. The key strength of IT is automation and control, and its key processes, listed here, are designed to accomplish that purpose:
- Incident Management (Goal: to control technical incidents)
- Problem Management (Goal: to control technical problems)
- Change Management (Goal: to control the software change management)
- Release Management (Goal: to control major software releases)
- Configuration Management (Goal: to gain control over every single object and to track it during its complete life-cycle.)
Like the HR department, IT is there to bring stability to the organization through the support and control of the current processes. It is sometimes shocking to see how negligent some organizations are with regard to supporting their IT departments.
During an SAP implementation, the pressures are extremely high on IT because of a combination of the following factors: we expect full support of legacy systems until cutover, we expect the techies to interface remaining legacy systems with SAP, we expect them to take the lead on data cleansing, at cutover, we expect them to be as competent in SAP as they were the day before in legacy systems.
In addition, the IT department is responsible for maintenance and support, not only for the legacy systems as mentioned above, but also for the newly implemented SAP system. Maintenance and support is a service-oriented function that requires certain capabilities. Those responsible are expected to support the users in using the system properly.
However, as its key strength is to automate and control processes, we should make use of that specific strength during and after the implementation. Just because a CIO is very capable of thinking in terms of processes and systems does not mean they should lead the change. Benefits realization goes beyond processes and systems. It’s a matter of full ownership by the business.
Saying that CIO’s must master the human side of IT implementations is OK, but we need to be very aware of the illusions we reinforce with that statement, i.e.: as if it were the only thing that is missing to fix IT implementations. The real problem is that we should evacuate the driver’s seat for the business owners to jump in.