Best practice not always a recipe for success
- 11 February, 2007 22:00
“Best practice in IT” is a term that is bandied around a lot, but can following the practices of others do more harm than good?
According to N. Dean Meyer, writing on CIO.com, there are times when the practices of others are ineffective for your organisation — and may do some harm.
“For example, I’ve heard a number of people say that decentralising applications developers is a ‘best practice’ when, in fact, it inevitably leads to replication of efforts, fragmented data and lost business synergies,” Meyer says.
He says the first of two kinds of best practice is well-defined processes (for example, helpdesk incident management and infrastructure change control where the best practice maps steps and interdependencies).
This is where best practice got its start and a good example is ITIL (IT Infrastructure Library), which describes routine operational functions in an IT department, says Meyer.
He warns, however, that adopting best practices can stifle innovation.
“There’s great value in a standardised process, which means that people aren’t allowed to creatively change the process at will. However, the day will come when somebody breaks the mold and invents a better practice. Make sure your organisation (not your competitor’s) is the one to do so.”
The second kind of best practice is organisational design (for example decentralisation, outsourcing, organisational structures, culture and governance mechanisms).
This kind is far more complex and Meyers says best practice here is more a philosophy than a procedure or process.
He refers to a study which is now ten years old, but which he says is still relevant today.
“In this study, all four CIOs described the same concern: Their organisations were not reliably delivering projects that were directly related to business strategies.”
However, after doing a root-cause analysis of their organisation, each leader came up with different solutions which were driven by the different causes of their problems.
Meyer says that in all the cases, adopting best practices of other organisations would have failed to address the real reason for IT not delivering strategic value.
“For these higher-level leadership issues, there is simply no effective substitute for analysing your own unique root causes and applying the fundamentals of organisational design.”
Meyer says that one of the reasons for the downfall of business process re-engineering was its treatment of white-collar organisations as simple assembly lines.
“Similarly, ERP-driven best practices are useful for processes like bookkeeping, but fail when they attempt to structure financial planning.”
He says that if you can’t flow-chart the process, then best practice may not be the answer.
Another CIO writer, Mark Hollands, is also sceptical about best practice – in fact the very term, he says, makes his blood boil.
“When lots of companies copy the copier, it becomes dull, intellectually stagnant and offers no competitive advantage. It's just a me-too strategy executed by the cynical, the lazy, or the lazy cynics.”
He recommends being very sceptical when peers post their successful projects as best practice: “get out the crucifix, garlic cloves and wooden stake…Just because it worked for them does not mean it will work for you. They may have dodged a bullet. You may not.”
Hollands says that often the real difficulties (such as corporate culture or poor vendors) are not documented well so you are no more informed than “learning how to redesign a garden by watching Backyard Blitz.”
Hollands says the solution is to lead the way. “You don't want to be a carbon copy of your competitor.”
If you’re not convinced and plan to move ahead with best practice, an article on Techworld.com has Denise Dubie writing about how the various best practice frameworks can be daunting, but need not be. She says quotes a consultant — Jon Vromat — as warning that managers should be cautious about falling victim to "standards slavery”.
"IT organisations often think they have to take it all on at once, and then they fail. Adopting frameworks is more like eating an elephant; to be successful, you have to do it in digestible chunks.”