Six pitfalls to Goldilocks service management

Service management concepts have been widely embraced by IT leaders as a means of improving the efficiency and effectiveness of their organisations.

Enlightened CIOs have come to realise that it’s difficult to create competitive advantage through talent or technology alone since most IT organisations have equal access to the people, software and hardware required to support business operations.

Under these circumstances, internal process sophistication and process discipline become essential components of any initiative seeking to create competitive advantage through the use of information technology.

Service management concepts also provide a new lingua franca for communicating with the functional groups that are ultimately underwriting IT’s expenditures.

Service management can liberate CIOs from trying to explain the benefits of application upgrades, storage virtualisation or network expansion to their internal clients.

A properly constructed business service catalogue can transform those conversations into discussions about inventory turns, market segmentation and cross-sell opportunities. in terms that IT’s clients understand and value.

Although the theoretical benefits of service management are well understood, the IT landscape is littered with organisations that have struggled to implement service management practices.

How can something that is so obviously beneficial in theory be so hard to implement in practice?

The Goldilocks Problem Goldilocks and The Three Bears is a children’s fairy tale about a young girl who stumbles upon the house of The Three Bears during a walk through the woods.

In the bears’ absence, Goldilocks samples their porridge, their chairs and their beds. In each case, Goldilocks has to try more than one sample of each item to find the one that is just right for her.

IT organisations seeking to implement service management practices typically encounter a very similar dilemma.

Zealots seeking to revolutionise the way IT does business will attempt to establish procedures that are far too detailed, far too sophisticated and, frankly, far too different from current practices to ever be successful.

At the other end of the spectrum, protectors of the status quo will begrudgingly adopt service management jargon to keep IT management happy while continuing to rely on existing operational practices.

The key to a successful service management implementation is to find the balance between business needs and operational sophistication that is just right for individual companies.

The Goldilocks Solution All successful change management initiatives have certain things in common such as visible executive support, alignment with major business initiatives, clearly defined objectives and success metrics, and early wins.

These key success factors clearly apply to service management initiatives. In addition, there are several potential pitfalls that are unique to service management programs and need to be avoided at all costs.

Several of the more common pitfalls include:

– Building a service catalogue for IT consumption Functional groups that are consuming IT services are frankly not interested in technical descriptions of three-tier application architectures, network latency or disaster recovery procedures.

They want to buy IT capabilities that enable specific business processes such as lead generation, sales pipeline management or renewals processing.

In addition, they want certain guarantees regarding the availability and response times of such services.

All too often IT groups define business service offerings in terms that make sense to technologists, not in terminology that makes sense to the service buyers.

– Overly ambitious CMDB construction A comprehensive and accurate Configuration Management Data Base (CMDB) provides the underpinning for almost every major operational practice employed in managing the various technical services that comprise a business service.

Left to their own devices, technologists become overly ambitious and frequently include items in the CMDB that are far too granular and frankly unnecessary.

As a general rule of thumb, the only items entered in the CMDB should be those that are routinely referenced through the change management process.

– CMDB federation vs. integration The path of least resistance for protectors of the status quo is to simply federate pre-existing databases into the CMDB without adhering to a consistent overall schema.

A Configuration Manager needs to be identified at the outset of a service management initiative and given full authority to define and enforce the schema that will be used in building a truly integrated CMDB.

The coverage and accuracy of the CMDB is an organisational responsibility, not the responsibility of the Configuration Manager.

Technical leaders across the organisation need to be involved in validating current entries and resolving discrepancies discovered through routine scans of infrastructure and application environments.

– Overly ambitious service impact modelling Service impact models (SIMs) delineate the interconnections among the configurable items (CIs) in the CMDB that support individual technical services such as an ERP system or data warehouse.

It’s not uncommon for IT organisations to support several hundred technical services. Modelling all such services is an overwhelming challenge.

As a general rule of thumb, SIMs should only be constructed for major, business critical services.

A further suggestion is to initially focus on services experiencing chronic problems and leverage the SIM to refine monitoring strategies, reduce change management errors or focus re-engineering efforts.

– Service costing takes precedence IT organisations frequently obtain funding for service management initiatives by promising greater cost transparency to their internal business clients.

Although such objectives are laudable, they can sometimes hijack the overall initiative and turn it into nothing more than an exercise in establishing a new IT chargeback system.

This can be a fatal pitfall that narrows the scope of the initiative and sacrifices many other operational benefits.

A One-At-A-Time Deployment Plan To keep things simple and minimise risk, many IT organisations adopt sequential deployment plans to introduce new operational practices.

Sequential deployments sacrifice the natural synergies that exist among such processes as incident/problem/change or asset/configuration or availability/capacity.

Early wins of material value are frequently achieved by deploying processes in bundles instead of individually.

Which Bed Do You Want to Sleep In? When Goldilocks gets to the bears’ bedroom, she finds that one bed is too hard, another is too soft while the third is just right.

Too many IT organisations launch well intended service management initiatives but end up making them far too hard by striving for a level of process sophistication that is beyond their inherent skills, available funding and/or business needs.

Others launch such initiatives in response to chronic operating problems but frequently end up losing interest and adopting only cosmetic changes that are too soft to produce material benefits.

Hopefully, by avoiding the pitfalls outlined above, IT organisations will have a better chance of ending up in the service management bed that is just right for them.

Mark Settle is CIO of BMC Software

Pic: GettysGirl4260cc2.0