Introduction

Every great horror story eventually gets a sequel. Sometimes because the monster wasn’t really dead. Sometimes because someone opened the wrong door. And sometimes because the studio needed another hit. Project management is no different. Just when you think you’ve slain the last bug, closed the last ticket, buried the last issue, and finally convinced stakeholders that “Phase 2” is not a supernatural dumping ground for everything they forgot to request — something moves beneath the project.

Then it comes back. Bigger, hungrier, and somehow still marked “Low Risk.”

Welcome to Part II of your Halloween survival journey — where the monsters are familiar, the warning signs are ignored, and the project risks have evolved into something much worse.

Last year, you survived the usual horrors. This year, you’re facing two creatures that should have been buried long ago: The Were-Requirement — a requirement that changes shape every time someone looks at it and The Living Dependency — a dependency that refuses to stay dead. Because if last year’s survival guide taught us anything, it’s this:

In project management, nothing stays buried for long.

Attack of the Were-Requirements

Every project begins with requirements. At least, that’s what they tell you.

At first, everything looks perfectly normal. The business analyst hands you a tidy list of features. The stakeholders nod. Everyone agrees. You think:

“Finally. Stable requirements.” Then the moon rises. Someone says: “We have one small enhancement” and the requirement begins to change. First, it grows a little. Then a little more. Then suddenly it has claws.

Welcome to the Were-Requirement — a shape-shifting creature that looks harmless in daylight but transforms when nobody is watching. One minute it’s: “Add a simple login screen.” And the next “Also add biometrics, single sign-on, password less authentication, a dark mode, three new security protocols and a holographic welcome animation.” You stare at the screen. The stakeholder smiles. “It’s basically the same requirement.” No. It isn’t.

And you know it.

The Were-Requirement doesn’t travel alone. Once one requirement changes shape, others begin moving in the darkness. A small enhancement becomes a feature. The feature becomes a workstream and the workstream becomes a program. And suddenly the innocent little project that was approved three months ago is standing over your schedule with fangs. This is why requirements management matters. Poorly managed requirements can contribute to scope creep, cost increases, rework, and schedule problems.

But the most dangerous part isn’t the transformation. It’s denial. Stakeholders insist: “Nothing really changed.” Meanwhile, the requirement has doubled in size and is eating your contingency reserve. Your defenses are simple:

• Document everything.
• Confirm assumptions.
• Make acceptance criteria explicit.
• Control changes.
• And when the full moon rises — usually immediately after you’ve baselined the schedule — keep your silver bullets ready.

In project management, those silver bullets are called change requests.

Because the Were-Requirement doesn’t just change shape. It changes your timeline, budget, staffing plan and eventually…it changes your blood pressure.

Night of the Living Dependencies

You close a dependency, mark it Resolved, update the schedule and move on. Three days later, someone walks into your office and says, “We have a problem.” You look at the dependency that has returned which you thought was dead. It wasn’t.

Welcome to Night of the Living Dependencies — where every task you thought was finished can rise from the grave and stagger directly toward your critical path. Dependencies are quiet when everything goes according to plan. But let one slip and suddenly the project begins to move sideways and not forward. An API update is late or testing can’t begin. Training and the business launch moves. And then someone schedules a meeting titled: “Quick Discussion — Minor Timeline Adjustment.” There is nothing minor about it.

Dependencies are especially dangerous because they can spread through a project. PMI research has identified dependency risks as a significant source of schedule impact, particularly when projects rely on other projects, teams, or external deliverables. And just like every zombie movie, there is always someone who says: “It’s fine. It won’t spread.” It spreads. The late API affects testing, deployment, training, and business launch.

And suddenly the entire project is walking toward you with its arms outstretched. Your only defense is vigilance.

• Track every critical dependency.
• Identify who owns it.
• Confirm the date.
• Watch for warning signs.
• Communicate changes immediately.
• And never declare a dependency dead until you’ve verified that the work it supports is actually complete.

Don’t just mark it Resolved. Make sure it stays resolved. Because in project management, the living dead aren’t in the graveyard. They’re in your project plan.

The PM’s Final Warning

So, this Halloween, keep your flashlight handy. Keep your risks updated

and your requirements under control. Check your dependencies. And when someone quietly approaches you at 4:59 p.m. on Friday and says: “It’s just one little change…” Don’t turn around and don’t run. And whatever you do… don’t say, “Sure. That shouldn’t be a problem.” Because somewhere in your project plan, something is already moving. A requirement, a dependency, or an unresolved issue or a meeting that everyone swore was finally dead. And when the lights go out…

you’ll know. They’re here. And this time…they’re on your project.

“They’re baaaack.” — Poltergeist (1982)

Have you had any spooky experiences in your IT projects? If so, feel free to trick-or-treat them in the Community Discussion Forum!