Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic

Home

Author

Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL® IT Governance and Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.

 

The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronym’s like ITIL, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."


Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams

Syndicate

Troy On Twitter

Recent Entries

Categories

Links

Other Blogs

Archive


Friday, October 26, 2007

Service Strategies That Work

Stop The Presses - Green Is The New Pink!

Earlier this year, we released Defining IT Success Through The Service Catalog.  The book was a hot seller and is in its 3rd printing!  Now, we’ve released Service Management Strategies That Work.  This book provides you with practical thought leadership about fundamental and strategic approaches to IT Service Management.

The content of this book comes from the writings of my fellow Pinkers as well as some of the key topics around organizational design and advanced Service Management principles we discuss here on the Don’t Panic Blog

Just like the service catalog book the topics get right to the point and provides executives and senior managers practical guidance on how to move an organization from a technology to a service centric model




Table of Contents:

Chapter 1: Introduction: Business Alignment Or Business Integration?
Chapter 2: IT Governance Unraveled
Chapter 3: The External Managed Service Provider
Chapter 4: Process Implementation
Chapter 5: Defining, Modeling & Costing IT Services
Chapter 6: The Federated CMDB
Chapter 7: Developing A Quality Driven Measurement Framework
Chapter 8: The Theory Of Constraints & Continuous Improvement

The contents of this book fit well with our strategic course called Developing a Vision and Strategy for IT Service Management based on the ITIL Service Strategy book and will be included as an additional value as part of this course.


Click on the book graphic to read the first chapter

FORWARD

The Service Organization

It is the nature of ideas, processes, structures and functions to mature and change over time as the needs placed upon those concepts evolve.  This is equally true of IT governance and the corresponding design of organizational structures and roles. The technology industry as a whole is undergoing a transformation, from one largely shaped by the leadership and personalities of individuals, to one that is becoming more defined, homogeneous and regulated. In parallel to this we see an evolution of IT management focus, moving away from a pure technology view to one focused on the needs and requirements of business partnership and integration.

To make the leap from technology management to business partnership, a cultural shift is required on the part of both the management staff of the IT organization as well as the business customer they serve, to the effect that IT is recognized as an inherent and integral part of the business organization, as opposed to a unique and separate function.

It is precisely due to this understanding of interdependency that IT governance and legislation have established public reporting and audit requirements on IT processes and controls. The result of this awareness translates into the following statements.

The financial results of a company are a direct result of its business processes.
Business processes are dependent on, and automated by, IT services and systems.
IT services are directly impacted by the maturity and controls of IT processes.
IT professionals have a direct impact on the consistency of IT processes.

From this perspective, the following are true:

  • There is no longer any true separation between the business process and its underlying technology
  • IT organizations have to understand what services they provide, and implement the enterprise processes that deliver and support them
  • IT organizations have a business and legal requirement to understand and manage how IT services are built by technology components
  • IT governance and management structures have to be in place to manage both services and processes that span existing technology management silos

This book represents a collection of advanced papers on various subjects related to the changing role of IT within a business focused service value network. Each paper was originally written as a discrete document and can stand alone on its content.  For this reason, the reader may find certain sections that seem to be repeated in other areas of this booklet. The goal of this book is to assist organizations to understand the impact of Service Management on various elements relating to IT Governance and to provide guidance on how to best apply a recommended approach.

You can find the book online at the following links:

Van Haren Publishing
Amazon.com


Our thoughts, what are yours?


”I may not have gone where I intended to go, but I think I have ended up where I needed to be.” ~Douglas Adams

 

(0) Comments
Posted by Troy DuMoulin on 10/26 at 11:14 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Thursday, October 18, 2007

Server Consolidation, Virtualization and Service Criticality

Complexity & High Risk Is An Argument For More Knowledge Not Less!

This morning I was reading my copy of Network World and pondering the trends in IT Service Management in context with the hot topics being talked about within the recent technology centric magazine articles.

For several years we have been seeing a focus on technology consolidation and lowering transactional computing costs with an emphasis of doing more with less by leveraging advancements in processor, memory, storage and OS virtualization technologies. In short, there has been a massive push to reduce the complexity of IT management by reducing the number of physical locations, applications and components that enable IT services.

Notice that I did not say that the number of IT services are being reduced!

In fact, the trend for IT Service Management is going in the opposite direction. The business need for, and dependency on digital automation, continues to rise while the technologies that support these services are being condensed and consolidated to the point that any specific component is potentially supporting multiple IT services of varying degrees of business criticality. 

This fact makes understanding Configuration Management (CMDB) relationships even more critical than it has been in the past.

For Example: Let’s say you have a physical server (a component of your Infrastructure Service called Hosting) which hosts three different virtual servers each supplying the processing support for a business application service. However, these three application services have very different levels of business criticality. Now let’s say a change has to be made to the parent physical server to address a patch level. What risk level do we assign to this change? The answer of course is that the physical server must inherit the highest risk level of the services that depend on it. This means that we maintain a clear understanding of what each component does in relationship to business outcome.

The challenge to this statement is that not only is the maturity and discipline of Configuration Management very low across the entire industry but that the complexity of tracking these relationships is growing with the move towards dynamic resource allocation. In short, an application service may be moved from server to server based on automated load balancing technologies making this critical business intelligence even more challenging to obtain.

Based on this observation there are two possible responses:

  1. We throw up our hands in frustration saying that Configuration Management will always be an impossible pipe dream not to be realized in our lifetime

  2. We realize that the very nature of the growing complexity and business need for this knowledge is the business case for why we need to do Configuration Management with a realization that it will require the use of IT discovery and monitoring tools as well as some good old fashion discipline and effort

Troy’s Thoughts What Are Yours?

”The difference between try and triumph is a little umph.”  ~Author Unknown

 

(0) Comments
Posted by Troy DuMoulin on 10/18 at 10:56 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Monday, October 08, 2007

Dealing With Rogue Support Agents

What To Do When Forward Deployed IT Support Agents Go Rogue Or Will Not Play

Many organizations with remote or branch support staff face a common and perplexing challenge. Faced with the very real need to provide onsite support, local IT talent is hired to work at distributed business unit locations. These onsite support staff typically act in the capacity of desktop support agents, application developers or service desk agents and assist with the deployment of new services and technologies to the further reach to the organization they serve. However, while they are dispersed over the geographical span of the organization they are in principle the remote arms of a distributed enterprise IT function. Recently with the adoption of IT Service Management practices based on ITIL the enterprise IT function is attempting to establish common policy, process and management tools across the various technology silos and distributed locations.

The challenge faced by most organizations is that placing these helpful folks out on the range, so to speak, typically results in a double edged sword. In one sense they provide that necessary onsite IT presence that is required by the branch or distributed business unit. However, being geographically removed from the structures, values and norms of the corporate IT function they perceive themselves as less bound by the centralized dictates and more sympathetic to the pressures and personalities of their local environment. This perception is strengthened or mitigated depending on who is paying their salary. The following list represents different scenarios of reporting lines for these remote staff in a descending order of perceived accountability to follow a corporate policy or process.

  1. Remote staff are managed and paid by a centralized IT function, they are measured and rewarded on how well they follow enterprise policy and process as well as their response to localized requirements.

  2. Remote staff are managed and paid by a centralized or corporate IT function, they are measured and rewarded on how well they respond to localized requirements. They have a dotted line accountability to a local business manager.

  3. Remote staff are hired by the central IT function but are managed, measured and paid by a local business unit manager. They have a dotted line of accountability to the IT manager within the corporate or centralized function.

  4. Remote IT staff are hired, managed, measured and paid by a local business manager. They have a dotted line of accountability to an IT manager or process owner within the corporate or centralized function.

  5. Remote IT staff are hired, managed, measured and paid by a local business manager. There is no allegiance other than good will or verbal agreements to the management functions of a centralized IT organization.

  6. Remote IT staff are hired, managed, measured and paid by a local business manager and there is little to no knowledge of their existence and the technologies they use (shadow IT functions or service desks are typically established due to a belief that the needs of the remote organization are not being met by the centralized IT function and its processes).

Depending on what model you are employing you will find more or less success in gaining the cooperation of the remote IT staff or their business unit managers for that matter to adopt or comply with enterprise IT requirements. This issue obviously poses a significant challenge to organizations attempting to adopt common service management practices. The summary of these models comes down to the simple fact of “whoever pays my salary and does my performance review has my allegiance and cooperation.” The reality of the situation is that many organizations find themselves with many different levels of the list I have made above all in practice at the same time. It is my strong opinion that any scenario below option 4 is a no-win situation for achieving the successful adoption of an enterprise process and that other tactics have to be employed. The most obvious approach is to make structural and organizational changes to the hiring and management practices for remote IT staff to resemble one of the approaches higher up than the list I have noted. However, many of the readers of this article may not have the political ability to make the necessary changes so another approach may be needed.  The second approach is to realize that if you cannot gain the commitment of these remote IT staff to adopt and follow common policies and processes then you have to define and treat them as customers. Any interaction with the enterprise IT processes such as Incident support, Change Management, Security, Procurement, Architecture, Consulting, etc., must enter the defined entry point for that process. For example, if the remote IT staff needs the cooperation of the Incident or Change Management process they must enter the process by calling the Service Desk as would any non-IT staff member that is not “part” of the process so that the appropriate workflow record can be logged and the correct process engaged. Of course they are going to want to by-pass this process since they know they can get their answer or aid quickly by calling their buddy in the central IT function. A quick phone call to Server Sam, Network Nancy or Darren Database and they can get instant action or information they have come to expect. The challenges with this approach are obvious and are the same ones we claim for anyone who bypasses the correct process or standard operating procedure. Typically their call is not logged for business intelligence or prioritization and an underground reactive support economy flourishes and saps the thin resources to the detriment of a kind of proactive approach to IT management. My advice is that if these roles refuse to operate within the process then they have earned the right to be its customer under the same conditions as any other customer would expect. In short, they can choose to be in or out of the process but both decisions come with consequences and activities that are different to what they are experiencing today. What you are doing is defining the rules of engagement for all customers of the process regardless of who they work for. Here are some typical scenarios for remote or forward deployed staff that resist participation in an enterprise IT policy or process.

  • Francine Frontline: Francine was interviewed by the central IT desktop support manager but hired by the branch business unit manager to provide desktop and miscellaneous IT support for the remote branch. She quickly became a hit with the branch users based on her ready smile and willingness to drop everything and drop by their cubicles.  Her emotional and financial allegiance is to the branch and not to a distant corporate IT function. She has been asked repeatedly to log her Incidents in a support tool by the central service desk but she refuses to do this due to a belief that she is being paid to respond quickly to branch needs and not paid to do paperwork. This belief is shared and supported by her direct manager at the branch

  • Andrew Appdev: Andrew belongs to an application development and support group that is managed and funded by a large business unit. While Andrew spends his whole day either developing code or supporting application based Incidents he and his fellow developers do not perceive themselves as being part of IT and not connected in anyway with the infrastructure organization other than they require services to host their applications.  They resent having to follow any policy or process which emanates from the corporate IT function. This perception of separation is augmented by the fact that he reports to a business unit CIO who is a peer of an Infrastructure CTO without any Executive CIO establishing enterprise IT policies and process across the entrenched technology silos.

Sound familiar? For more on this subject see the post on Service Organizations: The Service Organization Part 2

These two situations are perfect candidates to be introduced to the process as customers, until such time, that they realize that they are in-fact part of the larger IT Enterprise and are integral parts of what ITIL calls a Service Value Network and Eco-System.

Troy’s Thoughts What Are Yours?

“You know sometimes people tell you stories that are supposed to be something that happened to their wife’s cousin’s best friend, but actually probably got made up somewhere along the line.

Well, it’s like one of those stories, except that it actually happened,  and I know it actually happened, because the person it actually happened to was me.” ~ Douglas Adams

 

 

(0) Comments
Posted by Troy DuMoulin on 10/08 at 08:49 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Page 1 of 1 pages