1
2
3
A RACI matrix is a very important tool that can help in the implementation and
correct functioning of a process. The RACI matrix is mostly used to align the human
elements in the process. Usually there are many different people involved in any
process and they have differing responsibilities. A RACI matrix makes an explicit
documentation of this and keeps as a ready reference to be used at different stages
in the process. Here is how the RACI matrix can be utilized.
Responsible: This is the class of people who are ultimately responsible for getting
the work done. This may refer to the individual workers that perform the given task
or it could refer to the system in case the task is automated.
Accountable: This is the class of people that are accountable to oversee that the
work gets done. This usually means the immediate manager overseeing the work.
Consulted: These may be subject matter exerts who need to be consulted at the
time of an exception. There is a possibility that am unanticipated scenario arises in a
process. These are the people who will do the thinking and suggest any deviations
from the Standard Operating Procedure (SOP).
Informed: This is the class of people who have some interest in the performance of a
given task. This may be a manager trying to control the execution of the task at
hand. Also this could be an input signal to the other process.
4
Rules for using RACI Matrix
Only One Responsible and Accountable Person: It is essential that only one person
be assigned the R/A roles. Having more than one person responsible for the same
task increases ambiguity and the chances of the work not being performed. It could
also lead to duplication of work and wastage of efforts and costs.
Having more than one accountable person again leads to the same problem.
However, having only one person accountable also leads to a problem. If the
assigned person is incompetent, the whole process may go for a toss. It is for this
reason that there is often a hierarchy of accountable people in place.
Responsible-Accountable is Mandatory: The consult or inform roles are not
mandatory for every activity. It is possible that some activities may not require them
at all. But the responsible accountable roles must be assigned. Even if the system is
performing the tasks automatically, someone must be made accountable to see that
it does get done.
Communication with the Consultant: There must be a two way channel of
communication with the consultant. This communication is itself a task and must be
explicitly listed having its own responsible accountable persons. The important
aspect is that the communication should be two-way. Hence one has to ensure that
adequate follow-up is done and there is minimum time lag to complete the
communication.
Inform the Required Stakeholders: This is a one way channel of communication. It is
usually meant to be a signal for some other process to begin or as a control metric
to ensure smooth functioning of the same process. Usually this is automated but
needs accountability like other automated tasks.
Sometimes the extended version is used – RASCI matrix.
R - Responsible – Those who do the work to achieve a task. There is typically one
role with a participation type of Responsible.
A - Accountable – Those who are ultimately accountable for the correct and
thorough completion of the deliverable or task, and the one to whom Responsible is
accountable. Typically, the Process Owner is Accountable for a process, and there
must be only one Accountable specified for each task or deliverable.
S - Support – Resources allocated to Responsible. Unlike Consulted, who may
provide input to the task, Support will assist in completing the task.
C - Consulted – Those who are not directly involved in a process but provide inputs
and whose opinions are sought.
I - Informed – Those who receive outputs from a process or are kept up-to-date on
progress, often only on completion of the task or deliverable.
4
5
6
7
A role is a set of responsibilities, activities and
authorities granted to a person or team. A role is
defined in a process or function. One person or team
may have multiple roles. For example, the roles of
incident manager and problem manager may be carried
out by a single person.
Roles are often confused with job titles but it is
important to realize that they are not the same. Each
organization will define appropriate job titles and job
descriptions which suit their needs, and individuals
holding these job titles can perform one or more of the
required roles.
8
9
RACI tool helsp to identify the positiong of specific roles and the relationship setup
10
Latest Agile approach influences the ostion of Line Management!!!
11
12
The ITIL 4 SLM practice defines the purpose of service level management as “…to set
clear business-based targets for service levels, and to ensure that delivery of services
is properly assessed, monitored, and managed against these targets.”
Servicde Level should relate to a measurable business outcome. All too often the IT
industry has used SLA targets as a way to capture numbers and figures that make no
sense in a business context. By focusing on what the business wants as an outcome,
your organization will be able to deliver services that add value rather than simply
hit arbitrary metrics and targets.
13
Service level is the metrics by which a particular service is measured. Service level is
mostly used in the service-based industries. Service level provides the expectations
of quality and service type and also remedies when requirements are not met.
Service level is an important component of any vendor contract. Service level
includes all elements of the particular service provided and the conditions of service
availability. The exact measurement related to service levels depends upon the type
of service provided, volume of work, quality of work and the service provider. In
some cases, there are multiple approaches to determine the service levels. Service
level is often documented with the help of a service-level agreement, which
describes in detail the level of service anticipated by a customer from a vendor. Most
service providers have service levels and standard level agreements. A service-level
agreement deals with the reliability, responsiveness, monitoring and escalation
procedures related to service levels.
Service level measurement helps the involved parties to understand the level of
service quality. With a service-level agreement in place, it protects all involved
parties in the agreement. Service level helps in understanding the measures of the
certain goals and indirectly helps in achieving the goals.
A Service Level Agreement (SLA) is the service contract component between a
14
service provider and customer. A SLA provides specific and measurable aspects
related to service offerings. For example, SLAs are often included in signed
agreements between Internet service providers (ISP) and customers.
SLA is also known as an operating level agreement (OLA) when used in an
organization without an established or formal provider-customer relationship (very
often it is used as internal agreement between different units).
Adopted in the late 1980s, SLAs are currently used by most industries and markets.
By nature, SLAs define service output but defer methodology to the service
provider's discretion. Specific metrics vary by industry and SLA purpose.
SLAs features include:
• Specific details and scope of provided services, including priorities,
responsibilities and guarantees
• Specific, expected and measurable services at minimum or target levels
• Informal or legally binding
• Descriptive tracking and reporting guidelines
• Detailed problem management procedures
• Detailed fees and expenses
• Customer duties and responsibilities
• Disaster recovery procedures
• Agreement termination clauses
In outsourcing, a customer transfers partial business responsibilities to an external
service provider. The SLA serves as an efficient contracting tool for current and
continuous provider-customer work phases.
14
What Are Key Components of an SLA?
The SLA should include components in two areas: services and management.
Service elements include specifics of services provided (and what's
excluded, if there's room for doubt), conditions of service availability,
standards such as time window for each level of service (prime time and nonprime
time may have different service levels, for example), responsibilities of
each party, escalation procedures, and cost/service tradeoffs.
Management elements should include definitions of measurement standards
and methods, reporting process, contents and frequency, a dispute resolution
process, an indemnification clause protecting the customer from third-party
litigation resulting from service level breaches (this should already be covered
in the contract, however), and a mechanism for updating the agreement as
required.
This last item is critical; service requirements and vendor capabilities change,
so there must be a way to make sure the SLA is kept up-to-date.
15
16
17
What should I consider when selecting metrics for my SLA?
Choose measurements that motivate the right behavior. The first goal of any metric
is to motivate the appropriate behavior on behalf of the client and the service
provider. Each side of the relationship will attempt to optimize its actions to meet
the performance objectives defined by the metrics. First, focus on the behavior that
you want to motivate. Then, test your metrics by putting yourself in the place of the
other side. How would you optimize your performance? Does that optimization
support the originally desired results?
Ensure that metrics reflect factors within the service provider's control. To
motivate the right behavior, SLA metrics have to reflect factors within the
outsourcer's control. A typical mistake is to penalize the service provider for delays
caused by the client's lack of performance. For example, if the client provides change
specifications for application code several weeks late, it is unfair and demotivating to
hold the service provider to a prespecified delivery date. Making the SLA two-sided
by measuring the client's performance on mutually dependent actions is a good way
to focus on the intended results.
Choose measurements that are easily collected. Balance the power of a desired
metric against its ease of collection. Ideally, the SLA metrics will be captured
automatically, in the background, with minimal overhead, but this objective may not
be possible for all desired metrics. When in doubt, compromise in favor of easy
18
collection; no one is going to invest the effort to collect metrics manually.
Less is more. Despite the temptation to control as many factors as possible, avoid
choosing an excessive number of metrics or metrics that produce a voluminous
amount of data that no one will have time to analyze.
Set a proper baseline. Defining the right metrics is only half of the battle. To be
useful, the metrics must be set to reasonable, attainable performance levels. Unless
strong historical measurement data is available, be prepared to revisit and readjust
the settings at a future date through a predefined process specified in the SLA.
18
19
20
21
What Kind of Metrics Should be Monitored?
Many items can be monitored as part of an SLA, but the scheme should be
kept as simple as possible to avoid confusion and excessive cost on either
side. In choosing metrics, examine your operation and decide what is most
important. The more complex the monitoring (and associated remedy)
scheme, the less likely it is to be effective, since no-one will have time to
properly analyze the data. When in doubt, opt for ease of collection of metric
data; automated systems are best, since it is unlikely that costly manual
collection of metrics will be reliable.
Depending on the service, the types of metric to monitor may include:
Service availability: the amount of time the service is available for use. This
may be measured by time slot, with, for example, 99.5 percent availability
required between the hours of 8 am and 6 pm, and more or less availability
specified during other times. E-commerce operations typically have extremely
aggressive SLAs at all times; 99.999 percent uptime is a not uncommon
requirement for a site that generates millions of dollars an hour.
Defect rates: Counts or percentages of errors in major deliverables.
Production failures such as incomplete backups and restores, coding
errors/rework, and missed deadlines may be included in this category.
22
Technical quality: in outsourced application development, measurement of
technical quality by commercial analysis tools that examine factors such as
program size and coding defects.
Security: In these hyper-regulated times, application and network security
breaches can be costly. Measuring controllable security measures such as
anti-virus updates and patching is key in proving all reasonable preventive
measures were taken, in the event of an incident.
22
23
Service level is the metrics by which a particular service is measured. Service level
is mostly used in the service-based industries. Service level provides the
expectations of quality and service type and also remedies when requirements are
not met.
Service level is an important component of any vendor contract. Service level
includes all elements of the particular service provided and the conditions of service
availability. The exact measurement related to service levels depends upon the type
of service provided, volume of work, quality of work and the service provider. In
some cases, there are multiple approaches to determine the service levels. Service
level is often documented with the help of a service-level agreement, which
describes in detail the level of service anticipated by a customer from a vendor. Most
service providers have service levels and standard level agreements. A service-level
agreement deals with the reliability, responsiveness, monitoring and escalation
procedures related to service levels.
Service level measurement helps the involved parties to understand the level of
service quality. With a service-level agreement in place, it protects all involved
parties in the agreement. Service level helps in understanding the measures of the
certain goals and indirectly helps in achieving the goals.
24
ITIL focuses on three types of options for structuring SLA: Service-based, Customerbased,
and Multi-level or Hierarchical SLAs. Many different factors will need to be
considered when deciding which SLA structure is most appropriate for an
organization to use.
24
Key Performance Indicators (KPIs) are the critical (key) indicators of progress toward
an intended result. KPIs provides a focus for strategic and operational improvement,
create an analytical basis for decision making and help focus attention on what
matters most. As Peter Drucker famously said, “What gets measured gets done.”
Managing with the use of KPIs includes setting targets (the desired level of
performance) and tracking progress against that target. Managing with KPIs often
means working to improve leading indicators that will later drive lagging benefits.
Leading indicators are precursors of future success; lagging indicators show how
successful the organization was at achieving results in the past.
Good KPIs:
• Provide objective evidence of progress towards achieving a desired result
• Measure what is intended to be measured to help inform better decision
making
• Offer a comparison that gauges the degree of performance change over
time
• Can track efficiency, effectiveness, quality, timeliness, governance,
compliance, behaviors, economics, project performance, personnel
performance or resource utilization
25
• Are balanced between leading and lagging indicators
The relative business intelligence value of a set of measurements is greatly improved
when the organization understands how various metrics are used and how different
types of measures contribute to the picture of how the organization is doing. KPIs
can be categorized into several different types:
• Inputs measure attributes (amount, type, quality) of resources consumed in
processes that produce outputs
• Process or activity measures focus on how the efficiency, quality, or consistency
of specific processes used to produce a specific output; they can also measure
controls on that process, such as the tools/equipment used or process training
• Outputs are result measures that indicate how much work is done and define
what is produced
• Outcomes focus on accomplishments or impacts, and are classified as
Intermediate Outcomes, such as customer brand awareness (a direct result of,
say, marketing or communications outputs), or End Outcomes, such as customer
retention or sales (that are driven by the increased brand awareness)
• Project measures answer questions about the status of deliverables and
milestone progress related to important projects or initiatives
25
Every organization needs both Strategic and Operational measures, and some
typically already exists. This Figure depicts strategic, operational and other measures
as described below:
Ø Strategic Measures track progress toward strategic goals, focusing on
intended/desired results of the End Outcome or Intermediate Outcome. When
using a balanced scorecard, these strategic measures are used to evaluate the
organization’s progress in achieving its Strategic Objectives depicted in each of the
following four balanced scorecard perspectives:
• Customer/Stakeholder
• Financial
• Internal Processes
• Organizational Capacity
Ø Operational Measures, which are focused on operations and tactics, and
designed to inform better decisions around day-to-day product / service delivery
or other operational functions
Ø Project Measures, which are focused on project progress and effectiveness
Ø Risk Measures, which are focused on the risk factors that can threaten our
26
success
Ø Employee Measures, which are focused on the human behavior, skills, or
performance needed to execute strategy
An entire family of measures, including those from each of these categories, can be
used to help understand how effectively strategy is being executed.
26
IT metrics are quantitative assessments that enable organizations to understand the
performance of their IT initiatives. Key Performance Indicators (KPIs) are a subset of
metrics to illustrate how effectively specific business objectives associated with IT
performance are achieved.
What do IT metrics track?
Even when technology is not a core business of your organization, you can take
advantage of vast volumes and variety of data to make well-informed strategic
decisions. The strategic significance of IT metrics can be described in two domains:
Technology Performance. Data generated by connected technologies, IT
infrastructure, and technology systems can be gathered, processed, and
analyzed to identify technology performance. This information can be used to
maintain efficiency of technology systems at lower costs.
Business Performance. This data also contains hidden insights on the impact
of strategic choices on business performance. In order to drive the best
business outcomes, IT must identify and analyze metrics that correlate highly
with business performance.
27
Some important IT metrics and KPIs fall in the following domains and categories:
Operational Metrics
Operational KPIs help organizations track performance over a pre-defined period or
in real time. These metrics are associated with a range of business functions. But, in
the domain of enterprise IT, operational metrics focus primarily on the performance
of IT resources and functions. These resources include the workforce, technologies
and services used to conduct business operations or enable products and services to
end-users. Examples of operational metrics include:
• HR: Workforce productivity, overtime hours, employee turnover
rate, cost of hiring and training.
• IT Infrastructure: Infrastructure downtime, frequency of
production deployments, number of workloads processed, capital
and expense cost, resource availability.
• IT Solutions and Services: Service uptime, availability, reliability,
cost per user, cost per user acquisition, network outages.
• ITSM and Service Desk: Service availability, First Call Resolution
Rate, cost per contact, SLA breach rate, user satisfaction
Operational metrics overlap with a range of categories that focus on unique aspects
28
of organizational operations driven by technology. These metrics evaluate how the
resources made available to various functions of the organization contribute to the
overall business performance.
System Reliability
IT systems, including hardware infrastructure and applications, must operate
reliably—every second of downtime incurs revenue losses. The metrics associated
with system reliability help organizations evaluate historical performance and
predict future performance. These metrics not only empower IT teams to perform
upgrades and maintenance activities proactively but also give the business
confidence to scale operations and pursue new business opportunities that rely on
stable and reliable IT systems performance.
These metrics are mostly focused on the technology performance and require
additional layers of analytics and correlations to evaluate correlations with the
business performance. Common examples of system reliability metrics include:
• Outages: Mean Time to Resolve (MTTR), Mean Time to Failure
(MTTF), frequency and schedule of planned and unplanned
outages, redundancy levels for power and utility supplies,
hardware assets
• Network: Capacity, latency, incidents
• Procurement: hardware resources that are not easily replaced by
strategic suppliers and standard channels of procurement
• Cost: Operational and capital expenses, cost per user, cost per unit
asset such as data storage
• Security: Data breaches and network infringements encountered
and deflected, security policy adherence, cybersecurity awareness
training drills and results
IT Support and Customer Expectations
Measuring user satisfaction helps organizations identify operational and
performance issues within their organization and its IT resources. The IT service desk
for instance, is established to ensure that IT services are delivered effectively to
internal and external end users. The performance of the IT service desk has a direct
correlation with organizational capacity to deliver the expected services and
satisfaction levels of end-users.
Some common examples for metrics that track IT support and customer experience
include:
• Service Availability: How readily is the promised service made
available to the end-user, as per expected performance, quality
and dependability. Repeated outages, recurring technical and
security issues compromise service availability and hence,
customer expectations of the service quality
28
• Common IT Metrics:
o Mean Time to Resolve (MTTR) represents the average time
taken to resolve a ticket.
o Mean Time Between Failure (MTBF) represents the time
between failures.
o Mean Time to Failure (MTTF) represents the system uptime
after a possible issue has been resolved.
o These metrics must be evaluated collectively: a dependable
service fails less frequently, resolves fast after a failure and
remains available for prolonged duration.
• Service Desk Metrics: First Call Resolution Rate, Cost per Contact,
Customer Satisfaction, Net Promoter Score, Agent Satisfaction
Service Level Agreements (SLAs)
Most organizations procure a range of IT services and technology solutions. SLAs
oblige vendors to deliver promised service levels defined by specific metrics. Failure
to comply with these metrics not only penalizes vendors but also impacts end users
and, therefore, revenue generating opportunities. It is therefore critical to identify
the metrics that best describe the required performance levels. Examples of SLA
metrics include:
• SLA Compliance Ratio: The ratio between number of incidents
resolved in compliance with SLA and the total number of incidents
• SLA Performance: Uptime, Scale up/down capacity, response time,
storage
• SLA Verification: Defect rates, technical quality, security, business
results/KPIs, number of complaints
Financial Metrics
The performance of IT is a natural tradeoff with financial investments. It is therefore
critical to evaluate the financial performance of an IT initiative. The optimal tradeoff
between cost, performance, security and other ROIs should be considered with
designing and evaluating IT metrics and KPIs. Some common financial metrics
include:
• Cost: Cost of budget, budget variance, resource cost, maintenance
and support expenses
• Scheduling: Scheduling variance and schedule overhead
• Risk: Legal, societal, and natural causes impacting business
performance or ability to scale a product functionality and service
to extended marketplaces
28
Finding the right IT metrics strategy is not about deploying sophisticated analytics
technologies. It’s about identifying the metrics that yield most insightful knowledge
that can help align IT with desired business goals. Specifically, the chosen IT metrics
and KPIs should help organizations find accurate and actionable answers to the
following questions:
• How productive is the IT staff using the available technology resources?
• Are end-users and customers satisfied with the available services and
support?
• How dependable is the performance of core products and technology
solutions?
• Are the IT projects delivered efficiently and effectively?
29
There are hidden dangers here if both AST and DT are only loosely described. It is all
too easy for differences in views to hamper understanding and this, in turn, may lead
to an ambiguous set of commitments. AST is relatively easy to agree and from the
outset should be revisited on a regular basis to ensure that it does actually mean
what it says. There will often be times when the service provider has to rejig their
service offering to support their customers, meaning that the original AST is now
compromised. The onus would be on the SLM, to review consistently how
customers are using services in relation to set expectations and instigate the
necessary reworking of SLAs as appropriate.
If AST is relatively easy to agree and set, DT is a potential nightmare. Is it referring to
a loss of service that affects all users? Is the scope intended to include a partial
failure only affecting one person? Does it include maintenance time? How do we
actually measure DT? Does the customer have the ability to measure this in the
same way you can? Do they need to?
There is, of course, no easy answer away from the hard work involved in building a
strong relationship with the customer. It is to no good end that an SLM creates a
service level (for example, availability of service), measured only from a provider
perspective, and then presents what appears to be a compliant service at the review
meeting.
better to agree in advance the criteria for measuring the service levels that can be
30
accomplished by the service provider, no matter how high-level or simple they may
be, review them and make changes as appropriate
this approach of test-and-review will work for other commitments, too – reliability,
security, support, capacity, throughput, response times and continuity. Service levels
can be measured by both parties – and it must be stressed that both parties have a
responsibility to do this – and create a base understanding to build on. I am not
advocating changing service levels all the time; this would prove to be
counterproductive. However, in the early life of an SLA, an approach of regular
review and small changes on a frequent basis will provide long-term benefits for
relationships and trust.
30
31
32
33