CHAPTER 8: STANDARDIZED DEVELOPMENT
APPROACH

For those readers who have journeyed with us through the previous Seven Steps, we offer hearty congratulations! You should be proud of what you have accomplished thus far! We also recognize that some readers reside in organizations where the foundational building blocks have already been erected; so whether you skimmed through Steps One to Seven as a refresher, or skipped straight to Step Eight, we welcome you to this decisive point in the Transformation journey.

Regardless of how you got here, there is good news to be had. In many ways, the biggest obstacles (and risks) to ITSM success are behind you. Let’s quickly review what has been accomplished. In Steps One to Four, you addressed the service strategy phase of the lifecycle by documenting enterprise objectives, analyzing service financials, understanding and documenting current and future service demand, and chartering a service portfolio overseen by a representative governance body. As you entered the Service Design phase in Steps Five to Seven, you completed a high-level design by defining a target state service management ecosystem, negotiating development priorities, creating an execution plan and roadmap, and forging agreement on roles and responsibilities.

It is important to understand what has been accomplished (or, for the lucky few, what was already in place) because these service strategy and high-level design artifacts provide the foundation for everything that comes next: detailed design, transition, operations, and last, but not least, continual improvement.

Step Eight marks the beginning of detailed design. While this may come as a welcome relief to those of you more attuned to granular-level details than high-level strategy, you must also understand that complete coverage of this topic would require its own publication. In fact, it is interesting to note that the latest version of ITIL® addresses design in much greater detail than in previous versions, going so far as to add dedicated design roles and even elevating design as its own process in the framework.

Given this context, in Step Eight we will focus on the traditional ITSM discipline of process design to demonstrate how a structured enterprise approach to development helps us achieve the critical goals of standardized, repeatable and interoperable enterprise processes. In reality, each IT capability, function, service, process, etc. must go through its own mini-lifecycle of planning, design, development, transition, operation and improvement. While we recognize there are significant differences in the approach taken to designing, say, a service versus a process, we feel the lessons drawn from standardizing process design can be applied to the design of other ITSM elements.

There are many reasons to advocate using a standardized approach to process development. Above all, standardization is essential to achieving both efficiency and effectiveness. As the economist Ronald Coase demonstrated in his influential work The Nature of the Firm, Economica, 4:16 (1937), 386-405¹⁴ the very existence of a firm or organization is evidence of the desire to produce maximum results with minimum required resources. All organizations seek to be more efficient and effective, regardless of mission – this is equally true of commercial-/profit-maximizing firms, government agencies, non-profit organizations, or any variation of an organization thereof. Of course, achieving this state of nirvana is anything but assured – this is why the role of service management is so critical to an organization’s success.

In addition, there are many second-order effects of standardization that include, but are not limited to, the following. A standard approach:

•   Provides general direction and guidance for employees: a solid, yet flexible, framework within which to operate.

•   Improves communication within and between teams and, therefore, lessens the possibility of confusion and misaligned expectations.

•   Greatly reduces the learning curve and training time for new or retrained employees.

•   Enriches the consistency of the work effort across the enterprise.

•   Ensures business continuity, and aids in quickly recovering from natural or man-made disasters.

•   Allows for easier and more efficient delegation of routine tasks to lower-level employees.

To summarize, achieving process repeatability is the Holy Grail of service management. It virtually guarantees that the organization can rapidly scale (either up or down) to meet customer demand. Delivering the right amount of service with the necessary number of resources maximizes the bottom line, and promotes the overall health and well-being of the organization.

The underlying question is, and always has been: where and how should the line be drawn between enterprise-wide standards, and those standards that may be required for departmental- or geographical-specific requirements?

To satisfy customer demand, every organization must strike the optimal balance between enterprise standardization and the need to tailor individual processes to fit the unique needs of a particular business unit or wholly-owned subsidiary. A prime example of this is an international organization having branch offices in several different countries. Local rules and regulations may necessitate an exception or modification to an enterprise standard. Failure to do so may subject the organization to fines or penalties. It therefore behooves the enterprise to allow the local entity to modify existing standards, while continuing to adhere – as closely as possible – to enterprise policies, procedures and standards. This is important because enterprise efficiency and effectiveness can only be achieved through some degree of standardization. However, both measures ultimately suffer if standards are so rigid that individual business units are not able to apply the principles of a process to meet the unique needs of its customer base, or to adequately support a delivered service. Without flexibility and the authority to innovate, the business unit will inevitably resort to costly and inefficient workarounds, or, worse, will establish their own standards that may be at odds with inter-dependent processes and business controls.

The CIO is responsible for developing and enforcing a standard process framework for the enterprise. He or she should use the IT strategic plan and a tailored combination of industry best-practice frameworks to best meet the organization’s needs. When completed, it should consist of a complete set of processes, controls and metrics that support the current and future IT Service Portfolio. Using this organization-specific framework as a baseline, process design teams are then allowed the freedom to tailor lower-level process activities, tasks, work instructions and tool functionality to fit the individual customer needs, budget and operational constraints of each business unit.

For example, there must be one – and only one – enterprise process for accepting, evaluating, approving, coordinating, and closing a change, i.e. an Enterprise Change Management process. However, within each of these standard, high-level process activities, each business unit may tailor how a request for change is created and by whom, who within the business unit has the authority to review and approve it for submission, the degree to which the business unit utilizes enterprise tools and/or proprietary tools internal to its process, and the business-specific evaluation criteria and prioritization assigned to the change.

Figure 15 is a graphical representation of the four levels of process development, culminating with the integration of people, process and tools to make the process operational. On the left-hand side, the figure emphasizes the balancing act between CIO-sponsored enterprise standards (Levels I and II) and the inherent need for business unit flexibility to tailor process designs to meet their own unique customer and operational needs (Levels III and IV).

Figure 15: ITSM process development pyramid

This method and model may not be suitable for your organization, but, in situations where it is, you – as the ITSM practitioner – must work to find that optimal balance.

You may encounter resistance when first advocating that business units be granted this degree of latitude. Centralized authorities are typically reluctant to issue exceptions or modifications because they see it as the first step to total anarchy. In fact, anecdotal evidence points to the contrary. Remote branches and business units are more likely to adhere to enterprise standards when given the leeway to modify the standards to accommodate local conditions. If you encounter this situation in your organization, use the process development pyramid to foster dialogue with all relevant parties.

Figure 15 aligns to the ISO/IEC 20000 standard. It breaks the development approach into four primary categories:

1.   Policy and best practices

2.   High-level Process Design

3.   Detailed Process Design

4.   Work Instructions and Tool Integration.

The first tier

The first tier specifies – at the enterprise level – organizational policies, risk appetite, quality standards, adherence to regulatory directives, and any desired management controls the organization wishes to put into place. It mandates the parameters within which lower-level business units or subsidiary companies will operate. Although rare, some executives – perhaps unduly influenced by a consultant with a particular area of expertise to sell – will try to dictate which of the industry best-practice frameworks are used. One firm was so insistent on the use of Lean Six Sigma that its use was a major factor determining each line manager’s annual compensation. While you cannot ignore such organizational realities, the smart practitioner will fight for the right to use any tool that best fits the task at hand; in reality, this often involves combining elements from multiple frameworks.

One notable exception is where there exists an organizational mandate for ISO/IEC 20000 compliance. As an ITSM expert, you can advise the organization’s leadership on the merits and drawbacks (usually the cost) of pursuing or maintaining ISO certification. Achieving certification can be a big feather in your cap, and, if the organization can capture sufficient value from the investment, your ITSM Transformation initiative is the perfect vehicle for doing it. However, this is ultimately an executive decision that must be made in consideration of many factors – for example, whether or not the organization is already ISO9000 certified (or wishes to be). If certifying compliance is part of your ITSM mandate, then the ISO/IEC standard must be paramount; however, do keep in mind that ISO/IEC 20000 is designed to be compatible and synergistic with other frameworks – most notably ITIL®, but also CMMI®, COBIT®, Six Sigma, etc.

While on the subject of international standards, it should be noted that other ISO/IEC standards may need to be taken into account when designing your development framework. ISO/IEC 27001 (information security), ISO/IEC 38500 (IT governance), and ISO/IEC 15504 (process assessment) are three examples of prominent standards that can be factored into your development approach, with or without a mandate for ISO/IEC 20000 certification.

The second tier

The second tier of the pyramid describes what each service and process will do – not how it will be done.

Let’s use Amazon.com as an example of how this might work in the retail environment. Amazon’s CEO may direct that one of the company’s offered services be the sale and delivery of books to potential customers. (In this example, we will limit our attention to printed books. E-books will have their own unique set of activities and tasks.) Once the CEO has approved and funded this particular goal, his involvement in establishing this line of business is essentially finished. It is now up to the Service Owner (and the supporting Process Owners and line managers) to define the tactical and procedural steps necessary to meet the requirements the CEO has set out.

The third tier

The tactical and procedural steps are defined in the pyramid’s third tier. It is here that the required detailed activities and tasks are spelled out. Taking the example cited in the paragraph above a step further, the Service Owner, tasked with achieving the CEO’s mandate of offering and delivering books to customers, would outline the broad activities necessary to accomplish the goal (e.g. negotiate an arrangement with one or more publishers, design a web-based application displaying the products for sale, engage the marketing and advertising department to publicize the service offering, etc.) In project management terms, this is the beginning of the Work Breakdown Structure (WBS), which should comprise the components of the project plan directing these activities.

Once the broad activities had been defined, the Service Owner would then necessarily turn his or her attention to the various tasks comprising each defined activity. In the case of negotiating an arrangement with one or more publishers, the Service Owner would perform (or delegate) the following tasks:

•   Identify the publisher’s point of contact.

•   Arrange a meeting.

•   Specify desired outcomes.

•   Discuss logistical considerations (e.g. distribution/delivery channels).

•   Reach an agreement on costs/fees/revenue sharing.

•   Draw up the contract.

•   Execute the contract.

The Service Owner (or designee) would perform a similar exercise for each additional activity, until all tasks have been identified.

The fourth tier

The pyramid’s fourth tier – the foundational level – is where identified tasks are further decomposed into work instructions: the step-by-step procedures spelling out how operations or administrative staff will perform their day-to-day responsibilities. The work instruction documents the use of supporting tools, and should – if properly written – include tips and techniques for initial troubleshooting and incident resolution. This level of detail invests the operator with the maximum amount of authority and autonomy allowed them by senior management.

Execution: Integrated Process Development Teams

As any experienced practitioner or consultant will tell you, much of your ITSM success (or lack thereof) ultimately comes down to execution. Flawless execution by a high- performance team of experts can make even a mediocre plan look brilliant in hindsight; likewise, poor or uncoordinated execution can quickly render the best-laid plans useless.

At the end of this chapter, we describe a standardized process development methodology (PDLC) that has worked well for us in multiple client engagements. Chapters 9-14 further lay out the details of each phase. You may opt to tailor this approach to fit your organizational environment, or you may choose to use a different approach entirely. In your role as “ITSM General,” the development methodology serves as your battle plan. It is your tactical, step-by-step guide to achieving the desired result of standardized, repeatable and interoperable enterprise processes.

But, as any general knows, a battle plan – while essential – is often not enough. A general can only oversee activities; he or she cannot engage in every battle. As the ITSM General, you’ll require trusted commanders who can quickly adjust to changing battlefield conditions. Forces skilled at conducting battle by land, air, and sea must be at your disposal. You’ll require intelligence and tactical weapons experts, and, most importantly, in order to ensure an adequate supply of personnel and munitions, you’ll need a secure and reliable supply chain. Above all, you’ll need a command and control center to monitor conditions on the ground – one that provides you with real-time data and intelligence for rendering required decisions. All of these disparate “force elements” must be trained to understand their roles, and act as an integrated fighting force.

While we realize the battlefield analogy may seem a bit extreme, we have also seen the failure to adopt a solid process development methodology “kill” many ITSM initiatives dead in its tracks. We’ve witnessed this first-hand, and have no desire to see your organization suffer the same fate. Process development is arduous, it is costly, and it is inherently political. Imagine being in the heat of a battle, ready to charge and take a hill, only to turn around and find that your key allies have defected to the other side. Sadly, we have seen this happen, as well. Process development not only requires significant investment in time, money and organizational resources, but, at the end of the day, it dictates how people do their jobs and how power (however you define it) is distributed throughout the enterprise.

For all of these reasons, we highly recommend taking the time to think through how to best structure and staff your process development effort. A seasoned general doesn’t develop a battle plan overnight – and neither should you. After much trial and error, we have found that an integrated team approach, with strong coordination and oversight from a central authority, works best. This is especially true in larger enterprises with multiple independent business units. Figure 16, below, depicts what an integrated process development team structure might look like for our fictional insurance company.

Figure 16: Integrated process development teams

Let’s begin by looking at the individual team structure highlighted in the blue box (at the bottom of the diagram). In our approach, each process that is to be developed (e.g. service catalog management, change management, incident management, etc.) is assigned to a single development team. An individual resource may be assigned to more than one team, but it is imperative that each team be accountable and responsible for one – and only one –process at a time. The design team is staffed with at least one process design subject matter expert (SME) and at least one representative from each of the business units that, at the time, are either significant actors in the process, or a customer of the process. Each team is headed by a Design Team Lead, who is solely accountable for process development results. The design team lead also has a dotted-line relationship to the project manager for the project under which the process development/improvement effort falls.

Moving upward in the diagram, note that each development team has a solid reporting line into the central governing authority, represented in the gray shaded box (at the center of the diagram). In this example, we assume our fictional insurance company has established a Service Management Office (SMO) that is well-suited for this role. Your organization may not elect to establish a separate Service Management Office at this time. They may wish to wait until the service management culture in the organization has matured a bit.

Of course, the ITSM Steering Committee we chartered in Step Four is also ideally constituted to fill this role, authorized by its strong executive mandate and staffed with cross-organizational representation. Whatever form it takes, this body is charged with establishing and enforcing the enterprise standards to be used by all development teams, as well as adjudicating disputes as they arise. It also serves as the governing and approval authority for all development work, wielding veto authority over any design that does not align with the best interest of the enterprise. Before moving on, we must note that some organizations attempt to use their existing Project Management Office (PMO) to fill this important role. In our opinion, this is a grave mistake, unless the PMO is chartered with similar structure and authority as the ITSM Steering Committee discussed in Step Four.

The third and final dimension of our model is an integrated development team that is sponsored and resides within each strategic business unit – shown by the circular dotted-line arrows. This is not to be confused with the dedicated development teams assigned to each process. Rather, this team provides resources to participate in process development, and advises on business unit requirements that have to be factored into the design. The integrated team lead is often the same business unit liaison that participates as a member of design teams, and is responsible for reporting back to business unit leadership with any issues that arise. A crucial role in the integrated team is that of the tools subject matter expert, who is responsible for working with all functional constituents within the business unit to ensure that functional and technical tool requirements are factored into process design. The integrated development teams are essential for ensuring that processes are designed to be interoperable across the enterprise. Ultimately, it is the business units that will suffer if there are missed interfaces or dropped hand-offs that occur between any of the critical processes, such as between Change Management and Release and Deployment Management.

Is this a perfect development model, guaranteed to win you success on the battlefield? Will multiple independent business units, each with their own profit and loss issues, always work nicely together and agree on critical design issues? Unfortunately, the answer is no – but we believe our model is better than any of the alternatives we have tried. In this respect, we are reminded of Winston Churchill’s famous dictum: “Democracy is the worst form of government, except for all those other forms that have been tried from time to time.”

Tools

Up to this point in our Ten-Step approach, we have deliberately avoided any detailed discussion of tools. This is not an oversight; rather, we feel it is important to be agnostic about tools while defining what the business needs, and how to structure IT to deliver those needs. We strongly believe that tooling considerations, like costs and resources, are best cast aside when discussing the “art of the possible.” The business does not care what tools we use, any more than we care about the brand of carburetor under the hood in our vehicles, and neither should IT, up to this point in our ITSM transformation journey.

Are we saying that engine components, pricing and functionality do not matter? No, not at all. These become important inputs and constraints in the design, manufacture and marketing of an automobile. Indeed, IT relies heavily on automation to perform almost every activity and task that it does. The larger and more complex the organization, the more critical tool automation becomes. Customer-facing tools are especially important in creating or enhancing service value, as they act as a virtual extension of IT itself. Tool capabilities are an integral part of how we operate processes and deliver services. We simply advocate that tool capabilities be factored into “how” we design processes and services, and not the decision of “what” processes or services we deliver or prioritize for improvement.

That being said, Step Eight now requires that we consider the impact and role of tools in detailed process development (Levels III and IV). Here, we find not a sober, considered debate on the merits; on the contrary, we consistently find most practitioners aligned to one of two extreme camps. The “process purist camp” ardently believes that process design is paramount, and processes should be completely designed before considering how they will be automated. In this view, tool capabilities are treated as a constant, as in an algebraic equation. Alternatively, the “tool nirvana” camp believes that modern tool suites have advanced to such a state that processes can literally be deployed “out of the box,” with perhaps only minor tweaking to accommodate special requirements. Why devote precious time and resources developing processes, when they can simply be purchased “off the shelf”?

The intensity and passion on both sides of this debate almost reminds us of a pre-Renaissance religious schism. We typically find both sides to be skillful and passionate orators, with either party more than willing to twist the laws of evidence and logic to buttress their positions. Now, we make no claims one way or the other regarding the mysteries of faith and religion. However, within the realm of practical ITSM, we believe such extreme positions present the logical error of a false dichotomy; neither camp is completely right or completely wrong – the truth lies somewhere in the middle.

In our collective experience working with clients for more than 30 years, we find that process and tools must go hand-in-hand. When it comes to detailed development, it makes no more sense to divorce process design from the tools that will support it, than it does to assume “out of the box” processes can meet the majority of our organization’s needs. Both are false propositions, and highly dangerous. However, we are also sober enough to recognize there is truth in the claims of both camps. Process does, and always should, drive tool requirements – this is the proper order of things. However, it is also true that the capabilities of major ITSM tool offerings have progressed by leaps and bounds over the last five to ten years. It no longer makes sense to design processes and “pick a tool” at the end; it is much better to design processes with specific tool capabilities in mind, and begin functional integration testing as early as possible.

As you will see in the sections that follow, nothing replaces the hard work of defining the specific functional and technical tool requirements required to automate and support the process. Tool requirements not only feed design decisions, but become part of the formal process documentation that supports continual improvement activities. However, we do advise clients to research and evaluate tool options early in the Transformation process (e.g. Step Five: Define the Ideal Target State), and to at least know the broad tool capabilities that will be available prior to commencing detailed process design. If the organization has decided to purchase a tool suite, it makes sense to purchase licenses now, in order to conduct functional integration testing as procedures and work instructions are developed.

For the purpose of this book, we will remain agnostic with regard to tool vendors, and refrain from opining on the relative merits or demerits of any specific tool offering. We can say with confidence that most of our clients have a strong and growing preference for tools that can be provisioned via the Cloud as Software-as-a-Service (SaaS). Some tool offerings are even expanding beyond the range of traditional ITSM capabilities, to the point of resembling a Platform-as-a-Service (PaaS) offering. To site just one example, the CEO of ServiceNow described his company’s offering at the recent VMworld 2012 Conference as follows: “Organizations deploy our service to create a single system of record for enterprise IT, lower operational costs and enhance efficiency.”

Many resources are available – both public and proprietary – that can be used to research ITSM tool vendors, tool suites, and even point solutions – such as a service catalog, a stand-alone CMDB, event monitoring software, and other items of this nature. Probably the most well-known and respected independent source is the Gartner Group – specifically, the Gartner IT service support management (ITSSM) magic quadrant. The magic quadrant ranks the top ITSM tool vendors according to two key criteria: a) the ability to execute, and b) the completeness of vision.

This combined ranking results in each vendor being placed into one of four quadrants: niche players, visionaries, challengers, or leaders. In the most recent ITSSM magic quadrant, released August 2012¹⁵, two vendors were ranked as “challengers,” while the remaining nine were all ranked as “niche players.” While Gartner identified unique strengths and weaknesses of each vendor, the magic quadrant indicates that, overall, there is not much differentiation between ITSM tool vendors, with the most significant differentiator being the ability to execute. With all of that being said, let’s return to our standardized process development discussion.

In our Ten-Step approach, we’ve already addressed Levels I and II of the development pyramid. Here in Step Eight, we turn our attention to Levels III and IV, which provides guidance on the development of the detailed designs for the processes identified in your unique version of the IT Ecosystem.

Process Development Lifecycle

One of the primary reasons why the systems development lifecycle (SDLC) is so widely used throughout information technology is because it offers a structured way of creating or altering information systems, and the models that people use to develop them. The traditional waterfall approach, which was popular several years ago, has been replaced by a more proactive and nimble methodology, but the basic structure of the SDLC remains intact. This is why we have modified the SDLC framework and applied it to the application of designing structured, repeatable processes. Granted, designing processes differs from designing automated software. Yet, there are enough similarities to allow for the best aspects of the SDLC model to be customized for our use. Every step in our Process Development Lifecycle (PDLC) will produce a reviewable result. This is necessary in order to substantiate completion and assure a quality product is produced.

The Systems Development Lifecycle (or, in this case, the Process Development Lifecycle) has a fair number of critics. They cite its slow development time, its increased cost, and lack of user input. We are aware, and generally supportive of, the movement to adopt “agile” practices developed by the software community, and incorporate these activities into ITSM. As practitioners, we cannot afford the luxury of being purists with regard to any particular philosophy, creed or method – we must remain agnostic. Any method that offers a better, faster and cheaper way to produce results is fine by us, provided that quality is not sacrificed. The following table, summarizing the most widely quoted strengths and weakness of SDLC comes from work published in the 2006 book, Management information systems: solving business problems with information technology, Post G and Anderson D L, Irwain/McGraw-Hill (2000).

Strengths	Weaknesses
Control	Increased development time
Can monitor large projects	Increased development cost
Detailed steps	Systems must be defined up front
Can evaluate costs and completion targets	Rigidity
Complete and accurate documentation	Hard to estimate cost, risk of project overruns
Well-defined user input	User input is sometimes limited
Ease of maintenance
Development and design standards are well-defined
Tolerates changes in MIS staffing

Table 1: SDLC strengths and weaknesses

We would like to suggest that the PDLC has all of the SDLC’s known strengths, and minimizes its most prominent weaknesses. Increased development time and cost has been brought under control through careful planning and scope management. Creation of the logical model fosters flexibility – it does not hinder it. Continual validation of assumptions and constraints has allowed us to refine our cost estimates to the point where our variances should be statistically insignificant. User input, feedback and oversight has been a constant theme through every step of the approach.

1.   The step-by-step process ensures no element (essential, or otherwise) is overlooked.

2.   Periodic checkpoints ensure progress is tracking toward intended goals.

3.   The required validation scenarios force interdependent processes to define and agree upon required hand-offs.

4.   The overarching Quality Management System (QMS) can be defined once and used multiple times.

5.   Architectural standards (if and when applied) are easily integrated into the methodology’s lifecycle.

6.   It is easy to learn, to understand and to use.

The major benefit of this methodology is its flexibility. Should the organization wish to omit certain components of a particular phase of the lifecycle (such as defining the organization and personnel), it may do so without affecting the overall PDLC. This lifecycle gives you as much or as little detail as your organization requires. In addition, the development framework is clear, concise, simple and relevant. It was designed not as an abstract construct, but as a tool to use in the real world of process design and capability implementation.

We have created templates for each activity and deliverable in the PDLC. This makes creating and gathering documentation easier to do, and enforces established standards. Also, it acts as input to the future knowledge repository. As leadership and staff become familiar with the look and feel of the PDLC and its artifacts, communication across teams will improve because they will all speak the same language. Agreeing upon and using a standard vernacular eliminates the “Tower of Babel” syndrome so often encountered in improvement initiatives of this sort.

The ultimate goal of detailed design is to iteratively and incrementally build a definitive library of approved processes and service management artifacts that is unique to your organization. ITIL® and other resources (including this book), can help guide you through the design and development process; however, nothing can replace the hard work of actually doing it. Here’s a helpful hint based on hard-won experience: copying process models out of a book, or replicating another organization’s service catalog, simply won’t work. Consider your ITSM journey a lot like having children: children are best planned in advance; they cannot be “bought” off the shelf or “borrowed;” they always involve hard work; and each one is totally unique. Despite this, in the end, the journey is worth it.

Creating standardized templates will help immensely in building your library. Note that what we are describing here is not the same thing as your organizational knowledge base (KB) or service knowledge management system (SKMS), which is much broader in scope. We are not talking about knowledge articles, incident and change records, or known errors, as important as these may be. Nor are we advocating a “physical” library of large binders stuffed with Microsoft® Word® documents and Microsoft® Visio® diagrams; this isn’t the 1970s, and we don’t use punch cards or card catalogs anymore. Even the most budget-constrained organization is much better served by the efficiency, search functions and information security provided by a BPM tool, or, at the very least, a content management system (CMS) or Wiki.

So, what precisely are the artifacts you should be adding to your library? As with most ITSM questions, the answer is “it depends.” If you have journeyed with us this far, you should have a pretty good idea of what some of those factors are, and what the appetite of your organization – and business sponsor – is likely to be. Entire books have been written on the subject of process development, and many of the most important artifacts are explicitly mentioned (or assumed) in the chapters that follow. Nevertheless, we recommend using the following checklist to ensure your library contains all of the information your organization requires to build and manage its target state ITSM environment:

•   Service artifacts:

   Service charters (customer profiles, service demand, service financials)

   Service design packages (service level requirements, utility, warranty)

   Service- and operational-level agreements (SLAs/OLAs)

   Partner and third-party supplier agreements (underpinning contracts).

•   Process artifacts:

   Process current state (maturity assessment, measurement baseline)

   Process target state (high-level design, key goals and objectives)

   Process model (detailed activities, tasks, inputs, outputs, data, interfaces)

   Process policies, instructions, and guidance (“rules of the game”)

   Process governance and controls (auditing and compliance)

   Process metrics (critical success factors and key performance indicators)

   Process roles and responsibilities (task-level RACI including all required analyst, operator, and support roles)

   Process standard operating procedures (SOPs) and work instructions (WIs)

   Process tool automation requirements (functional and technical)

   Process validation (integration exercises, use cases)

   Process transition plan (facilities, logistics, systems, training)

   Process performance management/quality plan (monitoring, measuring, and reporting).

Note that a key deliverable coming out of physical design is a working transition plan for moving the new capability into the production environment. This gives you time to train personnel (if required) and alert the Test, Change, Configuration and Release & Deployment teams that their assistance will be required.

All things considered, the use of a standard methodology streamlines process, service and capability development, ensures deliverable review and approval at critical junctures, enforces quality and document standards, and creates a common lexicon. If your organization doesn’t already use a standard methodology, it is highly recommended that one be adopted with all deliberate speed.

14 http://en.wikipedia.org/wiki/The_Nature_of_the_Firm.

15 http://www.gartner.com/technology/reprints.do?id=1-1BS56X7&ct=120821&st=sb.