It may seem self-evident that organizations should study and adopt best practices. But in fact, this isn\u2019t always the case. There certainly are situations where others have figured out how to solve a problem and there\u2019s no need to reinvent your own solution. It\u2019s wise to avoid the \u201cnot invented here syndrome\u201d 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\u2019ve heard a number of people say that decentralizing applications developers is a \u201cbest practice\u201d 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\u2019t work for you. (We\u2019ll explore examples of this below.) How can a leader know when \u201cbest practices\u201d are really the best thing to do? \n\nTwo Kinds of Best PracticesBecause the term \u201cbest practices\u201d 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 \u201cbest practice\u201d 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 buzzwords described over the past year and a half in this column. 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 \u201cbest practices\u201d 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. \n\nWell-Defined ProcessesIf a process is well-structured and routine, like an assembly line, then it can be optimized\u2014that is, designed in a scientific fashion. A \u201cbest practice\u201d at this end of the spectrum is a process design that 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\u2019s \u201cscientific management,\u201d industrial engineering and, more recently, business process engineering. 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 enterprise resource planning (ERP) project. Two cautions are in order: First, be aware that adopting best practices will stifle innovation. There\u2019s great value in a standardized process, which means that people aren\u2019t 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 competitor\u2019s) is the one to do so. Some mechanism for experimentation and innovation should be designed into your organization\u2014for example, a process by which people can propose experiments and incentives for innovation. But just to be safe, it\u2019s 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. \n\nOrganizational Design QuestionsI\u2019ll bet you can guess what I\u2019m going to say about applying best practices to the other end of the spectrum, organizational design issues! In 1997, writer Lauren Paul did a study of how four leaders tackled the challenge of strategic alignment. (Paul, Lauren Gibbons. \u201cWhen Best Practices is the Worst Practice.\u201d PC Week, August 4, 1997.) Don\u2019t scoff that it\u2019s 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 communication 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\u2019s 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 \u201ctaking orders,\u201d 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\u2019t 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. \n\nWhen to Adopt Best PracticesWebster\u2019s dictionary defines the word \u201cpractice\u201d as a repeated or customary action, or the usual way of doing something. It\u2019s 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 business process re-engineering 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\u2019re considering isn\u2019t 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\u2019t flow-chart the process, it\u2019s not amenable to best practices.\n\n Dean Meyer helps IT leadership teams design high-performance organizations. Author of six books, numerous monographs, columns and articles, he brings innovative systematic approaches to what others consider the \u201csoft\u201d side of leadership. Contact him at email@example.com or visit his website for information that can help you implement these ideas, or with suggestions for other buzzwords to analyze in future.