Picked up

Happy to note that our recent post on Change Management was released to the larger ITIL community as this week's DITY by ITSM Solutions.

http://www.itsmsolutions.com/newsletters/DITYvol6iss1.htm

Amazing how they can photoshop my picture...better than plastic surgery.

ITIL Hands make light work...

Today's post really is meant to remind all of us (myself very much included) why ITIL and IT service management matter. 20 years ago, if my e-mail service went down, hardly anyone even noticed (On my BITNET account, I probably could send e-mail to about 5 people). Now, an e-mail outage can disrupt world commerce (ask anyone who has a Blackberry). Over the last 20 years or so, IT has transformed from a nice-to-have business enhancement to truly a utility - something that is basic and mandatory to operate virtually any aspect of a business.

This means that IT/business integration and alignment aren't hackneyed buzzphrases, but absolutely necessary to the organization's survival. We shouldn't use the ITIL framework or any other frameworks, models, or quality systems to add certificates to the wall, but to enable our businesses to meet their mission. If our IT teams understand services and service culture at its most basic level as our role in enabling the business to achieve its goals, we will be much more effective, and a much more powerful asset for our business partners.

Request Fulfillment is really obvious...and really important

One of the new processes in ITIL V3 is the Request Fulfillment process. The premise is simple enough; we get a number of routine service requests from users, so how do we deal with them and get them taken care of in a way that minimizes the pain? Users want us to facilitate the approvals process and cut red tape, and we in IT want to automate as much of the workload as possible so that we can invest more of our resources and capabilities in other activities that may deliver higher business benefits. The part a number of organizations struggle with is exactly how this works, and here is where we need to look at linkages across the lifecycle.

Back in Service Design, we describe the process of Service Catalog Management and the notions of the Business Service Catalog and the Technical Service Catalog. Business Service Catalogs describe the menu of service options available to customers, and Technical Service Catalogs describe the "cookbook", or procedures to provision and deliver the service. By publishing the Business Service Catalog, we make the services more transparent and available to the users. By publishing the Technical Service Catalog to our technical/functional teams, we provide the basis for consistent policies and procedures in deploying these standard services.

The role then of the Request Fulfillment process is to facilitate using these. A heavy emphasis in the books is on automating workflow activities; automating service requests and Financial and Compliance approvals on the client side, and automating provisioning and configuration management activities on the IT side. We can then use our understanding of lifecycle management to break down the process activities, and then look to leverage workflow management and automation tools to speed these through.

Even though Incident Management gets all the press (after all, it's when fires happen that people actually notice IT), Request Fulfillment is the key to maturing your provisioning activities and ultimately in freeing up Operational resources that can be reinvested in more proactive service activities such as Problem Management, Testing and Validation, and Service planning.

Common Sense isn't so common

Sounds like we're having a few of the usual pseudo-debates on a number of the LinkedIn groups again...I always hesitate to get involved in these conversations because so much of this is comon sense, but then again, perhaps common sense isn't so common.

Certification v Experience

Isn't this silly? It was silly for CNAs, MCSE's, CISSPs, and every other certification too (would you like a lawyer who has passed the bar but never tried a case before? A doctor with no experience treating your illness?). Certifications are independent acknowledgements of certain knowledge...and perhaps some developed skills. Coupled with expertise, a bit of wisdom, and the ability to work well in teams, you may have the makings of a good teammate or team leader. People or employers who expect certifications to be a magic bullet are likely to get what they deserve...

Is ITIL a panacea?

People have religious-level discussions over whether "the book" (should we add holy?) says we ought to do a particular thing or follow a particular procedure. All manner of consultants, technical wannabes, and other pretenders pose as oracles interpreting the "word". The ITIL describes a set of good practices that are demonstrated to work well in a variety of environments. Please understand that in no way does this mean that there are no other ways to do the same things well...or that all the "answers" will be found.

"The ITIL requires that we..."

ITIL is a set of books on my (and hopefully your) shelf, sometimes gathering dust, sometimes being very useful. The ITIL doesn't require anything...but our management should require that we use well-tested, validated policies and procedures for how we design, provision, and deliver services.

Be pragmatic, everyone. The goal is simple...help our organizations and customers achieve their mission by providing effective, efficient, and well integrated IT services to support the business.

Changing how we think about Change Management

One of the more challenging problems with deploying ITIL processes is our desire to make workflows linear. We teach the lifecycle one domain at a time, and teach processes in association with the book in which they are described. Reality is seldom so tidy, however. Processes like Change Management, Service Asset and Configuration Management, and Knowledge Management have a much broader scope; they span the entire service lifecycle and can become confusing if we try to limit them to a particular lifecycle domain. In this post, we’ll discuss the reasons why Change Management needs to be “liberated” from Transition, and how this simple idea will improve your organization’s ability to manage change.

Considering Change

Service Strategy describes the notion of managing a Service Portfolio. Our Resources and Capabilities define a set of Service Assets to be invested, with the goal of maximizing returns for our customer (Value Creation) and for the Service Provider (Value Capture). While many of these resources are invested in ongoing Operations activities (somewhere between 60-70%, depending on whose data you see), much of the remainder is invested in new or changed services in our Service Pipeline. The job of Service Portfolio Management is to define the Portfolio, analyze Business Cases for new or changed services, approve a new future state (in other words, choose the business cases we’re going to commit to doing), and charter the new portfolio (which has the effect of establishing projects to proceed to design and build the new or changed service in the business case).

While some Business Cases are requests for entirely new services, most come from different RFCs. Alignment between the Change Management process and what happens in Service Strategy and Design simplifies this workflow a lot. If we consider Change Management to begin in Strategy, RFCs begin with goals and objectives (e.g. removing a Known Error, implementing a CSI recommendation, etc.). By categorizing the Change, Standard Changes are weeded out and pre-approved, Emergency Changes are quickly driven to an ECAB for assessment, decision, and action, and Normal Changes are assessed by the appropriate CAB for cost, risk, impact, and business value. Given the scope of the Change request, some change requests can be handled at lower levels of the organization (though still through formal change management) where larger scope and resource-impacting changes should have Business Cases developed and these considered together as part of the overall Service Portfolio Management process. As a result, we have consistency in our Change Decision Authority, resource alignment and allocation across projects, and a consistent means of prioritizing the work to be done.

Once an RFC is approved, Service Design describes how we build the change, with the Change Management process continuing to coordinate multiple changes and working with other processes to prepare for effective Transition. This could include planning testing and validation windows, scheduling access to build and test environments, planning how changes will be packaged for release and deployment, and verifying business fit. “Coordinating Change” then largely is described by monitoring status of change build, ensuring proper Service Transition and Operational Readiness Plans are in place, and ensuring that communications is maintained among the various technical, process, and business stakeholders. Once the Service Design Package is complete, Release and Deployment Management can take the change and its associated documentation into the DML and coordinate appropriate packaging, build, test, and deployment/installation of the change according to our transition plan. Once deployed, Change Management finishes its workflow as always with a Post Implementation Review confirming technical success and business outcome (based on the Evaluation Report’s assessment of Change Acceptance, Predicted, vs. Actual Performance, and “unexpected side effects”). Assuming we’re good to go (with other remediation as necessary), we can close the Change at this point.

By thinking of Change this way, it’s easier to see how to use groups like PMOs to help adjudicate how projects align to new and changed services, portfolio management goals, and how to align Change authorities more sensibly. Most importantly, it improves our likelihood of delivering well designed, planned, and effective changes more quickly, improving our ability to adapt IT services to meet our customers’ changing needs.

New series of 5-minute tutorials

Hi all,

I'm pleased to announce that we have started to publish our new ITIL Results in 5 minutes daily learning snippets. You can watch the initial one, Why Availability Shouldn't Wait, at

http://www.brainshark.com/deepcreekcenter/vu?pi=590222616

Please feel free to request topics!

Best,

Patrick

Trip Report from ITSMF Fusion 09

Wanted to take a few moments to summarize the results from ITSMF 09...lots of good things going on, but here are the main highlights we saw.

- Show was smaller than previous years but attendance was better than expected...about 1200

- Most of the enterprises attending were well into at least substantial operational adoption of ITIL good practices.

- Attendance was especially high at programs discussing metrics, SLAs, service catalogs, and there was a strong turnout for "ask the expert" sections with several ITIL co-authors

- The keynote from Dr. Jackie Freiberg was powerful and compelling. The author of NUTS!, about Herb Kelleher of Southwest Airlines and BOOM! 7 Choices for Blowing the Doors off Business as Usual inspired us to move beyond "dead people walking" to embrace infusing our work and learning programs with energy, creativity, and active servant leadership.

- Plenty of tool vendors selling many of the same capabilities...as always, tools can be very helpful in supporting many aspects of your service mgmt initiative, but service and outcomes come first.