2008-07-14 (Monday) by Gregory Tucker.

This weekend excited me for a couple reasons:

1. I received my transcript in the mail. I am officially an MBA.

2. I passed the ITIL v3 Foundation exam on Saturday. I already had the V2 certification, so this updates my certification to the latest version of the standard.

My next step on ITIL is still TBD. APM Group has still not produced information or training on the higher certifications for ITIL V3. I will not pursue advanced certifications in ITIL V2 right now.

Posted in ITIL, MBA | Print | 3 Comments »

2007-06-28 (Thursday) by Gregory Tucker.

It is important that the help desk understand the requirements of the business. This is not as easy as it sounds for several reasons. The business consists of individuals who have different requirements. Additionally, there may be a gap between requirements as the business and the help desk understand them.

As a consequence, it is important to have a regular dialog between help desk and the business, both structured and unstructured. Unstructured communication may include making calls periodically to end-users to verify they are satisfied with the closure of a recent incident. It may include taking a department head out to lunch. Structured communication may include defining Service Level Agreements and providing regular reporting of help desk metrics.

Another critical success factor is defining the scope of services the help desk provides. I learned this from personal experience at Credit Suisse. When I joined my department was defined as “any IT-related work the developers don’t want to perform”, and I failed to redefine infrastructure support more proactively in terms that were meaningful to the business. In retrospect, what I needed to define was a service catalog, but a service catalog is not a prerequisite to running a successful help desk. At the very least, it needs some kind of formal definition to the services it provides (and doesn’t provide) that is communicated with the business.

The successful help desk also defines its processes, because its services must be professional and repeatable. This does not mean the help desk support members are little more than trained monkeys following a script—high levels of knowledge and professionalism are required too. However, it does mean the help desk organization strives for some base level of consistency that can be improved over time.

The final two critical success factors are ones I already mentioned here: reporting and training. Training of the help desk is important. The agents must be educated in the organization, its business requirements, its technologies, and its goals. Technical training is important, but not sufficient. Understanding the needs of the end users is equally important. Reporting is also important to the success of the help desk. Reporting goes beyond the simple generation of some reports. The reporting requirements must be analyzed. In some cases, new data fields or changes to data fields are required in order to create the required reports. The reporting results must be analyzed in order to draw lessons and make improvements. For example, the help desk may see that one department consistently has more incidents than others. This information can be used to recommend improvements that may reduce the number of incidents in the future.

Posted in ITIL, Technology | Print | No Comments »

2007-06-09 (Saturday) by Gregory Tucker.

Problems are issues in the infrastructure or applications that cause (or potentially cause) one or more outages, or Incidents. The root causes or Problems can be all over the map and just about anything.

For example, a printer consistently jams the paper. The root cause may be an improper paper type is loaded, or the roller needs to be cleaned every 3 months, or it may be a consistent problem with this model printer. The solution may be training, periodic maintenance, or replacing the printer. Based on the cost of lost productivity, and the costs of the potential resolutions, you can determine how you should proceed.

Sometimes the Problem resolution is merely a firmware update, which is free. This is a relative no-brainer. Sometimes the resolution is upgrading the memory, or expanding the hard disk storage. Sometimes more training is required. Sometimes you decide to tolerate the situation and document it as a known defect–the downside is less than the cost of fixing it.

The main sources of Incidents will vary from one company / environment to the next. That is why you want to track your Incidents and analyze them. There are some rules of thumb. About 60% of all outages are self-inflicted–IT makes a change. That is why a strong Change Management process is required, in order to review, prioritize, authorize, and schedule changes before they occur. Change Management goes hand-in-hand with Release Management, which is automating changes and the monitoring of changes in the production environment. IT engineers will often make changes without authorization, because they think it is quick and dirty and won’t break anything. Most of the time you cannot catch them, unless you have well-developed systems and processes for Release Management.

Posted in ITIL, MBA | Print | No Comments »

2007-05-15 (Tuesday) by Gregory Tucker.

Outsourcing may be commonplace, but it continues to confound IT executives’ expectations. Take the common myth that companies outsource to save money. Not only is this not true in half the cases, but our survey shows that most companies aren’t saving money by outsourcing.

Full Story

Hello? Is anyone home? Is this conclusion surprising to anyone? More importantly, how do IT executives know whether they will save money by outsourcing when they have no idea how much their existing services cost them? Doesn’t it make more sense to build a serve catalog and track your costs first?

Posted in ITIL | Print | No Comments »