ERYZE

Case study

Examining delivery risk in a food-ordering app

This coursework scenario examines what happens when integration complexity, testing effort, scope pressure, and timeline optimism meet a project without enough control points.

Back to case studiesGet in touch
01

Project Management

02

Agile Delivery

Overview

  • NoteBuilt as an academy retrospective exercise using a supplied project scenario.
  • NoteThe analysis focused on control points, communication quality, and risk handling.
  • NoteThe goal was not to assign blame, but to understand where the project stopped being manageable.

Original goal

  • NoteDeliver a product with clear timelines, aligned stakeholders, and a stable integration path.
  • NoteMaintain progress visibility while moving through planning, build, testing, and handover.

Delivery setup

  • NoteThe scenario described multiple streams moving in parallel.
  • NoteERP integration introduced a dependency that carried more complexity than the early plan reflected.
  • NoteThe setup required disciplined communication and tighter testing planning than it received.

What happened

  • NoteThe scenario reported optimistic timeline expectations while complexity increased underneath them.
  • NoteTesting effort expanded late, which compressed the room for correction.
  • NoteScope moved without enough control, which made delivery coordination harder to stabilize.

Root causes

  • NoteERP integration complexity was treated as manageable before enough was known.
  • NoteTesting scope was underestimated relative to the real delivery surface.
  • NoteScope creep weakened the predictability of the plan.
  • NoteTimeline drift was not escalated strongly enough, early enough.

Key artifacts

Communication plan

Mapped how updates, escalations, and dependencies should have been handled across stakeholders.

Sprint and daily tracking sheet

Used to evaluate how work movement and coordination signals could have been made more visible.

Close-out report

A sample coursework document capturing scenario outcomes, unresolved issues, and proposed lessons.

What I would do differently

  • NoteEscalate integration uncertainty earlier and treat it as a planning risk, not a technical detail.
  • NoteProtect testing time as a real workstream instead of a trailing activity.
  • NoteSet firmer rules for scope intake and change approval once the plan is live.
  • NoteUse decision logs and clearer milestone reviews to stop drift earlier.

PM lessons

  • NoteDependencies only stay manageable when their uncertainty is visible.
  • NoteA timeline is not credible if testing has not been planned as seriously as build work.
  • NoteChange control is a delivery safeguard, not bureaucracy.