We were in an IT shop the other day where a major infrastructure deployment was underway. In the staging area, a forty-three item “check out” was followed before allowing gear to move to the floor proper for installation (where another sixty-one item “check out” was followed). The organization’s track record at successful installations was excellent: it had been seven years since that last implementation failure. On the other hand, getting something done in their data centre typically took in excess of sixty days, no matter how urgent it was.

We discussed the practices they were following and discovered quickly that the lists were formed out of one incident after another where something had gone wrong in the past. In essence, the various items checked for prior errors in judgement.

This is not at all uncommon — but it is worthy of review.

Most organizations are like this: they have a bevy of practices which have grown up over time. In one case recently, a company did a year-long study of ITIL, looking to see if there was any value in using it to update practices. Their conclusion was that their existing practices were all “correct”, and that no change was needed. We do not dispute this — their practices work, after all, and give them a high service result — but we do believe that many of them could be streamlined without losing their service edge.

In the business world, it has long been standard to review product lines (for a product-based company) or customers (for a service-based company) periodically and look to prune it. Products are sold off or terminated because their market opportunity has passed; the customers at the bottom (low billings, difficult to work with) are removed from active selling situations. This kind of pruning keeps the company healthy. (Most companies don’t do this often enough, or rigorously enough — consider Polaroid’s demise at the hands of its decision to keep concentrating on film long after digital photography took over and destroyed its instant photo camera business — but at least it does happen.)

Banks also periodically undertake this kind of review: teller procedures are made steadily more complex to deal with each incident that occurs at a branch. Once a decade or so, a prudent bank will go through this, looking to remove as many as possible, so as to speed up counter service. This is what IT needs to do in its own interests as well.

The basic mind-set for a practice review is negative. The presumption is that a certain “to do” item in a practice should be out unless justified to stay in. In the event of indecision, table the item until the review is over. Allow 10% of the total practices to be reinserted from amongst those you tabled. The rest are out. This then becomes the new practice.

Why is this needed? Simply put, putting blades in a rack, or plugging a network cabinet, isn’t all that difficult. Sixty days to do these tasks is excessive: a sign of inefficiency. Benchmarks may not show this, in that your costs and labour numbers can compare favourably with the market, yet you can still be slow to execute. Eventually that lack of speed inhibits the enterprise’s ability to respond to market conditions.

“Just because we’ve been doing it for years doesn’t mean it’s wrong.” No, it doesn’t. But we do think practices should be periodically reviewed and made to account for the effort and time they soak up. If they’re good for the company, they’ll pass the test. If they’re luxurious in their risk avoidance, they’re probably inhibiting getting other more useful things accomplished.

19th century writers kept old books and a skull around to remind them of the past. But they didn’t remain in the past — and that’s what you remember, when you jump to defend “the way we do things here”.