How project management cases differ from other business cases
Strategy cases ask where to compete. Project management cases ask how to deliver — under fixed scope, a deadline someone else chose, and a budget someone already cut. The decision-maker is rarely the CEO; it is a project manager with just enough authority to be accountable and rarely enough to be comfortable. That shape changes what a good answer contains.
Three features define the genre. First, trade-offs are the substance: every option costs schedule, money or scope, and the marker is watching for the one you would spend. Second, people are variables, not decoration — sponsors drift, vendors slip, teams resist — so stakeholder analysis carries marks the way financial analysis does elsewhere. Third, sequence matters: a recommendation without an order of operations is a wish list. Your answer should show dependencies, not just actions.
The PM triangle: where the pressure sits
Scope, schedule and budget form the classic trade-off triangle, with quality sitting in the middle — push any two constraints and the third pays. In case-study answers, the triangle is a diagnostic: identify which side the case is squeezing hardest, and your analysis, options and recommendation all get a spine. Slide the pressures below to see how the reading changes.
Triple constraint balancer
A thinking aid — runs in your browserMove a slider. The tool reads the pressure mix and suggests what your answer should argue — a starting reading, not a verdict on your case.
The stakeholder register: interest × influence
Most PM cases reward a stakeholder register — a short table naming who cares, how much, and what you will do about it. Rate each role on interest (how much the outcome affects them) and influence (how much they can move the project), then give each row a "so what". The register below is illustrative, built around a warehouse software rollout used across the rest of this page.
| Role | Interest | Influence | So what (handling) |
|---|---|---|---|
| Warehouse manager | High | High | Co-sponsor the rollout; weekly check-in; their sign-off gates the pilot. |
| Floor supervisors | High | Medium | Train early and collect their objections before the pilot, not after. |
| IT director | Medium | High | Owns the integrations; give them a scope veto on interface changes. |
| CFO | Medium | High | Approves spend; monthly cost report with the variance explained, not just shown. |
| Picker crew | High | Low | Run champions on each shift; their adoption is the real go-live test. |
| Software vendor | High | Medium | Tie payments to milestone acceptance; hold them to the interface contract. |
Six rows is usually enough to cover a case's decision. What earns the marks is the handling column: registers without consequences read as a list of names copied from the case, which is exactly what they are.
Milestone tables that answer "what happens when"
A milestone table is the fastest way to show sequence, dependency and accountability in one exhibit — and it beats a full Gantt chart in a written answer for almost every brief. The illustrative version below continues the warehouse rollout, in relative weeks (W1–W12) because the case rarely gives you a calendar.
| Week | Milestone | Depends on | Signed off by |
|---|---|---|---|
| W2 | Requirements and interface list frozen | — | Warehouse manager + IT director |
| W4 | Vendor system-integration testing complete | W2 | IT director |
| W6 | User acceptance pass with floor supervisors | W4 | Warehouse manager |
| W8 | Pilot zone go-live (one aisle bank) | W6 | Warehouse manager + vendor |
| W10 | Rollout wave 2 (remaining zones) | W8 pilot review | CFO briefed on variance |
| W12 | Hypercare exit and handover to operations | W10 | Warehouse manager |
Three things make this table work in a marked answer: every milestone has an owner who signs, every dependency is explicit, and the pilot is small enough to fail safely. "Go live everywhere in W8" is a plan for one outcome; the wave structure is a plan with a feedback loop.
Read the case like a project manager: a checklist
Before writing, mine the case for the six things every PM answer leans on. Tick as you find them — the bar tracks your progress.
Case mining0 of 6 found
- Who has decision rights. The sponsor's name, and whether they can actually enforce scope or budget.
- The constraint evidence. Every stated date, budget figure and fixed scope item — these are the triangle's sides.
- The six most relevant stakeholders. Named roles, with a first read on interest and influence.
- Dependencies hiding in the narrative. Anything that must finish before something else starts.
- The recommendation in one sentence. What you would do first, and what you would deliberately not do.
- The trade-off you would defend first. Which constraint you would spend, and what you would say to its owner.
The five-step approach to a PM case answer
Each card below is one move; together they run from first read to defensible recommendation.
1 · Read for the decision, not the drama
Find what the project manager is being asked to decide and by when. Everything the case says about meetings, milestones and mood is evidence for that decision — catalogue it against the three constraints.
2 · Chart the constraints
Scope, schedule, budget — write each with its case evidence. The balancer above turns the mix into a reading your analysis can argue.
3 · Register the stakeholders
Interest × influence, six to eight named roles, each with a handling line. Escalation paths belong here too.
4 · Sequence milestones before dates
Dependencies first, calendar second. A milestone table with sign-offs shows control; dates without owners show hope.
5 · Answer the Monday question
Close with what the PM does Monday morning, what they tell the sponsor, and which risk they accept. Execution detail is the genre's signature.
A worked mini-outline you can copy
The full worked outline for the illustrative warehouse rollout, sized for a 2,000-word answer — adjust the proportions to your brief's weighting.
Four pitfalls specific to PM answers
Gantt cosplay
A full chart with no critical path is set dressing. If nothing in your schedule can slip the end date, the exhibit is not doing work.
Stakeholder lists without consequences
Interest and influence columns with no handling column name the cast without directing the play. The "so what" is the analysis.
Dates nobody signed
Milestones without owners are wishes with deadlines. Attach sign-off to each gate and your plan instantly reads as managed.
Ignoring the humans
Adoption risk, training load and floor resistance decide go-lives. Cases signal them deliberately — answers that miss them read as written by someone who has never run one.
Tools and guides for the write-up
Your recommendation is a claim, so give it the sentence it deserves: the thesis statement generator drafts decision-shaped claims you can sharpen. For the analytical layer — symptoms to causes — the moves in business case study analysis transfer directly to constraint and dependency reasoning. And when you want the full skeleton — sections, exhibits, referencing — the how to write a case study guide holds the complete structure this page assumes.
Case mined, but the plan will not commit to paper?
A quoted, deadline-bound writer can assemble your findings into the full answer — constraints argued, register built, milestones sequenced — for you to review, rework and submit as your own judgement.
Frequently asked questions
Do I need a Gantt chart in my project management answer?
Usually not. A milestone table with dependencies and sign-offs communicates more in a written answer and takes a fraction of the space. Build a Gantt only if the rubric explicitly asks for scheduling detail — and then pair it with a sentence naming the critical path.
What if the case gives no dates?
Use relative weeks — W1, W2 — and say the sequence is what matters. Markers grade dependency logic, not calendar accuracy, and inventing specific dates adds nothing your relative plan does not already show.
Which project management methodology should I reference?
The one your course teaches, described generically. Name phase-gate or iterative practice at the level your module uses it rather than citing a standard edition you cannot verify — precision you cannot support reads worse than honest generality.
How many stakeholders belong in the register?
Six to eight named roles is the working range: enough to cover the decision, few enough that each row earns its handling line. Every entry should change what the project does — a register row without a consequence is a name, not an analysis.
How do I answer a scope-creep question?
Show the control, not the complaint: a change-request gate, who approves, and the impact each change has on the triangle. The strongest answers quantify one example — "this interface request costs two weeks of testing" — and connect it to the constraint that already dominates.
Was this guide useful?