Capability maturity in management means that the adoption and implementation of a management methodology can go from primitive or slight, to advanced or comprehensive. In other words, it is necessary to "manage management" - essentially, an executive responsibility, and a prerequisite for making management perform as promised. This discussion reflects broadly observed reasons why management maturity failures can occur, putting the practical efforts of operating under management at risk.

1. How Good Are You At
Managing ITSM?
© 2007 Malcolm Ryder / archestra

2. Top Ten Management Gotchas
Ineffective 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

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. 7. Process automation
The 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.

10. 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.

11. 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.

12. 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.