Home    ITIL  Index

Breaking Down Silos - An ITIL Imperative

IT needs to have a systems mindset that focuses on enabling the business, which necessitates teamwork and the dismantling of silos, writes ITSMWatch columnist George Spafford.
Jun 24, 2010
By

George Spafford





Editor's Note: This will be George's last column for ITSMWatch and I would like to take this opportunity to wish him well in his new position as a research director at Gartner.

IT organizations typically follow a hierarchical division of labor with classic command and control structures that often results in silo'd groups. These overly verticalized groups tend to be isolated, self-invested and not working towards common goals.

On one hand, this bureaucratic structure promotes/enables specialization of technical skills but, on the other, there are imperfect transfers of data, information, knowledge and work between various groups leading to inefficiency, ineffectiveness and higher risks. IT organizations that are seeking to improve must carefully plan and take action to break down these silos for the betterment of the organization as a whole.

If improperly pursued, ITIL processes tend to exacerbate silos by formally reinforcing the roles and responsibilities of a given functional area in isolation. In actuality, the ITIL documentation does provide base sets of interactions between processes. Teams responsible for the design and implementation of processes must pay close attention towards both formally defining the integration of areas as well as promoting, formally and informally, the fact that everyone must work together in concert to support the goals of the business through IT services and their continual improvement.

As management and process improvement teams develop strategies, design and implement processes, they must take into account the integrated and tightly coupled "system" of IT processes and the nature of work. To help reduce silos and foster teamwork, this article sets forth the following base recommendations:

Tone from the top - First and foremost, from senior management downwards, it must be made clear that groups are to work together to create and value; that is to say to work together to enable the business to pursue the goal with adequate safeguards. They must make it clear that isolationism will not be tolerated and that the various groups must work together. If process documentation and such provides the letter of the law then management's "tone" must help identify and reinforce the spirit of the law. In other words, the need for various teams to work together must be an intrinsic part of how work is conducted and be clearly reinforced by senior management.

In this age of tight budgets, accelerated time to market and high expectations, management cannot afford impediments to high performance. Silo'd groups that are allowed to blame one another or develop other compensating mechanisms to overcome the perceived shortcomings of other teams will not be effective and efficient in the long-run (not to mention increase the level of risk inherent in IT services).

Formalize and promote process and data architectures - There must be an over-arching systemic perspective that guides the design of processes to maximize their value. As such, there must be a formal architecture that identifies the various processes and their relationships to one another. This includes the documentation of inputs, outputs, dependencies and so on.

The process architecture will also serve as an input to the creation of a supporting data architecture that can be coupled with a tools strategy to improve integration and overall effectiveness and efficiency. Process and data architectures are increasingly important due to complexity in the business and IT environments. If anything, a lack of formal architectures will allow organic complexity and costs to dramatically increase over time.

Design and implement processes with clear integration - In accordance with the formal process architecture, each individual process must be designed and implemented. To help avoid or break down silos, process design and implementation methodologies should take into account the following:

Processes need to be formally documented for consistency, training and continuous improvement. This documentation must be clear and truly add value lest useless shelfware be created.

Process integrations need to be identified in the documentation. For example, when does Incident Management need to engage Change Management and how? Process flows and sub process flows need to identify this information and have supporting detail.

Roles and responsibilities need to be identified. The use of swim lane diagrams for visual depictions and RACI charts to methodically identify involvement can reduce ambiguity.

There must be training when the processes are launched or revised as well as annual refresher training. It is imperative that staff understand what is expected of them.

Documentation and training must effectively communicate why the process matters. What are its objectives and why should people bother following it?

Processes should be reviewed at least annually or after organizational events such as mergers, divestitures, and so on.

Management should design processes to include the necessary data collection and reporting to provide oversight both on a specific process and on the system overall. For example, the performance of one isolated server is less relevant than the performance of an overall service in the eyes of customers and users.

Recognize and address human factors - To further break down silos, job descriptions, performance reviews and compensation plans need to both reflect the output of IT overall as well as customer satisfaction and the needs of the business overall. If they are created and managed with a local focus then the silo mindset will be reinforced and attempts to create a system focus will likely fail.

Consider the following: a server engineer may be primarily judged by the number of servers built and availability of the servers specifically. Those measures focus on a fraction of what it takes to provision and sustain an IT service. As a result, the engineer may focus only his servers at the expense of the business. The perspective can change by measuring performance and such at the service level as well as customer satisfaction. Thus, it wouldn't be the engineer's server performance solely that is looked at but also the service that they are a part of such as SAP in support of accounts payable.

To break down IT silos, senior management must have the appropriate tone from the top. Process and data architectures must be developed to guide efforts from a cohesive systemic perspective. With the architectures taken into account, processes need to be designed and purposefully implemented with integration factored in. Last but certainly not least, "soft" human factor issues need to be designed and implemented to reinforce the desired organizational changes.

George Spafford is an experienced consultant in business and IT operations. He is a prolific author and speaker, and has consulted and conducted training on strategy, IT management, information security and overall process improvement in the U.S., Canada, Australia, New Zeland and China. His publications include hundreds of articles plus the following books: "The Governance of Green IT", "Greening the Data Center", "Optimizing the Cooling in Your Existing Data Center" and co-authorship of "The Visible Ops Handbook" and "Visible Ops Security". His current area of research is the use of information technology for competitive advantage.

Tags:
ITIL, ITSM, Spafford, process improvement, silos



Comments  (click to add your comment)

Comments

    Name or nickname

    Email address

    Website

    Write comment
    You have characters left. (Maximum characters: 1200).

     


    IT Management Daily Newsletter




    Most Popular