CHAPTER 12: CONDUCT SERVICE AND PROCESS HEALTH ASSESSMENT

Now that the required capabilities have been agreed upon, prioritized, developed and tested, it’s time to begin the process of migrating them into the production environment. As we prepare to do so, we move out of Service Design and into Service Transition.

This phase of the Lifecycle is – in our collective opinion – the most fraught with peril, and presents the greatest overall risk to success. We have witnessed countless incidents where “there’s many a slip ‘twixt the cup and the lip.”¹⁷ At this key juncture in your project, you want to maximize your chances of success, while minimizing the opportunity of things going awry.

Putting capabilities into operations requires carefully orchestrating the transition of new or modified services (and supporting processes) into the live environment. This is always a dicey proposition, regardless of the conductor’s experience and skill level. No matter how comprehensive and rigorous your Transition Planning and Support, and Service Validation and Testing processes, and no matter how closely your test environment mirrors production, the live environment always manages to throw a few surprises into the mix.

By this point in the Ten-Step approach, a lot of hard work has been accomplished. Milestones have been reached, deliverables have been produced, and deadlines have been met. The ITSM Steering Committee and other stakeholders have participated in the Administrative Review Sessions. Questions and concerns raised during these exercises were remediated to everyone’s satisfaction. The “I’s have been dotted, and the “T”s crossed. For the process designers, and other staff assigned to this project, the end of their long journey is within sight. There is finally light at the end of the tunnel.

Many project teams experience a let-down at this point. It’s a common occurrence. Having worked so hard and long on the project, the team pauses to take a collective breath, before pressing on to the finish. If management – either you or someone more senior in the hierarchy – doesn’t take this into account, and order a brief pause, mistakes will be made. Being this close to the finish line is going to generate both excitement and trepidation. Take advantage of this natural pause to ask yourself (and your team) some critical questions:

•   “Have we planned for appropriate capacity and resources to deploy this solution?”

•   “Does the deployment plan ensure the integrity of the assets being deployed?”

•   “Have we accounted for every detail?”

•   “Are all of our risks identified and remediated to the greatest degree possible?”

•   “Did we consult absolutely everyone we needed to?”

•   “Are we sure our partners (internal and external) will deliver on time?”

•   “Are our communication plans sufficient to enable the end-users and business partners to align their activities with our own?”

•   “Are the staff properly trained, and ready to assume their new responsibilities?”

•   “Have our customers been properly notified of the upcoming service offering?”

The sample questions cited above are but a few of the thousand-and-one questions that will (or should) fly through your head at this point. You and the organization have a lot riding on this project, and it’s natural for all involved to be anxious and slightly on edge at this point. It’s natural for nerves to take over before launching a new initiative.

So, how does one combat this syndrome? You don’t want to slow momentum, yet neither do you want the project team to commit unforced errors due to weariness, time pressure or general anxiety. How do you give the team a chance to gather itself – to buy a little breathing space – without making it appear that you’re bringing the work effort to a temporary standstill?

In conjunction with the normal Service Transition Planning and Support activities, we advocate conducting a Service and Process Health Assessment at this juncture. The period between the finalization of the design efforts and the execution of the release and deployment phase is the perfect opportunity to make one final pass through your checklist.

Step Nine of our Ten-Step approach is a Service and Process Health Assessment. This simple tool provides a structured method to ensure all items have been seen to, while simultaneously giving the project team a chance to clear its collective head, in preparation for the next big push.

The Service and Process Health Assessment consist of eight major categories. Each category includes a list of pertinent questions designed to qualitatively assess relative health. The categories are logically ordered as follows:

•   Process Goals and Objectives

•   Process Ownership

•   Process Repeatability

•   Roles and Responsibilities

•   Policy, Plan and Procedures

•   Process Performance Improvement

•   Operational Solutions Planning

•   Knowledge Transfer and Documentation.

Many ITSM experts advocate assessing process maturity – either at the beginning of your improvement cycle, or immediately after implementation. This is the baseline, against which future progress will be measured. This is excellent advice and shouldn’t be discounted, but, in our opinion, many of the experts have missed an important intermediate step: assessing process health. This is not the same as assessing maturity. Used in conjunction with the development lifecycle (PDLC) presented in the previous step, the health assessment is a series of questions to be asked and actions to be taken that help ensure full accountability and responsibility from inception through to continual improvement.

It may be impractical for you or your organization to do so, but we suggest having the Service and Process Health Assessment conducted by an independent, objective third party. We advocate this for the following reasons.

1.   A fresh set of eyes will often catch items overlooked by persons actually involved in executing the task.

2.   It gives the team a chance to work on ancillary – but equally important – duties (e.g. completing documentation).

3.   It lends the assessment an aura of professional credibility (especially if evaluated by an external or internal auditing team).

4.   Discovered gaps can be addressed in priority order, instead of being tackled in an ad hoc fashion.

If review and evaluation by an auditing team isn’t possible (due to limitations in either timing or funding), then engage one or more members of the ITSM Steering Committee in conducting the Service and Process Health Assessment on your behalf. It bears repeating that this type of detailed engagement with the business unit leaders will build camaraderie and support for your efforts.

Let’s examine each category.

Process Goals and Objectives

Processes exist to support the efficient and effective delivery of services to the business customer and end-user. They do not exist in and of themselves. Therefore, it makes sense that process goals and objectives link back to one or more of IT’s strategic or tactical goals. (You will recall that, in a previous step, we linked the IT goals to one or more organizational goals.)

Questions to be asked include, but are not limited to, the following:

•   Does each process have specific, measurable, attainable, realistic and timely (S.M.A.R.T.¹⁸) goals and objectives established?

•   Are those goals directly linked to the organization’s strategic or tactical goals?

•   Do the established process goals fall within established risk parameters?

•   Is every staff member aware of the process goals?

•   Are incentives and staff compensation tied to the successful execution of the articulated goals and objectives?

•   Are the goals and objectives periodically reviewed and refreshed?

There are three high-level activities common to all processes. They are:

1.   Define and develop the process framework.

2.   Monitor, manage and report process performance.

3.   Evaluate the process’s efficiency and efficacy.

The first common activity – defining and developing the overall process framework – ensures that the purpose, scope, goals and capabilities for each process have been defined. Included in this activity are tasks such as defining the process’s policies, its standard operating procedures, and its relationship to other processes and external entities. As noted in previous phases of the Ten-Step approach, this activity also encompasses key activities such as assigning process roles and responsibilities, defining measures and controls, and documenting data requirements (frequency, timing and format).

The second common activity – monitoring, managing and reporting – focuses on the day-to-day operational performance of the process. Its activities include generating and analyzing reports based on the metrics deemed most important to the business, and then analyzing those reports to identify problems and areas where improvements may be made.

The last common activity – process evaluation – takes a macro analytical approach. Rather than focusing on the day-to-day performance of the process, the Process Owner assesses how well the process is performing in relation to established enterprise benchmarks. Is it fit for its purpose? Does it meet its quality and warranty standards? Is it as efficient or cost-effective as it could be? Are there any broken interfaces or dropped hand-offs with other processes? Do personnel require additional training?

As stated, all processes will have these three activities in common. Therefore, the Service and Process Health Assessment should ensure that the tasks associated with these activities have been properly executed.

Process Ownership

As highlighted in previous chapters, it is absolutely critical that each process have an owner who is ultimately accountable for the process’s success or failure. Ambiguous process ownership jeopardizes the entire improvement initiative. In the absence of an owner who is accountable, process policies and standards may not be followed, performance criteria may not be met, and service delivery may be impaired.

Questions to be asked include, but are not limited to, the following:

•   Has a single individual been assigned accountability for each process?

•   Has this owner’s role and responsibilities been clearly defined?

•   Is the process owner’s role and its associated responsibilities part of the owner’s internal job description?

•   Are the Process Owners’ incentives and compensation tied to the successful execution of the process’s purpose and intent?

•   Has the owner been provided with sufficient authority to execute his or her duties and responsibilities?

•   Has an operational budget sufficient to ensure full production support been allocated to the owner? If not, is there a mechanism by which the owner may request required or additional resources?

Process Repeatability

A successful process is one that has repeatability at its core. Every one of the process’s attributes (most notably its performance metrics) relies on the process being repeatable. Without repeatability, future performance comparisons cannot be made, and, as a consequence, improvements cannot be defined or implemented. Repeatability is the Gold Standard to which every process should aspire.

Questions to be asked include, but are not limited to, the following:

•   Is process repeatability a management objective? If not, there is the possibility of excessive cost due to variability within the process activities and tasks.

•   Are operational, high-risk processes (e.g. Availability and Capacity Management) periodically reviewed and assessed to ensure they are fit for purpose?

•   Is each process designed so that it can be scaled to accommodate future growth, and flexible enough to adjust for minor variations and unexpected circumstances?

•   Are staff adhering to established procedures; or are workarounds used to circumvent the system?

Lean Six Sigma (LSS) practitioners are well-suited for assessing and making recommendations to improve process repeatability. LSS is a focused and agile method for identifying and eliminating sources of variation, as well as waste. An experienced green belt or black belt practitioner does not only help improve repeatability, but increases process efficiency as well. If you have access to skilled LSS resources in your organization, we highly recommend that you utilize them.

Roles and Responsibilities

We have already detailed the importance of assigning clear, unambiguous roles and responsibilities throughout the organization. This assignment is even more crucial when it comes to service and process ownership and responsibility. As the custodians and guardians of the services to be delivered and the processes that support them, the Service and Process Owners play a key part in the organization’s ability to achieve its strategic goals. Without clearly understood and agreed-upon roles and responsibilities, the entire service implementation will fail.

Using the top-level enterprise RACI developed in Step Seven as a starting point, development teams have created a detailed task-level RACI for each process as part of the development work that has been conducted. Every RACI we have ever built has relied, at least in part, on making assumptions and negotiating areas of disagreement. Now is the time to validate the correctness of those assumptions and one’s negotiating prowess.

Questions to be asked include, but are not limited to, the following:

•   In addition to the Service and Process owner, have staff roles and responsibilities been clearly defined – including all analyst, operator and support roles?

•   Are staff activities, tasks and deliverables clearly defined, understood and accepted?

•   Have all service and process inputs and outputs been documented, along with all known dependencies, timing and frequency limitations or exceptions?

•   Are supporting policies, procedures and guidance in place for swift resolution to frequently occurring situations?

•   Has a clearly defined escalation process been defined?

Policy, Plans and Procedures

Policies, plans and procedures are part and parcel of the first of the three common activities. For every process, the Process Owner is responsible for defining the policies that define and control how process activities will be executed. These policies must conform to both regulatory and organizational dictates and standards. In those cases where policies are in conflict with one another, the suggested hierarchy is regulatory, then organizational, followed, lastly, by process-specific policies.

Plans are internal to the process itself. Note that this activity differs from project planning. Process plans include items such as how personnel will be trained, how the process will interact with other dependent processes, and what metrics will be captured (and how) to allow for future improvement analysis. The process plan is another way of ensuring that the process’s goals and objectives will be successfully realized.

Procedures are the detailed work instructions drafted during each process to guide staff in the execution of their daily activities and tasks. Each Process Owner will define and determine the work instructions most applicable to his or her process, but, in general, the work instructions must be detailed enough for staff to follow, and to account for unexpected deviations. The ideal work instruction should contain detailed step-by-step procedures, with a graphic displaying the expected flow of information through the procedure, and an addendum containing directives on how to handle major and minor exceptions.

Work instructions come in a variety of formats. Select one best suited to your organization’s culture, and aligned to the skill and experience level of the staff that will use it.

Questions to be asked include, but are not limited to, the following:

•   Are process policies in compliance with existing regulatory and organizational rules?

•   Are process policies known and understood by all the staff? Is adherence part of the employee’s annual goals and objectives?

•   Does an annual process improvement plan exist?

•   If so, does it track progress toward tactical or strategic goals and initiatives?

•   Are process plan milestones and deliverables clearly communicated to staff, dependent process owners and external business partners?

•   Are procedures detailed enough to allow staff to execute daily responsibilities with little or no management oversight?

•   Do procedures contain instructions on how and under what circumstances exceptions are to be handled and communicated?

•   Are internal documentation ownership, retention and change control procedures understood and followed?

•   Is there a clear understanding about how the documentation will be used for training and communication?

Process Performance Management

Later on, we will discuss the Balanced Scorecard and Continual Service Improvement in detail. However, that step takes an enterprise-wide approach. The analysis conducted here as part of this Service and Process Health Assessment will provide input into the overall service improvement plans (SIPs) described in Step Ten.

Process performance management focuses on a single process at a time, and seeks to measure whether the process is performing at the level required to support the organization’s service delivery objectives. We are proactively looking for early warning signals that could indicate problems with the process, whether those problems are due to poor design, poor management or factors outside the process owner’s control. In the extreme, a poorly performing process could jeopardize the chance of meeting stipulated and agreed-upon Service Level or Operating Level Agreements (SLAs/OLAs).

Questions to be asked include, but are not limited to, the following:

•   Are metrics applicable to achieving business goals identified and agreed upon by the business units?

•   Do management practices allow the Process Owner with high-level insight into the day-to-day operations (outcomes and performance) with limited effort?

•   Have Critical Success Factors (CSFs) and Key Performance Indicators (KPIs) been established?

•   If so, are they fit for purpose?

•   If not, why not? Is senior leadership aware this gap exists?

•   Is there an established schedule for reviewing captured metrics and taking remedial action when necessary?

Operational Solutions Planning

Operational solutions planning – as it may be surmised – revolves around the activities necessary to ensure a smooth and seamless hand-off between the development team, the release and deployment team and the operational staff responsible for the service’s operation and sustainment.

Mature organizations ensure that selected members of the development team are assigned to work alongside the operations staff for a period ranging from two to four weeks after implementation. If the new service contains special processing that occurs only periodically (say, for instance, a financial services application that must reconcile transactions monthly, quarterly or semi-annually, etc.), then development staff must also be available during the first instance of the periodic processing, to help operations quickly troubleshoot unforeseen issues that may arise.

Questions to be asked include, but are not limited to, the following:

•   Are procedures integrated across the enterprise, where necessary?

•   Is there a uniform approach to creating and distributing operational procedures?

•   Has the development staff created a set of standard troubleshooting procedures for the operational staff?

•   If troubleshooting procedures exist, are they housed in an easily accessible location that is known to all the operational staff?

•   For services that must operate 24/7, do detailed procedures exist to ensure a smooth hand-off between shifts?

Knowledge Transfer and Documentation

Transferring knowledge – to business unit managers, to end-users, and to operations and support staff – is perhaps the most critical component of the Release and Deployment Process. Attending to this detail eases users’ anxiety, ensures operations staff can support and maintain the service, and allows users to fully utilize the new or enhanced capabilities that have been introduced.

Sadly, IT professionals are notoriously negligent when it comes to training end-users how to properly utilize and maximize the advantage of their new service capabilities. Worse still, developers often spring the new capabilities on the users a day or two in advance of the service going live, leaving little time for users to become familiar with the look and feel of the new or modified service. With little advance notice, no business unit preparation, and virtually no organizational change management practices followed, what results is the birth of hostile, resistant users, who are primed to complain vociferously about every little bug or inconvenience that may arise.

As the organization’s service management champion, it’s your responsibility to ensure that end-users get the most value out of the capabilities you plan to deliver. It benefits the organization to make sure your end-users have the skills and knowledge that will allow them to effectively and efficiently use the implemented capabilities in support of their business processes. Doing so will reduce the number of calls to the Service Desk (especially during those critical first few weeks after the improvements goes live), and will result in happier, more motivated staff.

Questions to be asked include, but are not limited to, the following:

•   Is development documentation accurate and complete?

•   Has this documentation been used to prepare desktop operating guides for end-users?

•   Have business unit managers been properly prepared and trained to help staff within their departments deal with the newly introduced service?

•   Have Service Desk personnel been engaged to ensure they understand the timing of the implementation, and to alert them to the potential spike in service calls related to the implementation?

•   Is the technical documentation used by the operations staff sufficiently detailed to allow support staff to troubleshoot and correct problems?

17 Random House Dictionary of Popular Proverbs and Sayings, Titelman G, Random House Reference (March 5, 1996).

18 From Attitude Is Everything, Attitude & Motivation, 2, Meyer P J, Meyer Resource Group, Incorporated (2003).