Seven practical ways to stop IT project horror stories, from scope creep to hidden technical debt. Stoneseed’s P-U-M-P-K-I-N checklist for project managers.
Every project manager has a story that keeps them awake at night:
- The project challenges that kept coming back from the dead,
- The stakeholders that ghosted you,
- The go-live date that seemed perfectly healthy right up until the moment it wasn’t.
Since our last Stoneseed Halloween blog, we’ve helped lots of clients with their IT project horror stories. In the spirit of the season, we’ve distilled the patterns behind these all-too-familiar tales into a survival kit … and a handy mnemonic.
P-U-M-P-K-I-N
We are Stoneseed after all!
P: Prioritise core features
Prioritise core features, with a focus on the Minimum Viable Product.
Picture a team set to build a customer portal. Somewhere between kick-off and go-live, the backlog swells with features nobody asked for, each one “essential”. The MVP becomes a Maximum Viable Product, the launch keeps sliding, and a competitor eventually ships the few things customers actually needed first.
The lesson: value-first doesn’t mean cheap, it means ruthless.
Define the smallest set of features that delivers genuine user value and make everything else wait its turn in the backlog, on purpose. When you define that smallest set, protect the unglamorous essentials, security, compliance, and acceptance criteria, alongside the features customers can see.
If a feature doesn’t serve the core outcome, it’s a costume, not a character!
U: Uncover hidden risks
Uncover hidden risks and technical debt early, before they uncover you.
In the final stretch before go-live, an integration team opens the door to the legacy payroll interface and finds cobwebs: documented years ago, understood by one colleague who has long since moved on.
The project plan had assumed that interface was a doorway, not a cellar.
Technical debt rarely announces itself. It lurks, like a spider in a web, in the systems you touch, not just the one you’re building, and it compounds quietly while everyone argues about the new user interface. Run technical discovery against every upstream and downstream system in the early sprints and keep a “things we don’t know yet” entry on the risk log. The scariest risks are the ones nobody thought to write down.
M: Monitor velocity and burn
Monitor sprint velocity and resource burn rates together.
The dashboard glowed green month after month. Meanwhile, sprint velocity quietly slid, overtime quietly crept up, and the team was running on biscuits and fear. The report smiled; the burn rate did not.
Velocity is a forecasting aid, not a productivity league table. It becomes more useful when considered alongside team capacity, resource burn, delivery forecasts and outcomes achieved.
Look at those trends together and treat a permanently green RAG status with healthy scepticism. When the lights never flicker, ask what the dashboard isn’t showing you.
P: Plan for scope creep
Plan for scope creep and unexpected dependencies before they arrive.
“It’s just one small tweak.” The stakeholder said it every sprint, like clockwork. By mid-project, the scope had grown in the night into something with tentacles, and each new tentacle had dependencies nobody owned. The creature wasn’t malicious, it was just very, very well fed.
Scope creep isn’t managed by refusing all change; it’s managed by making trade-offs explicit. Every change request should state what moves out to make room, and every dependency should have a named owner.
If a change is genuinely urgent, fair enough, but something else is now genuinely late.
Say so out loud.
K: Knowledge-share across teams
Knowledge-share across siloed teams, to prevent single points of failure.
Every organisation has one. The engineer who has inadvertently become the only person who truly understands the pipeline, and the only reason it works. Then they hand in their notice, and the magic leaves with them. The wizard was the single point of failure all along.
Single points of failure can be human as well as technical. Pair the work, document the runbooks, and rotate ownership of critical components so the knowledge lives in the team, not in one head. If only one person can do something, that’s not a superpower; it’s a risk in a cape. Shared knowledge makes the team more resilient.
I: Iterate on fast feedback
Iterate based on continuous integration and automated testing feedback.
Friday, 6pm, release night. A spreadsheet of manual regression checks, a deployment window the whole team attends like a séance, and a silent prayer that nothing answers back. Every release a summoning ritual; every success a lucky escape.
Continuous integration and automated testing give you earlier feedback, but they don’t replace acceptance, security and operational-readiness checks.
The point is what you do with the feedback: investigate failures promptly, fix the defect rather than rerunning the suite until it passes, and let what you learn shape the next iteration.
Releases should be boring.
Boring is the goal.
Boring is beautiful.
N: Next-gen automation
I’ve worked with a few teams who are nailing next-gen! And a fair few who have ended up with zombie projects by automating the wrong things!
Integrate next-gen automation where it earns its keep.
One team automated their environment provisioning, their pipeline, even their release notes. The friendly ghost in the machine quietly did the boring bits … while the engineers went back to the interesting problems.
Good lesson: Automate the process once it works, not to paper over a broken process.
Improve first, automate second, keep a human accountable for the outcome, and measure whether it actually helps.
Start with the three most repetitive tasks on your team’s list. That’s usually where the bodies are buried.
TRICK, OR TREAT?
Most IT project horror stories turn out to be the same few ghosts wearing different costumes: unowned dependencies, invisible burn rates and critical knowledge locked away in one wizard’s head.
P-U-M-P-K-I-N is your checklist for keeping those ghosts outside the gate.
But recognising the risks is only half the battle.
If your portfolio has a few dark and creepy cellars of its own – risks you can name but can’t tame, projects lost in the fog and struggling for direction, or teams stretched too thin (skeleton staff? – Ed) then Stoneseed’s Project Management as a Service (PMaaS) can provide the expertise and additional capacity to help get delivery back on track.
Because the best time to tackle a project horror story is before something goes bump in the night.
Happy Halloween!
Got a project horror story of your own?
We’d love to hear it (and we’ve probably seen its cousin before).
Book a no-obligation chat with our team and we’ll help you work out which ghosts are worth worrying about, and how to keep them at bay.
