I recently delivered a Managing Across the Lifecycle class to a group of students in Northern California. The Managing Across the Lifecycle class is presently the capstone class in the ITIL certification program. When students have secured enough credits in the ITIL certification scheme, complete the Managing Across the Lifecycle class, and successfully pass the exam that’s given in conjunction with the class, they earn the ITIL Expert credential.

Earning ITIL Expert is a significant accomplishment. When people earn the ITIL Expert credential they are usually either positioning themselves for better opportunities with their current employer, or they are positioning themselves to compete with others in the open job market for higher-level service management positions. In either case, the ITIL Expert credential is definitely something that gets the attention of hiring managers in organizations that value ITIL.

There’s one minor problem though. Simply earning the ITIL Expert credential does not mean that the person is adequately prepared for a job interview leading to an ITIL Expert-level position. Someone that holds ITIL Expert might get the job interview, but once in the interview they might not be able to make a compelling case as to why they’re more valuable than any other candidate.

This is exactly why when I deliver the Managing Across the Lifecycle class, I treat it more like a job interview than a traditional training session. Once students have completed enough ITIL classes and exams to qualify them for Managing Across the Lifecycle, they most likely have the theoretical understanding of ITIL necessary to be ITIL Experts. Sometimes what they lack is the ability to make use of that theoretical understanding to solve real problems in organizations. That’s how I see the Managing Across the Lifecycle class, and because of that, I take a scenario-oriented approach to the class that is both similar to what they might experience on the exam and similar to what they might expect in a job interview.

As I was delivering this Managing Across the Lifecycle class, once of the students asked, “what type of interview questions would be asked of someone applying for an ITIL Expert-level job?” That’s an excellent question that I will address in this post and a series of posts to follow this one.

In most cases, someone applying for a service management job, at any level, should expect to participate in a behavioral event interview. A behavioral event interview is a job interview that seeks to determine an applicant’s suitability for a job by assessing their past experiences, competencies, and performance. In other words, the interviewer (or interview panel) will ask the applicant to describe situations where they used specific capabilities or behaviors relevant to the job. Typically, the applicant that makes the best case that their prior behaviors are in line with what the interviewer is seeking will be offered the job.

Notably, ITIL Intermediate and Managing Across the Lifecycle exam questions are very situational and are somewhat similar to the types of questions that might be asked in a behavioral event interview for a service management role.

The good news is being good at behavioral event interviews is a skill that can and should be learned and practiced. Over the next several weeks, I will post a series that gives sample questions that applicants might expect in a behavioral event interview for service management roles from foundation-level to expert.

Which of the following BEST describes a Problem?

1. An interruption to normal service
2. The unknown underlying cause of one or more incidents
3. A proposed modification to an IT service
4. A formal project to improve a service

The correct answer is 2.

Problems are the unknown, underlying causes cause of one or more Incidents.

Related Courses
ITIL Foundation
ITIL Service Catalog

This appendix is significant in that it clearly defines various types of cloud services and the types of clouds in use, as well as different aspects of cloud services. This post will focus on how this appendix describes the various aspects of cloud services.

Appendix C: Service Strategy and the Cloud indicates that there are five characteristics of cloud services. These characteristics are:

• On demand
• Ubiquitous access
• Resource pooling
• Rapid elasticity
• Measured services

I’ll provide a brief description of each of these characteristics, as well as how I’ve recently seen companies offer services that meet these characteristics.

On Demand

An on demand service is a service that can be accessed when and where it’s needed through either the Internet or an Intranet. “On demand” literally means it’s available when the user demands it.

I recently completed an XSLT class. To do the assignments for this class, students activated a host with specific settings. Once the assignment was finished and uploaded to a website, the host was no longer needed, so it was deactivated until the student was ready to begin working on the next assignment. This was helpful because the class required significant configuration to make everything work. Having an on demand service like this meant that students could load a pre-configured environment as needed.

Ubiquitous Access

Ubiquitous access means that various types of clients can use the service. Ubiquitous access requires three things:

1. The use of standard communication methods and network protocols
2. Coarse grained interfaces
3. An effective model for managing security-related aspects

An example of ubiquitous access includes services that allow users to store music, photos, or other information that can then be accessed by various devices such as traditional personal computers, tablets, and smartphones.

Resource Pooling

Cloud services are often provided through a collection of physical and virtual assets that are managed dynamically according to patterns of business activity and user and customer demand.

An example of resource pooling is having a collection of assets that can be quickly arranged as needed to meet customer demand. I once worked for a financial services company that pooled its hardware assets in such a way that we could utilize additional resources from the pool to quickly respond to demand for IT services.

Rapid Elasticity

A service that is elastic can be quickly and appropriately sized in-line with customer demand. What this means is that as patterns of business activity change, the demand for services is affected. A highly-elastic service is able to quickly add more resources in-line with increased demand or reduce resources in response to diminished demand.

Rapid elasticity has existed in IT for some time. An example of rapid elasticity I was recently exposed to was with respect to an IT organization’s network circuits. This organization moves large datasets across a portion of its network. At times, it requires more bandwidth and in order to achieve these needs dynamically reallocates networking circuits and assets. When the need for increased bandwidth diminishes, the organization positions network assets according to normal operating criteria.

Measured Services

Cloud services are often purchased according to a pay per use, or pay per utilization model. In order to offer that type of pricing arrangement, it is critical that there is some method to measure use of the service.

Measuring the utilization of services is nothing new. We’ve been doing it for quite a while in IT. An example of measuring a service comes from mainframe environments but has been used in other environments as well. Many organizations will calculate what is called a “MIPS rate”. “MIPS” stands for “million instructions per second”, and it is the number of instructions that a computer or service can execute per second. An MIPS rate will often not only consider this but also will weigh the average time various instructions take, consider the overall cost of providing the service, and ultimately produce a billing rate equal to the cost of 1 MIPS. I’ve worked with several organizations that billed internally for high-end computing resources in exactly this fashion.

In the most recent version of ITIL quite a bit of coverage is given to cloud-related topics and the impact of cloud technologies on IT service providers. The importance of this is to establish a common meaning of the various aspects of cloud services and how we as service providers can apply these technologies to deliver value to our customers.

Related Posts
Cloud Issues and HDI conference Orlando
Types of Cloud Services — As Defined By ITIL

Related Courses
ITIL® Foundation
ITIL® Service Lifecycle: Service Strategy

Our giveaways were pop-a-doos (computer dusters that everyone loved because they could really use them) and bobble head pens that people thought were great. Of course their kids or grandkids needed one too. We also had a drawing for an iPad. I was offered a couple of bribes to draw particular names from the box, but I was strong and resisted. After the first night we were out of almost everything including catalogs, and normally I have boxes of them left over! When deciding what to order for the show, I sent a few options to some Global Knowledge IT people and got their votes. Cool Mates got the first spot but did not make it in time for this show, so if you’re going to Fusion in Dallas this year, please stop by our booth for those. They are little, round, rubber feet you put on the table before you set your laptop down so your laptop stays cool as it allows air to circulate under it. The pop-a-doos were in second place, and pens in third. I gave our receptionist one of these pens a couple of weeks ago. She put it by the sign-in book, and visitors still comment about how cute it is. As a marketing person, I am happy that the giveaways were a total WIN. We are attending eight PMI events this year. I am going to do drawings for Bose headsets and Nintendo 3DS at them because I figure people want something for themselves and for kids too.

We were across from ScriptLogic who had some cool giveaways too, and those guys were fun to talk with. On Day Two I was on my own at the booth. Traffic was not heavy, so I got to have some great conversations. I met some very interesting people, including Phil Gerbyshack who had the most interesting business cards I have ever seen before. It was like a playing card — very cool.

Rick Joslin from HDI came by, and we shared some ideas since Global Knowledge provides HDI training. I enjoy working with Rick. He trained all of our sales people when we first began offering HDI courses, and it has been a really nice partnership. He asked if I was going to stay an extra day for the HDI after party, but I couldn’t. He told me how much fun they are and about some of the past acts including Penn and Teller, Jay Leno, The Doobie Brothers and Dennis Miller. The fortune tellers sound like something I would have enjoyed, and I wonder if I have been missing out on a lot of fun. Note to self:  Next year stay for the after party. I would stay this year, but my 3 year old expects me to be on a big plane Thursday night, and I miss my children like crazy. Oh yeah, and my husband, too.

I was happy that the gym was free for the HDI attendees. Tuesday night I was beside a man on the treadmill who was stoked about a team building class he took that day. He said he learned a lot of helpful hints he is going to take back and use with his team. The feedback I got from everyone who mentioned the sessions was they were helpful, particularly the Knowledge Management session.

Our own Michael Scarborough did a crack o’ dawn morning presentation Thursday that had about 40 attendees. He drew the winner for the iPad (Michele Karsk from Cox). She was super excited. A few people Michael trained on ITIL chatted with him. It was nice to hear about their wonderful training experience with him.  Your instructor makes such a difference in your overall training experience.

2,200 people attended, and I feel lucky that I got to meet so many people. A lot of help desk managers were here — more than I expected.

The space was nice and of course the HDI was wonderful.  I wish I had known our giveaways would be so popular so that I could have brought more. I felt bad when I had to tell people I was out. Traffic to the booths was really up this year. People spent more time in the exhibition hall talking to vendors. To me what makes a good show is when you can have conversations with people and learn what everyone does. I love finding out what people like and don’t like, what they look for in a training provider, and why they do and do not use certain providers. People seem more willing to share when you are face to face versus filling out our after class evaluation. Overall I am happy with the show, and I look forward to going back next year.

Related Post:
Cloud Issues and HDI Conference Orlando

1. To evaluate proposed changes for cost and risk
2. To evaluate incidents in order to improve the Incident Management Process
3. To regularly conduct reviews with customers regarding service achievement
4. To evaluate all emergency changes

The correct answer is 1.

The Change Advisory Board evaluates change in terms of cost and risk, and makes decisions about whether or not to move forward with proposed changes.

Related Courses
ITIL Foundation
ITIL Service Catalog

Which one of the following is the CORRECT sequence of activities for handling an incident?

1. identification, logging, categorization, prioritization, initial diagnosis, escalation, investigation and diagnosis, resolution and recovery, closure
2. prioritization, identification, logging, categorization, initial diagnosis, escalation, investigation and diagnosis, resolution and recovery, closure
3. identification, logging, initial diagnosis, categorization, prioritization, escalation, investigation and diagnosis, resolution and recovery, closure
4. identification, initial diagnosis, investigation, logging, categorization, escalation, prioritization, resolution and recovery, closure

The correct answer to this question is 1, however students often disagree with that answer choice. The rationale behind the answer is simply, “The correct order is given in the diagram in the incident management process, and in the subsections of [SO] 4.2.5.” In this post, I will provide a better explanation of why choice a is the correct answer.

First of all, the flow of activities in the incident management process is described in the Service Operation book section 4.2.5, and shown visually in Figure 4.3.  Figure 4.3 shows the following flow of activities for incident management:

As shown in Figure 4.3, the correct flow of activities in the incident management process begins with identification, which is followed by logging, which in turn is followed by categorization. Initial diagnosis occurs later in the process flow following prioritization.

While the Service Operation book is clear about the flow of activities, the logic behind why the activities are in this order is not completely clear. Very few people disagree that the incident management process begins with identification, which in turn is followed by logging. The disagreement primarily exists in what follows logging, whether it is categorization or initial diagnosis. A good way to summarize the flow of activities is that they flow from general to specific.

It often helps to clarify what the steps in the process do. Categorization allocates the type of incident that is occurring. In practice, organizations often use a multi-level categorization scheme, where the top-level consists of a few broad high-level categories.  Subsequent levels of categorization might provide an additional level of detail. Practically, I’ve always thought of categorization as a way of identifying at a high-level what general area an incident should belong to. For example, common top-level categories include things like “hardware”, “software”, “network”, “user induced”, “supplier induced”, etc.. In fact, I once worked at a large organization that processes about 50,000 incident tickets per month with a set of 8 top-level categories.  In other words, when categorization is done, we’re really just trying to identify a general area to which the incident most likely belongs.  Categorization can be revisited, and often changes throughout the lifecycle of an incident.

Prioritization accounts for the impact and urgency of the incident and assigns a pre-defined code that guides an organization’s response to an incident. In any population of incidents, an effective prioritization scheme tells the organization which incident to work on first. The ability to do this is critically important in high-volume environments where the organization has limited and shared resources capable of responding to numerous, simultaneous incidents. In other words, organizations have to make decisions about how to marshal resources based on their impact to the business and how quickly service must be restored.

Initial diagnosis is described in the Service Operation book in section 4.2.5.5 as the activity where the service desk attempts to understand all symptoms of the incident in an effort to uncover what is wrong and attempt to correct it. During this activity, the service desk staff might use the known error database to speed incident resolution, or diagnostic scripts to identify the service fault.

The logical reason why these steps are in this order is because during categorization and prioritization we try to uncover enough details about the incident so that it can be routed correctly throughout the process. For example, organizations might choose to handle hardware or network incidents differently than they handle software incidents. The same is true for prioritization. Prioritization seeks to establish facts about the incident in terms of its impact and urgency such that proper routing decisions can be made; for example, the highest priority is what is typically known as a “major incident”, which will often follow a specific procedure dedicated to handling major incidents.

Therefore, the early steps in the incident management process are focused on properly routing the incident. Knowing the category and priority help organizations make effective decisions about routing incidents. Improperly routed incidents will result in delayed resolution of service, which impacts users and customers and decreases satisfaction. For example, it would not make sense for a service desk to attempt initial diagnosis if they are not properly trained or equipped to investigate that category of incident. In fact, a service desk spending time doing initial diagnosis for incident categories where they are improperly trained and do not have effective scripts and tools will often result in delayed restoration of service, increased impact to users, and a negative impact to customer satisfaction.

Clearly, according to ITIL, categorization occurs early in the incident management process, and there are good reasons why this is the case.

1. A means of delivering value to customers by facilitating outcomes that customers want to achieve without the ownership of specific costs and risks
2. A means of delivering costs to customers, by facilitating outcomes that customers have paid for without the ownership of specific value and risks
3. A means of nullifying risk to customers, by offering products that customers want without the ownership of specific infrastructure items
4. A means of delivering best practice to customers, by facilitating outcomes that customers want to achieve.

The correct answer is 1.

A service provides value while taking away the ownership of specific cost and specific risk.

Related Courses
ITIL Foundation
ITIL Service Catalog

“What is the difference between a project and a service?”

To be honest, I haven’t spent much time thinking about this distinction. However, I think that those of us who practice ITIL consulting and training should have good answers to questions such as this.

Here’s how I answered this question.

A project is something that is temporary in nature and results in a new, modified, or retired good or service. In other words, projects result in the modification of something existing or the creation of something new. A project defines a boundary and includes the resources and capabilities required to achieve project milestones and deliver desired results.

A service, on the other hand, is different than a project in several ways. First, a service delivers some value that customers use to achieve outcomes while removing the ownership of specific costs and risks. Thus, a service always has an operational aspect and will often include a collection of requests related to aspects of that service. Services also define a boundary that specifies inputs and outputs as well as the result that the service delivers.

There is a strong relationship between projects and services. A project might be used as the mechanism by which a service is deployed, retired, modified, or updated. Projects often produce one or more changes and/or releases that, in turn, result in the implementation, modification, or retirement of services and aspects of services.

Another fly in the ointment, that sometimes IT organizations do not consider, is that “project management” itself can be defined as a service that the organization offers. In other words, many IT organizations provide value in the form of a service that applies a standard set of processes to project management activities. In these cases, they control the risk and cost often associated with projects in the form of a defined service offering.

While projects and services are not the same thing, there is definitely a relationship. Organizations benefit from a consideration and appropriate structuring of that relationship.

A project is defined as a temporary assembly of resources and capabilities designed to create a specific product or achieve a specific objective. Projects establish criteria that, when met, signify completion of the project.

A program, on the other hand, can be thought of as a collection of related projects that are managed in order to meet a related set of objectives. Where projects are temporary in nature and have a defined beginning and end, programs can include operational aspects.

A good example of the difference between a project and a program is the work that accredited training organizations did to update ITIL courseware in the context of the ITIL 2011 refresh.

For the intents and purposes of this discussion, there were 13 courses that were updated based upon the ITIL 2011 refresh. The series of activities to update each of these courses were managed as individual projects. For example, when we updated the ITIL Foundation course, specific start and end dates were established, along with overall project milestones.  Furthermore, resources were allocated for project activities. For each course that was updated, a similar set of activities was performed.

The projects to update all of the courses were related in terms of their overall objectives and the resources required to achieve those objectives. However, there is an ongoing operational aspect in which we constantly validate that the courseware is accurate and  any errors found are corrected. Therefore, the individual projects to update all of the ITIL courses were collectively managed as an overall program, which includes the ongoing operational aspects associated with keeping the courses accurate and up-to-date.

Fundamentally projects and programs help us apply boundaries and control scope. A good project is a boundary that helps to limit activities to only those that contribute to the objective of that project. A good project manager protects that boundary. A program is also a boundary, but it is broader than the boundary of a single project in that a program considers the contribution of many projects to a related set of objectives.

1. For an activity or task, defining who is Accountable
2. For an activity or task, defining who is Responsible
3. For an activity or task, defining who is Informed
4. For an activity or task, defining who is Correct

The correct answer is 4.

RACI helps determine who is responsible, accountable, consulted and informed for an activity or task.

Related Courses
ITIL Foundation
ITIL Service Catalog