Wednesday, December 05, 2012


Friday, June 01, 2012


ITIL outsourcing rarely, if ever, works for several reasons but mainly because vendors have little or no resources with the requisite knowledge and experience to successfully deliver what the customer needs. Further, the cost constraints of outsourcing agreements lead only to vendors acquiring low-cost, barely qualified resources to meet staffing requirements. After all, the outsourcers is in business to make a profit.

IT Managers would do well to remember that profit comes from keeping costs down. One of the biggest overhead costs for IT outsourcers is labor.

High quality does not equal low cost.

Saturday, March 10, 2012

Finally an ITIL article that begins to address real concerns.

Wednesday, December 07, 2011

Wednesday, November 09, 2011

How to Keep ITIL Project Momentum

Here's the quick and dirty from a consultant's perspective:

  • Establish specific and realistic goals with milestones
  • Don't get too ambitious
  • Identify project sponsors with skin in the game
  • Create awareness of project objectives
  • Identify and achieve project quick wins
  • Provide context for the project
  • Teach rather than do
Consultants, often out of frustration with organizational culture and politics, wind up completing the entire project themselves. I've seen this happen so many times. It is mostly due to the lack of leadership or clearly defined project roles and responsibilities from the client organization. Instead of providing advice and guiding a customer, the consultant will take over the detailed project tasks just to be able to complete a project and move on.

Rather than this, the consultant should play the role of advisor, providing guidance to the client throughout the project lifecycle. At times, the consultant will lead the team through various workshops and exercises as a learning tool but the consultant should never take over the project. Our jobs as consultants should be to teach the organization how to keep going long after we've left. This message should be clear from the outset of the project and should be reiterated thought the entire project.
  • Create a team of capable and willing participants
There is nothing worse than trying to move a project forward with the wrong team members. This would include team members who haven't a clue what the project is about and have nothing to contribute as well as those who are able but who resist change at every turn with constant complaints or excuses.

In short, if the project is important (as every project worth doing should be) be sure to carefully select core team members who are both willing and able to contribute to the success of the project.
  • Set regular face to face meetings with team members
With advancements in modern technology, distributed or remote project teams are becoming the norm. This allows for an organization to reduce costs and leverage the expertise of individuals at different locations around the globe. The downside, of course, is what is lost when there is little or no face to face communication. Face to face communication is essential when building project momentum. It makes it easier for team members to feed off of the energy and ideas of others.

Besides setting regular meetings, our recommendation would be that whenever possible, assemble all team members together in a room for the duration of the project phase. This facilitates idea generation and problem solving and keeps the project on track.
  • Break the project down into bite size mini projects or phases
This is important to prevent the project from seeming like never ending drudgery. If at all possible, it's also a good idea to try to replace a few of the core team members at the beginning of each new phase. This prevents burn-out and brings a fresh perspective. Have you ever tried to maintain excitement for a project that lasts more than 3 or 4 months?
  • Don't do projects that have no benefit to the organization
This is the hardest of all for consultants to follow because, after all, we're in business to make money. However, there is no way to win on a project that has no clear benefits to the organization. How do you measure success? Who determines whether the project was worthwhile? Most importantly, these types of projects are the prime candidates for loss of momentum. After a while, every loses interest because it becomes evident that there is no greater purpose. Everyone eventually realizes that it is a waste of time, money and resources.

Lastly, the consultant's reputation may be jeopardized by their involvement in a meaningless project. A consultant most valuable assest is always his/her integrity. This should not be bought and sold for any sum of money.

ITIL & IT Service Management

Monday, May 02, 2011

4 Components of A Successful IT Strategy:

1. Develop long-term, simple, clear, measurable and agreed upon objectives.

2. Gain a profound understanding of your IT customers.

3. Develop an objective and rational understanding of your internal resources and capabilities.

4. Develop a plan to effectively implement strategic intentions.
Published with Blogger-droid v1.6.8

Sunday, May 16, 2010

What is Service Availabiltiy?

The following is an excerpt from a comment posted on a TechRepublic forum in 2008. The topic, however, remains relevant:

By now, we should all be aware that Availabiity should be measured by Service. This means that if there are several systems necessary to deliver a service (email, internet access), we should measure the average uptime of all system components required to deliver that service. In doing so, we can arrive at a predictable level of uptime.

This is the baseline used to determine the improvements necessary to meet customers requirements and expectations regarding availability. If a higher level of availability is required, then additional components (bandwidth, storage, memory) can be added to reach the desired level of availability.

Additionally, availability is always relative to the timeframe in which it is measured. This means that a service that requires 99.999% availability between the hours of 9-5 (M-F) may be much different (in terms of architecture & resource requirements) than a service that requires the same level of availabilty 24/7. Thus, not every service requires the same level of availability.

This concept of relative availability is one that is always missing from the discussions of uptime.

What is also missing from these discussions is a definition of "uptime" and the impact of performance on that definition.

If a service is available but very slow, is it still considered "up?"

Here is where the specifics in a Service Level Agreements become very important.

The ITIL library provides guidance on these and other IT Service Management process disciplines.

ITIL & IT Service Management

↑ Grab this Headline Animator

Incident or Service Request?

My 2 Cents...

We are often asked to conduct small workshops for IT organizations to help Service Desk agents to better understand the differences between Incidents and Service Requests. In most cases, once the differences are explained and a few example are provided, people start to get it.

However, there are some instances when simply looking at a list of examples is not an effective approach to the correct classification of Incidents. This is primarily due to the fact that no list can predict every possible user call to the service desk.

While it may be possible to capture, record and classify the most frequent system breakdowns and user requests, the possiblities are infinite. If there were such a rule, we could simply program a computer to do the work and save a lot of money.

Until then, Service Desk agents will have to use their knowledge of IT and ITIL to make the determination.

For example, sometimes the difference between an Incident and a Service Request is determined by the details. An error downloading software to a user workstation can be attributed to several different causes.

The user could lack the appropriate knowledge or skills (Service Request)or, the error could be related to a fault in the infrastructure (Incident). By asking follow-up questions, the Service Desk agent, should be able to determine to most appropriate classification and course of action.

The point, is that in many situations, it is "why" rather than "what" the user is unable to do that determines whether the ticket should be classified as an Incident or as a Service Request.

Understanding this helps the IT organization to produce more accurate reports about the health of the inftastructure. These reports are also useful in identifying areas for targeted improvement and user training opportunities.

This post was contributed by Danielle Baker, Managing Director of Red Engine Consulting. Danielle is a certified V3 Expert and has extensive experience in ITSM, Organizational Change and Project Management.

ITIL & IT Service Management

↑ Grab this Headline Animator