Why IT Must Overturn Its Obsession With Best Practice

IT is changing at a phenomenal rate and at times we struggle to make sense of the vast array of tools, technologies, architectures, patterns and methodologies that are at our disposal. Sometimes we want to let others do the thinking and tell us the 'right answer'. Luckily, the vast armies of vendors, research organisations, standards bodies and consultants are only too happy to assist by supplying 'best-practices'.

Such best-practices have a role to play but there are several reasons why all that glitters is not gold.

Reason 1: Best-practices are rarely evidence based.

Anything claiming to be a best-practice must be empirically based, that is, derived from observation, experience or experiment. All too often conventional wisdom and anecdotal evidence is dressed up as best-practice.

Historically, the vast majority of significant advancements in business thinking have come out of academia. Academics may spend years researching a topic and gathering evidence and only then will they draw conclusions and offer advice. Vendors and consultants simply don't have time for the intellectual rigour required by the scientific-method, so they develop theories and test them in the field, on client projects.

Field-testing is important but it doesn't account for the many variables that influence the success (or otherwise) of an idea. Vendors and consultants aren't there to test and validate an idea – they're there to deliver a project. If the idea works, then great. If it doesn't, then it must be a problem with the client, not the idea – "they mustn't have followed our advice correctly". This outlier is promptly removed from the sample used to derive statistics on how effective the best-practice is.

Reason 2: Best-practices must actually be implemented.

Implementing best-practice can be done in one of three ways:

• Adopt
• Adapt then adopt
• Adopt then adapt

Adopt

Applying best-practices verbatim ignores the fact that there is no such thing as a universal truth. Frederick Winslow Taylor's assertion that there is "always one method…which is better than any of the rest," may be true in a widget factory, but the modern business world is not that simple.

The 'best' way will depend on a huge number of variables such as the problem you're trying to solve (efficiency, effectiveness etc), the constraints you have to contend with (resources, time, money etc), the organisation itself (structure, strategy, culture, politics, risk tolerance, existing standards, policies, procedures, processes etc) and the people involved (those leading the best-practice implementation and those affected by it). There is no single 'best' practice that will be universally applicable across all of these dimensions.

Adapt then Adopt

Adapting best-practices before adopting them creates a different and potentially worse problem. Adaptation is often an exercise in forcing the square peg best-practice into the IT Department round hole. This process often fails to differentiate between things that are optional extras and things critical to the structural integrity of the best-practice. Ideas that require any meaningful change to the status-quo are usually the ones 'adapted' and before long, the 'best' part of the best-practice is lying on the cutting room floor.

Adopt then Adapt

Here, the best-practice remains structurally intact as it's implemented and given time to bed down. Only then are adaptations made – but these will be grounded in real-world learning not speculation about what may or may not work, as in the case of the adapt-then-adopt scenario. Theoretically this is the best approach to take but in practice, it rarely works. People's innate resistance to change is compounded by the knowledge that they only have to 'prove' that the best-practice is a bad idea and it will be adapted in due course, hopefully in a way that will require minimal changes to the status quo.

Clearly, implementing best-practices is fraught with difficulties – irrespective of which approach you take.

Reason 3: Best-practices rarely define "best".

From the very beginning of our IT careers we've learned to deal with contradictions such as time to market vs. quality, security vs. user-friendliness, functionality vs. maintainability, performance vs. simplicity and future-proofed vs. fit-for-purpose. We've also had plenty of religious debates as well: Windows vs. Unix, Java vs. .Net, REST vs. SOAP, open-source vs. proprietary, Android vs. Apple, cloud vs. on-premise, to name a few.

It's really surprising that IT professionals who've had to deal with such ambiguities their entire careers, and always answer 'it depends' in response to questions about the 'best' solution to a problem, unquestioningly accept ideas labelled 'best'.

Best-practices are designed to produce repeatable results, which is fine so long as you're clear on what results you want. If you apply best-practice to your next ERP implementation will you get the cheapest implementation? Quickest implementation? Implementation with minimum risk? Minimum disruption to the business? What exactly?

Maybe the term 'best-practice' should be stricken from our vocabulary and replaced with 'good-practice'. Better yet, replaced with 'good-practice in specific situation X'.

Reason 4: Best-practices are often an excuse for slow delivery.

A perennial complaint about IT Departments is their lack of responsiveness. In response, IT employs the Nuremburg Defence: "it's not our fault, we're just following best-practice!"

Let's assume a best-practice is evidence-based, has been expertly tailored to your environment, and designed to consistently deliver the 'best' results (as defined by you). Congratulations, you're now the proud owner of a perfect hammer. The weight is perfect. The grip comfortable. You're an expert in its use. But as the old saying goes, if all you have is a hammer, then every problem you see will be a nail.

IT Departments often forget that 'best practice' and 'fit for purpose' are not at opposite ends of some 'quality' spectrum. Sometimes the real best-practice for a given situation is whatever achieves the desired outcome for least cost and in the shortest possible time. Just because something isn't best practice, it doesn't mean that it's inferior or inadvisable.

Reason 5: Blind deference to best-practices is intellectually lazy.

If you let others think for you, you soon forget how to think for yourself. This is a problem for IT Departments because IT is the organisation's problem solver, and to solve problems you need to be able to think.

Remember the old adage "catch a man a fish and you'll feed him for a day. Teach a man to fish and you'll feed him for a lifetime." Best practices are fish delivered to your door, and sometimes the convenience is great – so long as you don't forget how to fish. Even if the best-practice does teach you how to fish, remember that all best-practices are backward looking. They can tell you how to catch today's fish using today's tools but can't tell you how to catch tomorrow's fish using tomorrow's tools.

Reason 6: Best-practices are focussed on components, not the whole system.

Early in our career we learn that optimising individual components of a system doesn't necessarily result in an optimised system. The IT Department is a system but individual best-practices only target specific components within that system.

While there are best-practices for each IT Department component, applying best-practices to improve each one in isolation will lead to suboptimal results. The total will be less than the sum of the parts. There are three reasons for this.

Firstly, there are often conflicts between best-practices. Just listen to developers and a project managers discussing agile development.

Secondly, improvements to one component won't necessarily translate into improved system performance. Let's assume you've applied all available best-practice and you have the world's best software development capability. The goal of IT (the system) is to get business results. Best-practices in software development (one component of the system) won't matter if you have poor training, implementation, change management, support and benefits realisation capabilities.

Finally, even improving every component won't necessarily optimise the performance of the overall system. The relationships between components are as important as the components themselves, and, as Peter Drucker said, "there is nothing so useless as doing efficiently that which should not be done at all."

Conclusion

The six reasons presented above clearly demonstrate that implementing best-practices is not a panacea. Some best-practices are nothing more than conventional wisdom or anecdotes and others are ambiguous about the definition of 'best'. Those practices that actually do work must be implemented within your organisation, which is a difficult process regardless of which approach you take. Even if you manage to implement them, you may find that best-practices are a mixed blessing, resulting in a lack of responsiveness and agility as well as intellectual laziness. Finally, implementing best-practices doesn't necessarily lead to systemic improvements.

Increasing numbers of IT Departments are implementing industry best-practices but we're barely moving the needle on the one key metric that matters: business satisfaction with IT.

Slavishly implementing best-practices is not the answer, but nor is it advisable to ignore them entirely. Reinventing the wheel and repeating other's mistakes isn't a recipe for success either. But there's a middle ground: use best-practices as conversation starters – not the final word.

As Matsuo Basho suggested, seeking to understand the best-practices and forging your own path may be preferable to blindly following in the footsteps of the wise.