Informal Brain

I have been reading a flow of posts over on IT Skeptic discussing why creating an end user focused Service Management process drives the biggest bang for the buck within the ITIL v3 framework. Lets think about how users get services within any organization.

Channels:

1. Phone
2. Web
3. Email
4. Instant Messaging

Service Providers:

1. IT
2. Project Managers
3. Finance
4. Procurement
5. User Acceptance Testing

Key aspects of providing a clearly defined service:

• The User of the services needs a clear way to use each of the channels to reach the service provider.
• Where the user consumes the service the service must be clearly defined and provide “hints” to the User so they can provide required information so the service provider upfront. The “hints” must be in end user terms.
• All requests for service need to be queued and prioritized. Think about how many services are provided via email and the disaster which occurs when your inbox is full of responses to questions. You can no longer keep the queue straight.
• The execution details of actually executing the service should be hidden from the User. For example the User isn’t interested in the detailed tasks or collaborations which are required to dig into a capacity request and provide a response.
• There should be only one place all the channels end so users can always have a consistent experience.
• The user should have the ability to switch channels during service acquisition. For example, they may start by submitting a request on the web, but they may discover that the priority needs to be escalated. The User should be able to get a Service Desk Analyst on the phone and discuss how to escalate.
• At the end of the service the user should be surveyed to understand their satisfaction with the service. The survey results should be used to provide continuous improvement to the service structure.

Components of a well defined service:

• Service Description – An end user focused description of what they will receive as a result of requesting the service to be performed.
• Service Requirements – An end user focused script which leads the User through a set of questions which help discover requirements needed for the Service Provider. The better this script is the less times the Service Provider will need to consult with the user to clear up what is required. Continuous improvement is key in this space to reduce cost.
• Pre-defined service Execution Plan – A set of repeatable tasks which the service provider will use to deliver the service. The tasks provide a vehicle to deliver the service the same way every time with lower risk. Lessons learned and review of the tasks at a frequent interval should help drive down cost and remove errors which may occur.
• Clear Approval Process – The approval process for Service Execution should be pre-defined and the approvers should be pre-defined.
• SLA – A clear Service Level Agreement will help the user understand when they should expect the service execution to be complete. This reduces unnecessary queries to the service provider. These queries are a critical distraction.

Service Pipeline:

Channel -> Service Request -> Change Request

Service Contact Flow:

User -> Service Desk -> Service Owner -> Approver -> Specialist -> Service Desk -> User

I am currently running a project using Agile SCRUM to deliver a CMDB solution, an Upgrade to Remedy Version 7 and ITILv3 processes. Obviously this type of effort has some pretty profound impact on the organization especially when there are years of process, policy and belief which currently govern perceived best practices.

Obviously the goal of any ITIL implementation should provide an adequate set of controls, and awareness and collaboration within the Enterprise. The teams consuming the current processes are looking for ways to optimize their work, while still conforming to the core principles above.

We have laid out certain goals to mine out more standard changes within our organization to streamline IT. It is apparent that the focus of the organization should be on the large, complex and risky changes while metrics collected during problem management should help us understand if have turned the knob too far one direction.

One of the teams brought an interesting problem to us today. They wanted to document a set of activities which would not require even a standard change entered into out change management systems. This at first raised concerns on my part until I reviewed the kind of things they were talking about. They were asking about day to day system administrative tasks which in my mind would not fall under the definition of a change with ITIL:

The addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation. — Source ITIL v3 Glossary

What is interesting is that by this definition many day to day administrative tasks such as cleaning up logs, running jobs, etc really don’t fall under the definition of “Change” as they are not modifying a managed CI. For example if an UNIX admin needs to clean out /var should a change record be required? Some may argue that it could affect the system but I believe we could argue that most times it is completely safe.

So my thought here is to require a published document which outlines these types of Day to Day activities which are not changes. The standard would be reviewed and managed under change management and be approved by the CAB. These types of day to day activities would not require any change logs or records within our Change Management system. If problem management shows by trend that this day to day work is causing incidents then we reel them back to Standard or Non Standard Changes.

I would welcome the thoughts of others…

Change management is a tricky subject and is something that has been on my mind for some months now. I have realized that being recognized as an effective change agent requires understanding the psychology of change and knowing where your audience is spread along the change transition curve at any given time.

The change transition curve, shown here:

… provides a way to think about where your audience lies along the curve. At the beginning of any change naturally folks quickly move to a place called “Endings”. At the endings point the audience for change begins to understand they need to give up the old way of doing things. This typically generates a great deal of discomfort and pushes them into the Pit of Despair or as it is also known “The Neutral Zone”. The goal of any change agent is to move the audience out of the Pit of Despair to a state of “New Beginnings” where they accept the change and integrate with the change.

It is important to understand that the audience can be analyzed in many discrete groups with the transition curve. You can analyze where the entire audience is at. You can break down your audience based on criticality for the change to succeed and even break down the audience to discrete members. At any given time these groups may be at many places along the curve.

For example at a macro level the entire change audience may be viewed as moving to “New Beginnings” but some members of the audience may still be in the Pit. Those outliers may be more damaging to the change success then is immediately realized. It is also important to recognize that the actions of an outlier or external forces can easily force the entire audience or certain members back into the Pit. The reinforcement phase of the ADKAR model serves to keep people at the New Beginnings point. It is important that the audience is hearing about the change requirements regularly and frequently post awareness and ability phases of any change.

So, in conclusion, think about the curve and where your audience is at. Think big picture and consider the individuals you are targeting. At the lowest level, everyone needs to be driven along the curve and receive reinforcement to the New Beginnings to drive successful change.

When you are in a position of rolling out change to an IT environment the two most frustrating things you can hear are:

1. How come this is in stealth mode?

Typically what this means is you are running all over the place delivering the message right on target but somehow you have managed to miss the key target audience the person asking the question believes is critical to the success of the change.  Time to understand how to get out of stealth mode where it really matters!!

2. How long has it been since you have last seen this?

Arg, frequently the answer to this question is many shades of “too long”.  Rolling out change takes time, and lots of repeat performances of the same message over and over again.  Unfortunately with any change people naturally think the message has shifted during the last two weeks since they saw it last.  What they don’t understand is as a transition manager you are delivering the same message time and time again to different groups.  That three weeks has been spent delivering the same powerpoint 15 times, exactly the same way, with exactly the same message to 15 different groups.