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

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

How run books or work instruction procedures makes your IT team more efficiency and can save face!

‘What’s Your First Team?’

 In Patrick Lencioni’s fable ‘The Five Dysfunctions of a Team’ this is the question the new CEO asks her team of direct reports. Her point is that her leadership team: first, has to be a team; and second, that the leadership team itself has to be their priority. Too often this is not the case, leaders are closer and more loyal to the functional groups for which they are responsible.

 In our last post we discussed the temptation to reorganize that afflicts many leadership teams. Such reorganizations are often not successful because they do not begin with an understanding of the purpose of the organization chart. The result is that the chart is reordered, but the organization and the way it goes about its work is not truly restructured.

 In his recent ‘Predictable Success’ Les McKeown states that the organizational chart is meant to be a tool for decision making. To be an effective machine for decision making, management roles must be clarified and the organization must be prepared to work cross-functionally. Each management level must see their peer management team as their first team. This must begin at the highest leadership level.

 Most organizations do not evolve in this way and this is particularly true for most IT shops. We can illustrate this:

 The above graphic is a whiteboard that lists the brainstorming responses to the question, “What tools do you use to track your work?” This question was posed to representatives from an IT organization of about 500 people. (Yes, these responses were all from within the same organization).

 This graphic leads to some questions:

• If there is no central repository to track (and measure) the work that is being done, how can management obtain an accurate and consistent understanding of what is happening in the organization? We mean the whole organization, not just the separate functional units.
•  If there is no such clear understanding, how can the leadership team be a leader’s first team?

Clearly, the lack of coordination at this basic level of tracking and monitoring work indicates an organization for which the leaders are closer to their functional teams.

 If this is not addressed, if the work is not restructured such that everyone is doing similar things in a consistent way,  no level of shuffling an organization chart is likely to lead to lasting improvement. The first task is to address the symptoms and that means understanding and structuring how the organization does its work at its most basic level. Only then can the organization chart be turned into an effective machine for decision making.

- Bill Cunningham
bill.cunningham@cppit.com

“…we have observed that our current system of (job) titles is inconsistent. Our reorganization… provides an opportunity to take a fresh look at titles …”
 

The above is a quote from an IT organization that is undergoing a major reorganization. This is at least the third such major restructuring that this IT shop has undergone in the past 5 years.

 The leadership team has worked on this for 5-6 months and they are now focused on getting the job titles correct on their new organizational chart. For half of a year the line workers and middle managers have been waiting for the details of the managerial reshuffle. What do you suppose this has done to morale and effectiveness?

 Reorganizing is a frequent activity for managers unsure of how to improve performance. Sometimes a reorganizing effort is necessary and useful, but more often it is an excuse to do something when faced with a crisis or other driver to improve. It offers the balm of activity and the hope of making things better.

 A reorganization can be exactly the right thing to do, but only if it is clearly understood what the reorganization is intended to accomplish and how the revised organizational chart will help.

 Otherwise an organization can fall into a sort of trap. When the first reshuffling does not work, then a second, and even third, reorganization is undertaken.

 In ‘The Fifth Discipline’ Peter Senge makes the point that many organizations frequently reorganize only to find that the underlying issues they were seeking to address resurface. This is because there is an underlying systemic structure that is not addressed by the new org chart. The old patterns of behavior re-assert themselves despite the new formal structure.

 Management is indeed difficult, but IT Leaders are fortunate. They have available a set of best-practices frameworks that provide guidance in addressing many of the deeper structural issues in their organizations.

 By adopting a Service Management best practices management framework, such as ITIL, IT leadership can begin addressing the structural issues that are likely prompting the idea to reorganize. A reorg may indeed follow, but at least it will be the result of providing true re-direction and restructuring.

 This is admittedly more difficult than spending five months meeting over lunch and working on a new organizational chart and consistent job titles. But it is much more likely to lead to lasting change, and to set the stage for consistent improvement.

- Bill Cunningham
bill.cunningham@cppit.com

Unequivocally, tools should not lead the process. Gather your requirements, define your processes and then choose a tool that most closely aligns. But when looking for a tool what are the top 5 things you should consider?