Case studies
Real engagements, anonymized per NDA. Each case shows the context I walked into, the problem, what I changed, what became visible to the client, and the business impact.
Escalated project stabilization
A delivery reset to stabilize a mobile project.
Context
A 14-person team — PM, BA, designer, DevOps, 2 QA, 4 mobile and 4 backend developers — had been building a consumer mobile app for 4–5 months. The client was a strategic stakeholder with a personal investment in the app and ongoing relationships across other engagements with the company.
Problem
The team was running 2-week sprints against a delivery plan committed early, before the real product complexity had surfaced. Sprint goals became unrealistic, work carried forward sprint after sprint, and the catch-up pressure produced rushed delivery, quality issues, and falling morale. The client saw the project sliding out of control. Trust — and future work — was at risk by the time I came in as Delivery Manager.
What I changed
After an internal audit, I had an open conversation with the client about why the original plan no longer reflected reality. We moved from 2-week sprints to a Kanban flow to remove artificial deadline pressure, re-baselined the project against the latest complexity, coached the PM on status reporting and client communication, and I stayed personally involved in governance until delivery was stable. Kanban and the re-baseline worked together — neither would have been enough on its own.
What became visible
Clearer status reports gave the client real visibility into progress, risks, and next steps for the first time. The "sliding out of control" feeling went away because the client could see where the project actually stood week to week, and what we were doing about it.
Business impact
Roughly 60% fewer new bugs sprint-over-sprint. Release frequency improved from every 4 weeks to roughly every 10 days. The transition stabilized within 2–3 weeks. The project was delivered with good quality to the client's satisfaction — later than the original plan, but the strategic relationship was protected and future work remained safe.
Portfolio visibility improvement
From inconsistent PM reporting to evidence-based portfolio control.
Context
A 300-person software services company managing roughly 25 active projects across 15 PMs. Each project ran its own process — different reporting formats, inconsistent project-health colors, no shared metrics library, no PM skill matrix, only a thin set of shared templates.
Problem
Leadership had a partial portfolio view. Profitability was visible, but delivery health couldn't be compared project-to-project. Risks surfaced late, client escalations were too often a surprise, and PM evaluation was subjective. With 25 projects and 15 PMs, portfolio control couldn't depend on personal chasing or ad hoc reviews.
What I changed
As portfolio-level Delivery Manager, I built a shared delivery operating model: a company-wide SDLC, standard Jira project rules, a RACI matrix, regular project audits, shared templates (charter, status report, risk matrix, Confluence structure), a metrics library, a PM skill matrix, and a portfolio dashboard with evidence-backed RAG reporting across budget, scope, schedule, team, client, and profitability.
What became visible
For the first time, leadership could compare delivery health across the portfolio on the same terms. RAG status had to be supported by metric evidence, not opinion. Client sentiment shifts and margin pressure surfaced earlier. PM gaps showed up in the skill matrix instead of in escalations.
Business impact
Portfolio status collection and validation dropped from 10–12 hours to 1–2 hours. Client escalations fell from 1–2 per month to roughly 1 every 3–4 months. First visible results within month 1; most of the operating model in place by end of month 3.
Presales-to-delivery handoff improvement
From transferring documents to transferring delivery context.
Context
An outsourcing company with a company-wide gap between presales and delivery. As Head of Presales, I owned how new opportunities moved from commercial discussions into production. The standard handoff package transferred final artifacts but often missed the reasoning, agreements, and client context that sat behind the deal.
Problem
Context loss, not missing documents. Delivery teams asked clients the same questions again, challenged estimates after kickoff because they didn't know how the numbers were built, hit scope disputes over expectations that hadn't been transferred clearly, planned the wrong priorities first, and missed hidden commitments made during sales. Friction between presales, production, and the client started on day one.
What I changed
Redesigned the company-wide handoff process. Defined a required handoff package (call recordings, presales timeline, client context, agreements, estimate assumptions, priorities, stakeholders, initial risks, technical rationale), added a validation checklist, introduced an internal presales–production kickoff before the client kickoff, ran joint stakeholder analysis and risk identification, reviewed assumptions and technical decisions together, and brought the production PM in near the end of presales — before contracts were signed. First version live in 2–3 weeks; full rollout in 1–2 months.
What became visible
Risks, assumptions, stakeholder expectations, and hidden commitments became visible before delivery started rather than after. Production teams could see how estimates were built and which client priorities had to drive the project start. The internal kickoff surfaced gaps while there was still time to fix them.
Business impact
Smoother client kickoffs. Fewer repeated questions to clients. Fewer estimate disputes and scope disputes. Less rework at project start as production stopped reconstructing context the client had already shared. Friction and blame between presales and production dropped. Client NPS improved.
Seen enough? Start with the diagnostic.
Book a 20-minute call. We'll look at your delivery setup and whether the pattern matches what you've read here.