Real-World Stories

These stories are based on my experience over recent years; only the names have been changed to protect the innocent (or to keep me out of court!).

Fun with Finance

The terms fun and finance don’t always go together, but some of my experiences have tickled my sense of the absurd.

Internal Charging

Noncommercial organizations sometimes decide that they need to introduce an internal charging policy (on top of the usual budgeting and accounting disciplines that ITIL rightly states are compulsory). The reason given for this is typically to exercise better financial management and to increase cost awareness.

My job was in one of the internal customer business units, and I was essentially the overseer of the services being provided to that business unit. It was an uncomfortable position, particularly because the boss of the business unit and the boss of the internal service provider each thought I worked for them, not for the other! They obviously hadn’t heard of my commandment, “Thou shalt have clear roles and responsibilities.”

The top finance director had decided to introduce internal charging from the start of the subsequent financial year, including presenting internal invoices and actual internal cash transfers to the internal service provider. This necessitated much preparatory negotiation (often ill-tempered) alongside the setup of appropriate bureaucratic administrative mechanisms.

On the due date the new charging system was introduced, and relationships between the service provider and the internal customer became increasingly fraught, culminating in the service provider declaring that they had got their original sums wrong and would have to increase charges across the board by 10 percent with immediate effect.

I’ll leave you to picture the scene in your imagination! The lesson, of course, is to be extremely suspicious of any plans to introduce quasi-commercial methods into noncommercial relationships. Often the cost of setting up and running the charging mechanisms outweighs any resulting savings, and the impact may be to destroy trust between the service provider and the customer—the antithesis of what ITIL is about.

I sought and found a new job, in the commercial world!

Working with the Finance Department

It is clearly crucial for an IT department to work closely and harmoniously with the finance department. To do that, IT service management professionals need to appreciate the imperatives and concerns of those in the finance department.

•  Access to financial systems such as Oracle Finance needs to be controlled carefully. The owners of the IT Security Management and Access Management processes need to work closely with the head of finance to promulgate policies and to manage adherence to them. HR should also be involved to ensure that job descriptions include specific responsibilities and that appropriate disciplinary mechanisms are in place to back up the policies. I chaired monthly meetings between the outsourced Oracle Finance service provider, the outsourced IT service desk provider, the internal finance department, and the IT department process owners.

•  The finance department has to monitor expenditure against budget, looking particularly at the individual cost centers. Unfortunately, the official cost centers rarely seem to align neatly with the IT department’s various areas of cost, and some finance people also like to see revenue expenditure smoothed throughout the financial year. Within the IT department I created my own subordinate codes within the official ones to monitor at the level of detail I required while maintaining my ability to double-check the finance department’s outturn figures. Fortunately, we had good configuration management, and our records were more up to date than those of the finance department. I also explained patiently that where we had just a single cost center that covered just one service and for which we were billed annually, it was not possible for me to “smooth” expenditure over the whole year!

Beware Apollo, the Project Manager

Project managers need to be strong personalities but should temper their drive and determination with a coherent appreciation of the service management lifecycle within which their project is running—whether they like that or not.

A new warehouse management system (WMS) was going to be introduced using technology that promised to provide improved efficiency and safety in warehouse operations. I was pleased to see that, unlike many other projects with which I had been previously involved, post-rollout support and subsequent development of the new system had been included in the scope of the project.

However, the project had not ascertained the existing support arrangements beyond establishing that a centralized IT service desk existed. The project then assumed that the service desk could be left to work out itself how to take on support of the WMS, although the project did realize that some form of early life support would be needed. The support manager made regular efforts to get the project manager to provide full details regarding such aspects as how the WMS was to be supported; what additional service desk resources would be required; the provision of incident, problem, change, and release models; and configuration information. All that was received in reply was a querulous response that made it clear the project manager considered that these arrangements were the support manager’s responsibility. The support manager protested that this approach was unrealistic but was ignored not only by the project manager but also by the IT director who seemed more interested in the technical matters. To the surprise of no one in the support organization, the rollout and subsequent support efforts were disorganized, fractious, and unpredictable, and they caused significant stress on support staff who were trying to do their best despite having received no training and only a grudging amount of early life support.

That unsatisfactory experience demonstrates the crucial need for projects to run within the control of the service lifecycle, thereby ensuring that adequate financial resources are agreed on in Service Strategy, that a Design Coordination process oversees the design work and checks that a comprehensive and high-quality service design package is passed to Service Transition, and that a Service Transition Planning and Support process provides assurance that building and testing covers not only the new WMS service but also all the necessary support arrangements. This, of course, necessitates the owners of the Design Coordination process and the Transition Planning and Support process being given sufficient empowerment to discharge their responsibilities. It is crucial that when a project manager shows an inclination to use the management techniques of the Greek god Apollo, you apply service management best practices to bring the deity down to Earth and maintain proper control.

Outsourcing Occasions

When a decision is made to outsource services, the main driver is often to save money. However, I should hope that an equally important reason would be to reduce risk where the internal service provider doesn’t have the necessary skills and experience to deliver those services itself and believes it would be uneconomic to do so. But beware! When services are outsourced, while some risks may be reduced, new risks will arise because a degree of management control will have been outsourced too. Here are two cases that illustrate some of the new challenges that may appear.

Rollicking Review Meetings

I’d just taken up my new post and was looking forward to the first monthly review meeting with our outsource contractor who was providing service desk, fulfillment, and desktop support, plus server administration and management services.

Agenda Item 1   I was very encouraged. Handed out by the service delivery manager (SDM) were copies of the monthly report, spiral bound on good-quality paper, in full color and containing attractive charts—even exploded pie diagrams. “This is a really professional job,” I thought to myself.

I spent a few minutes examining this document after which I looked up and I said to the SDM that I was pleased to see that when incidents were closed, a short statement of the cause was recorded and that I presumed these statements came from a predefined list. The SDM confirmed that was so. I then asked the SDM how many statements were on this list. After much head scratching and whispered asides with colleagues, the SDM replied that it was about 1,500! I followed up by asking whether one of those statements was “miscellaneous.” The SDM then had the good grace to look embarrassed and admitted that more than 60 percent of all closed incidents were indeed being closed as “miscellaneous.” Everyone rapidly agreed that I was correct in saying that this situation was unhelpful to effective Problem Management.

I discovered that the list contained 1,500 closure statements because it was a consolidation of all the closure statements that had been agreed on with every customer of their service desk service. Therefore, I constructed my own list of closure statements (some 50 in all) and instructed the SDM that these were the only statements I now wanted used regarding my incidents. There was no “miscellaneous” option; if an analyst was unsure which particular statement should be applied, the statement “management review” would be used, and the service desk manager could then either improve the guidance to the service desk analysts or raise a change request for a new statement to be added to the list.

The next monthly meeting came round and, again, a beautifully produced report was distributed. I examined it carefully and then looked up at the SDM, sighed heavily, and remarked that what I’d wanted was my 50 statements to be used instead of, not in addition to, the existing 1,500 statements. “Ah,” the SDM replied.

Having overcome that issue, I then suggested that my own team should carry out a percentage quality check of the closure statements being selected by the service desk analysts and that we should institute a penalty points system linked to the individual’s bonus payments. If a statement had been selected that was correct, no penalty would apply. If a statement was selected that was close but not quite correct, one penalty point would be given. If the analyst had chosen a statement that, while it was on my list, was quite clearly incorrect, two penalty points would result. But, if the analyst had chosen a statement that wasn’t on my list at all, the sanction would be three penalty points.

Quickly the accuracy rate rose from little more than 60 percent to 95 percent, but, more importantly, really effective Problem Management could start.

You may be interested to see my table of approved closure statements (see Figure 8-1).

Figure 8-1   Incident closure statements—example

But whatever processes and specifications you put in place, remember that little may actually happen unless you apply good “governance” (see Chapter 1). ITIL is not a substitute for proper leadership, management, and supervision.

Agenda Item 2   “But there’s no denying,” said the SDM, “that the number of incidents coming to the service desk exceeds the maximum workload set out in the contract. We’ll have to charge you extra for the extra workload.”

I immediately adopted the “management technique of procrastination” and said I would need to examine the figures and the contract before I could agree.

The next meeting came round, and we got to Agenda Item 2 again. “You’re quite right,” I said, “the incident rate is exceeding the contractual limit, and on that basis, you can send us a bill for the extra work. However, I notice that you’re failing to meet the incident resolution targets in the contract and that, quite coincidentally, the penalty I can apply for your failure is about the same as the amount you want to charge me for the extra work. How about we work together to reduce the incident rate to below the contractual limit, thus enabling you to meet the resolution target? You won’t then be looking to charge me more money, I won’t be looking to apply contractual penalties, and, far more importantly, the users and the business will suffer less disruption and will be better supported.” It was agreed that this was a good idea!

The management of outsourcing contracts can easily become a confrontational, testosterone-fueled experience. That is usually unhelpful in the long run. It is far better to nurture a professional relationship where the contract itself rarely has to be produced for routine matters and where a real and mutually beneficial partnership operates.

Now watch out for Agenda Item 3 and Agenda Item 4 that you’ll be meeting soon!

A New and Improved Contract?

I was appointed to a small, part-time project team that was to review and make recommendations for a new outsourced contract for the service desk, desktop support, and fulfillment needs of the Type II service provider (shared service unit) with which my business unit had a Type I/Type II relationship, as one among a number of such business units (there was no service level agreement [SLA] with the Type II provider, but that’s another story!). The main reason for the change was dissatisfaction with the current contractor’s hardware support (to avoid confusion, let’s call this contractor Contractor A).

We got started with enthusiasm, applying both our experience and our ITIL knowledge (a number of us held the ITIL v2 Managers Certificate). We produced a set of detailed, objective selection criteria and held a series of meetings and presentations with potential supplier organizations (Contractor A was not considered). We followed up with further meetings and negotiations with a short list of three.

We documented our conclusions and recommendations in a comprehensive report that went to the high-level decision maker (the “great man”). Our unanimous recommendation was that Contractor B was clearly the best and should be awarded the contract.

A week or two later we were summoned to meet the “great man” who commended us on the professional and rigorous approach we had taken and on the quality of the report. In fact, he couldn’t have done better himself—except that we had not picked Contractor C, which was the contractor he wanted.

So, Contractor C was duly awarded the contract—and immediately subcontracted the hardware support to Contractor A! As a result, the users continued to receive unsatisfactory hardware support with the added drawback that now the hardware support contractor was not even under the direct management control of the provider of their customer-facing service.

The moral here is that you must be alert to the risks of unexpected and unwelcome subcontracting; it may be a good idea to include in the main contract a clause that prevents the contractor from subcontracting without your specific agreement. It may also be politically prudent and could save you a lot of effort if, before you begin such a project, you could ascertain what the “great man” wants to see as your answer!

Configuration Conundrums

Having a good Service Asset and Configuration Management (SACM) process is essential for effective and efficient service management. Here are three true stories that illustrate that reality.

What’s This Server For?

The business had been formed by the spinning off of a function that was not a core activity of the parent company. Several years later, the IT infrastructure of the new business had been disaggregated from that of the parent company (although a close relationship between the two businesses had continued).

The new business had created an effective configuration management process and a comprehensive and accurate configuration management system (CMS). The technical support manager now wanted to tidy up the infrastructure and remove any remaining equipment that had been inherited originally and that was no longer required by the new business.

Sitting in a rack in the server room was a server that was not on the CMS because it had not been procured by the new business, there was no known purpose for the server within the configuration, and there was no sign of ownership. However, the server was still powered up and connected to the data network, which was linked to the original parent company.

Options for dealing with this server ranged from “Unplug it and sling it in the garbage skip” to “We’d better check with the parent company because it’s probably theirs and disposal (in accordance with the Waste Electrical and Electronic Equipment Directive, of course) will be their responsibility.” The parent company was a little surprised by the news of this server and said they would check. The answer came back almost immediately: “Please don’t touch it—it’s the authentication server for our entire network, and it seems we’ve forgotten that it’s still on your premises!”

Further comment from me should be superfluous.

Agenda Item 3

We’re back to that meeting I covered in the section “Outsourcing Occasions,” but the subject has now moved on.

When I took over my new job, one of the first questions I asked was where to find the inventory of all the IT infrastructure components. I was told that a lot of information had been gathered for the relatively new support contract and that the original documentation should be somewhere around. It was—in a number of tea-stained manila folders that were sitting in a plastic tray under my desk. I did not have much chance to examine this potential treasure trove before the first monthly review meeting took place.

“Now, what about the configuration management service you’re supposed to be providing?” I asked innocently. “Ah, yes,” said the SDM, “I’ll bring the details to the next meeting.”

So when the next meeting came round and Agenda Item 3 was reached, the SDM handed me a floppy disk (it was a few years ago), which he told me contained the configuration management database (CMDB). I was fascinated and, after the meeting, lost no time in looking at what was on this disk. Disappointingly, it was a set of Microsoft Excel spreadsheets recording exactly what was to be found on the lists in the tea-stained manila folders under my desk.

I rapidly came to the conclusion that I would have to re-insource the configuration management service, saving money on the contract and regaining control of this essential element. It is an important consideration that whatever the level of outsourcing, a CMS is still essential to enable the business-facing service provider to perform the requisite level of service management.

Agenda Item 4

One aspect that was being done really well when I arrived was access management. My own staff operated an effective “user enrollment” system to validate and maintain user identities and access groups, although the actual enrollments were performed by the outsourced service provider under their server administration and management responsibilities.

A benefit of this clear process with associated roles and responsibilities was that the IT department’s records tended to be more up to date than those of the central HR function because when new employees arrived at a remote site, the first action there was to give them access to the services they needed to do their jobs. Of course, the other side of the coin was that remote sites tended to be dilatory in notifying the IT department when employees left. One reason for that delay was when the employee concerned had specific, unique access rights. In those circumstances, our suspicions were alert to the danger of a degree of impersonation taking place, despite clear company instructions that such impersonation would be considered a disciplinary matter.

You may recall that one of the five activities of the Configuration Management process is Validation and Audit; in this context at work I would ask the outsourced service provider to send me every morning a list of the overnight account lockouts. I would then call the manager at the remote sites listed and ask them to explain. The usual response was that the individual concerned had specific access rights and either was on leave or was working days, so when the night shift needed to carry out an activity for which no one present had the necessary permissions, they had tried to use this individual’s identity, failed, and succeeded merely in locking the account. The result was a highly embarrassed local manager, a reduction of attempted impersonations, and an increase in the reputation of IT department for its omniscience and diligence!

Nevertheless, we accepted that there was always going to be some delay in our receiving notification of departing staff from remote sites, so it was important to know the impact of this on the accuracy of our CMS. To ascertain that, whenever I visited a remote site, I would always take with me from the CMS an extract listing all the registered users and check its content with the local administrator. As a result, I knew that at any one time the number of registered users would be about 10 percent higher than the number of actual users. This was not an ideal situation, but at least we knew the facts.

This case also illustrates that for management information to be useful it does not necessarily have to be 100 percent complete and accurate, just so long as you know the level of any inaccuracies and omissions. In this context, you may recall the data-information-knowledge-wisdom (DIKW) model in Chapter 5.

It Was a Quiet Day in the Office When . . .

The IT director was away on vacation, but there was still a gentle hum of work going on when the telephone rang in the Technical Support department—it was the data center reporting that they had suffered a complete power failure! My team immediately contacted the service desk to inform them of this major incident just as the expected “incident blizzard” started to hit them.

“What’s going on?” shouted the development manager across the office. “Just finding out,” replied the technical manager, patiently.

Let me summarize the subsequent story.

The data center staff reported that they were investigating with all urgency and would keep us informed. The development manager said to the technical manager that we should invoke our contingency plan immediately to cut over to the standby data center. The technical manager said we should wait until we knew the facts because power could be restored quickly and all would be well. The development manager was unhappy with this approach and said that we had spent a lot of money on our contingency arrangements, including switching between data centers every three months to ensure ongoing familiarity and confidence. The technical manager agreed that the arrangements were sound and well-practiced but pointed out that once we had started to cut over there was no way back and it would take four hours for the job to be completed, whereas it was quite possible that the current power problem could be resolved much more quickly. Essentially, the choice was either to initiate a guaranteed four-hour outage with some risk or to be patient for the moment and to see what happens. The argument bounced to and fro for a little while until the telephone rang again. It was the data center reporting that they had found and fixed the power fault and that all services were coming back on line nicely.

Apart from this being another example of the effective use of the management technique known as positive procrastination (or not leaping to precipitate action), this experience showed us that we needed to clarify the continuity plan invocation rules—what are the various scenarios that could occur and the guidelines to go with them, and who should be the IT director’s deputy in these matters when the IT director is not available?

Have We Got a Problem?

This was a really interesting assignment in which I was engaged. I’d already been involved in a number of service management transformation initiatives, but this particular client’s business was rather special: it was providing secure hosting for high-profile customers. To that end there was a major focus on the Event Management process that frequently (and typically) served as the trigger for Incident Management and Problem Management.

The organization was staffed by highly qualified and intelligent people (some with PhDs) with a large number of new graduates. The practical challenge was to coordinate the efforts of these individual specialists who were not innately followers of process! They presented an unusual challenge because they required both convincing philosophical arguments of why processes had to be followed and a convincing basis for the definitions used in ITIL.

Much time was spent debating the difference between an event, an incident, a problem, and a Continual Service Improvement (CSI) initiative in the context of their specific business. I enjoyed particularly a discussion regarding what we called the “wobbly fence” hypothesis—a situation where, for example, a weakness was identified in the infrastructure that was considered to be a possible future cause of failure, but it was as yet uncertain when that point of failure would be reached.

After debate it was agreed that, in theory, a problem record should be raised and all related event management warnings cross-referred to it. The problem record would appear in the known error database (KEDB), and appropriate, prioritized investigation would take place and be visible to all interested parties. The next challenge was the tendency of the brilliant but inexperienced younger staff to raise a problem in every case, thus swamping the process and tending to obscure the “real” incidents and problems.

My suggested approach was that the authority to raise a formal problem (or an incident) should be restricted to a group of experienced managers so that when a more junior member felt that an incident or a problem needed to be raised, they would submit a request (a type of service request) to the appropriate member of that group. At the time of submission, the originator would prioritize it to ensure it received prompt attention when needed. The decision maker would then decide to either raise a problem, raise an incident, or raise a record for the CSI register; or the decision maker could take the originator quietly to one side to review the actual necessity for any action including reviewing the priority the request was given! Here, of course, the decision maker was playing a useful continual service improvement role in the education and guidance of staff.

This is also a good example of the well-known ITIL maxim of “adopt and adapt” in action. If you’ve adopted and introduced an effective Request Fulfillment process, why not adapt it for any useful purpose.

Common Challenges

In this section I’ll cover four particular areas where managers are often too involved in the details of trying to keep the business supported to have time to see a broader picture.

“IT Is Just More Overhead”

Business executives’ main focus is on the performance of the business and ensuring that finances are kept under control. They don’t always have an understanding of the importance of IT service management (although it would be hugely advantageous if they did!).

As a consequence, there is a risk of IT, and IT service management (ITSM) in particular, being viewed as an inescapable overhead cost rather than a strategic asset, which this book has shown that it is. For the good of the business concerned, it is crucial that ITSM professionals recognize that decision makers may well have this view and that they will make decisions, particularly about outsourcing, based on an excessively narrow perspective. To counter that misconception, ITSM must ensure that these decision makers receive and understand appropriate reports showing how the delivery of IT services adds value to the business and how cost effective is the management of the infrastructure and support of the users. Continual Service Improvement is the key to this, and the head of IT should ensure that the role of CSI Manager is undertaken by someone with the appropriate skill, resources, and empowerment to make this happen.

Does the IT Director Have to Make Business Decisions?

Another unfortunate consequence of IT being viewed as overhead, or as being just another cost center, can occur when the finance director decides that budgets must be cut. That decision may be fair enough in itself, and IT directors should expect to have to play their part by making cost savings in areas under their direct control. However, the lion’s share of the costs in IT are related to the services that IT provides to its customers. If the IT director makes cuts to the funding of those services, such cuts will inevitably have an impact on the business. After all, for whom are those services being provided? If the service lifecycle is being managed properly, any unnecessary services or services where demand had reduced would have already had their resources disposed of or redeployed.

Therefore, the challenge from the finance director to cut costs should go primarily to the customers of the IT services and should require them to consult with the IT director to determine what options there are regarding changes to business processes and to determine their impact in budgetary terms both for the business area concerned and for the cost of the supporting IT services. This may well require a loosening of SLA targets and a reduction in service hours; such changes are those for which the business must accept primary responsibility, not for the IT director to impose.

I Need to Get Started Now—Today!

There’s usually a lot to do to improve services, and in the next section I’ll be providing some guidance on a straightforward yet structured approach that I’ve used, but here’s an example of the initiative I took to get things started.

The situation was that, while there was some contractual and SLA-like documentation around, the documentation was far from comprehensive, it was often not followed by the practitioners, and many processes and procedures were undocumented. The area where I felt some basic improvement would be most fruitful was with the main outsourced contractor. We were yet to enjoy mature incident and problem management, and unsatisfactory support situations were constantly arising. After some discussion, the following Quality Issues Log (QIL) procedure was introduced.

As the customer’s representative, I was empowered to raise an auditable observation whenever I perceived something unsatisfactory occurring regarding the service being delivered. The observation would be recorded and passed to the contractor’s service delivery manager who would investigate and would place the QIL in one of three categories.

•  Category 1   There was a relevant process in place, but it wasn’t followed.

•  Category 2   There was a relevant process in place, but it was inadequate.

•  Category 3   There was no process in place.

We would then discuss and agree on the appropriate action for each category, as follows:

•  Category 1   The relevant managers and supervisors would ensure that the process was followed correctly in the future.

•  Category 2   The nature of the inadequacy would need to be identified and then addressed. Appropriate action could include such aspects as review and amendment of the process or identification of the need for additional resources.

•  Category 3   Further investigation was needed to ascertain whether this was covered by the contract and, if so, to produce a process or, if not covered by the contract, to consider a contract amendment if justifiable.

Is Your Change Manager Considered Omnipotent?

The role of Change Manager is crucial. Poorly managed changes are a frequent cause of service disruption and the subsequent avoidable waste of resources, which is why it’s obviously important to have an effective and efficient Change Management process. However, the role of the Change Manager in the process is sometimes not fully understood.

Every change must be properly authorized before it can proceed to build and test and subsequently to release. Whoever constitutes that relevant authority should be specified in the request for change (RFC). Using change models can be very helpful here, and of course, for standard changes a change model should almost invariably be followed.

Whoever has the role of Change Manager should be the manager of the change process (but not necessarily the Process Owner). As such, the Change Manager chairs the change advisory board (CAB), which does what it says—it advises the Change Manager on what to do about the changes upon which it deliberates. But ultimately the Change Manager is there to run the process, make sure that all practitioners comply with it, and take a lead in related continual service improvement.

Therefore, the Change Manager is not some omnipotent oligarch who approves or rejects changes on a capricious whim. If a change has proceeded correctly through the process (with all stakeholders having had their say, with those comprising the specific change authority having given their approval, and with the CAB having decided upon scheduling), the Change Manager has no option other than to provide the official stamp of approval. On the other hand, if some stakeholders try to bypass the process, the Change Manager would be required to withhold approval.

Moreover, those who would be responsible for build, test, and release would not have to check for themselves that the correct stakeholders had been consulted and the necessary approval given; the very presence of the Change Manager’s official approval provides that guarantee.

In this respect, the Change Manager is like Her Majesty the Queen in the British Constitution. If a bill passes all its stages in the Houses of Parliament, it then goes for Royal Assent at which point it becomes an Act of Parliament; it becomes a law. Her Majesty cannot withhold Royal Assent under those circumstances. However, if, say, the Prime Minister decided that it was all too tedious for a particular bill to have to go through parliament and that would be much easier to pop down to Buckingham Palace and get the Queen to give it Royal Assent without all that parliamentary fuss, the Queen would rightly refuse, because it would be unconstitutional. So, Her Majesty the Queen has the role of Change Manager—albeit with rather more majesty than most!

How Many Hours Is This Going to Take?

It is important to manage customers’ expectations if you want to achieve high levels of customer satisfaction. Therefore, it is important to ensure that all the ingredients of each service are sensibly and clearly defined. Wherever something is not clearly defined, you shouldn’t be surprised when other people fill the gap that’s left with their own conception (or misconception!).

First, what do I mean by service hours as opposed to support hours—are they the same thing? These terms should be defined in a glossary and in the relevant agreements (SLAs, OLAs, and underpinning contracts). Service hours are usually the times when a particular service should be available to its users, whereas support hours are the times when support (Service Desk, Second Line, Third Line, and so on) is available. Ideally, support hours should not be less than service hours for any particular service, but it may be agreed on by the business, perhaps because of financial constraints, that the business is prepared to take the risk of having a service, which, if it breaks outside support hours, may not be restored as quickly as it would like. That, of course, would be reflected in the SLA. On the other hand, just because service hours have ended does not mean that support hours no longer apply—incident and problem investigation and resolution should continue as specified under “Support Hours” in the SLA.

You also need to be careful about the pattern of hours. Clearly, if the hours are 24/7/365, that’s no issue. But if you mean Monday to Friday (in other words, normal working days), are you including all public holidays, or are you excluding any (Christmas Day, for example) or any other special days for that matter.

But what about incident resolution targets? Should the clock be stopped outside of support hours? The answer is that good ITIL response: “It depends.”

First, remember that the aim of Incident Management is “to restore normal service as quickly as possible”—if something breaks and can be fixed straightaway, then it should be fixed there and then. Often, of course, the necessary resources aren’t immediately available, so the incident has to take its place in the queue in accordance with its priority. Whether the clock gets stopped is a matter for negotiation, agreement, and documentation. However, it should not be stopped for reasons such as “awaiting a reply”; if relevant support hours for that particular support group are running, then so should the clock.

This is why incident resolution targets in SLAs are worded along the lines of, “For this priority, 95 percent of all incidents are to be fixed in four hours.” Such wording does not mean that there’s “a four-hour fix target.” It means that at the service review meetings, when performance metrics are presented showing how many relevant incidents occurred and how many were fixed within four hours, for a hundred incidents, no more than five should have taken longer than four hours to fix; the SLA target would then have been met.

As far as users are concerned, when an incident occurs, the normal service they reasonably expect to enjoy will have been interrupted, and their clocks will continue to run regardless of what the service provider does.

Listen, This Is a Major Disruption—I Want a “Sev 1”

Service providers and their customers like to clearly identify the most critical failures that occur. Often such failures are given a formal severity level of which the highest is Severity One (often referred to as a “Sev 1”). Such failures are then given precedence over all other work.

However, the priority of an incident should not be viewed as a symbol of the status of the individual user concerned. As you know, priority is a reflection of impact and urgency, and the priority given to any particular incident should be derived from the specific guidance provided in the SLA. But what should the service desk do when a user insists that higher priority should be given, perhaps a priority higher than the top priority permitted in that particular SLA?

To foster good relationships, it is good practice for service providers to try to avoid having to give a direct “no” to their customers. In this sort of situation, it may be helpful for the SLA to allow for a higher priority to be allocated if the business insists that it is justified. After all, it is the business’s outcomes that the service provider is there to facilitate. However, because such preferential treatment would come at a cost, it would be prudent to have an agreed-on tariff for such circumstances. Thus, the service desk analyst could say that the user could certainly have a higher priority but could the user please provide their cost center code so that the appropriate recharge could be made. I suspect that most users would agree to accept the priority that was originally allocated!

Service Management Improvement

If you have plenty of resource available, you can allocate as much of it as you want to Continual Service Improvement; however, resources are usually scarce, but you can still achieve much with a comparatively limited amount. Nevertheless, in the context of large and complex government organizations or in multinational companies, CSI projects could be expected to be of an equivalent size to the organization itself. Yet, even in those circumstances, taking as simple an approach as possible may yield more immediate improvement than a highly sophisticated and expensive arrangement. Indeed, while there is no doubt that in relatively mature and large examples formal Capability Maturity Model Integration (CMMI) may be justified, I would suggest that, to begin with, something more straightforward could often produce faster results. That would certainly be the case with organizations of a more modest size.

As you saw in Chapter 7, essentially there are four themes for improvement that could be addressed.

•  Firefighting reduction   In other words, gaining management control of incident activities, leading to improvements in Event Management, Request Fulfillment, and Problem Management practices

•  Control of change   Change Management itself along with Release and Deployment Management; this would also encompass user access control

•  Asset and configuration control   The progressive introduction of Service Asset and Configuration Management, but to be undertaken only as fast as the scope of change control expands

•  Service definition   Moving from the management of service components (infrastructure, applications and contracts, and so on) to the definition of services within a Service Catalog as a prerequisite for the negotiation and introduction of service level agreements

Progress should be made in parallel on all four of these work streams as resources permit, with the aim of achieving a defined level of maturity. That level could be, for example, one where CMMI would be worthwhile or where the disciplines of working toward an ISO 20000 accreditation would become practicable and worthwhile. However, before I get too far ahead of myself, it could be useful to produce a CSI approach model such as in Figure 8-2.

Figure 8-2   CSI approach—a generic top-level model

Regarding each of the four streams, I suggest that the following activities should be undertaken:

Firefighting Reduction

Many service providers are quite good at firefighting—they’ve probably had lots of practice! The following are the activities I recommend:

•  Review whatever tool you already have to ensure its available functionality is being used to best effect. Unless it is hopelessly inadequate, don’t get too concerned about replacing it with a new tool yet.

•  Make sure the existence and contact details of your Service Desk are known by all users.

•  Introduce an incident coding system (such as that as described in the section “Agenda Item 1” earlier) for use at both initial incident categorization and on closure. This will enable the capture of the crucial evidence that is essential for so many other processes to be effective (especially Problem Management).

•  Look for any evidence that users and support staff are bypassing the incident process. Is your Verification and Audit in the Configuration Management process identifying changes to CIs without a matching incident or change record? You should also ensure that your incident process is handy to use, that everyone is aware of its existence, and that everyone understands that they must follow it. The rest is then a management and supervisory responsibility.

Control of Change

Most service providers are already working hard to manage change effectively. If the existing Change Management process and Release and Deployment process are working well, give yourselves a pat on the back and apply Continual Service Improvement to keep them that way. Otherwise, consider the following:

Administration or Management?   You may have RFCs and release controls being raised and their progress being recorded, but are they actually being managed? Is it clear who precisely is empowered to authorize changes, releases, and deployments? Are post-implementation reviews being conducted? Are the impacts and the risks of every change, release, and deployment being properly assessed?

Types of Change   Are all changes being correctly categorized, and is the effectiveness of that categorization being monitored? Are too many changes being categorized as normal, thus generating excessive bureaucracy and tempting people to bypass an unwieldy process? On the other hand, are too many changes being handled as standard changes when they actually have unique aspects about them that means they are higher risk and merit closer control? Emergency changes should be comparatively rare. Look at the emergency changes to see how many are actually “late” changes where a sponsor failed to notify change management promptly as soon as the need for a change was identified. Don’t forget that changes (and releases and deployments) should be prioritized; emergency changes take precedence over all others and should be raised only when the business is already in crisis or soon will be if the change is not made almost immediately.

Link with Incident Management   Once you’ve got incident management running properly, it becomes possible to identify incidents that relate to changes that have caused unplanned disruption to services. Change management can then initiate appropriate investigation to identify the cause (inadequate impact assessment, poor risk management, insufficient resources, pressure to roll out prematurely, and so on) and initiate appropriate improvement measures.

Link with Configuration Management   If you attempt to introduce configuration management for areas not yet under change control, you are going to waste resources because no sooner would you have populated your configuration management databases than the installations, moves, and deletions that take place in those areas of the live environment would render your CMDBs progressively out of date. You should aim to extend the Change Management and SACM processes in step with each other. However, if out of necessity you have to do change management without configuration management, you can, but it won’t be as efficient and effective. Moreover, once these two processes are working in conjunction, the verification and audit activity of the Configuration Management process will identify areas where Change Management (and Release and Deployment Management—and not to forget Incident Management) procedures have been eluded or evaded.

Asset and Configuration Control

An old but, nevertheless, true axiom is

•  You cannot manage what you cannot control;

•  You cannot control what you cannot measure;

•  You cannot measure what you cannot define.

Therefore, if you are going to attempt to perform service management, you need to define what it is you are trying to manage, which is why you need the Service Asset and Configuration Management (SACM) process—as ITIL names it. But before rushing off to buy a specialist tool and construct your CMS, you should consider the following:

Link with Change and Release and Deployment Management   As mentioned in the section “Control of Change” earlier, don’t attempt to introduce the SACM process in areas not yet under change control. And don’t forget that these three processes—Change, Release and Deployment, and SACM—work extremely well together, and you benefit hugely when they do.

Where Are We Now?   As the first step, you should establish exactly what configuration information is already held, by whom, in what format, and to what level of completeness and accuracy. This could vary between detailed and accurate information on all laptops (for example) and a miscellaneous, uncontrolled collection of individual wikis. Nevertheless, establishing the level of knowledge is essential for you to agree on a coherent plan to roll out formal SACM.

Tools   It would be unrealistic to attempt to do SACM using a set of index cards. If you already have a service management tool that offers reasonable configuration management functionality, then use it. However, setting up a Microsoft Excel table or a Microsoft Access database would be a perfectly sensible early, preparatory step. You could upload your configuration data to something more powerful later.

What and When   I recommend applying formal SACM first to those areas where the greatest benefit can be achieved in the shortest time. Not only would this bring those “quick wins” you are always anxious to gain but also it would prove the concept and demonstrate the value of what you are doing. A good example would be a major retailer who was suffering constant failures regarding the electronic point-of-sale (EPOS) devices in their shops. Initially the retailer wasn’t sure exactly how many of these devices they had and where they were; of course, if your EPOS device isn’t working, you can’t take customers’ payments—something rather crucial for a retailer! Their efforts brought rapid benefits. Having proved the concept, gained confidence, and secured the necessary resources, you can then proceed at a manageable pace until the scope of SACM and the scope of Change Management are in alignment.

Identification   It may seem obvious that you should call things by what they are. However, once you set up your naming conventions and a related hierarchical structure, it gets difficult to change it. Top-level categories are clear: hardware, software, people, documentation, and so on. However, under hardware what do you call the devices that individuals use? If you set up lists under proprietary names such as iPads, Macs, iPhones, or whatever, you’ll soon have an unwieldy set of second-level categories. I would suggest that under hardware you set up a category such as “user items” (alongside printers, servers, and so on) and then break that category down to subcategories such as “workstations,” “portables,” and so on. What you actually choose will depend on your particular situation.

Unique Identity   Of course, every configuration item must have a unique identity, but this again needs some preparatory thought. Most hardware can be given a label showing its identity in your CMS, but labels can become detached, so it’s worthwhile ensuring that the record itself includes, say, the manufacturer’s serial number and the electronic identity of the item (where such exists). But what about CIs whose size and shape precludes them being labeled or where physical labeling is impossible such as with soft versions of software or a sensitive matter such as with people (and what unique identity would you use for people anyway)? Each organization must determine its own solution to these challenges.

Service Definition

Organizations that are comparatively early in their journey toward mature service management tend to be focusing their attention on specific items of hardware, system software and applications, or configurations of them. Certainly all these resources merit sound management in their own right, but service management requires the focus to be on the outcomes achieved by the management of these components; service management is concerned with “facilitating the outcomes customers want to achieve”—the definition you encountered in Chapter 1.

That focus on specific components and configurations is then often reflected in the style of any service level agreements that may have been produced. The sort of SLA you should be aiming to negotiate and agree on should focus on the service itself and with the individual components of that service being identified not in the SLA but in the CMDBs within the CMS. But before you can start developing such SLAs, you must first define your services and list them in your Service Catalog.

I find a good starting point is to examine existing contract and application software documentation (or where documentation is poor, talk to the relevant stakeholders that you can identify) and check any existing SLAs. Your incident records may also be a useful source by looking at individual incidents and asking the question “What was the user trying to do here?” In other words, what was the particular business process that was being “facilitated” when the issue arose?

Having gathered that information, you can produce a first-cut business/customer service catalog, which initially need not be anything more complicated than a matrix showing services and the business/customer departments that use them (see the example in Figure 4-1 in Chapter 4).

You can then validate and develop its contents, use it as a basis for developing your Service Portfolio, and set up your SLAs and SLA structure. At the same time, you can produce the technical or supporting service catalog that is the other side of the catalog “coin” and from which you can develop your operational level agreements and align them and the SLAs with your underpinning contracts.

Summary

I have kept this description of these four work streams deliberately simple and generic because I want to provide straightforward guidance; I want to avoid giving any impression that there could be “one-size-fit-all” approach. Like ITIL itself, this section contains guidance, and leaders and managers are strongly recommended to adopt it and then add their own details to adapt it to their specific needs.

Tool Selection

One of the most tempting courses of action to take when embarking on an effort to improve service management is to go out and buy a new service management tool (if you’ve got the money!). I strongly recommend that you pause for thought before getting that purchase order signed. Never forget that old but true saying: “A fool with a tool is still a fool!”

Many organizations already have some sort of IT service management tool; it may be obsolete regarding the technology it uses, and in comparison to others, it may not be the sharpest tool now available. However, the great advantage it has is that it’s the one you have and, probably, the one you know most about. That being the case, it would be worthwhile to review how it has been implemented and to see whether all its functionality is being used and used to its best effect. This is also an excellent opportunity to undertake some focused continual service improvement of your service definitions and of your processes, particularly identifying where your processes have been made to fit the tool rather than the tool to support your processes. This review will enable you to produce a set of detailed criteria not only for exploring improvement of the existing tool but also for the selection of a new tool.

The determination and documentation of these selection criteria are the foundations for successful tool selection. You should begin by exploring the market to ascertain particularly the following:

•  The tools that are available

•  The functionality that is being offered

•  To what level each tool could be considered an integrated service management tool (how far do they combine discovery capability, software management, deployment management, and so on, alongside the usual incident, change, and service level management functionality?)

•  The technology platforms required and available (hosted solutions, software as a service, and so on)

•  Pricing models (by functionality modules, number of “seats,” and the like)

•  Support options

•  Industry reputation of the potential suppliers (consult existing clients)

•  Future viability of potential suppliers

•  Future plans of the potential supplier (might they be looking to expand their business so that, while currently a welcome partner, your relative importance as a customer could be diminished by the arrival of a new and bigger customer?)

How much time you spend on this will depend on the urgency of your need and the resources available to undertake the research. Avoid the temptation to turn your work into a full-blown review of the market (unless you’re looking to sell the product of your research to others!).

The next stage is to divide your criteria into two sets: essential and desirable.

The essential criteria are those that any tool must meet in their entirety to be given further consideration. Each criterion would have a binary assessment: a clear yes or no. For example, such criteria could be “incident workflow separate from request fulfillment” or “total cost below $xxxxxx.” Any tool for which the answer to these questions is not an unequivocal yes would be excluded from further consideration. However, you may need to be flexible with your criteria. If your criteria are too demanding, you may end up with too few potential tools on your short list; conversely, your list may be impossibly long, in which case you may need to tighten up your criteria.

Your desirable criteria need to be put into an order that reflects your prioritization of your requirements. With these desirable criteria, your assessment will not be a straight yes or no but some sort of value—probably involving costed options. This is where you can apply the Pareto principle, or the 80/20 rule. It is unlikely that any particular tool will meet 100 percent of your desirable criteria, so the tool you select will be the one that meets all your essential criteria and that best meets your desirable criteria, not just in terms of the absolute number but in terms of the relative importance of the ones it does meet.

However, do not apply the 80/20 rule to your essential criteria; that’s where the 100/0 rule applies!

It is advisable to discuss and agree on all these essential and desirable criteria with the relevant stakeholders before going out formally to potential suppliers.

Once you have an agreed-on set of essential criteria, you can produce a shortlist of potential suppliers, all of whom meet your minimum requirement. You can then use your prioritized desirable criteria to score your short list and make your final choice; in doing so, you will have produced an audit trail to show what you did, what criteria were used, and on what basis the final decision was reached.

The main ITIL book ITIL Service Design provides some detailed guidance in Chapter 7.2, where you’ll find a mention of a rather more sophisticated selection method: MoSCoW analysis (which stands for “Must have, Should have, Could have, and Won’t have”).

The Continual Service Improvement Register

Continual service improvement is a fundamental part of the service lifecycle, and the more parlous the state of service management the greater the imperative of getting on with improvement. Furthermore, CSI does not have to be a super-sophisticated activity to be useful; it is often quite obvious what needs to be improved. However, improvement won’t happen just by thinking about it; you should record all the initiatives that arise, categorize them, prioritize them, and so on. Indeed, you should create and use a CSI register.

You’ve already been introduced to the CSI register in Chapter 7, but a few more words on the subject may be useful.

Table 8-1 shows a generic specification for a CSI register entry format.

Table 8-1   CSI Register Entry Format

Here is more information about the fields in Table 8-1:

•  Serial   Every record must have a unique identity.

•  Status   Any temptation or pressure to close entries prematurely should be resisted. Be careful to avoid choosing metrics and KPIs that might drive behavior down that route.

•  Description and Benefit   These need to be kept as concise as possible; maintain supporting details in an appropriate controlled document (which will be a configuration item in its own right) held in a suitable repository such as SharePoint.

•  Generic Area   Name of the relevant customer-facing services, supporting services, or processes. If this is not clear, you may want to raise another CSI record to have the documented scope of services and processes reviewed and revised!

•  Repository   This is the physical location where the supporting details are to be found, and the register entry should include their location within it.

•  Date Raised and Target Date   These are self-explanatory.

•  Benefit Rating, Urgency, Resources Estimate, and Breadth of Impact   These four ratings are crucial to achieving as objective an assessment as possible. The CSI Manager will need to draft, negotiate, agree on, document, and introduce definitions and guidelines that are appropriate to the particular service provider concerned.

•  Originator   This is the person who had this bright idea in the first place.

•  Sponsor   If this is not obvious or the likely sponsor is unwilling to take ownership, the CSI Manager may need to ask top management (the IT director or equivalent) to nominate (see also the section “The International Standard: ISO/IEC 20000”).

•  Cross-Reference and CSI Cross-Reference   Clear cross-referencing is essential, as covered in a moment.

•  Review and Reviewer   It is likely that all entries will be reviewed several times; therefore, it may be necessary to maintain a separate list of reviews with entries cross-referred to the CSI register.

•  Date Closed   There is no argument that an entry should be closed when it has been subsumed by another entry (but beware of any subsequent disaggregation). Otherwise, be careful to ensure that entries are closed only when the improvement initiative has been fully and successfully implemented.

•  RFC Number   This is a crucial cross-reference, as explained in a moment.

The CSI register should be owned and maintained by whoever has the role of CSI Manager. Ideally, the CSI register should be part of a comprehensive, integrated service management tool to help ensure its consistency, quality, and visibility to all stakeholders. However, at an early stage of maturity, a simple Microsoft Word document or Microsoft Excel spreadsheet will suffice so long as adequate control can be exercised over its update and visibility.

The CSI register sits alongside the entries in any existing risk registers and the records in the known error database (KEDB), the latter being owned by Problem Management, as I’m sure you remember. Where appropriate, all these records should be cross-referenced, not only within the CSI register but between the CSI register and the risk registers and the KEDB. As and when RFCs are raised against these entries, the RFC number should be cross-referenced to the originating register or KEDB record because subsequent action should take place under the control of the RFC. However, such CSI register entries should not be closed until the RFC has been successfully implemented and the benefit of the improvement has been realized.

The International Standard: ISO/IEC 20000

I’ve saved the best until last!

The IT Infrastructure Library and ISO/IEC 20000 are very close in concept with a significant overlap. However, there is a fundamental difference of approach, which is expressed best in the words of Dr. Don Page, one of the gurus of IT service management: “ITIL is documented common sense whereas ISO 20000 is auditable common sense.”

As you saw in Chapter 1, when seeking sources of best practice, the highest-quality sources and the most valuable are found in recognized standards, such as ISO 20000 (the “IEC” bit tends to get dropped in general parlance). Therefore, when you are considering your vision for the future quality of your service provision, it would make sense to set meeting the ISO 20000 requirements as your ultimate goal. You may not be able even to contemplate actually achieving all of them at this moment, but you can use them as a readymade, clear set of aspirations. When you create your top-level service improvement approach model, achieving ISO 20000 accreditation could be your vision, and “Where do we want to be?” could be the definition of an achievable step toward achieving that vision.

Moreover, having ISO 20000–style aspirations gives your auditors something certain against which to assess you. Now, before you run for cover at the mention of auditors, let me tell you that I have found auditors to be extremely useful when trying to drive forward service improvement. If your plans are sensible and adequately documented, the auditors will tend to be on your side, and their observations can add huge weight to any bids you make for resources for service improvement.

Of course, you may be embarking on a project to achieve formal ISO 20000 accreditation because that has been mandated by the executive board. If so, rejoice! Achieving ISO 20000 accreditation will require the introduction of the necessary management disciplines to achieve high levels of service provision. It does that by requiring evidence to be produced, not just good intentions.

Within the scope of this section, it is impossible to provide the detailed guidance necessary for setting up and running a successful ISO 20000 accreditation project. However, I believe an overview of the structure and disciplines of ISO 20000 will be useful.

ISO 20000 is based on the Deming cycle of Plan-Do-Check-Act you encountered in Chapter 7. In essence, it requires the creation of a service management system (SMS) that reflects the principles of governance considered in Chapter 1: fairness, transparency, and conformance to policies and legislation. The following are the main areas of ISO 20000:

•  The SMS

•  The design and transition of new or changed services

•  Relationship processes

•  Service delivery processes

•  Control processes

•  Resolution processes

SMS

The SMS includes the nomination and empowerment of a “top management” individual along with not only a clear statement of the commitment of management to “planning, establishing, implementing, operating, monitoring, reviewing, maintaining and improving the SMS” but also the production of evidence that supports that commitment. There must also be a clear definition of the business objectives and the service objectives that are derived from them (Service Strategy in action). These objectives are then linked downward through the supporting processes. Furthermore, acting on behalf of top management, a suitably skilled and empowered management representative must be appointed (this job is similar to that of CSI Manager). The SMS must also cover roles and responsibilities, documents and records management, resource management, and the application of continual service improvement.

From this discussion, I hope you can see that providing proof to an auditor of the existence of a credible SMS is fundamental to gaining an ISO 20000 accreditation. However, this should not be viewed as a “box ticking” exercise. The efficient and effective delivery of IT services, based on well-managed assets, is dependent on the existence of a controlling SMS.

New and Changed Services

This aspect covers those areas for which you exercise management through the service portfolio and the service catalog, encompassing the relevant activities of Service Strategy, Service Design, and Service Transition. Program and project management form a major part of this aspect.

Relationship Processes

These are the Business Relationship Management and Supplier Management processes.

Service Delivery Processes

The processes are

•  Service Level Management

•  Capacity Management

•  Service Continuity and Availability Management (ISO 20000 combines these two ITIL processes)

•  Information Security Management

•  Budgeting and Accounting (charging is outside the scope of ISO 20000)

•  Service Reporting (a discrete process, reflecting the importance of measurement and metrics)

Control Processes

The processes are

•  Configuration Management (the equivalent of SACM in ITIL v3)

•  Change Management

•  Release and Deployment Management

Resolution Processes

The processes are

•  Incident and Service Request Management (ISO 20000 combines these two ITIL processes—not recommended by ITIL, so be careful!)

•  Problem Management

Achieving ISO 20000 Accreditation

So, even if you’re not looking to achieve formal ISO 20000 accreditation now, taking an ISO 20000 approach will help you immensely in achieving worthwhile and provable service improvements. And you never know—you may find yourself at the ISO 20000 level almost without noticing it. But when you do, don’t be shy; you should blow your own trumpet on what you’ve achieved!

Chapter Review

In this chapter, I’ve shared a variety of IT service management experiences. Here is a list summarizing the topics that have been covered:

•  Finance (charging)   Be careful if you’re planning to introduce full charging for services delivered internally.

•  Finance (policies)   Remember that while the service provider and its finance department share many common areas of interest, the imperatives may be different, and the service provider has to act in accordance with the organization’s financial policies and procedures.

•  Project management   It must be absolutely clear that projects and programs, and all involved in them (including project managers), are subject to the organization’s service management policies and its application of the service lifecycle.

•  Outsourcing (process maturity and quality)   Does your contractor understand the crucial need to capture performance evidence, especially in the incident process? Are they able to use your specific incident closure codes? Is the implementation and functionality of their service management tool acceptable?

•  Outsourcing (penalties)   Applying penalty charges might not always achieve what you want.

•  Outsourcing (the business’s objectives)   Make sure that the business executives give you a full picture of their objectives before you embark on any detailed work; be ready to challenge those objectives if you consider that they are flawed.

•  Configuration Management   Good service management is seriously impaired unless you have good configuration management. Work with partners to encourage Type II service providers to match your standards and ensure Type III service providers are contractually obliged to do so.

•  IT Service Continuity Management (ITSCM)   Ensure you have identified all the various situations in which the invocation of a service continuity plan may be considered and ensure you have in place detailed guidance, especially regarding who makes the decision and what are the criteria they should consider.

•  Service Operation processes   Ensure you have coordinated closely the processes of Event Management, Incident Management, Problem Management, Request Fulfillment, and Access Management.

•  Business Relationship Management   Ensure that in practice the business actually does take responsibility for making business decisions and doesn’t let such decisions default to the IT service provider.

•  Capability Maturity Model Integration (CMMI)   Don’t be tempted to make this your first step in continual service improvement: start by appointing someone as an empowered CSI Manager and let them begin with the areas of greatest pain and greatest potential for significant improvement (an example of applying the CSI approach was provided); leave CMMI for later.

•  Change Management   Make sure that all stakeholders understand that the person with the role of Change Manager is there to manage the process and to ensure that appropriate action is taken in the event of any noncompliance; in other words, you want to ensure good governance.

•  SLA targets   Ensure all stakeholders understand what targets actually mean.

•  Incident prioritization   Ensure that everyone, users especially, understands that prioritization is based on impact and urgency and that the prioritization of any specific incident must be based on criteria agreed to during the negotiation of the relevant SLA.

•  CSI   When starting out, there are essentially four parallel paths to be followed (firefighting, change control, configuration, service definition); get these addressed first before worrying about sophisticated ongoing CSI arrangements.

•  Tool selection   Be as objective as possible using clear criteria.

•  CSI register   This is a crucial tool to be introduced as soon as possible, remembering that in essence it is a big “to-do” list and that usually the more entries in it the better.

•  ISO/IEC 20000   I gave you a brief overview of this standard.

Questions

Here are 11 questions for you to tackle.

1.  A user contacts the service desk to report a fault. Where would the service desk analyst look for the prioritization criteria?

A.  The known error database (KEDB)

B.  The relevant service level agreement

C.  The service portfolio

D.  The configuration management system (CMS)

2.  A major fault has occurred that would appear to justify the invocation of an agreed-on IT Service Continuity arrangement. Who would make the decision?

A.  The Service Desk Manager

B.  The Business Relationship Manager

C.  The IT Operations shift leader

D.  The occupant of the job specified in the IT service continuity plan or their deputy

3.  Which of the following would you expect to see in a contract, including the service level agreements within it, for an outsourced service desk service?

i.  Specification of agreed-on incident closure codes

ii.  Penalty charges and service credits

iii.  Specification of the format and content of the regular review meetings

A.  i and iii only

B.  All of them

C.  ii only

D.  ii and iii only

4.  Which one of the following is optional in Financial Management?

A.  Charging

B.  Accounting

C.  Budgeting

D.  Costing

5.  What one of the following statements is correct about the relationship between IT service management and projects or programs?

A.  Project managers must always be able to override the decisions of the change advisory board (CAB).

B.  Projects or programs should align their activities with the service lifecycle.

C.  There is no overlap between IT service management and projects until the project has rolled out into the live environment.

D.  In any conflict for resources, projects always take precedence over day-to-day service management needs.

6.  Which one of the following are not processes in the Service Operation stage of the service lifecycle?

A.  Change Management, Release and Deployment Management, Technical Management

B.  Event Management, Incident Management, Problem Management

C.  Incident Management, Request Fulfillment, Access Management

D.  Event Management, Request Fulfillment, Access Management

7.  Who of the following could be members of the change advisory board (CAB)?

i.  Service Desk Manager

ii.  Business representatives

iii.  Capacity Manager

iv.  Service owners

A.  i only

B.  iv only

C.  All of them

D.  i, iii, and iv only

8.  Which one of the following statements regarding the continual service improvement (CSI) register is false?

A.  Entries should be categorized as having a benefit rating such as high, medium, or low.

B.  Entries should be cross-referred to identify common themes or configuration areas.

C.  Entries should be closed only when either the initiative has been implemented or the entry has been subsumed by another entry.

D.  The number of entries should be kept to a reasonable minimum to ensure that focus can be maintained.

9.  An SLA target that states that 95 percent of all incidents for a particular service and priority are to be resolved within four hours means:

A.  The service desk has four hours to get back to the user.

B.  The service desk must get back to the user within four hours in 95 percent of cases.

C.  Normal service must be restored within four hours in 95 percent of these incidents.

D.  A four-hour fix is applicable.

10.  Which one of the following statements is correct?

A.  Service Asset and Configuration Management (SACM) is independent of the Change Management process and the Release and Deployment Management process.

B.  Service Asset and Configuration Management (SACM), Change Management, and Release and Deployment Management are all very closely linked.

C.  It is important to have Service Asset and Configuration Management (SACM) working before starting with Change Management.

D.  While Service Asset and Configuration Management (SACM) is closely associated with Change Management, it does not have any relevance to Release and Deployment Management.

11.  Other than Service Level Management, which processes should be involved in the development of service level agreements (SLAs)?

i.  Capacity Management

ii.  Availability Management

iii.  IT Service Continuity Management

iv.  Strategy Management

v.  IT Security Management

A.  i, ii, and iii only

B.  i, ii, and v only

C.  i, ii, iii, and v only

D.  All of the above

Answers

1.  B. The KEDB contains problem and known error records, the service portfolio list the services but would not contain this detail, and the CMS would record the existence and location of the SLA but not necessarily its contents.

2.  D. It is unlikely that the Service Desk Manager or the Business Relationship Manager would make such a decision; the IT Operations shift leader could be so empowered but not in all cases.

3.  B. These are all important elements to have in a contract for an outsourced service desk service.

4.  A. Budgeting and accounting are obligatory. In ITIL, costing is not an activity nor a concept that is an equivalent of budgeting, accounting, and charging.

5.  B. The situations in options A, C, and D may be encountered but are examples of very poor practice.

6.  A. The Change Management process and the Release and Deployment Management process are Service Transition processes; Technical Management is a Service Operation function.

7.  C. Representation on the CAB should be available to all relevant stakeholders.

8.  D. A well-designed and properly managed CSI register would easily accommodate many hundreds of entries.

9.  C. The other options are misinterpretations of the statement.

10.  B. It is important to understand that these three processes are mutually supportive and must work closely together to achieve maximum effectiveness.

11.  C. The link between Strategy Management and Service Level Management is tenuous. In contrast, the other four processes comprise warranty and are crucial contributors to producing effective SLAs.