I’ve written several times about the service catalog.  It’s one of those things that is as powerful as it is confusing.  Developing a service catalog is an evolutionary project.  As with any project that should be done in phases, where you start depends upon what your needs are.

Let’s start by looking at the benefits of the service catalog:

Rolling out new concepts, processes and procedures in the vast majority of organizations is bound to shake things up.  But when the culture is institutionalized the shift is seismic.  Kotter’s 8-step change model gives good guidance, but it is important to note that all 8 steps are important.

Step One: Create Urgency

Step Two: Form a Powerful Coalition

Step Three: Create a Vision for Change

Step Four: Communicate the Vision

Step Five: Remove Obstacles

Step Six: Create Short-term Wins

Step Seven: Build on the Change

Step Eight: Anchor the Changes in Corporate Culture

Once you’ve introduced change into an organization, it’s very easy talk yourself into the fact that you’ve won the battle.  One of  THE most important steps in this very practical approach is building  “powerful coalition”.  Without winning the hearts and minds of people in a position of leadership in the organization, it is very easy, in fact almost predictable, that the organization will revert back to its original behaviors.  The “coalition is key”.  Although the CIOs commitment is important,the key influencers, stakeholders and mid-level managers are the real drivers of day to day process conformance.  If they haven’t bought in the snowball of behavior reversion rolls down the hill very quickly.  Make sure your “powerful coalition” is in place to lead the change you seek to make.

There was recently an interesting discussion on one of the Linked-In groups concerning whether an ITIL initiative could be started as a grass roots effort  in one section of an organization or if it needed buy in from the top.

Of course, support from the top- such as strong executive sponsorship from a  CIO that has already formed her first team, is the ideal. It would also be helpful if the organization develops some underpinning organizational behaviors, such as a process management approach and project management discipline, before embarking on ITIL adoption.

Unfortunately, this ideal state is not always present. This does not necessarily mean that best practices and  ITIL have to be ignored however. Depending on the type of organization and the culture, it may be possible to kick-off an ‘ITIL initiative’ without sponsorship from the top.

In the best of cases this is a more delicate undertaking than the classic model. There are dangers associated with being an ‘agent of change’; particularly if you think you are going to force the organization to adopt a best practices framework. Lacking executive sponsorship, you need to start small.

Stephen Covey’s  7-Habits of Highly Effective People describes the concept of a ‘Circle of Concern’ and ‘Circle of Influence.’ The point is that you should focus on your ‘Circle of Influence.’

Applying this concept to an IT manager who would like to improve her organization’s performance but who lacks the executive buy-in that would ideally lead to universal adoption of the ITIL, or other best-practices, framework –  focus on the Circle of Influence. Adopt a process approach and use the portions of the ITIL framework that apply to your portion of the organization.

If you are a Service Desk manager you may not be able to influence the entire organization to adopt the same Incident Management process. But you can document a consistent Incident handling process for the your Desk and work on using a consistent Knowledge Mgt process to drive consistency.

One of Covey’s points is that by focusing on your Circle of Influence, by changing and improving what you can, you may find that this Circle of influence grows. If you apply a consistent process approach to your units, you may find that you gain the credibility to expand these nascent ITIL processes deeper in the organization.

I have seen it happen.

-Bill Cunningham

bill.cunningham@cppit.com

Service Management initiatives can be help drive better IT operational efficiency and effectiveness when you understand where you are and what improvements can help you meet your goals. As more companies start to consider implementing IT Service Management (ITSM), turning to professional consulting organizations for help with process definition and implementation can help to facilitate a successful program implementation.

It is, however, important to note that implementing ITSM good practices is much different than implementing technology. When implementing technology, there is a tendency, particularly within large companies, to heavily leverage consultants for the lion’s share of the work. Consultants are brought in to do any and all of the following tasks:

• manage the project(s),
• gather, and in some cases even specify the requirements,
• develop or configure software,
• implement necessary hardware,
• document the efforts,
• develop and deliver training and conduct the rollout .

In essence, much of the effort to deliver new technology capabilities in the form of IT services is often outsourced fairly routinely, and in many cases successfully. Ongoing success of service operation of these new technologies would require that internal resources are trained to provide support or that the appropriate outsourcer is in place to assure successful service operation.

The implementation of an ITSM program, however, is quite different. With respect to implementing good practices, we are primarily talking about instituting new or modifying existing processes and practices. While one or more ITSM consultants used in the “staff augmentation” model, as described above for technology projects, can crank out process documentation and help to specify requirements for automation, they cannot define your processes for you nor can they, alone, affect the behavioral modification required for successful implementation and ongoing continuous improvement. Getting to “success” with ITSM includes organizational transformation. People in the organization must adopt new policies, modify their procedures and embrace new responsibilities. We are talking about changing the way people do things.

To be successful, the drivers for such change cannot be outsourced. The message of expectations, urgency and sponsorship must be communicated early and often by senior IT management. A steering committee of senior managers along with your ITSM consultant(s) should form the guiding coalition to lead people in the organization through the changes that will be necessary to reach goals that need to be attained. In addition, each of the various teams involved in the daily activities of each process being defined or modified should be represented in the working teams that will define the processes they will be expected to use on a daily basis. Without this level of involvement process internalization and the sense of ownership that is necessary for long-term participation and continuous improvement is less likely to occur. Lastly, the system of rewards must be adjusted to reinforce the transformation you are hoping to achieve with implementation of retooled process and service management behaviors.

Below are 5 steps for using consultants for your ITSM program to promote successful ITSM implementation:

1. Use your principal consulting resource as a program mentor. This person can help you structure and plan the program and guide you in the right direction. Assign your own program manager and expect that this person will spend between 50 and 100% of their time (depending on the size of the organization) directly involved in this effort
2. Fight the urge to expect your consultant to give you an out of the box solution. Expect that if your consultant has worked with other customers in your industry, they can leverage this experience to help you streamline solutions for your need, but the size and nature of your organization will require more specific solutions to meet your needs.
3. Appoint Process Owners to work with consultants to define each process. Expect these individuals to spend 25 to 50% of their time (depending on the size of the organization) in the definition phase of this project. This process owner should be responsible for helping to identify a cross-functional working team for their process area to assist with process definition and roles and responsibilities.
4. Use consultants to facilitate process definition workshops.   Consultants should be trained in meeting facilitation and process modeling to provide objective, informed guidance to the overall project.
5. Once the process has been vetted and agreed to by the process team, consultants can be used to document the process, create training materials, solicit requirements and write requirements documents for process automation, train employees, assist in developing communication materials.

The development and implementation of your ITSM program cannot be outsourced to consultants. The typical staff augmentation rules for technology projects do not apply. The fundamental organizational and behavioral changes that accompany process improvement require direct involvement throughout the program from high level IT management and other players in the organization. Working in conjunction with your ITSM consultant(s) your IT organization can implement effective processes to help you achieve efficiencies while improving levels of service. But if you abandon the importance of your role in the process and think that you can hire a consultancy can come in, implement, educate without requiring sponsorship and time from individuals in the organization you are likely going to spend significant dollars with little return on investment.

Valerie Arraj
valerie@cppit.com

I don’t like the fact that I have a trust issue.  I wish I could change — but I can’t.  Oops sorry folks, I thought I was in my therapist’s office.

Last week’s issues with LastPass (LP), read here, should make me want to flame them to crispy pieces.  Alas, I have no one to blame but myself.  Unlike my other overdone, paranoid-driven steps to protect myself, I was not properly prepared for this outage.  The result:  I was completely locked out of several of my business accounts where I solely rely on LP for authentication.   LastPass is a password manager that stores passwords so you don’t have to remember them.

This outage got me thinking.  Are we getting too complacent with cloud services in our business and personal lives?

Sure, there were contingencies I could have put in place.  For instance, did I download pocket LastPass (the version where you can access your secure notes and passwords without having to rely on the internet)?  “No”.  Did I export my LP data to a file and encrypt it?  “Ah, no”.  (Imagine head banging against wall here).

I’ve always been careful to backup my business and personal data.  I have a 1TB Firewire encrypted drive that I use to backup my PCs.  In addition I utilize Dropbox as my file system, storing these files locally AND in the cloud.  I also backup my critical business files into the cloud, periodically zipping and exporting both folders and Outlook data to Carbonite.  Way over the top?  Why yes, of course.  But that is just me.  Do you think I would follow the same paradigm with *ALL* of my authentication information for my most critical access needs?

Now why did LP cut me off like a rich father cutting off his deadbeat son?  Because they experienced an “anomaly” on their network.  Learning from their past, they promptly and proactively set up safeguards, which unfortunately left many — including myself — unable access our passwords.  Let this be a lesson to all, there is no safe haven, even in the Cloud.

Build your own safeguards, controls and processes into your cloud strategy for your business and don’t be complacent.

- Jay Martin (jay.martin@cppit.com)

Often unnoticed by casual fans and underappreciated by the more experienced, footwork is a fundamental skill that separates the good from the very good. Footwork is a Critical Success Factor for great basketball play.

Aditi Kinkhabwala had a very nice piece in the Wall Street Journal that links Kemba Walker’s basketball success to the footwork he developed studying dance as a youth. Before picking up roundball the young Mr. Walker was a very serious student of dance, appearing a few times at the Apollo Theatre.

Quoting the article: ‘The hints of this training in his basketball moves are subtle, but to those who know dance, they’re unmistakable.’

What does this have to do with IT Transformation and ITIL? Well, to have success sometimes you have to put the time in to develop the fundamentals. Just as footwork is a critical success factor for basketball stardom, a process approach is essential for a successful ITIL adoption.

Just as Mr. Walker’s career began on the dance floor, perhaps your IT transformation might better begin with re-engineering a cross-functional business process or two.

When starting with ITIL, many organizations stumble on defining and introducing the processes that are a central part of the framework. Culturally, the organization is just not prepared to think in process terms. So the initiative must attempt to introduce two things at once; process fundamentals and the specifics of the ITIL framework. This adds considerably to the challenge.

Just as it’s easier to advance in basketball if you already know how to move your feet; it will be easier to make progress in implementing ITIL if your organization already naturally ‘thinks in process.’

-Bill Cunningham

bill.cunningham@cppit.com

In his recent and persuasive book ‘Predictable Success’ Les McKeown models the organizational lifecycle; identifying typical  stages of growth and decay.

After emerging from ‘early struggle’ an organization will typically hit a ‘fun’ stage. In a fledgling business this is the stage where a market has been found, sales are the overriding order of the day and growth is relatively easy because the operation is starting from a relatively low base. This is the stage where the ‘myths and legends’ are formed. The organization is relatively unstructured and has the luxury of being agile due to its relatively small size. A ‘hero-culture’ can develop; accomplishments can be made through sheer force of will.

Does this sound familiar? It describes the growth history of many IT organizations. For IT, this ‘fun’ stage was when the technology was relatively new and was advancing at such a pace it was difficult to just keep up. Many IT shops  grew rapidly, often in an unpredictable fashion. Demand was high, the technology was constantly evolving and IT was constantly working on delivering the latest and greatest solutions. It was fun, and this level of organization works…

… until it doesn’t anymore.

In McKeown’s model, a growing organization emerges from ‘fun’ to ‘whitewater’ when the growth that is the result of the ‘fun’ phase adds a level of size and complexity to the operation. It does not happen all at once, but slowly the old organically developed ways of operating start to become stretched beyond their capacity to deliver. Examples might include late production runs, orders don’t ship, customer complaints increase. In IT, outages due to failed changes increase; projects are cancelled, or just never delivered.

Firefighting becomes a predominant mode of operations. The old ways of doing business no longer smoothly work, the organization is having trouble keeping track of what is going on. The experience is one of confusion, the feeling that things are slipping through the cracks The organizational ship can no longer be steered effectively – - hence the designation ‘whitewater.’

The answer, which is not always immediately obvious, is to add a bit of structure to the operation. Formalize some processes and modify the organizational chart to take account of the new more complex reality.

McKeown makes the recommendation that to emerge from ‘whitewater’ into the more mature form he terms ‘Predictable Success’ an organization is going to have to embed some structure and processes.  His advice is valuable, but it is a little short on defining the specifics of how to proceed to define this more formal organizational structure and accompanying business processes.

Fortunately, once  IT leaders recognize their organization’s transition to a ‘whitewater’ stage they are fortunate in having  a number of frameworks of best practices to guide them. ITIL would be an example of a framework that can be adopted to help re-structure an IT shop’s business processes and internal organization to help with the emergence from ‘whitewater’ to ‘Predictable Success.’

There is no magic formula of course, either in McKeown’s model or the ITIL framework. But, again, for IT it is helpful to have a readily available set of proven best practices that can be tailored to fit the unique challenges of your IT shop’s struggle with the rapids.

-Bill Cunningham

bill.cunningham@cppit.com

I can relate to Valerie’s comments in her recent post in this space concerning the efforts of many managers to find a simple path to ‘implementing ITIL.’ When discussing the ITIL program at one organization and touching on some differences between the Version 2 and Version 3 ITIL releases I was asked, ‘what version are we on?’

Well, it doesn’t quite work that way. As Valerie indicates-  ITIL is not a product, it is a body of knowledge. No organization is ‘on’ ITIL v2 or ‘on’ ITIL v3. The framework offers guidance and an organization can choose be to be guided by either version, or to derive useful insights from a combination of the two versions. I know that this does not provide any easy answers; but then Valerie is correct that there is no easy recipe for service management processes.

It’s even worse, as there is no easy template to apply to define and manage any business process.

‘Sometimes it is simplest and shortest to take the long path.’

If the above  is not a statement made by a Zen master, it should be. How does it apply here? One of the most successful ITIL adoptions  I have witnessed did not begin with defining an ITIL process, or looking for an ITSM Tool at all.

Recognizing that a process approach was a necessary critical success factor for adopting ITIL,  the organization began by redefining two critical IT business processes using a Six Sigma methodology (and CPP can help with that…). Key to this was the fact that these processes were cross-functional, i.e., they required the participation of several of the different IT units to work correctly.

Two other keys were the designation of a process owner and managing the process development as a project. The result was a well-understood business process that was managed across functions. This helped to change the culture of the organization to understand the importance of process and project management.

Rather than starting with evaluating a tool, this organization understood that defining and managing a business process is about defining organizational behavior. They sought to embed a  process management approach and this prepared the organization when it was time to embed the ITIL processes.

This ‘long path’ put them ahead of many organizations that have begun with the idea of looking for a simple ‘in a box’ automated solution.

-Bill Cunningham

bill.cunningham@cppit.com

There have been many times when I have been questioned about the master process template for ITIL – as if it ITIL were a product as opposed to a body of knowledge.  As is the case for most of us who are in the field of leveraging technology to solve problems and automate business process, we would love to solve as much as possible with a tool.  It’s familiar; it’s tangible; we can relate to it.  And we think it can get us to the solution we seek with a greater degree of expediency – depending on the tool, that is ;^).

Unfortunately, there is no one-size fits all template for service management processes.  Fundamentally, once implemented, the processes for managing services have similar properties.  For example, at a high level the objectives, the inputs and the outputs or the change management process all look the same.  But the nuances of a large company in a regulated industry will make the change mangement process have very different gates than a small company in a non-regulated industry.

So, in a fast-paced world, when we would like to get to the end point model as quickly as possible, by implementing the one-size fits all solutions given to us by tool vendors, we may want to think twice before just implementing “ITIL in a Box” and running with it without considering how the specific needs of the organization to operate process successfully.  The tool itself may work well with the proper configuration, but unless we have properly considered the process steps appropriate for our organization’s size, industry and governance needs and addressed any cultural changes that will lead to successful adoption, chances for success are pretty slim.  Spend the time to figure out your process needs, define your processes and then select and configure a tool to closely align.

valerie@cppit.com

I’ve used jumper cables on dead batteries before.  I just don’t use them every day. So when a lady asked for help starting her car, I was enthusiastic about using my shining new jumper cables my wife bought me for Christmas.  As I removed them from my trunk, I starting thinking to myself “Do I connect the positive or negative to the dead battery first or the working battery?  I wish I had this written down.”  My mind was frantically searching for the good practice in order to avoid damaging my car or risking a fire. Fortunately, my fellow worker Bill was there and together we pieced together an apparent safe solution to start the car and claim our “Good Samaritan” status.

I was able to convey this parable to the client that we were meeting moments later.  They had just made a large investment in a new network infrastructure that included fiber/CAT 6 and shiny new core network switches, routers and firewalls (a la my shiny new jumper cables).  Before the meeting, the CIO shared a struggle with getting an outage notification routed to the correct individual within the organization to begin the Incident Management process. The incident was unfortunately escalated to the president which in turn made the IT group look disorganized.

That brings me to the point about having well thought-out and easy to locate work instructions (or procedures) that can be used by Service Desk Analysts during possible stressful events.

A simple example:

For outages affecting Tier 1 systems (provide list of Tier 1 systems):

1)      Log a ticket within the ticketing system and escalate to the System Service Owner (provide list of Service Owners here)

2)      If the incident is not remediated within (state period of time), escalate to the manager on duty.  (provide manager on duty and contact lists here)

3)      And so on…

It is wise to assign a point person accountable for reviewing and validating any knowledge prior to placing into production.

- Jay Martin (jay.martin@cppit.com)