Change and Release Management: Continual Improvement

Learn how IT organizations keep services stable while they keep changing them. You will see how service configuration management and IT asset management record what services are made of, how change enablement assesses, authorizes and schedules changes, and how release and deployment management make new features available safely. You will also learn how information security management and supplier management protect services, and how continual improvement uses a seven-step model and clear measures to make services better over time. Worked examples use realistic changes, deployments, contracts and improvement figures, in line with ITIL 4 and ITIL (Version 5) Foundation.

BeginnerLesson 5 of 5 in IT Service Management Course

What you will learn

  1. Describe how service configuration management and IT asset management keep reliable information about the parts that make up services, and how that information supports changes, support work and decisions.
    • Map configuration items and how they depend on each other
      Explain what a configuration item is, how configuration records, a CMDB and a configuration management system hold their details and relationships, and how teams use that information.
    • Manage IT assets from purchase to disposal
      Explain what an IT asset is, follow an asset through its lifecycle, control software licenses and cloud subscriptions, and tell IT assets apart from configuration items.
  2. Explain how change enablement lets an organization make beneficial changes quickly while controlling their risk: what counts as a change, the three types of change, risk assessment, change authorities and the change schedule.
    • Explain what a change is and why change enablement exists
      Define a change, state the purpose of change enablement, and explain the balance it strikes between speed and protection.
    • Classify changes as standard, normal or emergency
      Tell the three types of change apart by how they are assessed and authorized, and classify realistic change requests.
    • Assess risk, choose who authorizes and manage the change schedule
      Assess the risk of a change, assign a fitting change authority, use the change schedule to avoid conflicts, and review changes after implementation.
  3. Explain how release management decides when and how new features become available, how deployment management moves components into live environments, and how both work together with change enablement.
    • Plan and communicate releases
      Define a release, explain the purpose of release management, and plan, communicate and review a release in traditional and agile settings.
    • Choose a deployment approach and move components to live
      Explain the purpose of deployment management, describe environments, compare phased, big bang, pull and continuous delivery approaches, and plan for safe deployment.
    • Coordinate change, deployment and release in one delivery
      Follow one improvement from change request to release and review, and explain how change enablement, deployment, release, configuration and asset management each contribute.
  4. Explain how information security management protects the organization's information, and how supplier management keeps external and internal suppliers delivering what services need.
    • Protect information with information security management
      Explain the purpose of information security management, apply confidentiality, integrity, availability, authentication and non-repudiation, and balance prevention, detection and correction.
    • Manage suppliers and their performance
      Explain the purpose and activities of supplier management, compare sourcing strategies, and use contracts and performance data to manage suppliers.
  5. Explain how continual improvement keeps services and practices aligned with changing needs, use the continual improvement model to plan and check an improvement, and measure results with suitable techniques.
    • Make continual improvement part of everyday work
      State the purpose of continual improvement, explain who is responsible for it, and use a continual improvement register to collect and prioritize ideas.
    • Apply the continual improvement model step by step
      Use the seven steps of the continual improvement model to plan, carry out and check an improvement, and know how ITIL (Version 5) rephrases its last steps.
    • Measure progress and choose improvement techniques
      Use critical success factors, key performance indicators and baselines to measure improvement, avoid common measurement traps, and choose suitable techniques such as SWOT, gap analysis, balanced scorecard, maturity assessment and Lean.

Change and Release Management study guide

5 chapters

1

Keep accurate records of services and assets

Good change decisions depend on knowing what supports a service and what the organization pays for. Configuration information shows versions and dependencies; asset information follows value, cost, and lifecycle. You will trace a shared database dependency, compare records with the real environment, and follow equipment and subscriptions from acquisition to disposal. These records help teams assess impact, reuse resources, and retire assets safely.

1.1 Map configuration items and how they depend on each other

A server list tells you what equipment exists. To judge what happens when a server changes, you also need to know what runs on it and who depends on it. Service configuration management makes reliable information about service configurations available where and when teams need it.

Decide what needs configuration control

A configuration item (CI) is a component that must be managed to deliver an IT service. CIs can be physical equipment, virtual machines, databases, applications, cloud services, documents, or services themselves. The organization chooses which components need this control. A service level agreement can be a CI because its agreed content matters to service delivery; an inexpensive spare keyboard usually needs no configuration record.

A configuration record describes one CI. Useful fields include its identifier, type, version, owner, location, status, and relationships. The identifier keeps two similar servers from being confused. The version helps a deployment team check whether a planned update has already reached a target.

TermWhat it provides
CMDBA database holding configuration records.
CMSThe wider tools, data, and information used to manage and present configurations. It can combine several CMDBs and other sources.
Service mapA view of the CIs and relationships that deliver a service.
Follow dependencies to assess impact

Relationships such as "runs on," "uses," and "depends on" turn records into a service map. Read their direction carefully: an application that uses a database depends on that database being available.

Consider the ordering application WEB-ORD. It runs on virtual servers VS-01 and VS-02 and uses DB-ORD. That database runs on cluster CL-02. Monthly sales reporting also uses DB-ORD.

To assess an upgrade of CL-02:

  1. Find the database hosted on the cluster: DB-ORD.
  2. Follow the services that use that database: ordering and sales reporting.
  3. Consult both service owners about the impact and choose a time outside busy ordering hours.

Checking only the owner of CL-02 would miss the business services above it. The same map helps support staff trace a fault and helps security staff locate systems that need a patch. Release and deployment teams use configuration versions to check what is installed in each environment.

Keep records connected to actual work

Update affected records as part of authorized changes and deployments. Otherwise, a correct service map becomes misleading after the next upgrade. Verification and audits compare records with the real environment; automated discovery can help find differences. Investigate a mismatch to find whether the record is wrong or a change bypassed authorization.

A configuration baseline is an agreed, reviewed snapshot of CIs used as a reference for later changes. It helps teams compare a known state with the current state.

Collect the detail needed for real decisions. Recording every attribute of every device creates work that may not be maintained. A useful record set supports impact checks, diagnosis, and compliance, with clear responsibility for updates. An inventory alone cannot show those dependencies.

Key Takeaways

  • A CI is a component managed to deliver an IT service; it can include a service or document.
  • A CMDB holds records; the CMS is the wider system that manages configuration information.
  • Relationships reveal which services share a dependency.
  • Changes and deployments update records; verification compares them with reality.
  • Record detail that supports decisions and can be maintained.

1.2 Manage IT assets from purchase to disposal

IT assets have financial value and can contribute to delivering an IT product or service. They include equipment, software licenses, and cloud subscriptions. IT asset management manages their full lifecycle to gain value, control costs and risk, and meet contractual and regulatory requirements.

Follow the asset throughout its life

The lifecycle begins before purchase and continues after the asset stops being used:

  1. Plan: establish the need and consider what is already available.
  2. Acquire: buy, lease, or subscribe.
  3. Receive and register: record the item and its ownership or terms.
  4. Deploy: assign it to a user or location.
  5. Operate and maintain: repair, move, reassign, or renew it.
  6. Retire: remove it from active use.
  7. Dispose: erase data or destroy storage, then recycle or return equipment as appropriate.

Update the record at each event. A yearly count can check those updates, but cannot replace them. If a laptop changes user twice between counts, the organization still needs to know who holds it now.

An asset register records information such as asset tag, model, serial number, owner or user, location, purchase date and cost, warranty or lease end, license terms, and status. Status distinguishes an item "in stock" from one "in use" or "retired."

Match software rights to use

Software asset management compares entitlements with actual installation or use. Buying too few licenses creates compliance risk; retaining unused licenses wastes money. Check the license terms before reassigning or reducing subscriptions.

A company pays for 500 office-suite subscriptions at $120 per user per year. It has assigned 430, leaving 70 unused. Their annual cost in dollars is:

70×120=8,400

Forty new employees need the suite. Reassigning 40 unused subscriptions avoids buying 40 more, avoiding $4,800 of additional annual spending. Thirty remain unused; dropping those at renewal saves $3,600 a year. These are different benefits: avoided new spending and reduced existing spending.

Cloud accounts belong in the same financial view. A department's unreported subscription can escape both renewal control and security review. This shadow IT needs visibility even though there is no physical device to count.

Separate financial and configuration questions
ItemAsset viewConfiguration view
A live serverFinancial value and lifecycle costsManaged configuration and service relationships
A spare laptop in storageValue, location, and future useUsually no active service configuration to control
A service level agreementMay not be tracked as an IT assetCan be controlled as a CI

The same tool may hold both records, but the purposes differ. Resale value is not the test for an IT asset: a cloud subscription can have financial value without being resold.

Retirement does not complete disposal. Before equipment leaves, securely erase its data or destroy the storage and record the action. Send electronic waste to approved recyclers and return leased devices to the lessor. The asset record should show what happened to the item and when.

Key Takeaways

  • Asset management follows financial value, cost, risk, and lifecycle.
  • Update the asset register when assets are acquired, assigned, moved, renewed, retired, or disposed of.
  • Compare software entitlements with actual use before buying or renewing.
  • Assets and CIs overlap, but their management purposes differ.
  • Cloud subscriptions are assets even without a physical device.
  • Secure data and record disposal before equipment leaves.
2

Enable changes that succeed

Useful changes need a route that matches their risk and urgency. You will identify changes beyond software, distinguish standard, normal, and emergency routes, and decide who should authorize the work. Risk assessment, recovery planning, and scheduling connect those decisions to service protection. Worked cases show how a tiny edit can carry large consequences and how shared dependencies can make two otherwise reasonable plans conflict.

2.1 Explain what a change is and why change enablement exists

Changing a support procedure can affect a service just as changing a server can. A change is an addition, modification, or removal of anything that could directly or indirectly affect services. This includes equipment, applications, documents, processes, and supplier arrangements within the organization's chosen scope.

Make useful changes possible

Change enablement aims to maximize successful service and product changes. It does this through three connected responsibilities:

  • Assess the risks properly.
  • Authorize changes to proceed.
  • Manage the change schedule.

The aim is successful change, with protection suited to the risk. Users need improvements and fixes promptly. They also need existing services to keep working. A slow approval route for every minor task wastes time and can push teams to bypass it. Letting every team change shared systems without coordination exposes users to avoidable failures.

For example, replacing an application can bring new features but also interrupt existing work. Removing an old database is a change too: another service may still use its data. Even a document edit belongs in scope when it changes how staff deliver support. The relevant question is the possible effect on services, not whether someone writes new code.

Judge success by the result

A successful change is implemented as planned, delivers its intended result, and causes no unplanned harm such as incidents. "The installation finished" answers only part of that test. Users may still be unable to complete the task the change was meant to improve.

Suppose 240 changes were implemented in a quarter and 12 failed or were backed out. The number successful is 228. Calculate the rate using all implemented changes as the denominator:

Change success rate=240−12240×100%=95%

The 5% failure rate is the complement of the 95% success rate. Keeping both the count and the rate helps a team see the scale of the work. A high success rate should be read alongside how quickly valuable changes reach users; blocking useful work could produce few failures while meeting few needs.

Recognize names and sources of changes

ITIL 4 uses change enablement, as does ITIL (Version 5). Earlier material may say "change control" or "change management." Organizational change management is a separate practice concerned with people adopting new ways of working, including communication and training.

Change requests can begin with problem fixes, urgent incidents, security updates, supplier updates, new features, or improvement ideas. Their origin does not remove the need to assess, authorize, and coordinate them. A supplier patch still needs an appropriate change route; a small process improvement still needs attention to its effect on users.

Organizations define the scope and decision routes that fit their services. A useful route makes the responsible decision visible, gives people enough information to judge risk, and lets the team carry out the work at a suitable time.

Key Takeaways

  • A change can add, modify, or remove anything with a possible direct or indirect service effect.
  • Change enablement assesses risk, authorizes work, and manages the schedule.
  • Success includes the intended outcome and absence of unplanned harm.
  • Organizational change management addresses people adopting new ways of working.

2.2 Classify changes as standard, normal or emergency

A change's route depends on how it is assessed and authorized. Its technical size alone does not decide whether it is standard, normal, or emergency. A one-line router edit can carry greater risk than a large, proven software installation.

Choose the appropriate route
TypeAssessment and authorizationExample
StandardLow-risk, well understood, fully documented, and pre-authorized; no new authorization for each useInstalling an approved catalog application through its agreed procedure
NormalAssessed, authorized, and scheduled through a defined processMoving a customer database to a new storage system
EmergencyAssessed and authorized through an expedited route because implementation is needed as soon as possiblePatching a flaw being actively exploited

A standard procedure has its risk assessed when it is created and when it is modified. Its pre-authorization applies to that agreed procedure. A team cannot call an unfamiliar task standard simply because it expects the task to be easy.

Normal does not mean medium risk. A low-risk normal change may need only quick peer approval or automated checks. A major normal change may require senior management. Change models define these routes so teams know what information and authority each kind needs.

Write a usable change request

A normal change usually begins with a change request, also called an RFC. Give the decision maker the information needed to assess it:

  • What will change, why, and the expected benefit.
  • Affected services and CIs, with risk and impact.
  • Implementation and test plans.
  • A remediation plan for restoring service if it fails.
  • Proposed date and time.

For a database move, saying "new storage is faster" explains a hoped-for benefit but leaves the authority unable to judge who could be affected or how the team would recover.

Handle real urgency without losing control

Emergency assessment and authorization happen faster, often through a smaller authority. Keep testing as complete as time permits. Some documentation can be finished afterward, but the urgency does not turn the work into an unauthorized change. An untested repair can create another incident.

A manager wanting a feature today does not make the request an emergency. Immediate service or security threats justify the expedited route. For a quarter with 18 emergency changes out of 240 changes, the share is:

18240×100%=7.5%

Track this over time. Frequent urgent work can reveal planning problems that deserve improvement.

A repeated normal change can become standard after the team documents the proven procedure, assesses its risk, and obtains approval. Monthly patching of noncritical test servers might qualify. Repetition alone supplies experience, not pre-authorization. A firewall edit for a new partner remains normal unless an approved standard procedure covers that exact kind of edit.

Key Takeaways

  • Standard changes are low-risk, documented, well understood, and pre-authorized.
  • Normal changes use a defined assessment, authorization, and scheduling route at any risk level.
  • Emergency changes keep assessment and authorization but expedite them.
  • A change request includes benefit, impact, implementation, testing, recovery, and timing.
  • Technical size and managerial impatience do not determine change type.
  • A repeated normal procedure needs risk assessment and approval before becoming standard.

2.3 Assess risk, choose who authorizes and manage the change schedule

An approval is useful when the person making it understands the risk and can make a timely decision. A change authority is the person or group that authorizes a change. Assign authority according to the type and risk of the work, keeping routine decisions close to the people doing it.

Assess likelihood and impact separately

Likelihood concerns the chance of failure: complexity, testing, and the team's experience matter. Impact concerns the consequences: affected services and users, data loss, severity, and recovery time. Use configuration relationships to find services that share the changed component.

An organization might multiply impact and likelihood, each rated from 1 to 5. In this example it assigns scores 1–5 to peer approval, 6–12 to a change manager, and 13–25 to a senior authority or CAB. These are local thresholds.

ChangeCalculationRoute under this policy
Firewall rule: impact 4, likelihood 24×2=8Change manager
Database move: impact 5, likelihood 35×3=15Senior authority or CAB

A change advisory board (CAB) advises on significant changes. It need not approve every change. Peer review and automated checks can provide authorized routes for suitable low-risk work.

Plan recovery before implementation

Every normal change needs a remediation plan that says how to restore service and when to begin recovery. Rollback, or backout, returns to the previous state. Fixing forward applies a correction; another option is switching to an alternative service.

A tested recovery route can reduce the consequences of failure. A change with no tested recovery carries greater risk and deserves a higher-level decision. Simply writing "roll back if needed" leaves the team without a trigger, responsibility, or practical sequence.

Coordinate the change schedule

The schedule supports planning, communication, conflict checks, and resource allocation. It also helps incident and problem teams see recent changes that may explain a fault. Organizations may define freeze periods, such as a billing run, with emergency exceptions.

Suppose a switch replacement and an application upgrade both occupy Saturday 22:00–02:00. The application's servers depend on the switch. The outage would prevent application testing and make failures difficult to trace. Move the application upgrade to Sunday 22:00 and tell the service desk about both windows.

Review what actually happened

After implementation, check the objective, incidents, and unintended effects before closing the record. Review failures for lessons. Useful measures include success rate, changes causing incidents, emergency share, and request-to-implementation time.

Key Takeaways

  • Likelihood concerns failure probability; impact includes harm and recovery time.
  • Choose the change authority to fit the risk and change type.
  • Risk scoring thresholds belong to the organization.
  • Remediation includes rollback, fixing forward, or an alternative service, with a recovery trigger.
  • Check shared dependencies and resources before scheduling changes.
  • Review outcomes and incidents before closing the change record.
  • Peer review and automated authorization can support fast, controlled changes.
3

Make new and changed services available

Introducing a service improvement involves several decisions: approving the risk, moving components, preparing support, and making features available to users. You will separate these events and coordinate them in one delivery. Release planning, deployment approaches, controlled sources, and current records all contribute. A portal example follows a feature from an authorized change through deployment, limited access, wider release, and review.

3.1 Plan and communicate releases

A feature can be installed in production while users still cannot access it. Release management makes new and changed services and features available for use. It plans readiness and communication as well as the moment users gain access.

Define what the release contains

A release is a version of a service or other CI, or a collection of CIs, made available for use. It can contain application code, infrastructure, documentation, updated procedures, training, and knowledge articles. If support staff cannot help users with the feature, technical readiness alone leaves a gap.

Release planning sets scope, timing, and readiness criteria. For example, require tests to pass, support staff to be briefed, the user guide to be updated, and rollback to be tested. These criteria let the team decide readiness from evidence before access expands.

Version identifiers distinguish what is available. In a common major.minor.patch scheme, 4.2.0 to 4.3.0 marks a minor feature release; 5.0.0 marks a major one. Teams agree their numbering convention so release notes, support records, and installed versions refer to the same thing.

Separate deployment from access

Deployment moves components into an environment. Release makes them available for use. A feature flag, or toggle, can leave deployed code inactive and then enable it for selected users.

Consider a banking app adding PDF statements:

  1. On Tuesday, deploy version 3.4 to the live servers with the feature off. The code is present, but customers cannot use the new feature.
  2. On Thursday, release it to 10% of users. Monitor the crash rate against the team's limit of 0.5% of sessions.
  3. The rate stays below that limit, so on Monday release it to all users.

The rollout limit belongs to this team's release plan. It is not a universal release threshold. Controlled access gives feedback before the feature reaches the whole user population.

Match planning to the delivery rhythm
SettingTypical release patternManagement work still needed
Traditional or waterfallLarger, less frequent releases planned well aheadScope, readiness, timing, communication, and review
Agile or DevOpsSmaller, more frequent releases, often automatedScope, readiness, timing, communication, and review

Frequent delivery changes how the work is organized. Rules and automated checks can support quick decisions, while a team still decides who gets which feature and when.

Release notes explain what changed, what was fixed, and known issues in plain words. For the banking app: "You can download monthly statements as PDFs. Statements older than 24 months are not yet available." Give the service desk this information before users begin asking about it.

After release, gather user feedback, incidents, and performance data. Feed lessons into continual improvement. Pressing a deployment button does not perform this readiness, access, communication, and review work.

Key Takeaways

  • Release management makes new and changed services and features available for use.
  • Release scope includes the documentation, training, and support needed by users.
  • Readiness criteria provide evidence for the release decision.
  • Feature flags can separate deployment from release and limit initial access.
  • Release notes and post-release feedback support users and future improvements.

3.2 Choose a deployment approach and move components to live

Deployment management moves new or changed components into live environments and can move them into other environments for testing. Components include hardware, software, documents, and processes. The practice controls what reaches each target and checks that it works there.

Know where the component is going
EnvironmentPurpose
DevelopmentBuild components.
TestCheck components and their behavior.
Staging or pre-productionPerform final checks in a close copy of live.
Live or productionRun the CIs used to deliver services to customers.

A passed test in staging provides evidence for the move to live. After the move, quick functional tests and monitoring check the actual live result. Update configuration records to show the installed version and changed relationships.

Choose an approach that fits the service

Phased deployment moves components into one part of live at a time. It limits initial exposure and gives feedback before the next wave. A team updating 2,000 laptops chooses four waves of 500, starting with IT staff who can report problems clearly.

The team pauses if deployment-related incidents affect more than 2% of a wave's laptops. In the first wave, incidents affect 25 distinct laptops:

25500×100%=5%

Five percent exceeds the team's limit, so it pauses, investigates, fixes the cause, and retests before wave 2. The denominator is the deployed wave, not all 2,000 laptops. Count affected devices, since several incident tickets might concern the same device.

Big bang deployment moves components to all targets at once. It suits a clean switch when old and new versions cannot coexist. For example, all 120 stores receive new point-of-sale software on the same night because both versions cannot share the central system. A failure could affect every store, so test thoroughly and rehearse remediation.

Pull deployment places approved software in a controlled repository for users to install when they choose. An organization can publish a conferencing update in its software portal and set a deadline before the old version stops working.

Continuous delivery integrates, tests, and deploys components whenever needed, supporting frequent feedback. Automated movement still needs controlled sources, authorization, validation, and current records.

Control the source and the recovery

Keep deployable components in secure, controlled locations, such as a definitive library or artifact repository. Teams should obtain the authorized, tested version consistently instead of relying on an unverified local copy.

Carry out deployment under an authorized change. Have a remediation plan ready before moving components. Check the result immediately and act on failed checks. An installed version can remain inactive until release management makes its feature available to users; deployment completion does not establish that release has happened.

Key Takeaways

  • Deployment moves components into live or other target environments.
  • Phased deployment exposes one part at a time; big bang switches all targets together.
  • Pull deployment lets users obtain approved software from a controlled source.
  • Continuous delivery supports frequent, tested movement when needed.
  • Calculate wave incident rates using the wave and the quantity the rule counts.
  • Authorize the change, control component sources, check results, and update CI records.

3.3 Coordinate change, deployment and release in one delivery

One delivery draws on several practices because each solves a different problem. Coordinating them avoids a gap between an authorized technical task and a feature that people can use successfully.

Ask the question each practice answers
PracticeMain question in a delivery
Change enablementShould the change proceed, at what risk, and when?
Deployment managementHow do components reach the target environment?
Release managementWhen do features become available, and to whom?
Service configuration managementWhat is installed and how does it relate to other CIs?
IT asset managementWhat assets and costs now exist across their lifecycle?

These responsibilities can be carried out by the same team. They still need distinct decisions and records. An agile team can combine peer review, automated checks, and recorded decisions without sending every delivery to a meeting.

Follow a portal feature through delivery

An HR portal will let employees upload expense receipts. The change request describes the benefit, affected CIs, implementation, tests, and recovery. Under the organization's risk model, impact 3 and likelihood 2 give a score of 6. The change manager authorizes a normal change for Wednesday 20:00–22:00 after checking for portal conflicts.

The team tests version 2.8 in staging, then deploys it to the live servers during that window. It leaves the upload feature switched off. Configuration records now show version 2.8. Any added subscriptions or equipment also need asset records and lifecycle ownership.

On Friday, release management makes the feature available to 150 finance employees. The service desk has release notes and a short guide beforehand. A week later, access expands to all 2,400 employees. Installation and user availability have different dates, so a question about whether the feature is "live" needs a precise answer about which event is meant.

Review outcomes and pass on lessons

During the first week, three people ask how to use the upload feature. The service is working normally: these are requests for guidance, not incidents. The review checks that receipts can be uploaded as intended and finds no interruption or degradation. The change can close as successful, with an improvement idea to add an in-app tip.

One release can require several deployments, such as waves to different targets. One deployment can contain several features released at different times using flags. There is no required one-to-one relationship among a change, a deployment, and a release.

Connect the work to value delivery

In ITIL 4, these practices contribute especially to design and transition, obtain/build, and deliver and support activities. ITIL (Version 5) describes eight product and service lifecycle activities: discover, design, acquire, build, transition, operate, deliver, and support. Build and transition are central to preparing and introducing changed components. The delivery still needs evidence that the intended service result reached users.

Key Takeaways

  • Change, deployment, and release answer different questions in the same delivery.
  • Update configuration and asset information when the delivery changes it.
  • A request for guidance is not an incident when service is working normally.
  • One release may need several deployments; one deployment may support several releases.
4

Protect information and work with suppliers

Services depend on trustworthy information and reliable partners. You will identify the information properties a control protects, combine prevention with detection and recovery, and connect security to changes and asset disposal. Supplier management adds clear agreements, performance reviews, and exit planning. An availability calculation shows how a contract target becomes a concrete limit and how a missed target feeds improvement.

4.1 Protect information with information security management

Information security management protects the information an organization needs for its work by understanding and managing risk. It applies to the people, procedures, suppliers, and technology handling that information. The security team coordinates specialist work, but everyone has a role.

Identify what needs protecting
PropertyMeaningService example
ConfidentialityAccess to information is restricted to authorized people.Only HR staff can read salary data.
IntegrityInformation stays accurate and complete and is changed only with authorization.A payment amount cannot be altered in transit without authorization.
AvailabilityInformation and services can be reached when needed.Customers can order during a busy sale.
AuthenticationA claimed identity is checked.Sign-in requires a password and a phone-app code.
Non-repudiationEvidence supports accountability so an action cannot credibly be denied.A digitally signed approval records who approved it.

The first three are often called CIA. A service can protect confidentiality yet fail availability if users cannot reach it. Authentication checks who someone is; it does not by itself establish what they may access. Non-repudiation concerns evidence of an action, beyond the sign-in event.

Balance prevention, detection, and correction

Prevention reduces the chance of incidents. Examples include patching, access controls, firewalls, and awareness training. Detection finds incidents that get through, using monitoring, alerts, and log review. Correction limits damage and restores normal operation, using isolation, recovery, and fixes.

For ransomware, a balanced approach works across these stages:

  1. Patch promptly, filter malicious email, require multi-factor sign-in, and give accounts only the access they need.
  2. Alert when software starts encrypting many files unexpectedly.
  3. Isolate infected computers, restore from offline backups, and find and fix the entry route.

Backups support recovery; they do not replace measures that prevent attacks or detect them early. Choose controls in proportion to information value, threats, and vulnerabilities. Controls that make ordinary work needlessly difficult can encourage unofficial workarounds.

Build security into routine practices

A security policy, defined roles, and regular training guide daily behavior. Remove a leaver's access on the last working day. ISO/IEC 27001 sets requirements for an information security management system; organizations can seek certification against it.

Configuration information helps locate affected systems: a vulnerable library on 37 of 400 servers identifies the patch targets. Routine patches use standard or normal change routes. An active threat requiring immediate action uses emergency assessment and authorization. Asset management secures data before disposal, while supplier management sets security requirements and controls supplier access.

Key Takeaways

  • Information security manages risks to information needed by the organization.
  • Confidentiality, integrity, and availability protect different properties.
  • Authentication checks identity; non-repudiation provides evidence of actions.
  • Use prevention, detection, and correction together.
  • Choose controls in proportion to risk and make them workable.
  • Configuration, change, asset, and supplier practices all support security.

4.2 Manage suppliers and their performance

A supplier's work becomes part of the service customers experience. Supplier management manages suppliers, relationships, agreements, and performance so quality products and services fit together smoothly. Suppliers can be external businesses or internal departments.

Choose how to source the work
StrategyWhat it meansMain decision to examine
InsourcingThe organization does the work itself.Can it provide the skills and resources?
OutsourcingAn external supplier does the work.Can the supplier meet quality, cost, and risk needs?
Single source or partnershipOne supplier provides the service, often through a close relationship.How will dependence and exit be managed?
Multi-sourcingSeveral suppliers provide parts of a service.How will their work be coordinated?

These describe different aspects of sourcing: an organization may outsource to a single partner or several suppliers. Choose based on culture, skill scarcity, expertise, total cost, external constraints, and demand predictability. The cheapest quoted price can hide coordination effort or weak service quality.

Make expectations measurable

Maintain visibility of suppliers, strategy, policies, and contract information. Agree service targets, response times, security and data requirements, reporting, prices, and remedies such as service credits. Include dispute handling and exit arrangements, especially data return.

Contracts start ongoing management. Track performance, review relationships, and plan renewals and exits. A strategic cloud supplier needs joint planning and regular reviews; a cable supplier can usually be managed through standard purchasing terms.

Check performance against the agreement

Suppose a hosting contract promises 99.9% availability over an entire 30-day month. The measurement period contains:

30×24×60=43,200 minutes

The allowed downtime is 0.1% of that period, or 43.2 minutes. Actual downtime is 95 minutes. Availability is:

43,200−9543,200×100%≈99.78%

The target was missed. Apply the service credit specified in the contract and agree an improvement plan at the supplier review. A small-looking difference between percentage figures can still represent substantial extra downtime. Use the agreed measurement period and contract rules when assessing performance.

Keep responsibility and manage dependence

The organization remains accountable to its own customers even when a supplier delivers part of the service. A supplier credit addresses an agreement; it does not restore a customer's interrupted work. Teams need a coordinated response and improvement actions too.

Good relationships support honest reporting and shared outcomes. Manage vendor lock-in, the difficulty of moving away from one supplier, through portable data and a tested exit plan. With several suppliers, make responsibilities and handoffs clear so a fault is resolved across the service instead of passed between contracts.

Key Takeaways

  • Supplier management continues through performance, relationship, renewal, and exit work.
  • Choose sourcing using total cost, expertise, quality, constraints, and risk.
  • Contracts need measurable service targets and clear security, reporting, remedy, and exit terms.
  • Compare availability against the agreed period and measurement rules.
  • Outsourcing leaves the organization accountable to its customers.
  • Portable data and exit planning reduce dependence on a supplier.
  • Multi-sourcing needs coordination across the complete service.
5

Improve services continually

Improvement starts with a need and continues through evidence, action, feedback, and renewed priorities. You will use a register to manage ideas, apply the seven-step improvement model, and connect success conditions to balanced measures. Worked figures distinguish progress from target achievement and percentage points from relative change. Assessment techniques help you choose where to investigate, while everyday ownership keeps useful changes in place.

5.1 Make continual improvement part of everyday work

Service needs change as users, technology, and organizations change. Continual improvement keeps services and practices aligned with those needs through ongoing improvements to products, services, practices, and the way they are managed. A clearer form can matter as much to one team as a new platform does to the organization.

Give everyday ideas a route to action

Everyone is responsible for improvement. A dedicated team can coordinate work, coach people, and track results. Leaders provide time and budget. Staff doing the work identify difficulties and test better ways of handling them.

Improvement activities include finding opportunities, logging them, assessing and prioritizing them, making business cases, planning action, carrying it out, and evaluating results. Coordination helps teams avoid competing efforts or changes that move a problem elsewhere.

Ideas can come from incident and problem trends, customer feedback, satisfaction surveys, staff suggestions, audits, new technology, supplier reviews, and change or release reviews. A support team noticing repeated confusion after releases has useful improvement evidence even when no major outage has occurred.

Keep a continual improvement register

A continual improvement register (CIR) is a structured document or database that tracks ideas from identification through final action. Record the idea, source, expected benefit, estimated effort, priority, owner, and status. An owner gives a useful idea someone responsible for its next decision.

An organization can keep registers at team and organization levels. The important work is managing ideas through assessment and action. A long list with no owners or status updates gives little help in choosing what happens next.

Compare benefit and effort

A team scores benefit and effort from 1 to 10 and uses benefit per unit of effort as one prioritization aid:

IdeaBenefitEffortBenefit divided by effort
A: self-service password reset83About 2.7
B: replace the ticketing tool991.0
C: articles for common incidents616.0

On this measure, start with C, then A, then B. The highest total benefit is not the same as the highest benefit per unit of effort. Keep B in the register so its value and resource needs can be reconsidered. A ratio helps compare work; prioritization still needs attention to organizational goals and constraints.

Connect improvement to the service system

ITIL 4 places continual improvement in the service value system, in the value chain's "improve" activity, and in the management practices. ITIL (Version 5) keeps it in the ITIL value system and as a practice.

Improvement puts "start where you are," "focus on value," and "progress iteratively with feedback" into daily work. Begin with evidence of the present problem, choose an action with a useful outcome, and use feedback to decide the next action. Small, frequent steps by the people doing the work belong here alongside larger initiatives.

Key Takeaways

  • Continual improvement aligns services and practices with changing needs.
  • Everyone contributes; leaders provide resources and a team may coordinate.
  • A CIR tracks ideas, benefit, effort, priority, ownership, and status through action.
  • Benefit divided by effort can support prioritization alongside goals and constraints.
  • Feedback, trends, reviews, audits, and staff suggestions supply improvement ideas.

5.2 Apply the continual improvement model step by step

Buying a tool or rewriting a procedure is an action. To establish improvement, connect that action to a needed outcome and measure what changed. The continual improvement model provides seven steps for this work at any scale.

Set direction and understand the starting point
  1. What is the vision? Link the work to organizational objectives and explain the benefit stakeholders need.
  2. Where are we now? Assess the current state objectively and create a baseline for comparison.
  3. Where do we want to be? Compare the current and desired states and set specific, measurable, time-bound targets.

A vision such as "users can return to work quickly" supplies direction. A target such as "reach 70% first contact resolution within six months" makes one part of that direction measurable. "Faster support" alone gives no defined result or deadline.

A baseline records the starting state. Use a clear measurement definition so the later result can be compared meaningfully. Counting different kinds of contacts in the two periods can make an apparent change difficult to interpret.

Plan, act, check, and sustain
  1. How do we get there? Choose a plan, using iterations when the best route is uncertain.
  2. Take action. Carry out the plan while watching risks and side effects.
  3. Did we get there? Measure again and compare the result with both the baseline and target. Adjust earlier steps if needed.
  4. How do we keep the momentum going? Share results, embed the better way of working, and continue improvement.

These questions support a loop. They do not require waiting until a large project finishes before learning from feedback. An unsuccessful iteration can show what to change next.

Work through a service desk improvement

A service desk resolves 696 of 1,200 monthly contacts at first contact. Its baseline is:

6961,200×100%=58%

The team sets a 70% target within six months. It plans better knowledge articles and remote-access tools, then introduces them. After three months, 736 of 1,150 contacts are resolved at first contact:

7361,150×100%=64%

Compare rates because the total contacts changed. Sixty-four percent is above the baseline but below the target. Return to planning, examine contact types still being passed on, and add focused training. There is progress, but the team cannot report that the target has been reached.

After achieving a useful result, retain ownership of articles, train new staff, and share evidence of the outcome. This helps the service avoid slipping back when the original improvement team moves on.

Recognize the Version 5 wording

ITIL (Version 5) retains seven steps. Step 6 asks "Are we getting there?" and step 7 asks "How do we keep the improvements relevant?" The wording highlights ongoing checks of progress and continued relevance. The baseline, target, action, and feedback remain essential to using the model.

Key Takeaways

  • Link the improvement to a vision before choosing activities.
  • Establish the baseline, then a measurable target with a time frame.
  • Plan and act in steps that allow feedback.
  • Compare results with both baseline and target; progress can fall short of the target.
  • Embed useful changes and continue improvement.
  • Version 5 emphasizes ongoing progress checks and keeping improvements relevant.

5.3 Measure progress and choose improvement techniques

A useful measure shows whether the service is achieving something people need. Counting activity alone can make a busy team look successful while its users remain unhappy. Choose measures that connect the work to intended outcomes.

Connect success conditions to indicators

A critical success factor (CSF) is a condition that must be met to achieve the intended result. A key performance indicator (KPI) measures whether a CSF is being met. For the CSF "users get their problems solved quickly," possible KPIs include first contact resolution rate and average incident resolution time.

Balance indicators so one target does not reward harmful behavior. If agents are judged only on resolution time, closing tickets too early makes the figures look better. Pair that measure with reopen rate and user feedback to check whether the problems were actually solved.

When technical reports are green but users have a poor experience, the mismatch is sometimes called the watermelon effect. Satisfaction and complaint measures help reveal what technical indicators miss.

Compare percentages accurately

An increase from 58% to 64% is 6 percentage points. The relative increase compares that difference with the starting rate:

64−5858×100%≈10.34%

State which comparison you mean. Reporting "6% improvement" for this change confuses the point difference with the relative change. Use consistent populations, measurement definitions, and periods when comparing results.

When combining groups, add their success counts and total counts before calculating the overall rate. A web channel resolves 90 of 150 contacts and a phone channel resolves 20 of 50. Together, they resolve 110 of 200, or 55%. Averaging their 60% and 40% rates equally would give 50%, but the web group has three times as many contacts.

Choose a technique for the question
TechniqueQuestion it helps answer
SWOTWhat are our strengths, weaknesses, opportunities, and threats?
Gap analysisHow does the current state differ from the desired state?
Balanced scorecardHow are financial, customer, internal-process, and learning-and-growth results developing?
Maturity assessmentHow developed is a practice against a defined scale?
LeanWhere do waiting, rework, and unnecessary handoffs waste effort?

A maturity scale might run from 1, initial, to 5, optimized; use the scale defined by the assessment. A higher practice rating and a better customer outcome are different measures and need their own evidence.

A normal change takes 6 days from request to implementation. Five days are spent waiting for a weekly approval meeting. Waiting accounts for:

56×100%≈83.33%

Lean points attention to that waiting. A fitting peer-approval route for low-risk work can reduce the delay while preserving authorization. Speeding a short implementation task would leave most of the lead time untouched.

Agile supports small increments and frequent feedback. DevOps connects development and operations with automation for fast, safe delivery. Both fit iterative improvement. When an improvement alters a service, tool, or process, route it through change enablement and, where needed, deployment and release. Measure its effect against the baseline.

Key Takeaways

  • A CSF states a necessary success condition; a KPI measures progress toward it.
  • Pair speed measures with quality and experience measures to discourage harmful shortcuts.
  • Percentage-point differences and relative percentage changes use different comparisons.
  • Choose assessment techniques according to the question being investigated.
  • Lean examines waste such as waiting, rework, and unnecessary handoffs.
  • Measure an improvement after its associated change, deployment, or release.

Change and Release Management examples

5 Walkthroughs

1

Trace a service and manage what it uses

12 steps
Use a service map to assess an upgrade, then follow software rights and equipment through their lifecycle.
  1. 1
    IntroductionStart with two different questions

    A team plans a database-cluster upgrade and is also reviewing software costs. For the upgrade, it needs to know which services rely on the cluster. For costs, it needs to know which assets it pays for and uses.

    Follow both decisions: first trace configurations and relationships of each configuration item (CI), so no affected service is missed, then manage financial value and lifecycle of each IT asset, so costs stay under control. The same server can appear in both views, with different information needed for each.

  2. 2
    ExplanationChoose the items to control

    A configuration item (CI) is a component that must be managed to deliver an IT service. It can be an application, database, server, cloud service, document, or the service itself.

    Its record identifies it and describes useful details such as version, owner, status, and relationships. A CMDB holds these records; a CMS is the wider system of tools and information that manages and presents them.

  3. 3
    ExampleBuild the first dependency path

    The ordering application WEB-ORD runs on VS-01 and VS-02 and uses database DB-ORD. DB-ORD runs on cluster CL-02.

    Read the relationships as service dependencies. If CL-02 is unavailable, DB-ORD can be affected, and ordering may lose access to its data. A list saying that all five components exist would not show this path or identify the ordering service as a stakeholder in the cluster upgrade.

  4. 4
    ExampleFind the second affected service

    Monthly sales reporting also uses DB-ORD. The cluster upgrade can therefore affect both ordering and reporting through the shared database.

    Consult both service owners and plan outside busy ordering hours. Configuration relationships let the change team look beyond the component owner. The team also checks that the map is current, since a missing relationship could leave a service out of the impact assessment.

  5. 5
    ChallengeTrace a different shared dependency

    A booking application and a staff dashboard both use database DATA-A on HOST-A. HOST-B runs an unrelated test service. HOST-A will be restarted. Which service owners need consultation?

    ---reveal---

    Consult the booking and dashboard owners: both depend on DATA-A, which depends on HOST-A. Nothing in these relationships identifies the test service as affected. Trace the paths from the changed component instead of selecting only its technical owner.

  6. 6
    TipCheck the record against reality

    Update affected CI records during changes and deployments, not only during a later audit. A discovery scan can help compare installed versions and connections with recorded ones.

    Investigate differences: either the record may be wrong or a change may have bypassed authorization. A reviewed configuration baseline supplies an agreed reference state. Keep the detail needed for decisions at a level the team can maintain.

  7. 7
    ExplanationFollow value through the asset lifecycle

    An IT asset has financial value and can contribute to a product or service. Equipment, software rights, and cloud subscriptions all qualify.

    Follow the asset through planning, acquisition, registration, deployment, use and maintenance, retirement, and disposal. Update its register entry when its user, location, cost, terms, or status changes. A yearly count checks these records but leaves everyday moves unmanaged if it is the only control.

  8. 8
    ExampleFind unused subscription rights

    The firm pays for 500 office-suite subscriptions, but only 430 are assigned. Seventy are unused. Each costs $120 per year, so their annual cost in dollars is:

    70×120=8,400

    Before buying more, compare entitlements with use. Too few rights create compliance risk; too many waste money. The register must also include cloud subscriptions acquired by departments, even if IT did not arrange the purchase.

  9. 9
    ExampleSeparate avoided buying from renewal savings

    Forty new employees need the office suite. Reassign 40 of the unused subscriptions if the terms permit it. At $120 each, that avoids $4,800 of new annual spending.

    Thirty subscriptions remain unused. Dropping those at renewal saves $3,600 a year. Do not add the avoided purchase to a claim that all 70 subscriptions were canceled: 40 are now being used. The two benefits come from different decisions.

  10. 10
    Key InsightOne item can need both views

    A live server is usually both an asset and a CI. Its asset record follows cost and lifecycle; its configuration record shows version, setup, and service relationships.

    A spare laptop can be an asset without being an active CI. A service level agreement can be a CI without being tracked as an IT asset. The reason for managing an item determines the view; whether it can be resold is not the test for asset status.

  11. 11
    ChallengeRetire equipment without losing control

    A team replaces a service server and sends the old device to a recycler. It updates the service map but leaves the asset record "in use" and has no data-erasure record. What work remains?

    ---reveal---

    Secure the stored data before the device leaves and record the disposal action. Update the asset lifecycle status and disposal information. The configuration update records the service change, but it does not establish secure disposal or complete the financial lifecycle record.

  12. 12
    RecapUse the record that answers the decision

    For a service impact decision, trace CI relationships and check the current configuration. For a cost or lifecycle decision, check asset ownership, use, terms, and status.

    Keep both views current during real work. In the cluster case, relationships exposed two affected services. In the subscription case, entitlements enabled reuse before buying. At disposal, security action and an asset-record update finish work a service map alone cannot record.

2

Route a change from request to review

16 steps
Classify changes, judge likelihood and impact, choose authority, and coordinate implementation and recovery.

Save this lesson to follow every Walkthrough step by step.

  1. 1
    IntroductionFollow a useful change safely
  2. 2
    ExplanationRecognize changes beyond code
  3. 3
    ExampleCalculate change success
  4. 4
    ChallengeCheck the intended result
  5. 5
    ExplanationUse a standard procedure within its scope
  6. 6
    ExplanationGive normal work a defined route
  7. 7
    ExampleKeep control when action is urgent
  8. 8
    ChallengeClassify a small but unfamiliar edit
  9. 9
    ExplanationSeparate probability from consequences
  10. 10
    ExampleApply a local risk policy
  11. 11
    ExampleRoute a higher-impact change
  12. 12
    TipMake recovery executable
  13. 13
    ExampleResolve a dependency conflict
  14. 14
    ChallengePut risk and timing together
  15. 15
    ConnectionUse the review to improve the route
  16. 16
    RecapMatch the route to the work
3

Deliver a portal feature in separate stages

15 steps
Plan readiness, choose deployment controls, and distinguish installation from user access in a coordinated delivery.

Save this lesson to follow every Walkthrough step by step.

  1. 1
    IntroductionTrack components and user access
  2. 2
    ExplanationPlan the usable release
  3. 3
    ExplanationChoose the target environment
  4. 4
    ExplanationCompare deployment choices
  5. 5
    ExampleApply a wave pause rule
  6. 6
    ChallengeCheck the quantity the rule counts
  7. 7
    ExampleSee deployment without release
  8. 8
    ExampleCommunicate before widening access
  9. 9
    ChallengeDecide what is ready for users
  10. 10
    ExampleAuthorize the HR portal work
  11. 11
    ExampleInstall and update the records
  12. 12
    ExampleRelease to finance and then everyone
  13. 13
    ChallengeReview contacts without distorting results
  14. 14
    ConnectionPlace the practices in value delivery
  15. 15
    RecapName the event precisely
4

Protect a service and manage its partners

13 steps
Apply information properties and security controls, then use supplier evidence to manage risk and performance.

Save this lesson to follow every Walkthrough step by step.

  1. 1
    IntroductionLook beyond a secure server
  2. 2
    ExplanationDistinguish the core security properties
  3. 3
    Key InsightSeparate identity from evidence of action
  4. 4
    ExplanationUse controls at three points
  5. 5
    ExampleReduce the chance of ransomware
  6. 6
    ExampleDetect harm and restore service
  7. 7
    ChallengeDiagnose an incomplete security plan
  8. 8
    ExplanationChoose and coordinate suppliers
  9. 9
    ExplanationAgree what performance means
  10. 10
    ExampleTranslate availability into downtime
  11. 11
    ExampleCompare actual performance with the target
  12. 12
    ChallengeConnect supplier access and exit
  13. 13
    RecapCheck both protection and performance
5

Turn an improvement idea into measured progress

16 steps
Prioritize ideas, apply the seven-step model, and judge results with balanced measures and suitable assessment techniques.

Save this lesson to follow every Walkthrough step by step.

  1. 1
    IntroductionBegin with the outcome people need
  2. 2
    ExplanationGive improvement everyday ownership
  3. 3
    TipManage the idea through a register
  4. 4
    ExampleCompare benefit with effort
  5. 5
    ChallengeChoose a priority without losing ideas
  6. 6
    ExampleConnect vision to the baseline
  7. 7
    ExplanationDefine the next desired state
  8. 8
    ExampleMeasure again before declaring success
  9. 9
    ChallengeJudge a fresh result
  10. 10
    ConnectionKeep useful changes relevant
  11. 11
    ExplanationLink indicators to success conditions
  12. 12
    ExampleName the percentage comparison
  13. 13
    ExplanationMatch assessment to the question
  14. 14
    ExampleFind the time consumed by waiting
  15. 15
    ChallengeCheck whether faster is better
  16. 16
    RecapUse feedback to choose the next step

Change and Release Management practice questions

50 Practice Questions in 5 sets

Set 1: Records and everyday service decisions10 Practice Questions

Question 1 of 10

A technician needs to find every service that depends on a database before restarting it. What information is most useful?
  1. The database server purchase date.
  2. The database license renewal price.
  3. The database dependency relationships.
  4. The database storage warranty terms.
Show answerHide answer
Answer: C
Dependency relationships show which applications and services rely on the database. Following them reveals the reach of a restart, including indirect effects. A purchase record may identify the equipment but does not establish which services need it.

Question 2 of 10

A valuable spare laptop is stored for future staff and is not under configuration control. How should it be classified?
  1. As an IT asset, with its stock status recorded.
  2. As a CI, with no financial record needed.
  3. As both an asset and a CI in every case.
  4. As neither until it is assigned to a user.
Show answerHide answer
Answer: A
The laptop has financial value and can contribute to a service, so it is an IT asset while in storage. Its record should show that status. A component does not have to be an active CI to belong in the asset register.

Question 3 of 10

A team has repeated a low-risk task successfully, but has never documented or pre-authorized it. What route fits its next planned use?
  1. Standard, because repetition establishes approval.
  2. Emergency, because prior results reduce testing.
  3. Standard, once the requester confirms the need.
  4. Normal, using the appropriate assessment route.
Show answerHide answer
Answer: D
A normal route fits because this task has no approved standard procedure. Repetition provides useful experience but does not supply documentation or pre-authorization. To make the task standard, document it, assess its risk, and obtain approval.

Question 4 of 10

A support team removes a step from its user-verification procedure. Why can this count as a change?
  1. It always requires a software deployment.
  2. It could affect how the service is delivered.
  3. It becomes a new supplier arrangement.
  4. It necessarily requires a board meeting.
Show answerHide answer
Answer: B
A change includes adding, modifying, or removing something that could affect services directly or indirectly. A support procedure can affect service delivery even without a code change. The definition does not make a deployment or board meeting necessary.

Question 5 of 10

A reporting feature is installed in production on Monday but enabled for users on Thursday. When is the feature released?
  1. Monday, when production files are installed.
  2. Tuesday, once the installation is recorded.
  3. Thursday, when users gain access to it.
  4. Thursday, once the next build is started.
Show answerHide answer
Answer: C
The feature is released when it becomes available for use on Thursday. Monday is the deployment event: components reach production while access remains disabled. Installed code alone does not establish that users can use the feature.

Question 6 of 10

Employees install an approved update from a company portal at a time they choose. What deployment approach is this?
  1. Big bang deployment.
  2. Pull deployment.
  3. Phased deployment.
  4. Continuous delivery.
Show answerHide answer
Answer: B
Pull deployment makes approved software available from a controlled source for users to obtain when they choose. The portal and user choice identify this approach. Phased deployment concerns planned groups of targets, not simply different users choosing different times.

Question 7 of 10

An attacker changes an invoice amount without permission, while the invoice remains readable and accessible. What information property is directly harmed?
  1. Integrity.
  2. Availability.
  3. Authentication.
  4. Confidentiality.
Show answerHide answer
Answer: A
Integrity protects information from unauthorized change and keeps it accurate and complete. The changed invoice amount directly harms that property. Availability concerns being able to reach information; the invoice remains accessible in this situation.

Question 8 of 10

An employee finds an improvement idea that cannot be funded this month. Where should the idea be tracked with an owner and status?
  1. In the list of completed change requests.
  2. In the register of retired equipment.
  3. In the schedule of authorized deployments.
  4. In the continual improvement register.
Show answerHide answer
Answer: D
The continual improvement register tracks ideas from identification through assessment and action, including work awaiting resources. An owner and status make the next decision visible. A change schedule concerns planned changes and cannot replace management of an unfunded idea.

Question 9 of 10

A team chooses a tool and starts using it before measuring current performance. What essential evidence is missing for judging the result?
  1. A list of all possible replacement tools.
  2. A baseline of performance before the action.
  3. A record of how many meetings took place.
  4. A prediction that every user will approve.
Show answerHide answer
Answer: B
A baseline establishes the current state before the improvement so later results can be compared with it. Starting action first leaves the team without that reference. Counting meetings shows activity, not the service performance the improvement was meant to change.

Question 10 of 10

An application upgrade and a network replacement share a window. The application depends on that network, and its required live tests need the network available. Both changes are individually authorized. What should happen next?
  1. Run both, since separate approvals remove the conflict.
  2. Test the application only before the network work begins.
  3. Coordinate separate windows and communicate the new plan.
  4. Give both changes to the same engineer in the shared window.
Show answerHide answer
Answer: C
The shared dependency prevents the required application checks while the network is unavailable. Separate the windows and communicate the revised plan so implementation and testing can be coordinated. Individual approvals do not remove the combined scheduling conflict.
Set 2: Risk, readiness, and service protection10 Practice Questions

Save this lesson to see every answer and practice every set.

Question 1 of 10

A supplier reports an actively exploited flaw that must be patched immediately. What change route fits?
  1. Normal, delayed until the next scheduled meeting.
  2. Standard, because the supplier produced the patch.
  3. Standard, because the patch changes few files.
  4. Emergency, with expedited assessment and approval.
Show answerHide answer

Save this lesson to see this answer.

Question 2 of 10

A local policy multiplies impact and likelihood, each from 1 to 5. Scores 1–5 use peer approval, 6–12 use a change manager, and 13–25 use a senior authority. Impact is 3 and likelihood is 3. Who authorizes it?
  1. The change manager.
  2. The peer reviewer.
  3. The senior authority.
  4. The requesting user.
Show answerHide answer

Save this lesson to see this answer.

Question 3 of 10

A proposed database update has strong test results but would take two days to recover from failure. Two critical services depend on it. How should this affect assessment?
  1. Treat likelihood as high solely because recovery is slow.
  2. Keep risk low because testing covers the changed database.
  3. Assess the large impact and use a fitting authority.
  4. Require the CAB because all database changes use it.
Show answerHide answer

Save this lesson to see this answer.

Question 4 of 10

A release passes functional tests, but service desk guidance and required user training are unfinished. What release-planning gap remains?
  1. The release needs a different version-number pattern.
  2. The release has not met its full readiness criteria.
  3. The deployment must be classified as an emergency.
  4. The software must be deployed again to staging.
Show answerHide answer

Save this lesson to see this answer.

Question 5 of 10

A firm pays for 360 annual subscriptions at $90 each; 312 are assigned. Twenty new employees need them. How much new annual spending can be avoided by reassigning unused subscriptions, if the terms allow it?
  1. $4,320.
  2. $2,520.
  3. $32,400.
  4. $1,800.
Show answerHide answer

Save this lesson to see this answer.

Question 6 of 10

A contract measures availability over all 20,000 minutes in a reporting period and requires 99.5%. What is the maximum downtime consistent with that target?
  1. 10 minutes.
  2. 100 minutes.
  3. 199 minutes.
  4. 500 minutes.
Show answerHide answer

Save this lesson to see this answer.

Question 7 of 10

A monitor alerts the team when a computer begins encrypting many files unexpectedly. What kind of security control is the alert?
  1. Detection.
  2. Correction.
  3. Prevention.
  4. Authorization.
Show answerHide answer

Save this lesson to see this answer.

Question 8 of 10

An update has reached 240 of 960 devices. A policy pauses the wave if more than 3% of its devices have deployment-related incidents. Twelve tickets concern six distinct devices in that wave. What is the policy result?
  1. Pause: the affected-device rate is 5%.
  2. Pause: the affected-device rate is 0.625%.
  3. Continue under this rule: the rate is 2.5%.
  4. Continue under this rule: the rate is 1.25%.
Show answerHide answer

Save this lesson to see this answer.

Question 9 of 10

A normal delivery installs a new feature, updates its CI record, and later enables it for users. Why should the change review still check the service result?
  1. The deployment proves that all user benefits occurred.
  2. The review replaces any previous change authorization.
  3. The CI update establishes that no incident occurred.
  4. Success depends on the intended outcome and harm.
Show answerHide answer

Save this lesson to see this answer.

Question 10 of 10

Average ticket resolution time falls, but more users report that their tickets were closed before the issue was solved. What additional KPI best checks this risk?
  1. The reopen rate.
  2. The agent count.
  3. The tool's age.
  4. The meeting count.
Show answerHide answer

Save this lesson to see this answer.

Set 3: Coordinate deliveries and improvement10 Practice Questions

Save this lesson to see every answer and practice every set.

Question 1 of 10

A signed approval is retained so that an approver cannot credibly deny approving a change. What property is being supported?
  1. Non-repudiation.
  2. Confidentiality.
  3. Authentication.
  4. Availability.
Show answerHide answer

Save this lesson to see this answer.

Question 2 of 10

An approved normal change has a remediation note saying only "recover if needed." What important operational detail is still missing?
  1. The marketing name of the next feature.
  2. The recovery actions and when to begin them.
  3. A guarantee that the change cannot fail.
  4. A requirement to back out every change.
Show answerHide answer

Save this lesson to see this answer.

Question 3 of 10

A discovery scan finds an installed application version different from its configuration record. What should the configuration team do?
  1. Replace all historical records with the discovered values.
  2. Investigate whether the record or the actual change is wrong.
  3. Accept the record because it is the agreed database entry.
  4. Treat every discovery mismatch as an approved deployment.
Show answerHide answer

Save this lesson to see this answer.

Question 4 of 10

Old and new retail software cannot share the same central system, so every store must switch at once. What approach matches this requirement?
  1. Pull deployment.
  2. Phased deployment.
  3. Continuous delivery.
  4. Big bang deployment.
Show answerHide answer

Save this lesson to see this answer.

Question 5 of 10

A deployed package contains two disabled features. One is ready for users; the other still lacks required support guidance. Their flags can be enabled separately. What is the best coordinated action?
  1. Release the ready feature and retain the other flag off.
  2. Release both because the package is already installed.
  3. Disable the package and record both releases as failed.
  4. Redeploy both features before allowing any user access.
Show answerHide answer

Save this lesson to see this answer.

Question 6 of 10

A team ranks ideas solely by benefit divided by effort. Idea L scores 7 and 2, M scores 9 and 6, and N scores 5 and 1. What is the order from highest to lowest?
  1. M, L, N.
  2. L, N, M.
  3. N, L, M.
  4. N, M, L.
Show answerHide answer

Save this lesson to see this answer.

Question 7 of 10

A desk targets 75% first contact resolution by the end of six months. Its baseline is 360 of 600 contacts. At month six it resolves 468 of 720 at first contact. What conclusion and next action fit the model?
  1. Progress to 75%; close the work because the count increased.
  2. Progress to 78%; embed the process because the target was met.
  3. No progress at 60%; repeat the original measurement unchanged.
  4. Progress to 65%; revise the plan because the target was missed.
Show answerHide answer

Save this lesson to see this answer.

Question 8 of 10

A service uses several specialist suppliers. Each meets its own target, but work stalls when requests move between them. What should supplier management address?
  1. Replace shared outcome reviews with individual score reports.
  2. Reduce all contract prices before changing the coordination.
  3. Coordinate handoffs and responsibilities across the service.
  4. Assign customer accountability entirely to the slowest supplier.
Show answerHide answer

Save this lesson to see this answer.

Question 9 of 10

A team wants to reduce a four-day change lead time. Logs show three days waiting for approval and one day implementing. A proposal halves implementation time. What conclusion should guide improvement?
  1. The total falls to 3.5 days; investigate the approval wait too.
  2. Approval is a control, so its waiting time cannot be improved.
  3. Implementation work is all the lead time, so the total halves.
  4. The total falls to 2 days; remove the existing baseline now.
Show answerHide answer

Save this lesson to see this answer.

Question 10 of 10

A leased laptop is retired and will leave the organization. What should happen to its data before return?
  1. Delete its asset entry once the user stops signing in to it.
  2. Keep user files intact so the supplier can confirm ownership.
  3. Securely erase it or destroy storage as appropriate and record it.
  4. Wait for the next stock count before recording its retirement.
Show answerHide answer

Save this lesson to see this answer.

Set 4: Read evidence and diagnose weak plans10 Practice Questions

Save this lesson to see every answer and practice every set.

Question 1 of 10

A success rate rises from 40% to 50%. What are its percentage-point rise and relative percentage increase?
  1. 10 percentage points and 25% relative.
  2. 25 percentage points and 10% relative.
  3. 20 percentage points and 25% relative.
  4. 10 percentage points and 10% relative.
Show answerHide answer

Save this lesson to see this answer.

Question 2 of 10

In the improvement model, what is the purpose of "Where do we want to be?"?
  1. Choose tools before examining the current service.
  2. Measure the final outcome after action has ended.
  3. Set a measurable desired state with a time frame.
  4. Record only the current performance baseline.
Show answerHide answer

Save this lesson to see this answer.

Question 3 of 10

A new partner needs a firewall rule tomorrow because its request arrived late. The edit is one line, has no approved standard procedure, and addresses no immediate service or security threat. How should it be handled?
  1. Standard, because the partner supplied the required rule.
  2. Standard, because one line is below a normal change size.
  3. Emergency, because the requested date is the next day.
  4. Normal, with assessment, authority, and a suitable schedule.
Show answerHide answer

Save this lesson to see this answer.

Question 4 of 10

Tests for a change pass, but the service map omits a reporting service known to use the changed database. The authority has reviewed only the listed impacts. What is the best next step?
  1. Proceed because passing tests replaces dependency assessment.
  2. Complete the impact assessment before the authority decides.
  3. Proceed and record the omitted service after the release.
  4. Raise only the failure-likelihood score and keep the schedule.
Show answerHide answer

Save this lesson to see this answer.

Question 5 of 10

A supplier promises 99.8% availability over all 50,000 minutes in a period. Recorded downtime is 130 minutes. The contract provides a credit for a missed target. What response fits?
  1. Accept 99.8% after rounding and close the performance review.
  2. Record a miss, apply the agreed credit, and seek improvement.
  3. Accept the target because downtime is below 0.8% of the period.
  4. Transfer customer accountability to the supplier for that period.
Show answerHide answer

Save this lesson to see this answer.

Question 6 of 10

A team proposes relying on backups alone against ransomware. It has no unusual-activity alerts and plans no patching improvement. What is the main gap?
  1. Backups address authentication but leave integrity unprotected.
  2. Backups prevent infection but cannot restore damaged data.
  3. Backups make detection unnecessary if restoration is tested.
  4. Backups support correction but leave prevention and detection gaps.
Show answerHide answer

Save this lesson to see this answer.

Question 7 of 10

A release note says "updated internal modules." What information would better help users and the service desk?
  1. The user-visible changes, fixes, and known issues.
  2. The full list of private build-server identifiers.
  3. The purchase history of the development laptops.
  4. The expected number of future code review meetings.
Show answerHide answer

Save this lesson to see this answer.

Question 8 of 10

A release works as intended. Four users ask where to find the new button; there is no interruption or degradation. The team records four incidents and a failed change solely from those contacts. How should it correct the review?
  1. Keep four incidents but remove them from the change review.
  2. Mark success because every user contact is irrelevant to changes.
  3. Treat them as guidance requests and assess the actual outcome.
  4. Record an emergency change to remove the new button immediately.
Show answerHide answer

Save this lesson to see this answer.

Question 9 of 10

An organization wants to copy every discovered attribute into its CMDB, but cannot maintain most fields. What is a better starting point?
  1. Keep only purchase prices and omit all service relationships.
  2. Remove identifiers so records are easier to create quickly.
  3. Store everything and suspend verification until data is complete.
  4. Choose information needed for decisions and assign updates.
Show answerHide answer

Save this lesson to see this answer.

Question 10 of 10

A release review finds a recurring usability problem. The team adds it to the CIR with a benefit estimate, but no owner or next status. What should be added to help it progress?
  1. An accountable owner and a status for its next decision.
  2. A declaration that only the quality team can act on it.
  3. A closed change record stating the problem is fixed.
  4. A deployment date before any assessment takes place.
Show answerHide answer

Save this lesson to see this answer.

Set 5: Transfer the practices to new situations10 Practice Questions

Save this lesson to see every answer and practice every set.

Question 1 of 10

A team implements 150 changes; 9 fail or are backed out. What is the change success rate?
  1. 6%.
  2. 90%.
  3. 94%.
  4. 96%.
Show answerHide answer

Save this lesson to see this answer.

Question 2 of 10

A firm has 280 subscriptions, 250 assigned, and 18 incoming staff. Terms permit reassignment and reducing subscriptions at renewal; no other staffing changes are expected. What action minimizes new buying and removes the remaining unused renewals?
  1. Buy 18 now and drop 30 unused subscriptions at renewal.
  2. Reassign 18 now and drop 12 subscriptions at renewal.
  3. Reassign 30 now and buy 18 subscriptions at renewal.
  4. Buy 12 now and drop 18 unused subscriptions at renewal.
Show answerHide answer

Save this lesson to see this answer.

Question 3 of 10

An update reaches 400 of 1,600 planned devices. Twenty tickets concern 16 distinct devices in this wave. The team pauses above 2% affected devices, but reports 1% and continues to protect its release date. What correction fits?
  1. Pause: 4% of the wave is affected; fix and retest before continuing.
  2. Continue: 1% of all planned devices is affected, so the limit is met.
  3. Pause: 5% of the wave has tickets; count each ticket as a device.
  4. Continue: a 2% limit means the wave may affect 32 planned devices.
Show answerHide answer

Save this lesson to see this answer.

Question 4 of 10

A desk starts at 72% and targets 80% of contacts answered within 30 minutes. It now answers 486 of 600 within that time, but a new operating shift has no support. What should its improvement review conclude and do next?
  1. The target is permanent; retain the current scope despite the new shift.
  2. The rate is 81%; repeat the existing plan without reviewing its scope.
  3. The rate is 72%; restart the plan because the original target was missed.
  4. The rate is 81%; sustain progress and assess the added shift’s needs.
Show answerHide answer

Save this lesson to see this answer.

Question 5 of 10

Before an improvement, 240 of 400 contacts were resolved at first contact. Afterward, web contacts show 210 of 300 and phone contacts 40 of 200. A report quotes only the web rate while complaints rise. What conclusion fits the complete result?
  1. The overall rate is 70%; investigate complaints while reporting a rise.
  2. The overall rate is 45%; report the average of the two channel rates.
  3. The overall rate is 50%; investigate the decline alongside complaints.
  4. The overall rate is 62.5%; compare successes with the old contact total.
Show answerHide answer

Save this lesson to see this answer.

Question 6 of 10

A service is unreachable during an attack even though no stored information is read or changed. What core security property is harmed?
  1. Confidentiality.
  2. Integrity.
  3. Non-repudiation.
  4. Availability.
Show answerHide answer

Save this lesson to see this answer.

Question 7 of 10

A strategic provider promises 99.9% availability over 40,000 minutes and records 35 minutes of downtime. Its low-price contract ends next year, but data is hard to export. What should supplier management conclude and address?
  1. The target is met; address dependence through data-return and exit planning.
  2. The target is missed; pursue an availability credit and a data-return plan.
  3. The target is met; treat compliance as evidence that data can be moved easily.
  4. The target is missed; make availability remedies the sole renewal priority.
Show answerHide answer

Save this lesson to see this answer.

Question 8 of 10

An improvement introduces a paid cloud reporting add-on into a working service. Beyond deployment records, what asset-management update is needed?
  1. Remove all configuration relationships for the existing service.
  2. Register the subscription, cost, ownership, and renewal terms.
  3. Treat the subscription as a release note with no lifecycle record.
  4. Close the improvement because a supplier has issued an invoice.
Show answerHide answer

Save this lesson to see this answer.

Question 9 of 10

A team wants to compare its present change practice with a defined desired state and identify what needs to improve. What technique directly fits?
  1. SWOT analysis.
  2. Maturity assessment.
  3. Gap analysis.
  4. Balanced scorecard.
Show answerHide answer

Save this lesson to see this answer.

Question 10 of 10

A team uses benefit divided by effort to rank two optional improvements: P scores 8 and 4; Q scores 6 and 1. A new mandatory security action is also due. How should it use the ranking?
  1. Fund P first because its total benefit exceeds Q's.
  2. Fund Q and delete the security action because it lacks a score.
  3. Reject all ratios because mandatory work exists in the same register.
  4. Rank Q above P on the ratio and separately meet the mandatory need.
Show answerHide answer

Save this lesson to see this answer.

Stuck on your own question? Homework Help

Key Terms

76 Key Terms, each with its definition

A

Agile
Agile approaches organize work in small increments with frequent feedback so teams can adjust what they do as needs become clearer.
An improvement team tries one procedure change, reviews feedback, and adapts its next small step.
Asset lifecycle
An asset lifecycle is the sequence from planning and acquisition through use, maintenance, retirement, and disposal of an IT asset.
A leased workstation is registered, assigned, maintained, retired, securely cleared, and returned.
Asset register
An asset register records asset identity, ownership, location, financial details, terms, and lifecycle status for ongoing management.
When a laptop moves to another office, its register entry is updated with its new location and user.
Authentication
Authentication verifies that someone is who they claim to be, using evidence such as a password combined with a second factor.
The administrator signs in using a password and an app code before accessing the management console.
Availability
Availability means information and services can be accessed when needed by the people and processes entitled to use them.
A denial-of-service attack harms availability when customers cannot reach an otherwise intact website.

B

Balanced scorecard
A balanced scorecard views performance through financial, customer, internal-process, and learning-and-growth perspectives.
The review considers service cost alongside user satisfaction, process performance, and staff development.
Benefit-to-effort ratio
A benefit-to-effort ratio divides estimated benefit by estimated effort to support comparison of improvement opportunities.
A small knowledge update can rank above a tool replacement when it offers more benefit per unit of effort.
Big bang deployment
Big bang deployment moves components to all targets at the same time, creating a coordinated switch with broad failure exposure.
Every branch switches overnight because old and new application versions cannot share the central system.

C

Change
A change is an addition, modification, or removal of anything that could have a direct or indirect effect on one or more services.
Removing a support verification step counts as a change because it can alter service delivery.
Change advisory board (CAB)
A change advisory board is a group that advises on significant changes; organizations choose the authority needed for each change.
The CAB advises on a major cross-service change while routine work follows a quicker approval route.
Change authority
A change authority is the person or group responsible for authorizing a change, selected to fit the type and risk of the work.
A senior authority reviews a high-impact migration whose failure would disrupt several critical services.
Change enablement
Change enablement supports successful service and product changes through appropriate risk assessment, authorization, and scheduling.
A team routes a proposed database move for risk assessment before reserving its implementation window.
Change impact
Change impact describes the consequences if a change fails, including service harm, affected users, data loss, and recovery time.
A shared database has a high potential impact because several essential services depend on it.
Change model
A change model defines a repeatable route for handling a type of change, including the assessment and authorization it requires.
The organization’s model routes low-risk application updates to peer review and recorded checks.
Change request (RFC)
A change request sets out proposed work, its reason and benefit, affected services, risks, plans, recovery, and requested timing.
The RFC for a database move identifies affected applications and explains how service would be restored.
Change schedule
A change schedule coordinates planned changes, communication, dependencies, and resources, and helps teams investigate recent changes.
The schedule separates a switch replacement from an application upgrade that needs the same network.
Confidentiality
Confidentiality means information is accessible only to authorized people, protecting it from unauthorized disclosure or reading.
Payroll access rights prevent staff without a permitted role from reading other employees’ salaries.
Configuration baseline
A configuration baseline is a reviewed, agreed snapshot of CIs used as a reference when assessing later changes to their state.
After a server upgrade, the team compares the current configuration with the baseline agreed before the upgrade.
Configuration item (CI)
A configuration item is a component that needs to be managed to deliver an IT service, including services, documents, or technology.
The team controls the database version and its service dependencies as part of managing it as a CI.
Configuration management database (CMDB)
A configuration management database stores records about CIs and their configurations, including relationships used in service decisions.
The CMDB shows that both payroll and staff reporting depend on the same database cluster.
Configuration management system (CMS)
A configuration management system is the wider collection of tools, data, and information used to manage configuration information.
The CMS combines discovery data and several CMDBs to present a service view for change assessment.
Configuration record
A configuration record describes one CI, including identifying details, version, ownership, status, and relationships to other items.
After an application upgrade, the team updates its configuration record with the installed version.
Continual improvement
Continual improvement aligns services and practices with changing business needs through ongoing changes across the organization.
A support team improves its request form while another team reviews a larger service-management tool change.
Continual improvement model
The continual improvement model is a seven-step approach connecting vision, current state, targets, planning, action, checks, and continued progress.
A team measures first contact resolution, tries better articles, checks results, and adjusts its plan.
Continual improvement register (CIR)
A continual improvement register tracks ideas from identification through action, including benefit, effort, ownership, priority, and status.
A supplier review creates a CIR entry with an owner to investigate recurring delays in service recovery.
Continuous delivery
Continuous delivery integrates, tests, and deploys components whenever needed, supporting frequent feedback and controlled delivery.
Frequent tested updates still use authorization, a controlled component source, and current CI records.
Controlled repository
A controlled repository holds authorized, tested component versions securely so deployment teams can obtain a trusted release source.
The deployment fetches its approved package from the repository instead of an engineer’s local copy.
Critical success factor (CSF)
A critical success factor is a condition that must be met for a service or improvement to achieve its intended result.
The CSF “users return to work quickly” gives direction for selecting useful incident-resolution KPIs.

D

Deployment management
Deployment management moves new or changed components into live or other environments while controlling sources and checking results.
A team installs the approved version in staging, validates it, and then moves it to production.
DevOps
DevOps brings development and operations together with automation to support quick, safe delivery and ongoing feedback.
Development and operations share responsibility for validating frequent changes and observing live results.

E

Emergency change
An emergency change needs implementation as soon as possible and uses expedited risk assessment and authorization to address urgency.
An actively exploited vulnerability leads to an urgent patch with fast approval and available testing.

F

Failure likelihood
Failure likelihood is the chance that a change will fail, assessed using evidence such as complexity, testing, and team experience.
A familiar procedure with strong test evidence has a different failure likelihood from an untested one.
Feature flag
A feature flag is a control that enables or disables a feature, allowing deployed components to be released to users separately.
The code is in production on Monday, but its feature flag stays off until Friday’s planned release.

G

Gap analysis
Gap analysis compares the current state with a desired state to identify differences that improvement action needs to address.
The team compares current response performance with its target and identifies the missing support capacity.
Guidance request
A guidance request asks for information or advice about using a service, without necessarily indicating interruption or degradation.
A user asks how to find a working export button; support records a request for help, not an outage.

I

Improvement owner
An improvement owner is the person responsible for moving an assigned improvement idea through its next decisions and agreed actions.
The CIR names an owner to assess feedback, estimate effort, and bring a proposal to the next review.
Improvement target
An improvement target states a specific, measurable desired result with a time frame, connecting current performance to the intended state.
The team aims to reach 70% first contact resolution within six months instead of simply promising faster support.
Information security management
Information security management protects the information needed by an organization through understanding and managing information risks.
Security requirements are checked when a service changes and when a new supplier gains access to data.
Insourcing
Insourcing means the organization performs work using its own resources instead of arranging for an external supplier to perform it.
An internal operations team runs the monitoring service because the organization has the required expertise.
Integrity
Integrity means information remains accurate and complete and is protected from unauthorized changes during storage, use, or transfer.
A payment record must retain its correct amount as it passes between the ordering and finance systems.
IT asset
An IT asset is a financially valuable component that can contribute to delivering an IT product or service, including subscriptions.
An unused cloud subscription remains an asset whose cost and renewal date need to be tracked.
IT asset management
IT asset management manages assets throughout their lifecycle to gain value, control costs and risks, and meet relevant obligations.
Reassigning an unused license avoids a purchase while keeping the firm within its entitlement.
Iteration
An iteration is a cycle of planned work and feedback used to adjust the next action as an improvement develops toward its target.
After the first article update misses the target, the next iteration adds focused training for common contacts.

K

Key performance indicator (KPI)
A key performance indicator is a metric used to judge whether a critical success factor is being met and to track progress over time.
First contact resolution rate helps show whether the desk solves users’ issues without passing them on.

L

Lean
Lean is an approach to improving flow and value by removing waste such as waiting, rework, and unnecessary handoffs.
The team examines approval waiting because it accounts for most of a normal change’s elapsed lead time.

M

Maturity assessment
A maturity assessment evaluates how developed a practice is against a defined scale, helping identify capabilities that need improvement.
The team rates its change practice against an agreed scale before choosing its next development priorities.
Measurement baseline
A measurement baseline records the current state before an improvement and provides a reference for judging subsequent performance.
The desk records its initial resolution rate before introducing new tools so it can compare results.
Multi-sourcing
Multi-sourcing uses several suppliers for parts of a service, spreading provision while requiring coordination of responsibilities and handoffs.
The hosting and network partners coordinate recovery so the customer’s whole service becomes usable.

N

Non-repudiation
Non-repudiation provides evidence linking an action to its actor so the actor cannot credibly deny having performed that action.
A retained digitally signed approval supports evidence of who authorized the particular transaction.
Normal change
A normal change follows a defined process for assessment, authorization, and scheduling, with a route appropriate to its type and risk.
A planned storage migration needs an impact assessment and the authority assigned by the change model.

O

Organizational change management
Organizational change management supports people adopting new ways of working through activities such as communication and training.
Staff receive guidance and training before a new approval process changes their daily responsibilities.
Outsourcing
Outsourcing means arranging for an external supplier to perform work while retaining accountability to the organization’s customers.
A provider hosts the application, while the organization remains accountable for its customer service.

P

Percentage point
A percentage point is a unit for the difference between two percentage rates, distinct from a relative change based on the starting rate.
A rise from 58% to 64% is six percentage points, while the relative increase is about 10.34%.
Phased deployment
Phased deployment moves components into one part of the target environment at a time, allowing feedback before further rollout.
The organization updates one office first and checks its results before starting the next office.
Post-implementation review
A post-implementation review checks whether a change achieved its intended outcome, caused harm, and produced lessons for future work.
After a new portal goes live, the review confirms it works and records a guidance improvement suggested by early users.
Pull deployment
Pull deployment makes approved software available from a controlled repository for users to install at a time they choose.
Employees obtain an approved update from the company portal before the old version’s deadline.

R

Readiness criteria
Readiness criteria are the agreed conditions that must be satisfied before a release proceeds, covering technical and support needs.
The release cannot proceed until tests pass, guidance is updated, and support staff are briefed.
Release
A release is a version of a service or other CI, or a collection of CIs, made available for use by its intended users.
A reporting release includes the feature, user guide, and support notes needed for its introduction.
Release management
Release management makes new and changed services and features available for use through planning, readiness, communication, and review.
The release team waits for support training before enabling the new reporting feature for customers.
Release notes
Release notes communicate new features, fixes, and remaining known issues in plain words to help users and support teams.
Support staff read the release notes before customers begin asking about the changed export screen.
Remediation plan
A remediation plan defines how service will be restored if a change fails and the point at which recovery actions should begin.
If validation fails at the agreed cutoff, the team switches users to its tested alternative service.
Rollback
Rollback, also called backout, returns a changed component or service to its previous state as one possible remediation action.
The deployment team restores the earlier application version after the agreed failure trigger is reached.

S

Security control
A security control is a measure used to manage information risk through prevention, detection, or correction of security incidents.
Patching helps prevent attacks, alerts detect suspicious activity, and backup restoration supports correction.
Service configuration management
Service configuration management supplies accurate, reliable information about service configurations and their supporting CIs when needed.
Before a cluster upgrade, configuration information helps the team identify all dependent services.
Service map
A service map shows the CIs and relationships that work together to deliver a service, making its technical dependencies visible.
A service map connects the booking service to its application, database, servers, and network links.
Service value chain
The ITIL 4 service value chain connects activities that turn demand and opportunities into value through products and services.
A portal delivery draws on design and transition, obtain/build, and deliver and support activities.
Shadow IT
Shadow IT consists of technology or services acquired or used without the IT organization’s knowledge, escaping its normal oversight.
A department buys an unreported file-sharing subscription that misses security and renewal checks.
Single sourcing
Single sourcing uses one supplier for a service, often in a close relationship that needs careful management of dependence and exit.
One strategic provider supplies the platform, so the organization tests how it could move its data away.
Software asset management
Software asset management compares software entitlements with actual installation or use to control license risk and avoid waste.
The annual subscription review finds paid seats that can be reassigned to incoming employees.
Staging environment
A staging environment closely resembles live and is used for final checks before components move into customer-facing production.
The team tests the new configuration in staging before its authorized move to the live service.
Standard change
A standard change is low-risk, well understood, fully documented, and pre-authorized, with no further authorization needed for each use.
An approved catalog installation follows a procedure whose risk and authorization were settled in advance.
Successful change
A successful change is implemented as planned, delivers the intended result, and causes no unplanned harm such as service incidents.
After a new search is installed, a review checks that it works for users as well as confirming that installation completed.
Supplier management
Supplier management manages suppliers, their relationships, agreements, and performance to support seamless quality products and services.
A hosting review combines availability evidence, contract remedies, and a joint improvement plan.
SWOT analysis
A SWOT analysis examines strengths, weaknesses, opportunities, and threats to support assessment of a team, service, or organization.
The review considers skilled staff as a strength and increasing supplier dependence as a potential threat.

V

Vendor lock-in
Vendor lock-in is dependence that makes leaving a supplier difficult, for example because data or service arrangements are hard to move.
Portable data formats and a tested exit plan reduce the difficulty of replacing a strategic provider.

W

Watermelon effect
The watermelon effect occurs when technical indicators show good performance while users experience poor service, hiding an outcome gap.
All technical reports are green, but satisfaction surveys show users still struggle to get useful help.

About this lesson

By StudeliReport a mistake

Make your own Study Materials

Turn your notes, slides and documents into Study Guides, Practice Questions, Flashcards and 6 more tools.

Get Started