Service Matters! ITSM & IT Management

Following on from my previous entry I wanted to highlight why development and test environments tend to be a problem area, a root cause analysis if you will.

Rather than looking at some of the symptoms that we see that challenge the on-going operation of Environment type services I think it is important to go back to the moment of birth. The picture I am going to paint is a worse case scenario, but elements of this situation haunt all major development and test environment deployments.

The birth tends to be a painful process. Usually a large development project comes along with the objective of developing some major piece of software. At some point in the process they realise they need some sort of an infrastructure platform. They have money and in a bit of a hurry they get a few servers into the data centre, hook it up to a network and some storage and dump some software services on top.

The developers then hack around a bit, get it all working, go through a few test cycles and deliver an application or service to the business. In this frenzy, or should I say, highly controlled project delivery environment, on time delivery of change is the priority. Once the software has successfully been released into the Production environment the work stops, and most likely the budget has been burned.

For this reason, projects rarely clean up after themselves and indeed there is little short term incentive to do so. What they therefore leave in their wake is a large amount of hardware and software, probably far more than is required for the odd bug fix and for which there is no ongoing budget to support or maintain properly. Releases and fixes still flow into the Production environment and some or all of the development and test environments may be left behind in terms of release updates and patches.

This then leaves the next poor unsuspecting soul that wants to deliver change to come and make sense of it all….

Posted by Bruno Calver at 10:28 AM | Permalink | Comments (0) | TrackBacks (0)

Posted by Aswin Kumar

It may be a funny debate if I start scoping out the extra number of R’s required in Change Management. Anyway, I’m not a potential author of the next version of Service Transition book yet

Of course, I always wonder why all the R’s were fitted under the magic number ‘Seven’? Was someone inspired by the ‘McKinsey 7-S Model’ or the ‘7 principles of Supply Change Management’?

Hey, Shirley and Ivor, Are you reading?

On a slightly ITILized note, have we really analyzed and implemented the 7R’s of Change Management? Recently, we came across the need for a similar philosophy where we planned to use the tenets of the 7R framework. Yes, this is for a hard-core Change Management model design assignment.

Let me first put forward my interpretation of each of the question under 7R (keywords after each question below):

1. Who ‘Raised’ the Change?  - “Who”
2. What is the ‘Reason’ for the Change?  - “Why”
3. What is the ‘Return’ required from the Change? –  “ROI”
4. What is the ‘Risks’ involved in the Change? – “Risks”
5. What ‘Resources’ are required to deliver the Change? – “Resources”
6. Who is ‘Responsible’ for the build/ test and implementation? – “Roles & Responsibilities”
7. What ‘Relationships’ are there between this and other Change? – “Impact Analysis”

Now what needs inclusion here? Any guesses? I would give 3 keyword hints for the 3 new questions: “Requirements”, “Value” & “End-Users”. Let’s go for it in the following lines.

The existing question on the ‘Reason’ for the Change focuses more on the ‘Why’ factor. The Service requirements fulfillment perspective from a change needs to be explicitly addressed.  

 “What are the Service ‘Requirements’ fulfilled from this change?” This should cover the specific requirements for the services that are enhanced due to the change implementation. For instance, if a database change ultimately modifies the Email Service component and is deployed to fulfill the Sarbanes Oxley guidelines then all the functional and legal requirements need to be documented.

Secondly, the value realization tracking seems to be completely missing. We need a question that assures the value tracking mechanism right from the inception of the change to the steady state.

 “Is the Change value ‘Realization’ plan available”? This will put an onus on the business stakeholders to define the value realization requirements and work with the enablers such as Information Technology (IT) to validate the actual value derived during the post-steady state reviews of the change. I am sure that this will generate a list of lessons learned for future changes.

Thirdly, the human side can be better addressed systematically in the 7R questions, especially when the change is of a global scale. I feel more for the end-users of the change where there is a need for a thorough and consistent diagnostics that can assess the organizational readiness to accept the Change and also be able to successfully operate it. These diagnostics need to specifically address the human behaviors, perceptions, language capabilities and build sufficient infrastructure and programs needed to drive the change globally. For instance, if a change is deployed out of the US and needs a training material creation in Spanish or Japanese for the regional offices then there needs to a dedicated planning and execution effort to close on this.

I suggest that validating this aspect is crucial for the business approvers of the change. This can also enable the business (end-users)/IT alignment.

These were my thoughts on one of my favorite topics: Change Management, what are Yours?

Posted by Guest Author at 07:55 PM | Permalink | Comments (2) | TrackBacks (0)