Just the thought of taking a mathematics or science class in college sent me into a state of panic. However, I decided that if I wanted to continue to work on projects about the IT Infrastructure Library (ITIL), I better take an ITIL foundation class and get ITIL certified.

The good news was that the course did not have anything to do with science, and I could delegate the math-related activity to math wizards in the class. The class provided practical information about how to manage IT from a business perspective. We learned that people, processes, and technology need to be aligned to the business goals. In our class, the goal was to run a profitable airport.

Taking Care of Business

The class included a three-day overview of ITIL processes, exercises related to managing IT from a business perspective and a final test on content. My favorite activity was the Airport Simulation exercise. This activity gave students a chance to understand what it really means to implement have IT and business goals be the same.

ITIL was, obviously, at the heart of this approach, which entails managing IT from a business perspective. During this exercise, we monitored onscreen how much money our airport was making or losing based on decisions we made related to IT.

Our class was divided into groups of people from IT and the business, where we each assumed different roles. Our job was to solve IT problems effectively so flights could take off on time and our airport could make money. If we didn’t have adequate processes in place, and if we failed to ask the right questions, we would lose money.

Ironically, I was assigned to work with two other people as a technical services expert. It was not unusual to have three or four problems hit us at the same time, but we had a “budget” to hire consultants if we knew that we needed assistance.

A classmate assigned to the service desk would send my team a trouble ticket. We then looked up information in relevant class guidebooks and applied our newly learned skills to find the right question and solve Mensa-like math problems for closing trouble tickets.

Bad Start

We failed miserably the first round and shut down the airport. In fact, by the second round, our cumulative loss was nearly $250,000, our mean-time-to-repair (MTTR) was over 16 minutes per problem, and availability was less than 45%. That is no way to run an airport—even an imaginary one.

What did we do wrong? For starters, we didn’t talk to the business. We thought we were working on solving the right problems, only to learn we sometimes asked the wrong questions.

We were handling tickets as they came in, and they were not always based on business priority. For example, we treated the airport terminal’s catering availability with almost the same sense of urgency as a threat to the control tower: What were we thinking? We didn’t always keep the help desk informed of ticket status. With each mistake, we could see how much it was costing the company. There are many right-brained people out there who find themselves working in a position that requires technical expertise. I’m one of them.

Just the thought of taking a mathematics or science class in college sent me into a state of panic. However, I decided that if I wanted to continue to work on projects about the IT Infrastructure Library (ITIL), I better take an ITIL foundation class and get ITIL certified.

The good news was that the course did not have anything to do with science, and I could delegate the math-related activity to math wizards in the class. The class provided practical information about how to manage IT from a business perspective. We learned that people, processes, and technology need to be aligned to the business goals. In our class, the goal was to run a profitable airport.

Taking Care of Business

The class included a three-day overview of ITIL processes, exercises related to managing IT from a business perspective and a final test on content. My favorite activity was the Airport Simulation exercise. This activity gave students a chance to understand what it really means to implement have IT and business goals be the same.

ITIL was, obviously, at the heart of this approach, which entails managing IT from a business perspective. During this exercise, we monitored onscreen how much money our airport was making or losing based on decisions we made related to IT.

Our class was divided into groups of people from IT and the business, where we each assumed different roles. Our job was to solve IT problems effectively so flights could take off on time and our airport could make money. If we didn’t have adequate processes in place, and if we failed to ask the right questions, we would lose money.

Ironically, I was assigned to work with two other people as a technical services expert. It was not unusual to have three or four problems hit us at the same time, but we had a “budget” to hire consultants if we knew that we needed assistance.

A classmate assigned to the service desk would send my team a trouble ticket. We then looked up information in relevant class guidebooks and applied our newly learned skills to find the right question and solve Mensa-like math problems for closing trouble tickets.

Bad Start

We failed miserably the first round and shut down the airport. In fact, by the second round, our cumulative loss was nearly $250,000, our mean-time-to-repair (MTTR) was over 16 minutes per problem, and availability was less than 45%. That is no way to run an airport—even an imaginary one.

What did we do wrong? For starters, we didn’t talk to the business. We thought we were working on solving the right problems, only to learn we sometimes asked the wrong questions.

We were handling tickets as they came in, and they were not always based on business priority. For example, we treated the airport terminal’s catering availability with almost the same sense of urgency as a threat to the control tower: What were we thinking? We didn’t always keep the help desk informed of ticket status. With each mistake, we could see how much it was costing the company.
There are many right-brained people out there who find themselves working in a position that requires technical expertise. I’m one of them.

Just the thought of taking a mathematics or science class in college sent me into a state of panic. However, I decided that if I wanted to continue to work on projects about the IT Infrastructure Library (ITIL), I better take an ITIL foundation class and get ITIL certified.

The good news was that the course did not have anything to do with science, and I could delegate the math-related activity to math wizards in the class. The class provided practical information about how to manage IT from a business perspective. We learned that people, processes, and technology need to be aligned to the business goals. In our class, the goal was to run a profitable airport.

Taking Care of Business

The class included a three-day overview of ITIL processes, exercises related to managing IT from a business perspective and a final test on content. My favorite activity was the Airport Simulation exercise. This activity gave students a chance to understand what it really means to implement have IT and business goals be the same.

ITIL was, obviously, at the heart of this approach, which entails managing IT from a business perspective. During this exercise, we monitored onscreen how much money our airport was making or losing based on decisions we made related to IT.

Our class was divided into groups of people from IT and the business, where we each assumed different roles. Our job was to solve IT problems effectively so flights could take off on time and our airport could make money. If we didn’t have adequate processes in place, and if we failed to ask the right questions, we would lose money.

Ironically, I was assigned to work with two other people as a technical services expert. It was not unusual to have three or four problems hit us at the same time, but we had a “budget” to hire consultants if we knew that we needed assistance.

A classmate assigned to the service desk would send my team a trouble ticket. We then looked up information in relevant class guidebooks and applied our newly learned skills to find the right question and solve Mensa-like math problems for closing trouble tickets.

Bad Start

We failed miserably the first round and shut down the airport. In fact, by the second round, our cumulative loss was nearly $250,000, our mean-time-to-repair (MTTR) was over 16 minutes per problem, and availability was less than 45%. That is no way to run an airport—even an imaginary one.

What did we do wrong? For starters, we didn’t talk to the business. We thought we were working on solving the right problems, only to learn we sometimes asked the wrong questions.

We were handling tickets as they came in, and they were not always based on business priority. For example, we treated the airport terminal’s catering availability with almost the same sense of urgency as a threat to the control tower: What were we thinking? We didn’t always keep the help desk informed of ticket status. With each mistake, we could see how much it was costing the company.
By round three, we had the system processes working correctly and more than made up for losses, with a cumulative profit of $108,000. Our revenue jumped from a low of $9,600 in round one to $459,000 in round three. Availability jumped to 83%. Per problem, the MTTR dropped from 16 minutes to just 3 minutes and 30 seconds. In the first round, only 11 flights were able to take off, but we got that number up to 55 by round three.

Doing it Right

In our strategy session before the third round started, we made sure that our processes and technology implementations were effective and understood by everyone. Then we set up a clear communications strategy and defined how events would be prioritized and efficiently communicated.

Most importantly, we learned to make sure we always understood the reported problem before we provided an answer. Each time we thought we had identified the problem, I asked the person assigned to be the “business” to confirm that we really were working on the correct request. There’s no point in solving a problem if you solve the wrong one!

As obvious as this seems, we, like many real IT organizations, didn't always first checked with the business, didn't asked the right questions, and consequently sometimes solved the wrong problems.

Just as ITIL recommends, we paid close attention to working toward business priorities instead of only IT priorities, and very quickly assessed which problems we could solve in-house immediately and which ones needed to be outsourced.

We also collected a knowledgebase of answers, so that if we were asked the same question more than once we would be able to expedite the answer. We felt the pain of what happens when IT is not aligned with the business, and experienced the benefits of managing IT based on business priorities.