- Learn
- Computer Science & IT
- Information Technology
- IT Service Management
- Change and Release Management
Change and Release Management: Continual Improvement
BeginnerLesson 5 of 5 in IT Service Management Course
What you will learn
- 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 otherExplain 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 disposalExplain 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.
- Map configuration items and how they depend on each other
- 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 existsDefine a change, state the purpose of change enablement, and explain the balance it strikes between speed and protection.
- Classify changes as standard, normal or emergencyTell 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 scheduleAssess the risk of a change, assign a fitting change authority, use the change schedule to avoid conflicts, and review changes after implementation.
- Explain what a change is and why change enablement exists
- 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 releasesDefine 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 liveExplain 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 deliveryFollow one improvement from change request to release and review, and explain how change enablement, deployment, release, configuration and asset management each contribute.
- Plan and communicate releases
- 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 managementExplain the purpose of information security management, apply confidentiality, integrity, availability, authentication and non-repudiation, and balance prevention, detection and correction.
- Manage suppliers and their performanceExplain the purpose and activities of supplier management, compare sourcing strategies, and use contracts and performance data to manage suppliers.
- Protect information with information security management
- 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 workState 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 stepUse 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 techniquesUse 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.
- Make continual improvement part of everyday work
Change and Release Management study guide
1Keep 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.
| Term | What it provides |
|---|---|
| CMDB | A database holding configuration records. |
| CMS | The wider tools, data, and information used to manage and present configurations. It can combine several CMDBs and other sources. |
| Service map | A 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:
- Find the database hosted on the cluster: DB-ORD.
- Follow the services that use that database: ordering and sales reporting.
- 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:
- Plan: establish the need and consider what is already available.
- Acquire: buy, lease, or subscribe.
- Receive and register: record the item and its ownership or terms.
- Deploy: assign it to a user or location.
- Operate and maintain: repair, move, reassign, or renew it.
- Retire: remove it from active use.
- 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:
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
| Item | Asset view | Configuration view |
|---|---|---|
| A live server | Financial value and lifecycle costs | Managed configuration and service relationships |
| A spare laptop in storage | Value, location, and future use | Usually no active service configuration to control |
| A service level agreement | May not be tracked as an IT asset | Can 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.
2Enable 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:
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
| Type | Assessment and authorization | Example |
|---|---|---|
| Standard | Low-risk, well understood, fully documented, and pre-authorized; no new authorization for each use | Installing an approved catalog application through its agreed procedure |
| Normal | Assessed, authorized, and scheduled through a defined process | Moving a customer database to a new storage system |
| Emergency | Assessed and authorized through an expedited route because implementation is needed as soon as possible | Patching 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:
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.
| Change | Calculation | Route under this policy |
|---|---|---|
| Firewall rule: impact 4, likelihood 2 | Change manager | |
| Database move: impact 5, likelihood 3 | Senior 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.
3Make 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:
- 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.
- On Thursday, release it to 10% of users. Monitor the crash rate against the team's limit of 0.5% of sessions.
- 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
| Setting | Typical release pattern | Management work still needed |
|---|---|---|
| Traditional or waterfall | Larger, less frequent releases planned well ahead | Scope, readiness, timing, communication, and review |
| Agile or DevOps | Smaller, more frequent releases, often automated | Scope, 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
| Environment | Purpose |
|---|---|
| Development | Build components. |
| Test | Check components and their behavior. |
| Staging or pre-production | Perform final checks in a close copy of live. |
| Live or production | Run 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:
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
| Practice | Main question in a delivery |
|---|---|
| Change enablement | Should the change proceed, at what risk, and when? |
| Deployment management | How do components reach the target environment? |
| Release management | When do features become available, and to whom? |
| Service configuration management | What is installed and how does it relate to other CIs? |
| IT asset management | What 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.
4Protect 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
| Property | Meaning | Service example |
|---|---|---|
| Confidentiality | Access to information is restricted to authorized people. | Only HR staff can read salary data. |
| Integrity | Information stays accurate and complete and is changed only with authorization. | A payment amount cannot be altered in transit without authorization. |
| Availability | Information and services can be reached when needed. | Customers can order during a busy sale. |
| Authentication | A claimed identity is checked. | Sign-in requires a password and a phone-app code. |
| Non-repudiation | Evidence 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:
- Patch promptly, filter malicious email, require multi-factor sign-in, and give accounts only the access they need.
- Alert when software starts encrypting many files unexpectedly.
- 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
| Strategy | What it means | Main decision to examine |
|---|---|---|
| Insourcing | The organization does the work itself. | Can it provide the skills and resources? |
| Outsourcing | An external supplier does the work. | Can the supplier meet quality, cost, and risk needs? |
| Single source or partnership | One supplier provides the service, often through a close relationship. | How will dependence and exit be managed? |
| Multi-sourcing | Several 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:
The allowed downtime is 0.1% of that period, or 43.2 minutes. Actual downtime is 95 minutes. Availability is:
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.
5Improve 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:
| Idea | Benefit | Effort | Benefit divided by effort |
|---|---|---|---|
| A: self-service password reset | 8 | 3 | About 2.7 |
| B: replace the ticketing tool | 9 | 9 | 1.0 |
| C: articles for common incidents | 6 | 1 | 6.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
- What is the vision? Link the work to organizational objectives and explain the benefit stakeholders need.
- Where are we now? Assess the current state objectively and create a baseline for comparison.
- 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
- How do we get there? Choose a plan, using iterations when the best route is uncertain.
- Take action. Carry out the plan while watching risks and side effects.
- Did we get there? Measure again and compare the result with both the baseline and target. Adjust earlier steps if needed.
- 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:
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:
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:
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
| Technique | Question it helps answer |
|---|---|
| SWOT | What are our strengths, weaknesses, opportunities, and threats? |
| Gap analysis | How does the current state differ from the desired state? |
| Balanced scorecard | How are financial, customer, internal-process, and learning-and-growth results developing? |
| Maturity assessment | How developed is a practice against a defined scale? |
| Lean | Where 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:
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
1Trace a service and manage what it uses
12 steps
- 1IntroductionStart 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.
- 2ExplanationChoose 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.
- 3ExampleBuild 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.
- 4ExampleFind 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.
- 5ChallengeTrace 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.
- 6TipCheck 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.
- 7ExplanationFollow 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.
- 8ExampleFind 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:
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.
- 9ExampleSeparate 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.
- 10Key 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.
- 11ChallengeRetire 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.
- 12RecapUse 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.
2Route a change from request to review
16 steps
Save this lesson to follow every Walkthrough step by step.
- 1IntroductionFollow a useful change safely
- 2ExplanationRecognize changes beyond code
- 3ExampleCalculate change success
- 4ChallengeCheck the intended result
- 5ExplanationUse a standard procedure within its scope
- 6ExplanationGive normal work a defined route
- 7ExampleKeep control when action is urgent
- 8ChallengeClassify a small but unfamiliar edit
- 9ExplanationSeparate probability from consequences
- 10ExampleApply a local risk policy
- 11ExampleRoute a higher-impact change
- 12TipMake recovery executable
- 13ExampleResolve a dependency conflict
- 14ChallengePut risk and timing together
- 15ConnectionUse the review to improve the route
- 16RecapMatch the route to the work
3Deliver a portal feature in separate stages
15 steps
Save this lesson to follow every Walkthrough step by step.
- 1IntroductionTrack components and user access
- 2ExplanationPlan the usable release
- 3ExplanationChoose the target environment
- 4ExplanationCompare deployment choices
- 5ExampleApply a wave pause rule
- 6ChallengeCheck the quantity the rule counts
- 7ExampleSee deployment without release
- 8ExampleCommunicate before widening access
- 9ChallengeDecide what is ready for users
- 10ExampleAuthorize the HR portal work
- 11ExampleInstall and update the records
- 12ExampleRelease to finance and then everyone
- 13ChallengeReview contacts without distorting results
- 14ConnectionPlace the practices in value delivery
- 15RecapName the event precisely
4Protect a service and manage its partners
13 steps
Save this lesson to follow every Walkthrough step by step.
- 1IntroductionLook beyond a secure server
- 2ExplanationDistinguish the core security properties
- 3Key InsightSeparate identity from evidence of action
- 4ExplanationUse controls at three points
- 5ExampleReduce the chance of ransomware
- 6ExampleDetect harm and restore service
- 7ChallengeDiagnose an incomplete security plan
- 8ExplanationChoose and coordinate suppliers
- 9ExplanationAgree what performance means
- 10ExampleTranslate availability into downtime
- 11ExampleCompare actual performance with the target
- 12ChallengeConnect supplier access and exit
- 13RecapCheck both protection and performance
5Turn an improvement idea into measured progress
16 steps
Save this lesson to follow every Walkthrough step by step.
- 1IntroductionBegin with the outcome people need
- 2ExplanationGive improvement everyday ownership
- 3TipManage the idea through a register
- 4ExampleCompare benefit with effort
- 5ChallengeChoose a priority without losing ideas
- 6ExampleConnect vision to the baseline
- 7ExplanationDefine the next desired state
- 8ExampleMeasure again before declaring success
- 9ChallengeJudge a fresh result
- 10ConnectionKeep useful changes relevant
- 11ExplanationLink indicators to success conditions
- 12ExampleName the percentage comparison
- 13ExplanationMatch assessment to the question
- 14ExampleFind the time consumed by waiting
- 15ChallengeCheck whether faster is better
- 16RecapUse feedback to choose the next step
Change and Release Management practice questions
Set 1: Records and everyday service decisions10 Practice Questions
Question 1 of 10
Show answerHide answer
Question 2 of 10
Show answerHide answer
Question 3 of 10
Show answerHide answer
Question 4 of 10
Show answerHide answer
Question 5 of 10
Show answerHide answer
Question 6 of 10
Show answerHide answer
Question 7 of 10
Show answerHide answer
Question 8 of 10
Show answerHide answer
Question 9 of 10
Show answerHide answer
Question 10 of 10
Show answerHide answer
Set 2: Risk, readiness, and service protection10 Practice Questions
Save this lesson to see every answer and practice every set.
Question 1 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 2 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 3 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 4 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 5 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 6 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 7 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 8 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 9 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 10 of 10
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
Show answerHide answer
Save this lesson to see this answer.
Question 2 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 3 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 4 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 5 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 6 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 7 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 8 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 9 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 10 of 10
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
Show answerHide answer
Save this lesson to see this answer.
Question 2 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 3 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 4 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 5 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 6 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 7 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 8 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 9 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 10 of 10
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
Show answerHide answer
Save this lesson to see this answer.
Question 2 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 3 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 4 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 5 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 6 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 7 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 8 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 9 of 10
Show answerHide answer
Save this lesson to see this answer.
Question 10 of 10
Show answerHide answer
Save this lesson to see this answer.
Stuck on your own question? Homework Help
Key Terms
A
Agile
Asset lifecycle
Asset register
Authentication
Availability
B
Balanced scorecard
Benefit-to-effort ratio
Big bang deployment
C
Change
Change advisory board (CAB)
Change authority
Change enablement
Change impact
Change model
Change request (RFC)
Change schedule
Confidentiality
Configuration baseline
Configuration item (CI)
Configuration management database (CMDB)
Configuration management system (CMS)
Configuration record
Continual improvement
Continual improvement model
Continual improvement register (CIR)
Continuous delivery
Controlled repository
Critical success factor (CSF)
D
Deployment management
DevOps
E
Emergency change
F
Failure likelihood
Feature flag
G
Gap analysis
Guidance request
I
Improvement owner
Improvement target
Information security management
Insourcing
Integrity
IT asset
IT asset management
Iteration
K
Key performance indicator (KPI)
L
Lean
M
Maturity assessment
Measurement baseline
Multi-sourcing
N
Non-repudiation
Normal change
O
Organizational change management
Outsourcing
P
Percentage point
Phased deployment
Post-implementation review
Pull deployment
R
Readiness criteria
Release
Release management
Release notes
Remediation plan
Rollback
S
Security control
Service configuration management
Service map
Service value chain
Shadow IT
Single sourcing
Software asset management
Staging environment
Standard change
Successful change
Supplier management
SWOT analysis
V
Vendor lock-in
W
Watermelon effect
About this lesson
Make your own Study Materials
Turn your notes, slides and documents into Study Guides, Practice Questions, Flashcards and 6 more tools.