vaayaa Inclusive Education

Project and Program Management Case Studies

Professional5 Case StudiesUpdated Sep 2026

These five cases follow a program office through problems that look unrelated until they sit together. A delivery team misses its numbers, a sponsor loses patience, a recurring approval workflow eats days every cycle, a new reporting tool meets quiet resistance, and leaders must choose among initiatives without the data they want. The tools are ordinary: role charts, service levels, cycle time counts, and staged funding gates. Read them for the order of decisions rather than the outcome. What changes is how carefully those tools are matched to the problem in front of you.

1

Case Study 1

Onboarding team misses targets as roles blur

Ostrander Benefits Administration, a third-party firm that runs enrollment and benefits changes for about 140 employer clients.

The situation

Ostrander's onboarding team sets up new employer clients, and each setup is a project with a go-live date promised during the sales handoff. Over the last stretch, roughly a third of go-lives landed late, and the program office was asked to find out why. The team has six people, two leads, and one shared queue. Nobody could say with confidence who owned data validation, who approved configuration changes, or who told the client when a date was at risk. Sales promised dates from the standard eight-week template, yet complex plans routinely needed twelve. Ticket data showed work sitting untouched for an average of 3.4 days before anyone picked it up.

The challenge

The team lead wanted more hours in the day and a larger headcount. The sales director wanted the team to stop being the reason deals slipped. Neither view was testable. The program office needed to separate capacity from clarity, decide which causes sat with the team and which sat upstream, and produce an accountability plan the team would actually use within a month, not a poster on a wall.

Analysis

Teams grounded in Project and Program Management usually begin by separating role ambiguity from raw capacity, since the two look alike from the outside. The ticket data made the split visible. Waiting time before pickup accounted for most of the elapsed days on late accounts, while active work per ticket stayed close to the historical norm. That points to a queue without an owner rather than a team that cannot move quickly. The RACI chart listed three owners for data validation and none for go-live notification. Nobody had agreed a response time for new tickets, so work could age quietly without breaching anything.

The second reading concerns stakeholder expectations, which were drifting in opposite directions. Sales committed dates using the standard template and had no visibility into the complex-plan adjustments. Clients were told go-live was eight weeks and heard nothing until the week before a miss. Delivery targets were set at the program level as a count of on-time go-lives with no split by plan complexity, so the team looked uniformly poor when it was actually failing on one category. Reframing the target by complexity band and quoting dates from each actual plan would expose the gap to the people who set it.

Accountability loop for the onboarding queue
Onboarding accountability
1Assign queue owner
2Set response times
3Publish plan dates
4Review aging weekly
  1. Assign queue owner One named owner per ticket from intake to go-live.
  2. Set response times Agreed pickup window by complexity band, reviewed weekly.
  3. Publish plan dates Dates drawn from the actual plan, shared with sales and clients.
  4. Review aging weekly Tickets past their window escalate to the team lead.

Actions taken

  1. Name one owner for every onboarding ticket, from intake through go-live notification. The RACI chart was rewritten in the second week so each role maps to a named person, not a function.
  2. Agree response windows for each complexity band with the team leads and sales. Standard plans get two business days for pickup, complex plans get one day, and each ticket shows its deadline.
  3. Publish go-live dates from the actual plan rather than the eight-week template, and show sales the complexity split each month. Dates become a planning input agreed before a client hears them.
  4. Review every ticket past its window at the Monday meeting and escalate it to the team lead with a revised date. Track the escalation count as a service measure before setting any target.

Results

Within one full quarter, the share of late go-lives fell from about a third to about one in six on the same client mix. Average waiting time before pickup dropped from 3.4 days to under one day, and the team now runs a Monday review that clears aged tickets before they breach. The gain was not uniform. Complex plans still ran long, but the gap became a planning conversation with sales rather than a surprise at go-live. Escalations now average four a week, and each one carries a revised date the client has seen.

Questions for discussion

  • Which of the ownership gaps in this case would have surfaced first if the team had tracked waiting time but not active work time, and what would that have led you to fix?
  • How would you handle a sales director who resists publishing dates from the actual plan because it lengthens quotes?
  • What evidence would convince you that a team lead's capacity request is justified rather than a symptom of unclear ownership?
2

Case Study 2

Retail client loses confidence after a missed packaging launch

Brackett Print and Fulfillment, a mid-sized printer that runs packaging programs for four regional grocery clients.

The situation

Brackett ran a packaging refresh for Larkin Market Group, covering labels and carton artwork across forty-one stores. The launch window was agreed early, and the first wave went live nine days late. Larkin's procurement director, Ines, had been copied on status reports that showed amber for three weeks before the slip, but nobody had called her directly. When the late wave landed, she asked for a written account of every decision since kickoff and a meeting with the managing partner. The account team had been meeting her weekly, yet the agenda rarely covered schedule risk. Her frustration was less about the nine days than about learning of them from a status table.

The challenge

Ines wanted a credible recovery plan and a reason to keep Brackett on the next two waves. The account lead was worried that a defensive reply would confirm her view. The managing partner had already conceded the slip in an email and wanted the conversation reset within days. The program office had to rebuild expectations, stop the bleeding on the remaining waves, and give Ines commitments she could check herself without relying on Brackett's word.

Analysis

Start with the reporting chain, because the escalation was partly a roles failure. The account lead owned the relationship, the program manager owned the schedule, and the print plant owned the proofing step where the slip began. Each assumed someone else would call the client once risk crossed a threshold. Proofing data showed artwork sitting in revision for an average of four days in the third week, yet the report carried one amber line. The agreement promised a flag within two working days, but Brackett had never defined what counted as risk, so the report met the letter and missed the purpose.

Look next at what Ines actually needed. Her contract language was about dates, but her internal exposure was about shelf resets, which were booked around the store calendar. A nine-day slip on the first wave moved the reset for eleven stores into a promotional period she had already committed to. Brackett's delivery target counted on-time waves as a percentage of the total, which made the miss look like a small fraction. Measured against her reset calendar, it was a failure. Recovery has to start from her constraint, and targets must be restated in her unit.

Where the escalation sat on expectations and delivery
Stakeholder confidence, low to high
Borrowed goodwillClient trusts the relationship but waves keep slipping, so the goodwill is borrowed.
Trusted delivery partnerReliable waves and open reporting, the target position for Brackett after recovery.
Escalation riskLate waves and a client who learns of slips from the status table.
Reliable but unheardWaves land on time but nobody asked what on-time means for her stores.
Delivery reliability, low to high

Actions taken

  1. Call Ines directly before any written reply and walk her through the decision log from kickoff. The managing partner joined to own the miss without hedging.
  2. Rebuild the status report around her reset calendar. Each wave gets a red, amber, or green call tied to a named store and date, and any amber older than two days escalates.
  3. Recover the eleven delayed stores first with a dedicated two-person proofing team for ten working days. Hold later waves to a capacity plan the print plant signs before each run.
  4. Give Ines three commitments she can check herself: named proof approval dates, a weekly queue extract, and an invoice credit for any wave that misses its reset window.

Results

Ines accepted the recovery plan with two changes to the reset calendar. The eleven delayed stores went live inside the promotional window and later waves landed on their agreed dates. In the following month the report carried eleven amber calls and no surprises, and Ines said it was the first report she could act on without calling someone. Brackett paid the invoice credit for one wave that missed its window by a day, and she accepted that without argument. The account now runs a quarterly review rather than a weekly escalation call.

Questions for discussion

  • Which expectation would you test first with a stakeholder who says the contract was clear, and how would you show the gap without sounding defensive?
  • When a delivery target looks healthy in aggregate, what slice of the data would you pull to find the part that is failing for a specific client?
  • What would make you withdraw the invoice credit commitment, and who should decide that before it is offered?
3

Case Study 3

Freight damage claims stall at three handoffs

Cordell Freight Systems, a regional less-than-truckload carrier with four cross-dock terminals and about 1,200 employees.

The situation

Cordell receives about 2,400 damage claims a month across its terminals. Each claim passes through intake at the terminal, a documentation check by the claims desk, a carrier liability review, and final payment approval by the regional finance lead. The average claim took 19 days to close, against a target of 10. About one in four claims came back to an earlier step for missing documents, so some files were handled two or three times. Service levels existed for the desk but not the handoffs, so files could wait unnoticed. Terminal managers blamed the desk, and the desk blamed the terminals for photos and bills of lading that arrived late.

The challenge

The regional operations director wanted the cycle time brought under 12 days within the quarter without adding claims staff. The program office had to map the handoffs as they actually ran, not as the procedure described them, identify which delays were structural and which were behavioral, and compare fixes on cost, speed, and the risk they add to payment accuracy. Several proposals were already on the table, and each had a champion.

Analysis

The handoff map was the first real output of the work. Walking each claim through the system showed that the desk and terminal were not sequential as the procedure implied. The desk sent document requests back to terminals by email, and terminals answered in batches, so a file could cycle between them without changing status. Timestamps across 300 sampled claims showed that waiting between steps made up about 70 percent of elapsed days. The bottleneck was not processing speed. It was the gap between the desk's request and the terminal's answer, where no role owned the clock.

Set the proposals against what each stakeholder would accept. Terminal managers wanted intake photos made mandatory at pickup, which would cut document requests but add time at the dock. The desk wanted a second clerk, which fixes queue age but not the handoff gap. Finance wanted a stricter liability threshold, which lowers payment error but may increase carrier disputes. The delivery target was ten days, but nobody had agreed what share of the ten should sit with each step. Without that split, every option looked like it helped someone else's segment, so the group could not rank them.

Improvement options scored against the handoff problem
Photos at pickup6/10
Cuts document requests but adds dock time at intake.
Second desk clerk5/10
Shortens queue age, leaves the handoff gap untouched.
Stricter liability threshold4/10
Lowers payment error, may raise carrier disputes.
Shared handoff clock9/10
Named owner and timer at each handoff, shared with terminals.
Claim packet at intake7/10
Standard template filled in at the dock before the desk sees the file.

Scores set by the review team in this scenario, 10 = highest priority.

Actions taken

  1. Rebuild the claims map from timestamps on 300 sampled files, then compare it with the written procedure line by line and mark each divergence.
  2. Assign a named owner and a four-day clock to the request-and-answer step, so every open document request has one person accountable for its age.
  3. Move the packet template to intake so terminals attach photos and bills of lading before the desk sees the file, and track returns each month.
  4. Pilot a shared-clock dashboard at two terminals for six weeks before any hiring decision, with a rule that a second clerk is considered only if queue age stays above target.

Results

The map changed the argument. Within two months the average close time dropped from 19 days to 13 and returns for missing documents fell by about half. The shared clock showed that most waiting sat in two terminals, which had been treated as identical. The second clerk was not hired, because queue age at the desk dropped below target once the request step had a named owner. The regional director accepted a 12-day target for the quarter, with 10 days still the aim for the year.

Questions for discussion

  • Which handoff in this map would you instrument first if you could only add one timestamp, and why?
  • How would you weigh a proposal that speeds one segment but shifts risk to a stakeholder who was not consulted?
  • What share of the delivery target should each step own, and who should agree to it before any option is ranked?
4

Case Study 4

Dual approval policy meets resistance across branches

Ashgrove Valley Credit Union, a member-owned lender with eleven branches and about 380 staff that runs a shared accounts payable group.

The situation

Ashgrove Valley's finance committee approved a dual approval rule for vendor payments above a set threshold, delivered through a new workflow tool. The policy was meant to close a control gap found during an internal review. Branch managers, who had spent years approving their own purchases, learned of the change through a memo and a training invitation for the same week. Within a fortnight, about a third of payment requests were being routed to the wrong approver, and several branches began printing requests and walking them to the regional office. Dashboards showed about 40 percent of eligible requests in the tool by the second week.

The challenge

The chief risk officer wanted full adoption within the next month and asked that non-compliance be reported weekly by branch. The shared services manager was worried that enforcement would push branches to route around the tool entirely. The program office had to find out what was driving resistance, sequence the adoption activities so the rule and the tool landed in a workable order, and set measures that showed real uptake rather than logins.

Analysis

Resistance was not one thing. Interviews with twelve branch managers and four approvers separated three concerns. Some managers feared delay, because the approver for their branch sat at the regional office and could be slow to respond. Others were worried about losing standing, since the old process let them clear small payments without a second signature. A third group had a practical problem: the tool did not show the branch manager the approver's status, so requests disappeared into a queue. Each concern called for a different response, and the memo treated all three as a single failure to comply.

The measures had the same problem. Adoption was counted as logins to the tool, which rose quickly because managers opened it to check requests and then printed them anyway. The service level for approvals was also undefined: the policy said approvers should respond promptly, with no hours or business days attached. A useful target would separate three things, requests routed correctly, requests approved within an agreed window, and requests that avoided the paper path. Setting a single adoption percentage would hide which branches were stuck and why. Each measure needs an owner and a source the workflow data can produce on its own.

Adoption sequence for the dual approval rule
  1. 1Fix routing firstCorrect the approver map for each branch before any enforcement date.
  2. 2Pilot at two branchesRun live requests at two branches for three weeks and log each stall.
  3. 3Publish status visibilityShow each branch manager the approver's status on every open request.
  4. 4Retire the paper pathStop print-and-walk approvals only after the pilot clears its stall rate.

Actions taken

  1. Set approver coverage for every branch before go-live, with a named backup at the regional office for each approver who is out or slow.
  2. Run a three-week pilot at two branches with live requests, logging each stall by cause: routing, delay, or visibility. Pick branches with different manager concerns so the pilot tests all three.
  3. Add approver status to the request screen and send a reminder to the approver at the agreed window, so branch managers can see progress without calling the regional office.
  4. Brief each branch manager in person on what changes for small payments, then give them a named contact for the first month.

Results

Stalls at the pilot branches fell by more than half within three weeks, and the routing errors traced back to one outdated approver map. The team rolled the status view out to all branches, then set the paper path to end after a fixed window. By the end of the quarter, about 85 percent of eligible requests moved through the tool, and managers reported fewer follow-up calls. Two branches still lag, and the review shows why: both lack a backup approver. Compliance reporting now runs weekly by branch, with a stall count next to each uptake figure.

Questions for discussion

  • Which of the three manager concerns would you expect to fade fastest once status is visible, and which would need a policy answer instead?
  • How long should a pilot run before a team decides whether the stall rate is a design problem or a people problem?
  • What would you accept as a reason to delay the paper path shutdown, and who should approve that exception?
5

Case Study 5

Choosing among three initiatives with incomplete data

Pell Harbor Renewable Components, a manufacturer of inverter housings with two plants and roughly 950 employees.

The situation

Pell Harbor's executive team had funding for one major initiative in the coming year and three proposals on the table: a second assembly line, an automated inspection system, and a redesign of the supplier qualification process. Each sponsor brought a business case, but the cases used different assumptions. Demand forecasts ranged widely because two large customers had not yet confirmed volumes. The inspection vendor's defect-reduction figures came from its own trials, and the supplier process had no baseline data at all. The program office was asked to recommend a choice and to say how confident the team should be in it.

The challenge

The chief operating officer wanted a decision at the next steering meeting, and two sponsors had already lobbied the board. The finance lead argued that waiting for data would cost a quarter of production capacity. The program office needed to define criteria the sponsors would accept before scoring, assess how much each option depended on unconfirmed inputs, and propose a path that kept the decision reversible where possible.

Analysis

The first move was to agree criteria before anyone scored anything. The team settled on four: expected contribution to margin, sensitivity to demand changes, time to first measurable result, and reversibility. Reversibility carried more weight than most sponsors expected. A second line committed early could not be unwound, while an inspection system could be scaled back or resold. Sensitivity was tested by re-running each case at the low and high ends of the demand range. The second line's advantage disappeared at the low end, which mattered because the two uncertain customers were the largest share of volume.

Each option was also judged by what it would teach the company. The inspection proposal came with a vendor claim that could be tested on one line within a single quarter, using the plant's own rejected-unit data as the baseline. The supplier redesign needed a baseline before any change could be judged, and the existing qualification records showed approval times that varied by a factor of three depending on the buyer. Stakeholders expected a commitment, but the most useful next step was the one that produced evidence fastest at the lowest irreversible cost. The chosen initiative should therefore carry a gate where the other options can still be reopened.

Staged path from evidence to full commitment
  1. Weeks one to fourBaseline the supplier process and run the inspection pilot on one line.
  2. Weeks five to eightConfirm the two large customers' volumes and rerun all three cases.
  3. Week nine gateSteering review decides whether to commit to the line or hold.
  4. Months three to sixBuild the chosen initiative in stages, with the reversal path kept open.
  5. Next planning cycleCompare realized results against the gate assumptions before any second commitment.

Actions taken

  1. Agree four scoring criteria and their weights with the sponsors in writing before any option is scored, and record who approved the weights.
  2. Run each business case at low, expected, and high demand, using only inputs the customers or plant have confirmed, and mark every number that rests on a vendor claim or an assumption.
  3. Fund a limited inspection pilot on one line with a fixed budget, a fixed end date, and a go-no-go threshold on rejected units agreed before the first run.
  4. Defer the second line until the gate review, and tell its sponsor in writing what evidence would move it forward. Keep the supplier redesign on a small budget to build its baseline in parallel.

Results

The steering group chose the staged path. The inspection pilot cleared its threshold at the first gate, and the supplier baseline showed approval times that justified a narrower redesign. The second line was held, and at the gate the team confirmed that the demand floor was lower than the sponsor had assumed. The company committed to the inspection system in stages and kept the line on the reserve list. The result is a funding decision that the sponsors can explain, with a record of what would reopen it.

Questions for discussion

  • If the criteria were agreed before scoring, which sponsor would have the strongest case to reopen the weighting, and how would you respond?
  • What would a stage gate look like for a decision that cannot be reversed once made?
  • Which input in this case would you spend money to confirm first, and what would you do if the answer came back unfavorable?

Learning Resources

Professional CASE STUDIES

China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.

Hourly Active: 37,008 Learners