Improving IT Maturity

in Higher Education

Sponsored by
 About This Toolkit

This HDI toolkit is a series of practical, instructive job aids designed with the IT service management
practitioner in mind. Each area of focus can be studied and used by itself, or as part of the whole. This
toolkit will help clarify IT maturity, as well as the steps necessary to achieve it in your organization.

1. Introduction - What is IT maturity and why does it matter?

2. Focus Area 1 - The self-assessment: Why, when, and how often

3. Focus Area 2 - Measurement: Measuring what matters

4. Focus Area 3 - Technologies: Choosing the right tools and using the right tools

5. Focus Area 4 - Frameworks and methodologies: There is no one magic formula

6. Focus Area 5 - How to continually improve

HDI: Improving IT Maturity in Higher Education 2

 Introduction: What is IT maturity and why
does it matter?

Maturity, as it pertains to IT and IT service management, means the state of people, processes, and
technology in the organization, and the achievement of improvement goals based on accepted
measurements. Generally, a model is chosen (two are discussed below) and assessments are
performed, either by the organization itself (self-assessment) or by an auditor from an external
organization.

Maturity matters because it shows the capability of IT and IT service management organization to
serve as a ready, willing, and able partner to achieve business or organizational goals in a stable and
predictable way.

In general, states of maturity move from the chaotic or ad hoc to the optimized in defined steps
according to the model. According to CMMI, “each maturity level provides a layer in the foundation for
continuous process improvement.”

Generally, stages of maturity move from the unorganized and reactive to the organized, managed,
measured, and proactive. The similarities between these two maturity models should be evident:
the terms initial, defined, and managed appear in each. The most mature state in each is about
optimization.

Two maturity models:

Capability Maturity Model Integration

ITIL Maturity Model
(CMMI)

Initial: Disorganized, reactive. Things are done on

Increasing maturity
Initial: Unpredictable and poorly controlled.
case-by-case basis, ad hoc.

Repeatable: Procedures are followed, but Managed: Process characterized for fixed-length
individual knowledge is depended upon. projects, and reactive.

Defined: Procedures are documented and Defined: Process characterized for the
standard. Becoming more proactive. organization and proactive.

Managed: Objectives and targets are aligned with

Quantitatively Managed: Measured and
business goals. Monitoring and measurement
controlled.
occur and action is taken to ensure compliance.

Optimized: Practices are followed and automated

wherever possible. There is continuous Optimizing: Focus on continuous improvement.
improvement.

HDI: Improving IT Maturity in Higher Education 3

 The similarities are rather striking: In each model, order is being brought to chaos, and the movement
is from reactive to proactive. Measurement is introduced, and the objectives are focused more toward
the organization as a whole than at specific projects.

HDI research tells us that about 6% of support centers use CMMI. While ITIL is the framework of
choice in at least 50% of organizations, how many of those organizations assess their maturity using
the ITIL model is unknown.

If you choose to use a maturity model (and these are only two of many), you will need to consider
which one is right for your organization. One way to assess that is to get to know organizations that
are similar to your yours and ask them which maturity model they use, and why. Great ways to find
answers to these questions include asking in LinkedIn groups, in-person at local or national industry
events, or in dedicated community groups such as HDIConnect.

HDI: Improving IT Maturity in Higher Education 4

 Focus Area 1 - The self-assessment:
Why, when, and how often

Self-assessments are most useful for organizations that are seeking to undertake improvement
programs, but do not have a clear idea of their current state. Many self-assessments are available
for low or no cost, and can help establish the needs of the organization for improvement, including
specific deficiencies and strengths.

Organizations tend to either overestimate or underestimate their own maturity level, and so self-
assessments should be taken with some caution. If the assessments are well designed, the questions
will produce a far more accurate view of the organization than would just making an internal
statement (a guess). Be honest in your evaluation of where you are.

Self-assessments provide a questionnaire of some length, asking about very specific aspects of
the IT organization and at least some about the organization as a whole. The responses are scored
in some fashion, and a report is delivered back to the assessment-taker with the results. Self-
assessments should not be considered definitive, but they do give the organization a snapshot of
the current state of maturity, and can be used in building a business case for having a professional
assessment done.

Professional assessments are done by certified third parties who have no interest in making
your organization look better than it is. Self-assessments are not comparable to full, professional
assessments.

It is best to make a decision about which maturity model is best for your organization before taking
any self-assessments, since each assessment is based on a specific model. Your organization should
not assume that if a self-assessment under the CMMI model says you are at Level 4, you are at Level 4
in all maturity models. Specifics vary, as will the results of your self-assessment.

Because they are comparatively low in cost, self-assessments can be taken often, and may serve as
mileposts in between professional assessments.

In summary:
• Choose a self-assessment that suits your organization
• Be honest
• Don’t confuse self-assessment results with a professional assessment

HDI: Improving IT Maturity in Higher Education 5

 Focus Area 2 - Measurement: Measuring
what matters

Collecting metrics and measurements is easy; deciding which ones are important and useful is more
difficult. This in itself is part of maturity: understanding what matters to the organization as a whole,
and measuring in ways that illuminate that understanding. Unless performance is measured, it is
impossible to gauge whether it has improved. Therefore, measurements form part of the foundation of
maturity.

The metric is not the goal. The metric is a

milepost to measure progress toward the goal.

Metrics can be measured and applied at the operational, tactical, or strategic level. A classic error in
the world of service and support is mistaking operational metrics for strategic ones, and reporting
them up to executives who are looking for something quite different.

•  s maturity increases, metrics are increasingly aligned to key performance indicators which are
A
more organizationally aligned (see below).
• Consistency, repeatability, and predictability are increased through the considered collection
and analysis of metrics.
• Metrics should increasingly focus on quality over quantity, and outcomes over activities
• Activity-based metrics are the most widely quoted and used in the literature of the
support center. Call or contact volume, handle time, speed to answer, and the like are all
based on the activities of support, not on business outcomes. The activities of support
are mostly reactive: something broke, someone contacted support, and that particular
incident was resolved, for example. These metrics can be “gamed” quite easily.

Example: First contact resolution – User calls unable to access an application. The
support analyst resets the user password and marks the case resolved. Ten minutes
later, the user contacts the support center again because that did not work. A new
ticket is opened and resolved on first contact. Result: Two tickets are scored as FCR
when there was only one.

• O
 utcomes-based metrics are more tactical and sometimes strategic: as a result of
a changed support process or technology, the sales team was able to convert more
potential orders, or the marketing team had a higher response rate, for example. These
metrics are aligned with the organization’s goals as opposed to the goals of the support
center alone. These metrics are harder to “game.” The example used by the Open
Customer Metrics Framework is the Customer Effort Score, which measures how easy
or difficult it was for a customer to obtain and benefit from support.

HDI: Improving IT Maturity in Higher Education 6

 Focus Area 3 - Technologies: Choosing the
right tools and using the right tools

The purchase process

Too often IT—or even just the support center—makes a decision about which tools to buy without
considering that their institution is spending money and expects certain benefits from that
expenditure. If, for example, the tool is expected to serve the organization for three to five years, it
is important to know what the business has planned for that time period. Will service management
be expanding into other areas, such as Facilities and HR? If yes, then the range of tools under
consideration may change to suit the anticipated needs of the broader organization.

It’s not an IT decision; it’s a business decision.

Benefits, not features
In business as well as in our own personal lives, we often make purchase decisions based on a feature
set rather than the specific benefits we will derive from the purchase. A particular car may have a great
set of features that appeal to us, but if the back seat is too small to accommodate our children, the
features are of no use. Likewise, a tool that is built to be compatible with twenty-two ITIL processes
is overfeatured for your desired five processes, and may lack the reporting capability required for your
desktop support group.

Building a business case

The first question a business partner will ask likely ask about a new tool purchase is, “What
problem(s) does it solve?” Before investing a substantial sum of money in a new tool, ask:
• Does the capability to do this already exist anywhere in the organization?
• What, specifically, will be made better as a result of this purchase?

What is the return on investment for this tool?

There are several ways to calculate return on investment (ROI), and your organization may have a
preferred method. Work with your financial department to determine the best and most compatible
way to calculate ROI. It may be difficult to articulate the expected return, since IT and/or support often
do not charge for services. The financial benefit is often derived indirectly, such as from time saved.

Identifying stakeholders
Perform an inventory of stakeholders to make sure that you are including all of them when you plan to
purchase a tool or technology. The example above of desktop support lacking reporting capabilities is
one consequence of overlooking a stakeholder. Another might be that your organization is considering
a knowledge management group (not just for IT), and may be planning to unify knowledge
management in the next two years. If the tool you are looking at lacks the capability to expand, it will
be a poor decision.

HDI: Improving IT Maturity in Higher Education 7

 Consider:
• Who will use the tool or technology most?
• Who else in the organization might be looking for a similar tool or one that has some of the
benefits?
• Is another group or unit willing to share the expense of a more fully featured tool because it
has functionality they want?
• What were the considerations when your current tool was purchased, and what was
overlooked then that has you looking at a purchase now?

If you don’t use it, it’s not a benefit.

Implementation considerations
Implementation can be expensive and complicated. How many procedures or processes will have to
be changed? How much of the implementation work can be done by existing staff, and how much will
need to be contracted out with the tool developer or a third party?

How will it be done?

• Phased approach: The tool or technology is brought into the organization in modules, or
rolled out in a planned way over a specified time period. This approach can work if there are
aspects of the new tool or technology that are mostly compatible with the way things are done
now, and can be integrated into the current process flow.
• “Band-Aid” approach: The do it all at once or “rip off the Band-Aid” approach may be
the best way to go about implementation if there are technical migrations—such as user
data—involved, or if there is a window of time available for major changes, such as summer
vacations.

Getting the results needed and expected

The best tool and the best tool implementation in the world will not yield the desired results if the use
of the tool or technology is not optimized. Will training be needed for users as well as support staff?
How much organizational change must be managed in order to get things to work and keep them
working in the new system? Technical change requires people change as well.

HDI: Improving IT Maturity in Higher Education 8

 Focus Area 4 - Frameworks and
methodologies: There is no one magic formula

The watchwords of frameworks and methodologies are adopt and adapt. It is not necessary to choose
one “right way” to guide an organization; elements of several frameworks and/or methodologies
can be used together. Many articles, blogs, and white papers have been published on the topic of
integrating different frameworks and methodologies, so do not let anyone convince you that you have
to have “an ITIL shop” or a “DevOps shop.” There is no reason you cannot use both sets of guidance—
and add more if your organization needs them or decides they will help.

Examples:
• ITIL and KCS
• ITIL and COBIT
• DevOps and IT service management

General guidance on adopting and adapting

Adopting and adapting does not mean that you can simply choose bits and pieces of one framework
and bits and pieces of another framework and cobble them together. It does mean that you should
carefully consider how your organization will get the best out of a framework in light of your current
state and your future plans. As AXELOS’s Phil Hearsum says about ITIL, “The principle of adopt
and adapt works with your existing systems as well as being flexible enough to handle any new
developments your business introduces.”

Some general guidance

•  ake sure you understand both your organization’s current state and desired future state
M
before adopting one or more frameworks.
• Consider the objectives of the frameworks (process improvement, production velocity,
standardization) before choosing one or more. How do they fit your organization, based on
what you know?

The key is not to become bound by an ideology rather than taking the ideas various frameworks have
to teach you and building upon them for your organization’s future.

HDI: Improving IT Maturity in Higher Education 9

 Focus Area 5 - How to continually improve

Why measurement is key to improvement

There is an old adage, often erroneously attributed to W. Edwards Deming, that if you can’t measure
it, you can’t manage it. Perhaps it is more true to say, “If you don’t measure it, you cannot improve it.” If
you do not know how you are doing now, how will you know when you are doing it better? Refer back
to Focus Areas 1 and 2 and make sure that you can determine where you are now—both in terms of
maturity and performance—before you embark on a formal improvement initiative.

Improvement is not a project

Projects, by definition, have an end. Something is completed or accomplished, and the project is
ended. Improvement does not have an end date. It is ongoing and continual. Your performance is only
ever as good as your last interaction or achievement.

Don’t forget the people part

Almost any change requires people to change. Behavior, expectations, actions—something or some
things must change. Organizational change is required, and often overlooked. Your organization
probably has a preferred method for organizational change—there are many—and the preferred one
(provided it has been successful in the past) should be followed.

The steps do not have to be big, but must be taken

The Japanese business philosophy of kaizen espouses continual improvement but recognizes that
changes may be small, incremental steps. Large steps are often disruptive and problematic. Plan for a
future of continuously introducing small improvements, and your progress will soon become evident.

Set the bar for performance a little above where you have it now. Perhaps raising your commitments
under your service level agreement (SLA) by one percent per quarter will do it. Year over year, that
performance will begin to show great results.

HDI: Improving IT Maturity in Higher Education 10

 About HDI
In 1989, HDI became the first professional association created for the technical
support industry. Since then, HDI has remained the source for professional
development by offering resources to promote organization-wide success through
exceptional customer service. We do this by:

• Facilitating collaboration and networking

• Hosting acclaimed conferences and events
• Producing renowned publications and research
• Certifying and training thousands of professionals each year

Our mission is to elevate the customer experience through the development of the
technical support industry.

About TeamDynamix
Service and project portfolio management designed specifically for higher education.
A single platform bringing together IT service management extending to Facilities,
Resident Life, Admissions, HR, and more—with project portfolio management.

• Fully integrated cloud platform

• Integration services
• Managed application services
• Process consulting
• Custom client portal design

ITIL® is a registered trademark of AXELOS, Limited

KCS™ is a service mark of the Consortium for Service Innovation

HDI: Improving IT Maturity in Higher Education 11