by Greg Shields

Or, more specifically, IT doesn’t understand the impact of its processes. Again relating back to the thesis that IT’s relatively short history is the source of its misalignment, IT as an industry today finds itself in a kind of “second wave” of process formalization. Allow me to explain.

To best understand this “second” wave of process formalization, it’s important to recognize the history prior to even its “first” wave. Consider the earliest days of IT, during that “wild west” time before process was even a consideration. During this time (which was not all that many years ago) the daily activities of IT organizations were fundamentally chaotic. When IT needed new servers, new servers were purchased. The same held true with applications, or management tools, or virtually any technology purchase. If a business team needed a new service, that service was quickly created, often with little to no documentation and no integration with other services or existing infrastructure. Services and applications grew in number as individual and segregated business teams identified and instantiated IT projects out of their anticipated needs.

This unrestrained growth quickly expanded to the point where most businesses found themselves awash with hundreds or thousands of services and applications. Many of those were redundant or tangential in capabilities. Others were created only to later lose their stakeholders but still require maintenance and support. Some services during this period went wholly unused but lacked the management necessary to instruct IT to turn them off. Occurring during one of the great boom periods of the economic cycle, IT’s early days found itself with no end of work to do and a bottomless well of funding to accomplish that work.

The result was chaos.

As we all know, that period’s irrational exuberance of expansion was short-lived. Following that period, businesses like your own found probably themselves spending far too much on techno-centric projects that didn’t provide positive return. The following period found businesses reducing IT budgets, while at the same time requiring a more strict formalization of IT processes. Process frameworks like the IT Information Library (ITIL), Microsoft Operations Framework (MOF), and others became the defining documents by which IT determined how it would accomplish its required activities.

Yet with every knee-jerk reaction comes an equivalent overcompensation. By rapidly replacing IT’s early “wild west” mentality with a new approach based on strict and formalized process, many organizations took that implementation of process too far.

This process represents IT’s “first wave” as previously discussed. But what really happened during that first wave? How were those processes implemented in many organizations? As you’ll find out in a minute, the “going too far” succeeded in stopping the hemorrhaging. But it did so by stripping all the agility and a good deal of the raw creativity out of IT’s fledgling industry.

Consider as an example ITIL. Currently in version three, the operational activities defined by ITIL are documented in a series of six books. The first book discusses an introduction to the framework, with the remaining five covering each of the five stages in ITIL “IT Service Lifecycle.” Included within these five stages are no less than 24 major activities that are recognized as critical parts of an IT infrastructure. Figure 1 shows a representation of each of the five stages with their accompanying activities.

Figure 1: ITIL’s 5 stages and 24 activities.

Although each of these activities has a place in businesses everywhere, one of the defining tenets of ITIL (as well as other frameworks) is that the framework’s massive guidance should be tailored to suit the needs of the business. As a simplification, this can mean that businesses with simple needs likely won’t need every activity. Or, that individual processes within each activity needn’t necessarily be followed exactly. In effect, ITIL and frameworks like it are intended to be used as guidelines and best practices rather than established dogma.

Unfortunately, IT’s rush in many organizations to implement formalized process and process frameworks has led today to a hyper-implementation of process. ITIL itself has its history in federal government bureaucracy. Its concepts started as a project within the British government, and were in fact for a time referred to as the Government Information Technology Infrastructure Management. If you’re the type of person that dislikes the level of waste and non-optimization that can be common in government-style bureaucracies, then it becomes easy to see (and also dislike) the parallels found within IT process frameworks like ITIL.

Think for a minute about how such government bureaucracy and its parallel in the manifestation of formalized IT process creates a strain on an organization’s agility:

• Accomplishing even the smallest of tasks requires the cooperation of multiple individuals and teams, each with their own political aspirations.
• Organizations can find themselves wielding “process” as a weapon to be used against the fulfillment of service requests. At the same time, businesses (particularly large, enterprise businesses) find themselves losing agility as their requests take longer and longer to be fulfilled.
• “Process” itself can also grow to become an impenetrable shield behind which organizations hide and in front of which service requestors cannot breach.
• In the face of documented process, an individual requestor lacks sufficient organizational power to manifest change within the IT organization. As such, simple requests for servers, services, and applications become bureaucratic nightmares of justification, paperwork, and approvals.
• Often, the weight of the process itself becomes a hindrance to completing needed tasks. When needed tasks require a massive effort to make their way through the process framework, those tasks can be simply abandoned.

Consider the following real-life example of an enterprise process implementation gone horribly wrong. In this organization, its IT department, like many others, began with a simple charter to serve the technology needs of the company. That charter eventually grew to the point where IT found itself involved with virtually every part of the organization, called in to provide assistance for many projects, and providing services for numerous teams throughout the business.

This early “wild west” approach indeed had its downfalls. Some services were not properly architected prior to implementation or not well managed in the period after. These shortfalls caused unnecessary outages along with levels of service quality that were below the requirements of the company. Yet even in this situation, while service quality itself wasn’t to acceptable levels, the implementation of services themselves generally happened on schedule as required by the company.

After a series of small mistakes with big impacts, this company decided to incorporate a formalized process framework to assure service quality. It at the same time laid into place the structures to ensure that IT projects were only taken on after a lengthy deliberation, justification, and approval period. This new package of processes was laid in place over a 2-year period, with much of the time involved with gaining buy-in from both IT and the business.

At the end of the 2-year period, its implementation was complete, with the results being a marked improvement in service quality for the core services of the company. Service uptime began to improve, as did the overall quality of services that were provided to users.

However, at the same time, came a significant reduction in IT worker productivity along with a dramatic increase in time-to-completion for even the smallest of projects. Implementing such projects required documenting the project through a series of 12 “gates.” Each gate required the creation of a formal documentation package as well as a presentation to stakeholders and engineers. Moving from gate to gate typically required an approval by a Change Control Board, an Engineering Review Board, and/or IT management, the members of which were sometimes the same. Mission-critical changes with widespread implications required an additional path through a high-level Technical Exchange Board, which operated as a kind of board of certification to which plans were defended.

Once project plans were officially approved through the gating process, each individual change then required approval by the Change Control Board. This board was responsible for the individual baseline of each server, service, and application. Change Control Boards met twice per week, with Engineering Review Boards meeting one per week or less, and Technical Exchange Boards meeting only when a quorum of stakeholders could be present.

The result of this process incorporation indeed eliminated the “wild west” approach to IT operations. It did so by purposely slowing down the process. As a result, even the smallest of changes typically took weeks or months to get started.

Do you see this situation in your business today? Are you finding your business becoming more and more unable to bring needed IT services online within a schedule that meets your agility needs? While no one wants to return to the costly days before these processes were put into place, what your IT organization needs is its own “second wave.”

One of the primary failures in IT’s first wave of process formalization was in rationalizing its processes within the perspective of its accompanying business. Process frameworks like ITIL indeed brought about a much-needed formalization of IT activities, but entirely without the much-needed right-sizing to the requirements of today’s business. As a set of historically government-centric guidance, most implementations of its activities simply didn’t take into account the fundamental speed of business. Right-sizing that velocity while maintaining structure will require effort from both your IT organization as well as yourself.

Or, more specifically, IT doesn’t understand the impact of its processes. Again relating back to the thesis that IT’s relatively short history is the source of its misalignment, IT as an industry today finds itself in a kind of “second wave” of process formalization. Allow me to explain.

To best understand this “second” wave of process formalization, it’s important to recognize the history prior to even its “first” wave. Consider the earliest days of IT, during that “wild west” time before process was even a consideration. During this time (which was not all that many years ago) the daily activities of IT organizations were fundamentally chaotic. When IT needed new servers, new servers were purchased. The same held true with applications, or management tools, or virtually any technology purchase. If a business team needed a new service, that service was quickly created, often with little to no documentation and no integration with other services or existing infrastructure. Services and applications grew in number as individual and segregated business teams identified and instantiated IT projects out of their anticipated needs.

This unrestrained growth quickly expanded to the point where most businesses found themselves awash with hundreds or thousands of services and applications. Many of those were redundant or tangential in capabilities. Others were created only to later lose their stakeholders but still require maintenance and support. Some services during this period went wholly unused but lacked the management necessary to instruct IT to turn them off. Occurring during one of the great boom periods of the economic cycle, IT’s early days found itself with no end of work to do and a bottomless well of funding to accomplish that work.

The result was chaos.

As we all know, that period’s irrational exuberance of expansion was short-lived. Following that period, businesses like your own found probably themselves spending far too much on techno-centric projects that didn’t provide positive return. The following period found businesses reducing IT budgets, while at the same time requiring a more strict formalization of IT processes. Process frameworks like the IT Information Library (ITIL), Microsoft Operations Framework (MOF), and others became the defining documents by which IT determined how it would accomplish its required activities.

Yet with every knee-jerk reaction comes an equivalent overcompensation. By rapidly replacing IT’s early “wild west” mentality with a new approach based on strict and formalized process, many organizations took that implementation of process too far.

This process represents IT’s “first wave” as previously discussed. But what really happened during that first wave? How were those processes implemented in many organizations? As you’ll find out in a minute, the “going too far” succeeded in stopping the hemorrhaging. But it did so by stripping all the agility and a good deal of the raw creativity out of IT’s fledgling industry.

Consider as an example ITIL. Currently in version three, the operational activities defined by ITIL are documented in a series of six books. The first book discusses an introduction to the framework, with the remaining five covering each of the five stages in ITIL “IT Service Lifecycle.” Included within these five stages are no less than 24 major activities that are recognized as critical parts of an IT infrastructure. Figure 1 shows a representation of each of the five stages with their accompanying activities.

Figure 1: ITIL’s 5 stages and 24 activities.

Although each of these activities has a place in businesses everywhere, one of the defining tenets of ITIL (as well as other frameworks) is that the framework’s massive guidance should be tailored to suit the needs of the business. As a simplification, this can mean that businesses with simple needs likely won’t need every activity. Or, that individual processes within each activity needn’t necessarily be followed exactly. In effect, ITIL and frameworks like it are intended to be used as guidelines and best practices rather than established dogma.

Unfortunately, IT’s rush in many organizations to implement formalized process and process frameworks has led today to a hyper-implementation of process. ITIL itself has its history in federal government bureaucracy. Its concepts started as a project within the British government, and were in fact for a time referred to as the Government Information Technology Infrastructure Management. If you’re the type of person that dislikes the level of waste and non-optimization that can be common in government-style bureaucracies, then it becomes easy to see (and also dislike) the parallels found within IT process frameworks like ITIL.

Think for a minute about how such government bureaucracy and its parallel in the manifestation of formalized IT process creates a strain on an organization’s agility:

• Accomplishing even the smallest of tasks requires the cooperation of multiple individuals and teams, each with their own political aspirations.
• Organizations can find themselves wielding “process” as a weapon to be used against the fulfillment of service requests. At the same time, businesses (particularly large, enterprise businesses) find themselves losing agility as their requests take longer and longer to be fulfilled.
• “Process” itself can also grow to become an impenetrable shield behind which organizations hide and in front of which service requestors cannot breach.
• In the face of documented process, an individual requestor lacks sufficient organizational power to manifest change within the IT organization. As such, simple requests for servers, services, and applications become bureaucratic nightmares of justification, paperwork, and approvals.
• Often, the weight of the process itself becomes a hindrance to completing needed tasks. When needed tasks require a massive effort to make their way through the process framework, those tasks can be simply abandoned.

Consider the following real-life example of an enterprise process implementation gone horribly wrong. In this organization, its IT department, like many others, began with a simple charter to serve the technology needs of the company. That charter eventually grew to the point where IT found itself involved with virtually every part of the organization, called in to provide assistance for many projects, and providing services for numerous teams throughout the business.

This early “wild west” approach indeed had its downfalls. Some services were not properly architected prior to implementation or not well managed in the period after. These shortfalls caused unnecessary outages along with levels of service quality that were below the requirements of the company. Yet even in this situation, while service quality itself wasn’t to acceptable levels, the implementation of services themselves generally happened on schedule as required by the company.

After a series of small mistakes with big impacts, this company decided to incorporate a formalized process framework to assure service quality. It at the same time laid into place the structures to ensure that IT projects were only taken on after a lengthy deliberation, justification, and approval period. This new package of processes was laid in place over a 2-year period, with much of the time involved with gaining buy-in from both IT and the business.

At the end of the 2-year period, its implementation was complete, with the results being a marked improvement in service quality for the core services of the company. Service uptime began to improve, as did the overall quality of services that were provided to users.

However, at the same time, came a significant reduction in IT worker productivity along with a dramatic increase in time-to-completion for even the smallest of projects. Implementing such projects required documenting the project through a series of 12 “gates.” Each gate required the creation of a formal documentation package as well as a presentation to stakeholders and engineers. Moving from gate to gate typically required an approval by a Change Control Board, an Engineering Review Board, and/or IT management, the members of which were sometimes the same. Mission-critical changes with widespread implications required an additional path through a high-level Technical Exchange Board, which operated as a kind of board of certification to which plans were defended.

Once project plans were officially approved through the gating process, each individual change then required approval by the Change Control Board. This board was responsible for the individual baseline of each server, service, and application. Change Control Boards met twice per week, with Engineering Review Boards meeting one per week or less, and Technical Exchange Boards meeting only when a quorum of stakeholders could be present.

The result of this process incorporation indeed eliminated the “wild west” approach to IT operations. It did so by purposely slowing down the process. As a result, even the smallest of changes typically took weeks or months to get started.

Do you see this situation in your business today? Are you finding your business becoming more and more unable to bring needed IT services online within a schedule that meets your agility needs? While no one wants to return to the costly days before these processes were put into place, what your IT organization needs is its own “second wave.”

One of the primary failures in IT’s first wave of process formalization was in rationalizing its processes within the perspective of its accompanying business. Process frameworks like ITIL indeed brought about a much-needed formalization of IT activities, but entirely without the much-needed right-sizing to the requirements of today’s business. As a set of historically government-centric guidance, most implementations of its activities simply didn’t take into account the fundamental speed of business. Right-sizing that velocity while maintaining structure will require effort from both your IT organization as well as yourself.

 

About the Author

Greg Shields is an independent author, speaker, and IT consultant, as well as a Partner and Principal Technologist with Concentrated Technology. With 15 years in information technology, Greg has developed extensive experience in systems administration, engineering, and architecture specializing in Microsoft OS, remote application, systems management, and virtualization technologies. He is a Contributing Editor and columnist for TechNet Magazine and Redmond Magazine, and serves as the Series Editor for Realtime Publishers, the world’s leading provider of high-quality content for the IT market. Greg is a highly sought-after and top-ranked speaker for both live and recorded events, and is seen regularly at conferences like TechMentor Events, Microsoft Tech Ed, VMworld, and more. He is a multiple recipient of Microsoft “Most Valuable Professional” award.