With IT leadership, the "how" is as important as the "what"

Close attention to smart change management will yield positive results.

The other day my IT operations leader entered my office in a state of confusion. He had just been reviewing our uptime statistics and was baffled by what he saw.

In 2010, on one particular web stack we had an uptime of 99.88% (translates to about 10 hours of an outage). But when he looked at our data for 2011 to date, we had 100% uptime. While clearly glowing with such a result, his confusion was based on the fact that we had not implemented any specific technology or fixes in this stack to garner such impressive results. He said: “I am very proud of these results. I just don’t know what we did to achieve them.”

In this instance he was asking the wrong question. It was not what we did. It was how we did it.

Doing things right

Our IT strategy is and will always be focused on doing the right things. Getting positive results is the bottom line. But while doing the right things is essential, it can be equally important to do things the right way.

It is my belief that a fleshed out IT strategy reconciles predictability with innovation. It will seldom fly to just have one or the other. Both are required and they must feed off each other.

The core challenge essential to implementing both is finding the right blend for your organization. I have written about it here. In the first year of our IT transformation much effort was expended on putting in place good process to support the right level of predictability. It’s a work in progress.

Getting the right level of process consistent with culture and organizational needs is a science unto itself.

The IT team made good progress in process areas such as IT governance, project management best practices, IT service management, business analysis and change management. It is in the latter that we gained particularly positive results.

Web 2.0 Summit, being held October 17-19 in San Francisco, will examine “The Data Frame” — focusing on the impact of data in today’s networked economy.

Save $300 on registration with the code RADAR

Managing change

At its core, change management is about moving from one state to another to achieve a desired result while being adequately prepared and managing to an acceptable level of risk. It is also an important vehicle for communications between individuals and across teams.

Put bluntly, change management is good business.

Change happens all the time within IT. What contributes to the definition of a world-class IT organization is how that change is accomplished.

As O’Reilly IT entered 2011, we decided to be very deliberate about change. We agreed that we would be hyper-judicious in the infrastructure changes we made. We became priority junkies. Every time a change was identified we asked questions such as whether it was a priority, if there were alternatives, and studied the consequences of not making the change (see the change tool later in the blog).

And as we did that, something extraordinary happened.

The IT operations team started to get the most important projects deployed. Distractions became manageable and the priorities process kept everyone on track.

But most of all, we experienced increased infrastructure stabilization.

Of course some stabilization occurred because the improvements that were being made were being applied through a rigorous change management process. But, moreover, there was greater stability because less unnecessary change was being applied.

Change management was helping us make changes successfully and it was also helping us to determine what changes not to make.

Good process still gets insufficient focus

In IT, most of the time technology gets all the press. We get excited by new innovations and start-ups that introduce cool new capabilities. We are thrilled when a big player disrupts the market with something really compelling. And we should. We live in amazing times and new technology is a big part of that.

But often lost in the enterprise is that while technology represents a part of change — albeit, a critical part — the processes to implement and manage that technology are as important (and often more) than the technology itself.

I would guess we have all seen a great technology fail in an organization because of non-technology reasons. At the same time, I bet we have all seen how good technology coupled with good processes has resulted in excellent results.

When my IT operations leader observed great things happening despite technology, he was inadequately recognizing how we were working. For all involved it provided a rewarding “aha” moment.

Quick tool to manage change

I will conclude by sharing a brief tool that both IT and business can use for managing technology-related change. These are the minimum questions that must be asked for every change. They are simple questions, but all too often one or more is omitted when embarking on a change that expends scarce enterprise resources:

  1. Why [Governance]: Is the change aligned and essential to achieve business objectives?
  2. What [Measurable Outcome]: Is it understood whether it is a technology or process (or both) that will provide the desired result? Can the outcome be measured?
  3. Who [Resourcing]: Have the appropriate participants been identified for this change?
  4. How [Methodology]: What approaches have been identified to execute and manage this change?
  5. When [Prioritization]: Has sequencing been agreed to relative to all other objectives?

If both IT and the business are in agreement on the answers to each of these questions, you’ve just taken your IT management up a few notches. And you might just find a few people surprised by the positive results.

Related:

tags: , , ,
  • Tyler

    So, what you’re saying is that the stodgy old Enterprise types have something to offer?

  • http://cloud81.com Alan Perkins

    Jonathan, I always get a lot out of reading your material. I have a concern though with focus on uptime statistics for all but service providers – metrics for most businesses have nothing to do with uptime. You could be down for large chunks and if it doesn’t affect your business or customers, so what?

    There needs to be first and foremost questions asked about whether we are achieving the best possible outcome with the resources we have. Focussing on achieving high uptime at the expense of innovating for improvement through better products / better customer experience / better competitive advantage or whatever will lead to localised optima that are far from globally ideal.

    I know that is not what you are saying but I know from the questions I often get asked from an audience of CIOs means they are too focussed on uptime at the expense of their business.

    Love the brief explanation of Why What Who How When.

  • http://radar.oreilly.com/reichental/ Jonathan Reichental

    Hi Alan: Thanks for your comments. You make a really important point: not all systems are equal. I encourage organizations to agree on service level agreements (SLA) for each system. That would include uptime requirements. As you note, some systems don’t need 100%.

  • http://www.linkedin.com/in/michelleransom Michelle Ransom

    Thanks for this – I too, use the Who, what, where, when, why how – for one-pagers explaining an intiative or proposal. I would suggest you add the where – as a Change Mgmt practitioner, the where is another element of the who… and who needs to be ready. Where is also an influencer of when.. etc etc. Best to include them all – also easier to remember! Your thoughts?