Hard Difficulty Questions

The organization may have automated too many security controls, leaving zero room for human error.

Why it fails: Excessive automation is not a recognised root cause of compliance failure; failures typically stem from unclear ownership, poor control design or weak monitoring. It is tempting because automation is often assumed to guarantee consistency, and over-automation would be a genuine concern where controls must flex to human judgement.

The CISO may have started their assessment by looking at the current state too thoroughly.

Why it fails: Thorough current-state assessment is a guiding-principle virtue, not a cause of compliance failure, so investigating it misdirects the CISO. It is tempting because analysis paralysis is a real risk, and this would be valid where assessment has stalled progress rather than informed it.

The metric is based on objective, automated data collected directly from ServiceNow.

Why it fails: Objective automated ServiceNow data removes manual gaming and measurement bias, so it signals a well-designed KPI rather than a dysfunctional one. The warning signs sought are metrics that incentivise suboptimal behaviour, such as targets that pit teams against each other or reward volume over quality.

The metric trend is reviewed monthly in collaboration with business stakeholders.

Why it fails: Monthly trend review with business stakeholders is governance best practice, aligning metrics to value delivery rather than driving dysfunction. Poorly designed KPIs instead show warning signs such as encouraging siloed behaviour, being easily gamed, or measuring activity rather than outcomes.

Outsource all outage troubleshooting to external vendors who are subject to PAM controls.

Why it fails: Outsourcing troubleshooting does not remove the outage pressure that drives bypass; it transfers the work while leaving the underlying PAM design and visibility gaps intact. It is tempting because vendor contracts can mandate PAM compliance, and it would suit organisations lacking in-house capability, not one needing holistic process redesign.

Suspend all PAM controls permanently so administrators can never be blocked during an outage.

Why it fails: Permanently suspending PAM controls eliminates the very privileged-access governance the audit found being circumvented, increasing risk rather than improving visibility. It is tempting because it guarantees administrators are never blocked mid-outage, and it would only be defensible if no privileged accounts existed at all.

Implement immediate automated termination for any admin who bypasses PAM, regardless of outage severity.

Why it fails: Automatic termination for any bypass ignores outage severity and removes the experienced administrators needed during incidents, so it neither builds visibility nor addresses the systemic pressure causing bypass. It is tempting because zero-tolerance enforcement appears decisive, and it would fit environments where policy breaches carry no operational context.

Ensuring all metrics are restricted exclusively to raw server CPU and memory utilization.

Why it fails: Restricting metrics to CPU and memory utilisation measures infrastructure consumption, not business outcomes such as cost avoidance, revenue or time-to-market. It tempts because these metrics are readily available from monitoring tools, but a value-based framework must tie migration results to business benefits, not just resource usage.

Eliminating any requirement for stakeholder feedback or qualitative value assessments.

Why it fails: Excluding stakeholder feedback removes the qualitative evidence that explains whether migration outcomes deliver intended business value, leaving only partial quantitative signals. It tempts as a way to keep measurement objective and low-effort, but a value framework must blend qualitative and quantitative inputs to capture benefits such as agility and user experience.

The IT service desk failed to categorize incidents according to ITIL 4 service desk practices.

Why it fails: Incident categorisation concerns service desk triage, not how improvement outcomes are communicated or embedded across teams, so it cannot explain improvements failing to sustain organisation-wide. It is tempting because ITIL 4 service desk practise is a recognised capability, and would be correct if the symptom were misrouted or misclassified incidents.

The steering committee held meetings via video conference instead of in-person boardrooms.

Why it fails: Meeting delivery format does not govern whether improvement changes are communicated to affected teams or embedded in their working practices. It is tempting because in-person sessions can aid engagement, and would be correct if the gap were specifically poor participation or decision-making during steering committee meetings.

The continual improvement register was stored in a spreadsheet instead of a relational database.

Why it fails: The storage medium for the improvement register does not determine whether improvements are communicated, adopted and reinforced across the organisation. It is tempting because a relational database offers better reporting and integrity, and would be correct if the problem were data quality, concurrency or reporting limitations in the register itself.

Increase the size of development batches to reduce test frequency.

Why it fails: Larger development batches increase work in progress and queueing before test, lengthening lead time rather than reducing the 80% test bottleneck. It is tempting because fewer test cycles appear to save effort, but batch size is the axis that governs flow, not test frequency.

Eliminate testing phases to accelerate service release.

Why it fails: Removing testing eliminates the quality gate that validates the 5G service, allowing defects to reach release rather than shortening the constraint. It is tempting because testing dominates lead time, yet the strategic intervention is to relieve that constraint through automation and flow, not delete it.

Outsource development while keeping testing manual and internal.

Why it fails: Outsourcing development while retaining manual internal testing leaves the 80% test constraint untouched and adds handoff delay. It is tempting because external capacity appears to accelerate delivery, but the bottleneck sits in testing, so offshoring build work does not shorten lead time.

Abolish all regional business units and manage all operations from global headquarters.

Why it fails: Abolishing regional units removes the local management structures whose buy-in the differing labour laws and styles require, so resistance escalates. Centralising operations suits organisations with homogeneous, single-jurisdiction workforces where headquarters control aligns with compliance, not a multi-region provider facing divergent legal regimes.

Abandon the continual improvement initiative entirely in regions that show any initial resistance.

Why it fails: Abandoning the initiative wherever resistance appears forfeits the continual improvement outcomes the provider must deliver across all units. Withdrawal is tempting to avoid conflict, and would be defensible only where a region's laws make the practice genuinely unlawful, not merely where initial opposition exists.

Enforce a single, rigid global change plan without exception to ensure standardization.

Why it fails: A rigid global plan cannot accommodate the differing local labour laws and management styles that drive regional resistance, so it entrenches rather than reduces it. Standardisation is tempting where business units share one regulatory environment and uniform processes are enforceable, but here variation is the stated constraint.

Aligning employee performance metrics and reward systems with the new behaviors.

Why it fails: Alignment actually helps sustain change, not cause failure.

Progress iteratively with feedback AND Start where you are

Why it fails: Policy-as-Code is an automation and simplification strategy.

Collaborate and promote visibility AND Focus on value

Why it fails: While collaboration happens, the technical mechanism is automation and practical streamlining.

Start where you are AND Think and work holistically

Why it fails: This describes technical automation and policy integration, not baseline discovery.

Actively collaborating across organizational silos.

Why it fails: Collaborating across silos dismantles the very barriers that cause strategy execution to stall, so it prevents failure rather than causing it. It is tempting because siloed working genuinely is a documented pitfall, but the option describes its remedy; the question asks for pitfalls to guard against, not practices to adopt.

Iteratively reviewing feedback from customers and employees.

Why it fails: Iteratively reviewing customer and employee feedback surfaces misalignment early, so it prevents strategy failure rather than causing it. It is tempting because ignoring such feedback genuinely is a recognised pitfall, but this option describes the corrective practice; the question asks which pitfalls to guard against, not which behaviours to encourage.

It measures internal infrastructure efficiency and hypervisor performance directly.

Why it fails: Internal infrastructure efficiency and hypervisor performance are output measures tied to the legacy hosting model, not the customer-facing value the migration exists to deliver. Such metrics are tempting because they are easy to collect, and they suit capacity or platform engineering reporting rather than steering-committee value reporting.

It simplifies the data collection process by removing the need for ServiceNow data integration.

Why it fails: Value-based metrics measure outcomes, not data-collection ease; the stem asks why cost per active digital customer is superior under ITIL 4 DPI, and removing ServiceNow integration describes tooling effort, not value. Simplification would suit a reporting-automation scenario where integration overhead, not outcome alignment, is the constraint.

It automates cloud cost optimization alerts through AWS Trusted Advisor.

Why it fails: AWS Trusted Advisor generates cost-optimisation recommendations; it does not express value delivered to customers, so it cannot replace a value-based measure. It is tempting because it is an AWS-native cost tool, and it is correct when the goal is identifying idle or underutilised cloud resources.

Increase the duration of classroom lecture hours by an additional 40 hours.

Why it fails: Adding lecture hours repeats the training delivery that already failed to translate into usage, without identifying the barrier. Extending instruction is appropriate when assessment shows a genuine knowledge deficit, not when completion is high but workflow usage is low.

Assume employees are lazy and mandate weekly testing on ERP system theory.

Why it fails: Mandating theory testing treats the symptom as an attitude problem, producing no evidence about why trained users avoid the system. Testing knowledge is a valid reinforcement tactic once a specific capability gap has been diagnosed, not a diagnostic step itself.

Replace the ERP software vendor immediately with a different market leader.

Why it fails: Replacing the vendor addresses nothing in the training-to-usage gap and discards the existing implementation investment. Vendor replacement is a procurement decision taken when the product itself cannot meet requirements, not a diagnostic step for adoption shortfalls.

Improvement activities should only be triggered following a major P1 incident.

Why it fails: Triggering improvement only after major P1 incidents makes it reactive and episodic, which is precisely the one-time-project mindset the director identified as the cause of failure. Continual improvement should draw on all feedback sources, not solely major incident reviews.

Improvement is strictly an operational-level task managed solely by service desk supervisors.

Why it fails: DPI positions continual improvement as everyone's responsibility embedded across the value chain, not a task confined to service desk supervisors; the stem's failure stems from treating improvement as a one-off project. Restricting improvement to a single operational role contradicts that scope.

Improvement requires pausing all value stream activities until the strategic plan is rewritten.

Why it fails: Halting all value stream activities to rewrite strategy treats improvement as a discrete interruption rather than an ongoing capability, recreating the project-based failure described. Improvement should be embedded continuously alongside delivery, not paused for a separate strategic exercise.

Total number of physical desktop computers replaced by hardware support.

Why it fails: Counting desktops replaced measures hardware support activity volume, not improvement velocity or value realisation, since no improvement initiative, cycle time or benefit is captured. It is tempting because asset-refresh numbers are easy to report and look like progress, but they belong to hardware lifecycle or service-asset management reporting.

Total electricity consumption of the primary data center facility.

Why it fails: Electricity consumption measures facility operating cost and environmental impact, revealing nothing about improvement velocity or the value realised from improvement initiatives. It is tempting because continual improvement programmes often track sustainability metrics, and energy data is readily available from data centre monitoring, but it belongs to a green-IT or facilities KPI set, not this practice.

Require executive sign-off for every individual daily task performed by developers.

Why it fails: Daily task-level sign-off imposes per-task approval latency that destroys iteration cadence, contradicting the rapid delivery the hybrid model requires. It is tempting because PMO gate approvals genuinely apply to large budget decisions, where formal executive authorisation is the correct control.

Abandon Agile methodologies entirely and force all improvements into rigid annual waterfall projects.

Why it fails: Discarding Agile removes the rapid iteration the delivery teams require, so the hybrid model's conflicting demands are not reconciled but one side is eliminated. Forcing waterfall is correct only where governance mandates sequential phase gates and no iterative delivery need exists.

Circumvent the PMO governance completely by hiding improvement budgets inside operational ticket pools.

Why it fails: Concealing budgets inside operational ticket pools bypasses the PMO's formal gate approvals, breaching governance rather than reconciling it with iterative delivery. Hiding spend suits nothing; the correct approach satisfies gate approval for large budgets while preserving short delivery cycles.

Delegate risk appetite definitions entirely to software developers.

Why it fails: Developers cannot own risk appetite; it is set by governance and leadership, and delegation without oversight breaks accountability under 'optimise risk'. Delegating technical risk decisions is tempting where teams own delivery, but appetite definition remains a governing-body responsibility, not a development task.

Transfer all risk to cyber insurance carriers and remove internal security controls.

Why it fails: Cyber insurance cannot absorb all risk; residual risk and control ownership remain with the organisation, and removing internal controls breaches governance and the 'optimise risk' practice. Insurance transfers financial impact only, and is tempting where a specific, bounded risk is genuinely cheaper to insure than to mitigate.

Enforce strict compliance controls uniformly regardless of business impact to guarantee zero security breaches.

Why it fails: Uniform controls ignoring business impact contradict 'Focus on value' and the 'optimise risk' practice, which balances cost, risk and value; zero breaches is unattainable. Such rigidity is tempting where regulatory or safety obligations demand identical treatment, but here it stalls revenue-generating features without reducing overall risk.

Total gigabytes of log data ingested into Splunk daily.

Why it fails: Log volume measures ingestion throughput, an operational capacity figure that says nothing about likelihood or impact of loss. It is tempting because SIEM coverage is a genuine governance concern, and would suit a licensing or data-onboarding discussion, but risk-based reporting needs a metric such as percentage of critical assets with unpatched high-severity findings.

Number of firewall rules configured in Cisco devices.

Why it fails: Firewall rule count is configuration inventory, not a measure of exposure or control efficacy. It is tempting because rule sprawl genuinely signals hygiene debt, and would be correct for a change-management or rule-cleanup review, but risk-based reporting requires something like percentage of internet-facing services with no compensating control.

Total number of phishing simulation emails sent to employees in a month.

Why it fails: Simulation emails sent counts awareness activity, not exposure or control effectiveness. It is tempting because phishing is a real risk vector and campaign volume is easy to trend, and would be correct for tracking programme participation, but a risk-based posture metric must express residual likelihood or impact, such as click rate on simulated lures.

Total cost of support staff divided by total number of active users.

Why it fails: Dividing support cost by active users yields a per-user cost metric, not a ratio of active work to elapsed time. Flow efficiency requires value-added time divided by total lead time, exposing waiting and queue delays in the incident workflow. Cost-per-user suits budgeting or chargeback reporting, where comparing departmental spend against headcount is the goal.

Total number of resolved incidents divided by total operational labor hours.

Why it fails: Throughput per labour hour measures productivity or resolution rate, not the proportion of lead time spent on value-adding work. Such ratios suit capacity planning and performance reporting, whereas flow efficiency compares active time against total elapsed time.

Mean time to repair (MTTR) minus mean time to detect (MTTD).

Why it fails: Flow efficiency is value-added time divided by total lead time, expressed as a percentage. Subtracting MTTD from MTTR yields a duration, not a ratio, so it cannot express efficiency. MTTR and MTTD are legitimate flow metrics, but they measure elapsed repair and detection durations rather than the proportion of time work is actively progressing.

Reassign their job titles to positions with zero peer interaction.

Why it fails: Reassigning titles removes their peer reach, destroying the emotional influence the strategy must channel rather than address. It is tempting as a way to neutralise vocal dissent, and would be correct only where a role genuinely requires no peer contact, not as stakeholder engagement during a merger.

Ignore this group entirely because they lack formal decision-making power.

Why it fails: Ignoring them discards their high emotional influence over frontline morale, which is precisely the stakeholder attribute requiring engagement. It is tempting because low power suggests low impact, and would be correct for a group with both low power and low interest, where monitoring alone suffices.

Broadcast threats of termination to deter them from expressing negative opinions.

Why it fails: Threatening termination escalates resistance among employees whose emotional influence shapes morale, converting potential advocates into active opponents. It is tempting as a show of authority, and would be correct only where formal disciplinary action is warranted, not as a stakeholder engagement tactic during a merger.

Replace the corporate strategy with whatever local units decide to do each quarter.

Why it fails: Replacing corporate strategy with quarterly local decisions inverts the cascade, removing the common direction that alignment depends on. This appeals where units demand autonomy, yet DPI interventions build two-way translation between strategy and operations, not bottom-up strategy substitution.

Centralize all operational decision-making at global headquarters, stripping local units of any planning authority.

Why it fails: Stripping local planning authority removes the operational ownership that strategy execution requires, producing compliance rather than alignment. Centralisation is tempting for enforcing consistency, but DPI addresses conflicts through shared objectives, translation and governance, not by eliminating local planning.

Ignore the local conflicts since operational units operate independently from strategy.

Why it fails: Ignoring the conflicts leaves the misalignment unresolved, so operational plans keep diverging from corporate objectives. This is tempting when units are treated as autonomous, but DPI exists precisely to connect strategy to execution; the intervention must reconcile local plans with strategic intent.