Continual Improvement practice questions

Enable Incident Management auto-closure rules.

Why it fails: Incident management rules govern IT support tickets, not CIM initiative review workflows.

Configure a UI Action with client-side script validation.

Why it fails: While UI actions can validate inputs, ServiceNow provides native workspace checklist configurations specifically designed for step-by-step task verification.

Modify the out-of-the-box Service Level Agreement (SLA) definition.

Why it fails: SLAs measure elapsed time, not checklist compliance.

BMC Client Management automatic asset discovery scanner.

Why it fails: Asset discovery is used for hardware and software inventory management.

BMC Helix Change Management risk assessment engine.

Why it fails: Risk assessment is designed for evaluating individual change failures, not prioritization of general improvement backlog items.

BMC Helix Multi-Cloud Service Management integration engine.

Why it fails: Multi-Cloud integrations synchronize data between external providers, not prioritize internal items.

Stakeholder Perceptions (customer and employee feedback results)

Why it fails: Stakeholder Perceptions belongs to the EFQM Results group.

Strategic Performance Results (financial and operational outcomes)

Why it fails: Strategic Performance Results belongs to the EFQM Results group.

Change Management [change_request]

Why it fails: Change records authorise and implement modifications to configuration items; they do not hold improvement opportunities awaiting assessment in the CIM register. It tempts because improvements eventually require changes, so change_request looks like the place where such work is logged and tracked.

Project Portfolio Management [pm_project]

Why it fails: Project records plan and deliver scoped work with tasks, resources and financials, not ongoing improvement opportunities tracked in the CIM register. It tempts because improvements are often delivered as projects, so pm_project appears to be the natural container for that work.

Problem Management [problem]

Why it fails: Problem records capture root cause and known errors, and improvement actions must be created as CIM improvement records instead. It tempts because post-incident reviews often generate problem records, and problem management is where recurring incident causes are investigated and resolved.

Measurement and Reporting

Why it fails: Measurement and Reporting tracks performance against objectives and produces metrics, but ownership of the Continual Improvement Register sits with the continual improvement practice. It is tempting because the CIR holds improvement data that reporting surfaces, and would be correct where the question concerns defining and presenting service metrics.

Service Level Management

Why it fails: Service Level Management negotiates, monitors and reports on service level targets; it owns SLAs and OLAs, not improvement records. The Continual Improvement practice maintains the CIR, logging and prioritising improvement opportunities. Service Level Management would be the right answer if the question asked who agrees and reviews service level targets with customers.

Change Enablement

Why it fails: Change Enablement authorises and schedules changes through change models and CAB review, so it does not own the register of improvement opportunities. It is tempting because improvements often arrive as changes, and would be correct when assessing risk, authorising, or scheduling a change to a live service.

Global permissions settings restricting project creation.

Why it fails: Global permissions govern who may create projects, not transitions between statuses within one, so the Backlog-to-Approved gate stays open. They are tempting because they do enforce governance, and would be correct when restricting project creation to a licensed group.

Jira Service Management automation rules sending an email notification to the steering committee.

Why it fails: Automation rules can send notifications but cannot block a transition, so an idea still moves to Approved without validation. They are tempting because automation rules genuinely enforce actions elsewhere, and would be right for alerting the steering committee after a gate is passed.

Service Level Agreements (SLAs) configured on the 'Backlog' status.

Why it fails: SLAs measure elapsed time against targets on a status; they never prevent a transition, so validation is not mandated. They are tempting because SLAs are configured per status, and would be correct when you must track how long ideas sit in Backlog.

Outsource the technology management dimension to a third-party managed service provider.

Why it fails: Outsourcing technology management does not address the people and process bottlenecks that value stream mapping identified, and the register's tooling skew is a prioritisation problem, not a sourcing one. Outsourcing suits capability gaps where a provider delivers a defined service, not rebalancing improvement demand across dimensions.

Decommission the tooling improvement initiatives and replace them exclusively with process tasks.

Why it fails: Decommissioning all tooling work discards legitimate improvements and ignores that the CIR should be rebalanced, not purged. It is tempting because tooling dominates the register, but the governance action is to reprioritise entries toward the people and process bottlenecks value stream mapping revealed, retaining valid tooling items.

Transition the Continual Improvement Register from a shared spreadsheet to an automated ITSM tool.

Why it fails: Automating the register changes the tooling dimension, which already dominates 70% of logged improvements, so it reinforces the imbalance rather than addressing the people and process bottlenecks mapping revealed. It tempts because tooling upgrades appear efficient, but the governance gap is improvement targeting, not register administration.

To establish metrics for measuring past operational performance.

Why it fails: Metrics for past performance belong to 'where are we now', which baselines current capability. The vision step instead articulates the target future state and how the improvement supports business objectives, so it would be the right answer when establishing direction rather than measuring history.

To identify root causes of recent major incidents.

Why it fails: Root cause analysis belongs to the 'where are we now' and 'how do we get there' stages, not the vision step. Asking 'what is the vision?' sets the improvement's desired future state and its alignment to organisational objectives, so it would be correct when defining the improvement's direction.

To procure external toolsets for workflow automation.

Why it fails: Procuring toolsets is a 'how do we get there' activity, executed only after the vision and current state are understood. The vision step defines the desired outcome and its business alignment, so it would be correct when setting improvement direction, not when selecting automation platforms.

Execute the improvement plan and implement the changes.

Why it fails: Executing the plan follows the later "take action" step; the model requires defining measurable targets for the improvement before any implementation. It is tempting because execution is the visible work, and it would be correct once the where-are-we-going and how-do-we-get-there steps are complete.

Define the vision and objectives of the initiative.

Why it fails: Defining the vision and objectives is the second step, which precedes establishing the baseline; the team has already passed it. It is tempting because a new initiative naturally suggests setting direction, but the model's sequence places where-are-we-now before where-are-we-going.

Evaluate metrics to determine if the target state was achieved.

Why it fails: Evaluating metrics belongs to the final "did we get there" step, which can only occur after the target state has been defined and the improvement implemented. It is tempting because measurement underpins the whole model, but at this point no target or plan exists to evaluate against.

Only when an audit fails to meet compliance standards.

Why it fails: Baselines are measured before improvement begins so progress can be evidenced against a starting point. Assessing only after a failed audit is reactive; establishing the baseline at the start would be correct whenever an improvement initiative is launched, regardless of audit results.

After the improvement changes have been fully implemented and stabilized.

Why it fails: Measuring after implementation captures the post-change state, not the pre-change reference needed to quantify improvement. A baseline must record current performance before alterations so gains can be compared. Post-implementation measurement is the correct activity for benefits realisation or verification, not for establishing the baseline itself.

At the exact moment the corporate vision statement is drafted.

Why it fails: A vision statement sets long-term direction and contains no performance data, so it cannot yield a measurable baseline. Baselining requires current metric values captured before changes begin. Vision drafting is a strategic exercise; baselining belongs to the measurement phase of continual improvement, where the as-is state is quantified against defined KPIs.

Initiate a Major Problem Review with external vendors.

Why it fails: A Major Problem Review convenes external vendors to examine a severe incident's causes and prevent recurrence; it is incident-driven, not a routine retrospective across completed actions. It is tempting because it is a structured review, and would be correct after a critical outage involving third parties.

Perform a SWOT analysis on the enterprise organizational structure.

Why it fails: SWOT examines an organisation's internal strengths and weaknesses against external opportunities and threats; it does not elicit participant reflections on a completed project's process. It would suit strategic planning for the enterprise structure, not a retrospective. The stem requires capturing what went well and what could improve, which SWOT's four-quadrant framing cannot produce.

Execute a root cause analysis using the Ishikawa (fishbone) diagram.

Why it fails: Ishikawa diagrams trace a single defect back to causal factors; they do not structure reflection across a completed cycle's successes and failures. It is tempting because root cause analysis is a familiar improvement tool, and would be correct when diagnosing why one specific problem occurred.

Implement mandatory quotas requiring each employee to submit three improvement ideas per month.

Why it fails: Mandatory quotas increase submission volume without creating any response mechanism, so ignored ideas continue and distrust deepens. The stem's root cause is absent feedback, not insufficient idea counts. Quotas would suit a mature programme needing volume targets once leaders reliably acknowledge and act on suggestions.

Tie employee performance bonuses exclusively to the number of completed IT tickets.

Why it fails: Linking bonuses to ticket counts rewards throughput, an unrelated metric that gives employees no reason to submit improvement ideas and no assurance of feedback. It addresses neither the ignored-suggestion history nor trust. Such incentive alignment would suit a service desk targeting resolution productivity, not rebuilding improvement engagement.

Outsource the collection of improvement ideas to an external third-party consultancy.

Why it fails: External consultants cannot restore internal trust; employees need visible leadership responses to their own submissions. Outsourcing distances decision-makers from the workforce, repeating the original failure to close the feedback loop. Third-party facilitation suits anonymous culture surveys or benchmarking, not rebuilding the submit-and-respond cycle that was broken.

To execute the tactical implementation plan.

Why it fails: Step 6 evaluates whether the improvement delivered the intended outcomes, using metrics against the baseline; executing the tactical plan belongs to step 5 ('Did we get there?' measures results, not delivery). The option is tempting because implementation is the visible activity, and it would fit a question asking which step carries out the plan.

To identify new improvement opportunities from scratch.

Why it fails: Step 6 checks whether the implemented improvement met its success metrics; identifying fresh opportunities belongs to the earlier 'where are we now' and 'where do we want to be' steps. It is tempting because evaluation often surfaces new gaps, which suits initiating a subsequent improvement iteration, not completing the current one.

To define the strategic vision for the organization.

Why it fails: Step 6 evaluates measured results against the defined targets and confirms whether the improvement delivered its intended value; strategic vision is set earlier, during the 'where do we want to be' step. It is tempting because direction-setting feels conclusive, which suits executive strategy workshops rather than verifying improvement outcomes.

Waste of Overproduction

Why it fails: Tickets idling in 'Pending Vendor' create delay without adding value, which Lean classifies as Waiting waste, not Overproduction. Overproduction means producing more output than the customer demands or ahead of demand — for example, generating reports nobody requested or building features before they are needed. Here nothing is produced in excess; work simply stalls.

Waste of Transportation

Why it fails: Idle tickets in 'Pending Vendor' represent waiting, not transportation. Transportation waste covers unnecessary movement of materials or information between processes or locations, such as routing tickets through extra handoff queues. It would be the correct choice if tickets were being shuttled between teams or systems without adding value, rather than simply sitting untouched.

Waste of Defects

Why it fails: Defects are work requiring rework because it failed to meet requirements, such as misrouted or incorrectly resolved tickets. Idle tickets awaiting a vendor are not defective; they are delayed, which is the waiting waste category.

Merge all regional instances into a single database schema using database-level triggers.

Why it fails: Database-level triggers cannot span separate ServiceNow instances; each instance keeps its own schema, so no trigger can consolidate regional data. Merging schemas this way is not a supported integration pattern. It tempts because triggers automate cross-table updates within one database, which would suit a single-instance deployment with shared tables.

Export weekly XML dumps from each region and import them into a spreadsheet.

Why it fails: XML exports and spreadsheet imports are manual, batch-oriented and cannot feed a live ServiceNow dashboard; they also break the single-platform model. This approach is tempting where regions already report offline, and would be correct for one-off historical reporting rather than a consolidated real-time view.

Configure individual SLAs for every regional business unit.

Why it fails: SLAs measure service target attainment against commitments; they hold no improvement initiative or ROI data, so per-region SLAs cannot populate a global ROI dashboard. SLA configuration is tempting because it is a familiar regional ServiceNow construct, and would be correct if the requirement were tracking response and resolution compliance.

Total budget allocated to software licensing and number of staff resignations.

Why it fails: Software licensing spend and staff resignations are financial and HR inputs, not indicators of improvement throughput or realised value. They tempt because budget and attrition affect capability, yet neither measures how quickly improvements are delivered nor the value they return to the organisation.

Total number of major incidents reported and average speed of hardware replacements.

Why it fails: Major incident counts and hardware replacement speed measure operational stability and asset logistics, not improvement velocity or value realisation. They are tempting because incident reduction often results from improvement work, but neither metric tracks the throughput of improvements delivered or the business value those improvements return.

Number of open improvement tickets and average time spent on training courses.

Why it fails: Open ticket counts and training hours measure activity and effort, not velocity or value realisation; neither ties improvement work to delivered business outcomes. It tempts because ticket volume and training are easy to track, which would be the correct choice for monitoring practice workload rather than improvement effectiveness.

To establish the initial vision and mission of the enterprise.

Why it fails: Establishing vision and mission belongs to step 1, 'What is the vision?'. Step 7 instead sustains momentum by embedding changes and identifying further improvements; defining direction at the outset is correct before improvement work begins, not after.

To perform root cause analysis on unresolved outages.

Why it fails: Root cause analysis of outages is problem management activity, not step 7. That step keeps improvement momentum by embedding changes into business-as-usual and identifying next actions; diagnosing unresolved outages would be correct within problem management, not here.

To archive the Continual Improvement Register and close the practice.

Why it fails: Step 7 embeds improvement into business-as-usual and identifies next actions, so archiving the register and closing the practice contradicts its purpose. Closing the practice would be appropriate only when improvement work is formally retired, not to sustain momentum.

Define phase

Why it fails: The Define phase establishes the problem statement, scope, customer requirements and project charter; fishbone and Pareto root cause analysis occurs in Analyze, after measurement data exists. Define is tempting because it frames the improvement effort, yet no process data has been collected at that stage to support statistical causal analysis.

Improve phase

Why it fails: The Improve phase develops, pilots and implements the chosen countermeasures; fishbone and Pareto analysis belongs to Analyze, which precedes solution selection. Improve is tempting because root causes inform the fixes, but conducting analysis there inverts DMAIC sequence and risks implementing remedies before causes are statistically confirmed.

Control phase

Why it fails: The Control phase sustains the gains through standardised procedures, monitoring and control charts; fishbone and Pareto root cause analysis belongs to Analyze. Control is tempting because it also uses statistical tools, but those tools there verify ongoing stability rather than identify the causes of the original patch management defect.

Service Level Agreement (SLA) breach escalation actions.

Why it fails: SLA breach escalation actions fire when a task exceeds a defined duration target, not when a dollar threshold is met, so a $50,000 capital expenditure would never trigger routing. It is tempting because SLAs automate escalation, and would be correct if the governance trigger were elapsed time rather than cost.

Access Control Lists (ACLs) restricting write permissions.

Why it fails: ACLs govern record read, write, create, and delete permissions by user or role; they cannot evaluate a capital expenditure value and trigger routing. It is tempting because ACLs enforce governance boundaries, and would be correct if the requirement were restricting who may edit initiative records rather than conditional approval routing.

Data Archiving retention policies.

Why it fails: Data archiving retention policies govern how long inactive records are stored before deletion or transfer, so they cannot evaluate expenditure thresholds or trigger routing. They are tempting because both archiving and workflow rules are configured on tables, yet archiving addresses storage lifecycle compliance, not conditional governance routing.

It applies exclusively to software development and Agile release trains.

Why it fails: Continual improvement applies across the whole organisation and all value streams, not exclusively to software development and Agile release trains. Limiting it to software delivery would suit a DevOps improvement initiative rather than the ITIL 4 practice.

It is restricted to infrastructure hardware and network availability improvements.

Why it fails: Continual improvement in ITIL 4 spans all four dimensions and every value stream activity, not just infrastructure hardware and network availability. Restricting it to infrastructure would fit an availability management remit, not the continual improvement practice.

It is limited to major problem remediation and incident reduction.

Why it fails: ITIL 4 Continual Improvement spans the entire service value chain, not just problem and incident management. Limiting it to major problem remediation and incident reduction excludes improvement of services, practices, and value streams across all four dimensions. It tempts because reactive incident reduction is a visible, measurable improvement trigger, and would fit a narrower continual service improvement remit.