Three approaches to leading IT change

Provided you have successfully managed to build a stable and reliable IT platform, sooner or later you have to do more than just keeping the lights on.

The pressure will be unavoidable. Change will be driven either by business decisions or by new technical break-throughs.

However, these two drivers must be handled differently.

When IT is driven by business decisions When it comes to business-initiated changes, the project should be led and owned by the business.

This type of IT project will always be difficult to manage. Although the requirements are initiated as a result of business functions, it’s the IT team that has to deliver the goods.

A strong governance structure is required for this to work: it should always be clear that a senior non-IT business executive owns the project, and that IT is only providing resources and support.

Without this business ownership, the project will run the risks of not having requirements sufficiently detailed, of business staff not taking part in training and testing, and of a potential loss of interest from the business when faced with conflicting priorities.

In order to manage business-led IT initiatives, we believe that your company should put in place a corporate IT Steering Committee.

This small but important bit of bureaucracy should be responsible for managing the entire portfolio of business-led IT projects.

This makes it easier to manage the risk profile across all projects, to ensure that sufficient business resources are available, and to enable budget control.

The IT Steering Committee should include all the senior business leaders: the CEO, CFO, COO and of course the CIO.

This group should meet regularly to ensure that the IT function continues to be aligned with corporate strategy.

The IT Steering Committee is particularly important if you are not formally part of the board, and thus may not have a clear view of changing corporate objectives.

Technology initiatives Some technology-driven initiatives are easier to handle than others. In the case of infrastructure projects, we believe that you as CIO should take the lead without too much fuss.

For all those initiatives implemented purely in order to maintain a stable IT environment, the business input is likely to be minimal.

There is generally little point in trying to develop a business case for something that has no real financial impact. For instance, what is the business rationale for moving from Windows XP to Windows 7?

As an IT professional you can answer this question clearly from a technical perspective, but it’s difficult to quantity it from a financial standpoint.

If that’s the case, why bother? If you’ve built trust and credibility in your organisation, you should be trusted to make the right decisions when it comes to maintaining business as usual.

And from a budget perspective you should include investments for keeping the lights on. Remember always to ensure IT stability before embarking on discretionary spend initiatives.

On the other hand, some technology changes are not driven by a need for stability, but rather from an opportunity to exploit new technology, such as smart phones.

There’s no compelling need to invest in such technologies, but there may be business benefits to be derived from doing so.

Here, you need to tread carefully. Try to run a pilot project first in order to get some real-world feedback from your users, and make sure you listen and act on it.

And when you get to the point of planning the roll-out of the new technology across the business, make sure the full costs have been confirmed and backed up with commitments from your vendors.

Then get the backing of the IT Steering Committee to make sure you have some air cover if there are any delays or cost-overruns when the project finally happens.

Dividing transformational change into manageable chunks A final word of warning. When it comes to large-scale IT initiatives (regardless of whether they’re driven by the business or technology), always start small and divide the work up into manageable chunks.

This will help to maintain momentum as well as allow for clear success criteria. It will also help you take stock of the situation regularly, rather than waiting 18 months or so before realising that the project is way off track.

Finally, a phased roll-out helps staff to feel accountable and motivated, because the successes are visible (as are the delays and problems). Ideally, each phase should not be longer than six months; if they are longer than that, you start to lose momentum and focus.

Antony Barnes and Marcus Johansson are associates at PricewaterhouseCoopers

Pic: vestmancc2.0