Select Two (Multi-Select) Questions

Requiring all incidents to be resolved by the Service Desk only

Why it fails: Requiring the Service Desk to resolve every incident is inefficient and often impractical for complex technical issues. A modern desk should act as a hub, escalating work to specialized teams when necessary and focusing on orchestration and communication, rather than trying to solve every technical problem in isolation without subject matter experts.

Limiting user contact to email only to reduce wait times

Why it fails: Limiting communication channels to email often frustrates users and reduces the quality of the interaction. A modern Service Desk should support an omnichannel approach, allowing users to choose the channel that best fits their needs, which increases accessibility and improves the overall experience of requesting support and service delivery.

Performing final user acceptance testing only after the full deployment is complete.

Why it fails: Waiting until the end of the deployment cycle to conduct user acceptance testing is a traditional, 'shift-right' or waterfall approach. This often leads to late-stage discovery of requirements mismatches, necessitating expensive rework and causing significant delays in delivering actual value to the end user.

Increasing the number of approval gates before code is merged into the master branch.

Why it fails: Adding more manual approval gates generally increases friction and slows down the development cycle. While it is a control mechanism, it contradicts the goal of Shift-Left, which is to streamline the value stream by empowering developers and automating validation at earlier stages.

Outsourcing all incident management activities to a third-party vendor.

Why it fails: Outsourcing incident management does not relate to the Shift-Left principle of moving work earlier in the development lifecycle. Instead, it is an organizational sourcing strategy for operational support that may actually distance developers from the real-world impact of their code failures.

Implementing all suggested improvements simultaneously.

Why it fails: Implementing every suggestion simultaneously would overwhelm the organization, causing massive disruption and resource contention. Improvement must be prioritized and implemented in a controlled, manageable way to ensure that changes are successful, measurable, and do not negatively impact the stability of the existing services currently in operation.

Outsourcing all improvement activities to a third-party consultant.

Why it fails: While consultants can provide valuable expertise, outsourcing all improvement activities is counterproductive. Improvement must be an internal capability, embedded within the teams who understand the services and the customers. Relying solely on external parties weakens the organization's ability to learn, adapt, and maintain ownership of its continuous improvement processes.

Creating knowledge articles only after an incident is fully closed.

Why it fails: Waiting until an incident is closed often leads to delayed or forgotten documentation. Effective knowledge management encourages capturing knowledge 'in the flow' of work, ensuring that insights are captured while they are fresh and relevant, which is vital for continuous improvement in fast-paced IT environments.

Assigning knowledge maintenance to a single, dedicated team.

Why it fails: Centralizing knowledge maintenance in one team creates a bottleneck and disconnects the knowledge from the people who actually use it. Knowledge should be maintained by the teams that use it, promoting shared ownership and ensuring that the content remains accurate and reflective of actual practices.

Mandating that all team members achieve individual certifications annually.

Why it fails: While professional development is good, mandating certifications can create a 'check-the-box' mentality that does not foster true learning or psychological safety. It focuses on individual credentials rather than collective team knowledge, and may ignore the practical, experiential learning that is more valuable for day-to-day service delivery.

Rewarding only those who achieve the highest individual performance metrics.

Why it fails: Rewarding only individual metrics can discourage collaboration and risk-taking, as employees may prioritize personal success over team outcomes. A culture of learning requires a focus on collective improvement and shared goals, which is undermined by aggressive, purely individual-focused performance incentives.

Restricting access to production logs to senior engineers only.

Why it fails: Restricting access limits transparency and prevents junior team members from learning how systems actually behave under real-world conditions. A culture of learning relies on openness and accessibility, allowing team members at all levels to investigate issues and gain insights into the operation of the services they manage.

Performing manual security reviews after every deployment.

Why it fails: Manual reviews performed after deployment are too slow and occur too late in the process. This creates a bottleneck and increases the risk of deploying vulnerabilities. Instead, security reviews should be automated within the CI/CD pipeline to ensure that security checks are performed continuously and early in the development lifecycle.

Keeping security policies hidden to prevent unauthorized bypasses.

Why it fails: Security through obscurity is an ineffective and dangerous practice. Security policies should be transparent and well-communicated so that everyone understands the requirements. Hiding these policies prevents team members from knowing how to comply with them, which increases the likelihood of accidental security gaps that can be exploited by attackers.

Dissolving teams immediately upon the release of a new feature set.

Why it fails: Dissolving teams at the end of a feature release cycle disrupts the continuity and product ownership essential for long-term service management. Product-based approaches rely on stable, cross-functional teams that manage the product throughout its entire lifecycle, allowing them to accumulate deep domain knowledge and respond effectively to ongoing operational requirements.

Prioritizing the adherence to a fixed scope and timeline.

Why it fails: Product management prioritizes value and outcomes over rigid adherence to fixed scopes and deadlines. Focusing on static project constraints often results in 'feature factories' that ignore user needs and operational quality. Product teams must be flexible enough to pivot based on user feedback and changing business priorities.

Prioritizing individual performance metrics over team outcomes.

Why it fails: Focusing on individual metrics promotes competition rather than collaboration. In modern service delivery, success is a collective outcome. Encouraging individual competitiveness often leads to silos and prevents team members from supporting each other, which is detrimental to the shared goals and collective responsibility required for effective service management.

Maintaining a strictly top-down communication structure.

Why it fails: Top-down communication is slow and stifles feedback from the people closest to the service. A healthy culture relies on open, bidirectional communication, ensuring that insights from front-line staff are heard by management and that the team understands the strategic vision, which is vital for alignment and engagement.

Total number of support tickets closed per engineer per week, regardless of whether the user's underlying business problem was resolved.

Why it fails: Measuring tickets closed per engineer is a traditional activity metric that incentivizes rushed closures over quality resolutions. It fails to measure customer value or actual business outcomes, often leading to poor user satisfaction and recurring incidents.

Total volume of lines of code written by the software engineering department during each quarterly release cycle.

Why it fails: Lines of code written is a classic vanity metric that measures output rather than outcome or value. High code volume can often indicate poor design, technical debt, or inefficient implementation rather than successful service delivery.

Total number of change requests approved and implemented without conducting any post-implementation reviews.

Why it fails: Counting approved changes without post-implementation reviews measures throughput alone and ignores whether changes delivered value or caused incidents. ITIL 4 value measurement pairs output with outcome and feedback. Change volume suits capacity or workload reporting, not evidence of realised service value.

Enforcing strict departmental silos to ensure that individual teams maintain exclusive ownership and control over their specialized technical domains.

Why it fails: Silos restrict cross-team information flow and shared accountability, directly opposing the collaboration and trust the scenario requires. It is tempting because clear ownership and domain expertise genuinely reduce ambiguity, and silos would be the correct choice where regulatory separation or strict segregation of duties demands isolated technical control.

Punishing individuals publicly for operational errors to deter careless behavior and enforce strict compliance with standard operating procedures.

Why it fails: Public punishment suppresses the psychological safety that underpins trust and continuous improvement, driving error concealment rather than learning. It is tempting because deterrence and compliance enforcement have a place in regulated operational environments, where disciplinary consequences for wilful procedural breaches are genuinely warranted.

Relying entirely on annual performance appraisals conducted by senior management to evaluate team productivity and direct all improvements.

Why it fails: Annual top-down appraisals give feedback too infrequently and too remotely to steer iterative improvement, and they bypass the team-level ownership that high-performing cultures require. They are tempting because formal appraisal cycles remain a legitimate governance mechanism for pay, promotion and individual accountability decisions.

Restrict access to documentation to senior engineers only.

Why it fails: Restricting knowledge access creates information asymmetries and exacerbates silos. Knowledge sharing should be democratized to empower all team members, promote collective problem-solving, and ensure that junior staff can contribute effectively, which ultimately improves the organization's overall support capacity and operational resilience.

Mandate that all documentation must be written in proprietary formats.

Why it fails: Using proprietary formats limits accessibility and interoperability between different tools and teams. Open, standardized documentation formats ensure that information remains useful over time and across various platforms, which is critical for long-term knowledge retention and the seamless integration of support activities.

Outsource all knowledge management to a third-party vendor.

Why it fails: Outsourcing knowledge management removes internal control and creates dependency on external vendors. Internal knowledge is a strategic asset that must be nurtured within the organization to ensure it remains relevant and actionable for specific business contexts and unique technical challenges.

They allow providers to ignore user complaints to save costs

Why it fails: Ignoring user feedback is counter-productive and leads to misalignment with business value. ITIL CDS focuses on co-creating value. Feedback is essential for identifying service gaps and improving the customer experience. Dismissing input prevents the organization from adapting to user needs and ultimately results in lost competitive advantage.

They should only be established at the end of a project

Why it fails: Feedback must be continuous throughout the lifecycle, not just at the end of a project. Waiting until the end misses opportunities for early correction and improvement. Constant loops provide a steady stream of data, allowing teams to make incremental improvements and avoid major failures in the long run.

They are only relevant for technical software development

Why it fails: Feedback loops are essential for all types of services, not just software. Whether it is facilities management, customer support, or business services, understanding user satisfaction and performance is universal. Applying these loops across all service practices ensures a holistic approach to service delivery and consistent value for users.

An increase in the total number of items started by the team each week.

Why it fails: Increasing the number of started items is the opposite of the intended effect of WIP limits. High WIP levels often lead to multitasking, which slows down completion rates. Successful WIP management aims to increase the number of finished items, not just the volume of work initiated simultaneously.

The team consistently achieves their highest possible utilization rates for every individual member.

Why it fails: Maximizing individual utilization often leads to queuing and wait times, which harms flow. ITIL 4 advocates for flow efficiency over resource efficiency. When everyone is 100% busy, there is no slack to handle urgent requests, which leads to increased lead times and reduced overall delivery speed.

The implementation of a strictly top-down management strategy for task delegation.

Why it fails: Top-down management is generally counterproductive to the self-organizing team structure recommended by ITIL. Flow management relies on transparency and team autonomy to manage work queues. Imposing external delegation without team buy-in usually ignores the practical constraints visible to those actually performing the work.

Mean time between failures (MTBF)

Why it fails: MTBF is a reliability metric measuring the average operational time between hardware or software failures. While important for availability management, it is not a core metric used within value stream mapping to analyze workflow bottlenecks.

First contact resolution (FCR) rate

Why it fails: FCR measures the percentage of service desk incidents resolved during the initial customer interaction. This operational metric is specific to incident management performance rather than end-to-end software delivery value stream analysis.

Net promoter score (NPS)

Why it fails: NPS measures overall customer loyalty and satisfaction based on survey feedback. Although it indicates general sentiment, it does not provide the granular operational timing data needed to identify specific bottlenecks in a value stream map.

Restricting documentation access to lead engineers to protect intellectual property.

Why it fails: Restricting access creates silos and prevents team members from learning or contributing effectively. Transparency and open access to documentation are essential for fosterring collaboration and ensuring that information is readily available for all team members, which is a foundational requirement for agile and DevOps-driven service delivery models.

Mandating strict departmental boundaries to define clear areas of responsibility.

Why it fails: Strict departmental boundaries typically lead to the 'throw it over the wall' mentality, which is antithetical to modern CDS practices. Instead, ITIL 4 promotes cross-functional collaboration and shared responsibility throughout the service lifecycle to ensure that the service value stream remains fluid, responsive, and oriented toward customer outcomes.

Encouraging the use of proprietary tools that are incompatible with other systems.

Why it fails: Using incompatible tools prevents integration and data sharing across the enterprise, which hinders collaboration. Interoperability is a key requirement for modern IT service management, as it allows tools to exchange information seamlessly, supporting a unified view of the service and enabling teams to work together across different technical domains.

Requiring all tier-one support tickets to be escalated immediately to specialized engineering teams for manual root-cause investigation.

Why it fails: Immediate escalation to engineering teams contradicts the shift-left philosophy by pushing issues rightward toward expensive resources. Tier-one agents and self-service tools should handle the majority of standard inquiries to optimize support efficiency and resource allocation.

Restricting access to troubleshooting documentation exclusively to senior technical architects to maintain strict configuration control.

Why it fails: Restricting troubleshooting documentation to senior architects concentrates knowledge rather than distributing it to frontline staff, directly opposing shift-left's aim of resolving issues at first contact. Access control of this kind suits protecting sensitive configuration data, not enabling service desk and users to self-solve.

The number of employees currently available in the IT department.

Why it fails: Current headcount alone is a poor indicator for the 'buy vs. build' decision. Strategic decisions should be based on capabilities, long-term talent strategy, and the ability to maintain the service, rather than just the current number of available staff, which can fluctuate over time and with training.

The specific programming language preferred by the development team.

Why it fails: The programming language is a technical detail that should be secondary to strategic business goals. While it might impact the 'build' process, it is not a primary driver for the 'buy vs. build' decision, which focuses on business value, strategy, cost, and operational sustainability over the long term.

Transferring all responsibility for incidents from support to developers.

Why it fails: Shift-left does not mean shifting all responsibility to developers, which would overwhelm them. It aims for a balanced distribution where knowledge is shared and tasks are handled at the most appropriate level, ensuring developers remain focused on building features while support staff handle what they can.

Increasing the number of manual testing phases before deployment.

Why it fails: Manual testing is typically a source of delay in modern delivery pipelines. Shift-left advocates for automated testing earlier in the lifecycle to catch bugs during development, rather than relying on late-stage manual phases which are slow, error-prone, and contradict the goal of continuous delivery.

Replacing all automation tools with manual verification processes.

Why it fails: Automation is a cornerstone of effective shift-left strategies. Relying on manual verification ignores the scalability requirements of modern IT environments, where high-frequency deployments necessitate fast, repeatable, and consistent automated feedback loops that manual processes simply cannot provide for a fast-paced development team.

It ensures that only the highest-paid employees manage critical tasks

Why it fails: Work management focuses on task alignment and value flow, not individual salary levels. Assigning work based on hierarchical status or compensation is not an ITIL practice. Instead, tasks should be assigned based on skills, availability, and the specific requirements of the service value stream to optimize throughput.

It allows teams to eliminate the need for service level agreements

Why it fails: Work management does not replace SLAs or service level requirements. SLAs remain critical for defining expectations with customers and measuring performance. While work management helps in meeting these targets more effectively, it does not remove the necessity of having clear, documented agreements regarding performance and service quality expectations.

It replaces the need for incident management activities

Why it fails: Work management is a broader organizational approach and does not negate the need for specific practices like incident management. Incident management handles service disruptions, while work management coordinates the daily operations of teams. Both are distinct but complementary practices within the service value system for maintaining operational excellence.

Strict adherence to individual functional silos to maintain technical expertise.

Why it fails: Functional silos are detrimental to high performance in a cross-functional CDS environment. They create barriers to communication, slow down decision-making, and prevent the holistic problem-solving required to support services effectively. Modern teams should encourage T-shaped skills and cross-functional collaboration instead of strictly enforcing siloed roles.

A clear, hierarchical management structure for final decision-making.

Why it fails: Traditional hierarchy often slows down teams by creating bottlenecks in the decision-making process. High-performing CDS teams rely on empowered individuals and collaborative decision-making to maintain velocity. Over-reliance on a hierarchical structure undermines the agility and autonomy that these teams need to deliver value efficiently.