It may seem self-evident that organizations should study and adopt best practices. But in fact, this isn't always the case.

There certainly are situations where others have figured out how to solve a problem and there's no need to reinvent your own solution. It's wise to avoid the "not invented here syndrome" and remain open to learning from others.

But there are also situations where others (sometimes many others) have adopted practices that are ineffective, or even harmful. For example, I've heard a number of people say that decentralizing applications developers is a "best practice" when, in fact, it inevitably leads to replication of efforts, fragmented data, and lost business synergies.

In addition, there are many situations where others have found solutions that work for them but won't work for you. (We'll explore examples of this below.)

How can a leader know when "best practices" are really the best thing to do?

Two Kinds of Best Practices

Because the term "best practices" is used to describe a range of very different things, the first step in understanding when to apply best practices is to clarify the definition.

On one end of the spectrum, there are well-defined processes such as help-desk incident management and infrastructure change control. When a process is structured and repetitive, a "best practice" maps all the steps that need to be done and their interdependencies.

On the other end of the spectrum, there are organizational design questions like decentralization, outsourcing, organizational structures, culture, governance mechanisms, and the range of leadership fads and buzz-words.

These are far more complex issues, and do not lend themselves to an assembly-line style of process optimization. At this end of the spectrum, the term "best practices" does not mean a procedure or process, but rather a philosophy that others are pursuing.

Consider the application of best practices in these two very different situations.

Well-defined Processes

If a process is well-structured and routine -- like an assembly line -- then it can be optimized, that is, designed in a scientific fashion. A "best practice" at this end of the spectrum is a process design which describes everything that must be done, the interdependencies of the tasks, and perhaps methods for doing the tasks.

This is where best practices got its start. This tradition goes back to Frederick W. Taylor's "scientific management," industrial engineering, and more recently, business process engineering (BPR). An example within IT of this end of the spectrum is ITIL which, for the most part, describes routine operational functions within an IT department.

Opportunities for best practices are found within the well-structured processes of IT (like service delivery) and throughout a business (like the routine business processes commonly redesigned as part of an ERP project).

Two cautions are in order:

First, be aware that adopting best practices will stifle innovation. There's great value in a standardized 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 organization (not your competitors) is the one to do so.

Some mechanism for experimentation and innovation should be designed into your organization, for example, a process by which people can propose experiments and incentives for innovation. But just to be safe, it's wise to continually scan the rest of the world for a better best practice.

Second, remember that best practices describe what must be done, not how you organize to do it. Structuring your organization around routine processes is not wise; it scatters each specialty within IT among the various processes that utilize it, and undermines accountability for the various entrepreneurial businesses-within-a-business inside an IT department.

Instead, think of the process as cutting across your organization chart, describing what various groups contribute to the end result.

Organizational Design Questions

I'll bet you can guess what I'm going to say about applying best practices to the other end of the spectrum, organizational design issues!

In 1997, Laura Paul did a study of how four leaders tackled the challenge of strategic alignment. (Paul, Lauren Gibbons. "When Best Practices is the Worst Practice." PC Week, August 4, 1997.) Don't scoff that it's too old to be relevant. Nearly a decade later, IT leaders are still struggling with the same challenge.

In this study, all four CIOs described the same concern: Their organizations were not reliably delivering projects that were directly related to business strategies.

But these four leaders took the time to do root-cause analysis of their organizations.

Lew Davison at the Missouri Department of Transportation found that all his IT resources were being consumed by low-payoff projects. He implemented a client-driven portfolio-management process based on the principles of market economics. Sure enough, clients chose to buy from IT the things that were most strategic to them.

The CIO of Case Corp., Jim Hatch, found the key to strategic alignment was better communications between IT and business leaders. He implemented a culture within IT of customer focus and entrepreneurship, and saw a dramatic improvement in strategic value.

Max Watson, then CIO of the U.S. Army's Missile Command at Redstone Arsenal, found that everyone in IT was talking to clients about their needs, each bringing the bias of his/her specialty in a technology-driven approach to requirements planning. He restructured his department to include a relationship management function.

At Johnson & Johnson, Rich Wasilius found that his corporate IT function was passively "taking orders," not proactively helping clients discover strategic opportunities for IT. He introduced a leading-edge method of strategic requirements planning.

Had any of these leaders simply adopted the solution of another, calling it a best practice, he would have failed to address the real reasons his IT organization wasn't reliably delivering strategic value.

For these higher-level leadership issues, there is simply no effective substitute for analyzing your own unique root-causes and applying the fundamentals of organizational design.

When To Adopt Best Practices

Webster's dictionary defines the word "practice" as a repeated or customary action, or the usual way of doing something. It's a set of actions.

The concept of best practices is useful when the subject of discussion can be described this way, as a process or procedure. For these issues, best practices can tell you what needs to get done (but not who does what, i.e., not an organizational structure). This is an excellent use of best practices, as long as you leave some room for innovation.

But beware of zealots who believe that what works for routine, well-structured assembly lines will work equally well for creative processes and less-structured jobs. One of the reasons for the downfall of BPR was that it treated entire white-collar organizations as simple assembly lines. Similarly, ERP-driven best practices are useful for processes like bookkeeping, but fail when they attempt to structure financial planning.

For more significant leadership challenges such as organizational design, following the lemmings may very well lead you off a cliff.

If the best practice you're considering isn't a process or procedure, it probably warrants a study of root-causes and fundamental principles rather than best practices.

The simple guideline is, if you can't flow-chart the process, it's not amenable to best practices.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....