Selecting an inappropriate delivery model can lead to significant project setbacks, particularly when the model does not align with the project’s size, complexity, and requirements. The following case studies illustrate the challenges of adopting Scrum and SAFe for projects better suited to alternative models, highlighting the importance of matching delivery approaches to specific project needs.

The following case study examines the challenges of adopting Scrum for a complex inventory management system implementation at MediPill Pharmaceuticals. It highlights the risks of using Scrum’s flexible, iterative approach in a project requiring stringent regulatory compliance and extensive system integrations that demand structured governance.

Background

MediPill Pharmaceuticals initiates Project Scrum Rush, a two-year effort to replace its legacy inventory management system. The project seeks to modernise operations across ten warehouses and comply with pharmaceutical regulations. It requires integration with the enterprise resource planning (ERP) and warehouse management systems (WMS), migration of two million inventory records, and coordination across multiple departments. With a fixed budget of $50 million and a 24-month delivery timeframe, MediPill selects the Scrum framework based on a corporate directive to standardise Scrum across all IT projects. However, a Waterfall or Hybrid approach would provide stronger alignment with regulatory constraints and integration complexity.

Rationale for Scrum Selection

MediPill adopts Scrum based on several assumptions that do not align with the project’s actual delivery needs:

• Perceived speed: Leadership expects Scrum’s Sprint structure to accelerate feature delivery and reduce delivery time by 30% compared to past Waterfall projects.
• Flexibility: The business anticipates that an adaptive backlog will accommodate evolving requirements across ten warehouse environments.
• Corporate mandate: A strategic decision to enforce Scrum across all IT projects overrides an assessment of delivery model suitability for this initiative.
• Team familiarity: A 30-member team trained in Scrum assumes the capability to deliver complex ERP and WMS integrations within iterative Sprints. 

Project Scope

Project Scrum Rush delivers custom development for enhanced inventory management, with a defined but adjustable scope that includes:

• System upgrade: Implementation of a modern inventory management system integrated with ERP for procurement and WMS for logistics.
• Data migration: Mapping and cleansing of two million inventory records to maintain compliance with Good Manufacturing Practice (GMP).
• Process redesign: Revision of tracking processes, including reorder logic and demand forecasting, to increase efficiency by 15%.
• Stakeholder coordination: Involvement of 500 staff across procurement, logistics, and quality control to support adoption and training.
• Legacy system decommissioning: Retirement of the previous platform through a phased transition to maintain continuity of operations. 

Implementation Challenges

Scrum’s application introduces several challenges during delivery:

• Regulatory rigidity: GMP requirements for end-to-end inventory tracking conflict with Scrum’s incremental delivery model, delaying compliance validation for 20% of required features.
• Inadequate documentation: The initial backlog includes only 50 user stories with no supporting system specifications, resulting in misinterpretation of scope and 15% non-compliance with regulatory standards.
• Stakeholder misalignment: Business units expect measurable progress within the first six months and perceive Scrum’s incremental delivery as insufficient, reducing confidence in 70% of Sprint Reviews.
• Integration failures: ERP and WMS interface development in isolated Sprints leads to incompatibilities in 30% of integrations, delaying accurate inventory synchronisation until the project’s final quarter.
• Excessive rework: Incomplete analysis of reorder logic and forecasting results in defects across ten Sprints, consuming 25% of the budget through rework activities. 

Delivery Management

The delivery approach fails to align Scrum with the project’s compliance and integration requirements. The Product Backlog allows additions without appropriate approval, such as real-time analytics, which increases delivery scope and contributes to cost overruns. Documentation produced during delivery lacks GMP-compliant traceability and is not audit-ready. Continuous testing reveals defects during each Sprint, but critical issues remain unresolved due to time constraints, requiring temporary manual workarounds. A follow-up enhancement project is required after go-live to address compliance gaps.

Outcomes

The selection of Scrum for this project results in the following issues:

• Budget overruns: Additional features and rework increase total costs to $60 million, exceeding the allocated budget.
• Delivery delays: Scope expansion extends the delivery timeline to 28 months, exceeding the original 24-month plan.
• Stakeholder dissatisfaction: Incomplete deliverables and missed compliance obligations erode confidence among 80% of stakeholders.
• Quality deficiencies: The new system has a 5% error rate in inventory tracking, introducing regulatory risks valued at $2 million.
• Loss of trust: Repeated budget requests and missed expectations reduce collaboration from 60% of involved departments. 

Conclusion

Project Scrum Rush demonstrates the consequences of selecting a delivery model that is not appropriate for the regulatory complexity and integration dependencies of the initiative. A more structured delivery model, such as Waterfall or Hybrid, would have provided stronger control over compliance, documentation, and stakeholder expectations.

The next case study explores the challenges of adopting the SAFe delivery model for a COTS ticketing system implementation at Trackston Rail. It illustrates the risks of applying SAFe’s scalable agility to a project needing heavy customisations and regulatory adherence that require rigorous planning and coordination.

Background

Trackston Rail, a government-owned rail operator, launches Project OnTrack, a three-year initiative to implement a COTS ticketing system with heavy customisations. It aims to streamline passenger services and compliance with financial transaction regulations. The project requires coordination across 20 teams, integration with third-party payment APIs, and extensive stakeholder engagement. With an estimated budget of $100 million and a 36-month timeline, Trackston Rail adopts the Scaled Agile Framework to align IT initiatives with strategic goals, despite limited understanding of SAFe’s resource demands. A Hybrid model would better balance agility with the project’s scale and regulatory needs.

Rationale for SAFe Selection

Trackston Rail adopts SAFe based on generalised benefits rather than a project-specific assessment:

• Strategic alignment: Leadership expects SAFe’s portfolio management to align 50 IT projects with enterprise objectives and optimise a $500 million investment pipeline.
• Scalable agility: The organisation anticipates that SAFe will coordinate 20 agile teams and reduce time-to-market by 25%.
• Cultural transformation: The company plans to transition 2,000 staff to an agile delivery model but provides minimal SAFe-specific training.
• Industry conformity: Sector-wide adoption of agile delivery frameworks influences the decision, despite limited internal readiness or capability. 

Project Scope

Project OnTrack delivers a configurable ticketing system. The scope is defined at the outset but remains open to change during delivery:

• System implementation: Delivery of a COTS ticketing platform customised to support one million monthly transactions and integrated with third-party payment gateways.
• Process customisation: Configuration of fare calculations, booking workflows, and transaction handling to increase operational efficiency by 15%.
• Regulatory compliance: Conformance with financial transaction legislation and production of artefacts suitable for external audit.
• Data migration: Transfer of five million passenger records from legacy systems with data integrity controls to meet compliance standards.
• Stakeholder coordination: Involvement of 2,000 operations and customer service staff to support deployment and operational transition. 

Implementation Challenges

Mandated use of SAFe introduces several challenges that affect delivery performance and compliance:

• Misaligned delivery model: SAFe’s incremental Program Increments conflict with the requirement for end-to-end system customisation. As a result, 20% of payment API integrations are postponed until late delivery phases.
• Portfolio management overhead: Aligning the ticketing system with 50 concurrent initiatives redirects focus from specific compliance needs. This misalignment causes 25% of Sprint objectives to deviate from regulatory priorities.
• Synchronisation complexity: Managing 20 agile teams increases coordination demands. Unclear prioritisation causes 30% of fare calculation features to miss delivery targets.
• Limited audit traceability: SAFe’s lean documentation approach produces epics and user stories but lacks sufficient detail for financial audit purposes. This exposes 15% of payment processing features to compliance risks.
• Rework due to evolving backlog: SAFe’s adaptive scope management allows late-stage changes such as reordering of custom workflows. Inadequate upfront analysis results in rework across 10% of transaction processing features 

Delivery Management

Delivery management struggles to reconcile SAFe’s flexibility with the structure required for regulatory assurance. The Portfolio Backlog allows reprioritisation of work items, including additional API integrations and booking features. These shifts increase total costs and contribute to delivery delays. Documentation produced during Program Increments lacks audit-grade traceability. This makes it difficult to meet financial compliance standards. Although continuous testing occurs throughout delivery, short Sprint cycles limit issue resolution. Several critical defects remain unresolved at go-live and require manual workarounds. A follow-up enhancement release is necessary to improve stability and operational accuracy.

Outcomes

Project OnTrack delivers an incomplete solution at increased cost and reduced confidence:

• Budget overruns: Cost increases from rework and SAFe training raise total expenditure to $120 million, exceeding the original $100 million budget.
• Delivery delays: Misaligned priorities extend the timeline by six months and prevent delivery of key service enhancements.
• Stakeholder dissatisfaction: Inconsistent communication and unclear progress reduce confidence for 70% of internal and external stakeholders.
• Quality deficiencies: A 3% transaction error rate in the new system leads to refunds totalling $1 million.
• Operational disruption: Role changes and reassignments disrupt service delivery, resulting in a 10% decline in operational performance and loss of public trust. 

Conclusion

Project OnTrack highlights the risks associated with applying SAFe to large-scale COTS implementations that require significant configuration and regulatory conformance. The challenges in aligning iterative delivery with integration dependencies, audit requirements, and structured documentation obligations suggest that a Hybrid approach would provide better delivery control. A more structured delivery model would support traceability, regulatory compliance, and stable deployment across a multi-team environment.