How Good Are You At Managing ITSM?

© 2007 Malcolm Ryder / archestra

Top Ten Management GotchasIneffective management is not neutral: it is detrimental. It’s almost a certainty that in each of the ten following areas, omissions, defects and errors pile up to inhibit the effectiveness of your management. A big question is, if you haven’t prevented these problems beforehand, why would you expect your management to be effective? The importance of looking into them speaks for itself.

1. Making the right thing manageable

2. Requirements definition

3. Change Management

4. Money

5. Balancing demand and supply

6. Staff roles/model

7. Process Automation

8. Systems integration

9. Management Information

10. Measurement

Missing elements

Bad elements

Bad use of elements

malfunctions

breakage

harm

waste

stoppage

delays

violations

The world of problems.© 2007 Malcolm Ryder / archestra

1. Making the right thing manageable

Management is a continuous cycle. It defines something, declares its purpose, prescribes its conditions and limits, observes and steers it to the purpose, and changes it if and when necessary. Since this set of responsibilities is a function, it must itself be managed for the correctness of its continuity and impacts.

Naturally, “service management” cannot occur where there is no organized management function that implements and sustains it. More obviously, if a service has not been defined, then it cannot be managed.

The purpose of a service is to make an operation usable on demand by the requester. Terms of demand will be specified and agreed, but not all requesters are alike.

One operation may be the basis of many services. Managing the operation is not the same as managing the services. And managing the requesters is not the same as managing the operation.

2. Requirements definition

The requester of a service is, literally, any user of a service that should have on-demand access within the agreed terms. But, since a service is basically a view of an underlying operation, the service may be a delivery vehicle for a technical output as well as for a non-technical one.

We can assume that an operation is continuous because it is systematic. Given that, services of different types are found within systems; the system itself may be a service; and services may be found around systems.

Service requesters are users, but users can include devices, applications, and organizations.

Without further logical organization, this suggests that any type of user might try to request any type of operation. The risk is that a lack of mediation will allow chaos.

Defining a service requires modeling the relationship of the user to the service as well as the service to its underlying operation. Without the relational model, managing the separate parts can just as readily disassemble the service as sustain it.

Without a model, a service has no practical definition. And, the requirements for a service stem from the model.

3. Change management

Management is not how an organization does something; management is how the organization (or function) is made appropriately capable of doing something.

In management circles, forces of change have been catalogued for decades. In retrospect, the affect of change on capabilities falls into just three general categories: when change occurs, capabilities become more or less important, aligned, and sustainable.

This puts change itself into just two general categories: resolved, and promoted.

Nearly all management is consumed with handling the importance, alignment or sustainability needed to address reactive change resolutions or proactive change enablement. However, because there are even this many variables, managing change inherently carries the prospect of interests and priorities that are competing, contradictory, or interdependent.

Thus, complexity and policy are always at the heart of “executive” change management. Without adequate visibility and governance of the variables, poor change management can prevail, readily undermining the ability to practice other types of management with consistency or persistence. This situation of inadequate executive capability maturity is an ITSM inhibitor.

4. Money

The most common error in financial evaluation is mistaking costs and expenses.

This occurs because their different levels and purposes of authorization are not consistently used to distinguish them.

We all know that cost is a set final amount that gets authorized to use, while expense is an amount that is permitted to consume immediately. Unfortunately, the sensitivity to the difference in benefits of the cost and the expense is too often weak or even missing.

Put simply, the benefit of the cost is assurance of capacity, while the benefit of expense is return on investment.

To obtain and maintain business financial approval of ITSM, almost every company needs to show the ROI of its expense, but few companies represent expense as investment.

Meanwhile, the misrepresentation of ROI as a cost measure is extremely common and often prevents the level of funding that would logically support continuity and persistence in the management effort being proposed.

5. Balancing demand and supply

Management oversees the identification of services. According to the service modeling that should be involved, available connections are formed between different users and different operations.

The varying demands of different users does not mean that only some of them can be accommodated. Instead, multiple services may exist to address similar needs.

This means that given users should be able to see that a service is appropriate for them, and providers of services should be able to see that there is sufficient justification for the given service to be maintained as a distinctive option.

The provider of a service is seen as being in business with the users. A portfolio view is how managers can track the services according to their business justification. But to correctly assess the value of the service to the business, the importance of the user’s request to the business must first be established.

A catalog view of services is the way that business managers systematically place a request for service in a business approval context. However, a catalog is only as good as the ongoing profiling and business assessments backing it up.

In effect, a service is a product. Companies that make products know that they must have successful product management. Products can be defined and cross-referenced from a portfolio to a catalog. The management competencies already in product management should also be available as part of the organization applicable to its “internal” market. Lack of prior management readiness makes effective service management unlikely.

6. Staff roles / model

When services are correctly modeled and provided, the user’s orientation predominates. The justification for making the service available to users is a business argument. Business management is the POV that most strongly applies to service management decisions.

Because the goal of service management is to address justifiable business demand, availability of services must be organized on the basis of assuring fulfillment by reliable providers.

The diversity of business efforts and users means that the catalog and portfolio of needed services can exceed the ability of internal organizations to produce enough to meet demand. As a result, external providers must be considered, and management needs to be able by default to model internal providers as peer options comparable with external providers.

For internal providers, this means creating an organizational structure with service production and accountability built into its design. This includes identifying the business managers within IT, as well as distinguishing and allocation internal and external locations of roles.

Modeling internal IT organizations as service providers can require a change in funding, human resources, reporting, and infrastructure. These same factors may independently be evolving, or currently “locked in”, according to terms unrelated to a provider model. For service management to be effective, establishing and preserving the structure of a provider organization must have high-enough priority to withstand the competitive pressure of other executive interests.

7. Process automationThe major driver of ITSM is the same now as it has been for fifteen years.

The basic premise of ITSM adoption is that ITSM can work when it is based on process standards, because IT complexity itself is the root cause of the business problem that needed to be solved, and management processes resolve or minimize the IT complexity. But what is not especially obvious is how management process complexity and standards relate.

Logically, complexity can be good when it is the solution to maximizing the precision and control of outputs. At the same time, complexity can be bad if it makes the probability of initial and repeatable execution significantly less likely. Management is responsible for the risk in the difference.

Usually, complexity is a response to an environment that has a high number and degree of influences making process control and precision difficult. The other major source of complexity is a lack of design or renovation replacing entrenched still-active older environments underlying layers of superimposed adaptations.

Management environments are typically made up of the objectives, policies and procedures authorized by the business for given purposes. Too often a process that need not be complex is complicated by an insistence on complex procedures. Most processes are mapped to align to the environment. Trade-offs and add-ons may occur primarily to accommodate the process presence in multiple environments. These customizations often then get automated to ensure their routine.

But decision-makers about these trade-offs and add-ons may not appreciate the extent to which their respective requirements affect the probable effectiveness of the process being proposed. Automating bad implementations of processes is far more likely when the process design is not allowed to generate the supporting procedures.

This poses a significant risk to the key premise of ITSM processing, which is its reliance on standards.

8. Systems integration Companies use information systems primarily to reduce the manual labor of repetitive processing. There is no real debate about this, but the labor benefits include opportunity to manually address non-repetitive tasks having high present value.

In general, systems integration represents the automation of communications, where a task-level I/O of information is passed directly from one system to another instead of one person to another. The key feature here, of technologically enabling a successful connection, has largely dictated how information could be represented for the purpose of communication.

Massive investments already made in making these connections can present a huge challenge to new systems that want to communicate, unless the already-implemented communications interfaces support them.

ITSM assumes that numerous management processes will integrate with each other, which may or may not be delivered pre-integrated. Interfaces must have enough longevity to allow ITSM to be “built-out” incrementally, possibly across several different providers. Meanwhile, companies typically are extremely interested in avoiding “unnecessary” duplication of information that may already be in routine processing.

This scenario suggests that “ITSM information” may already be available in non-ITSM systems for mining by ITSM processes. But the location and hosting of purpose-built ITSM processing systems may go through technology evolution much faster than existing internal integrations.

Consequently, an architecture assessment is a success factor for identifying the short-term and long-term requirements for supporting the ITSM implementation.

9. Management information

Management communications is always essential to the same three objectives: gaining support for plans; directing efforts; and accounting for effects.

The pressure to immediately confirm understanding is continuous, but the evidence of understanding will appear more in records of interpretations than in records of messaging. This creates the need to codify interpretation in ways that allow consistent comparisons over time and against follow-up actions.

For ITSM, the related issue is the vocabularies used for distinguishing and tracking the following:

• Service Quality

• Service Impact

• Service Value

• Service Performance

Without the ability to clearly both distinguish and relate the four evaluations, misinterpretation quickly becomes misinformation during communications. Consistent distinguishing definitions must travel along with the information to assure that the significance of the management message is not arbitrarily replaced by the perspective of a different manager or management domain. This also means that management teams must, in advance, understand and agree on what they are expected to do about the service management information that is cultivated to describe service management. This can require education or even re-education in the management ranks.

10. Measurement

No one debates that management requires measurement. Measurement is one of the primary actions of management.

Good measurement always aims for accuracy and completeness while also having its results be actionable. But the most common error in measurement is not to measure the right things poorly; instead it is to measure the wrong things.

Management action is otherwise focused on gaining support for plans; directing efforts; and accounting for effects. Management measurement focuses on awareness that is needed to support those actions.

When information suitable mainly for awareness is made available, it is typical that prescribed types of follow-up are also available. However, information that begins a “new” interpretation by its user needs to be associated with contexts and experiences (perspectives and history) that support decisions; these decisions are ones having accountability based on current expertise rather than on conventional rules.

ITSM knowledge, providing perspectives and history, incorporates measurement – but it also offers decision support that exceeds or can even exclude measurement, and that relies more primarily on logic. The management logic is a more important characteristic of the environment in which measurement is conducted.

Without a knowledge-based service management culture, ITSM measurement is far more likely to risk error.