Constraints and Resources: The Three Questions Every Project Should Answer Before It Starts
Timeline, budget, team — most failed projects didn't fail in execution, they failed at the moment someone said "sure, we can do that" without checking any of the three. Here's how to map your constraints before the work begins.
4 min read
Every project begins with a fantasy. Someone describes what they want, everyone nods, and for a brief shining moment the work is weightless — no dates, no invoices, no one saying "I'm already at 120% this quarter." Then reality arrives, usually in week three, usually all at once. The launch date was never negotiable. The budget was half what you assumed. Your best engineer is on parental leave from the 14th.
Constraints aren't the enemy of ambition. They're the shape ambition has to fit into. The projects that go badly are rarely the ones with tight constraints — they're the ones where nobody wrote the constraints down. So before you open a board or draw a timeline, answer three questions honestly.
Timeline: Work Backward, Not Forward
Most teams plan forward. They list the tasks, add up the estimates, and announce a finish date that nobody outside the team believes. Reverse it. Start at the final target date and walk backward through every milestone that has to land before it.
While you're walking, separate your dates into two piles:
Hard deadlines — a trade show, a regulatory filing, a contract expiry, a public announcement already made. These do not move, and everything else bends around them.
Flexible frames — internal reviews, "end of Q2" ambitions, nice-to-have launches. These are negotiating room, and you should know exactly how much of it you have.
The gap between where the backward plan lands and today's date is your real slack. If that number is negative before you've written a single task, you've learned something enormously valuable for free. This is where a Gantt view earns its keep — in Casperry, laying out dependencies on a timeline makes it immediately obvious which chains are load-bearing and which milestones have nowhere left to slide.
Budget: Know the Ceiling and the Floor
Budget conversations fail because people talk about totals when the useful information is structure. What's the hard ceiling? What's already committed versus still discretionary? Is there a contingency reserve, and who has to approve touching it? Does funding arrive in one lump or across quarters — because a project with £200k available in April is a very different project from one with £50k per quarter.
Write down the number you cannot exceed, the number you'd be uncomfortable exceeding, and what you'd cut first if you had to. Doing that exercise in a calm planning meeting takes twenty minutes. Doing it in a panic in month four takes your whole reputation.
Team: Availability Is Not the Same as Headcount
A team of six does not mean six people's worth of work. It means six calendars, each already partly spoken for, with skills that overlap unevenly and holidays nobody mentioned. Before launch, get specific about three things: who is actually available and for what percentage of their week, what each person can genuinely do (not what's on their job title), and what role they hold on this particular project.
That last one is where most teams get vague, and vagueness is expensive. "The design team owns this" is not ownership — it's a way of ensuring that when something slips, four people each assumed one of the other three had it. Real accountability is singular. This is exactly why Casperry enforces a full RACI matrix on every task with exactly one Accountable person: consulted and informed can be as many people as the work requires, but there's always one name to ask.
The Counterpoint: Don't Let Constraints Become a Cage
There's a fair objection to all of this: over-specifying constraints up front can lock you into assumptions that were wrong from day one. Discovery work, R&D, and genuinely novel products often can't be scoped accurately until you're partway in — and a team that treats its initial budget and timeline as sacred will keep marching toward a target that stopped making sense in week two.
The resolution isn't to skip the exercise; it's to date-stamp it. Treat your constraint map as a snapshot of what you knew when you started, and schedule a real checkpoint to revise it. The point of writing constraints down was never to freeze them — it's to make changes visible. A budget quietly drifting is a crisis. A budget formally revised, with a reason attached, is just management. Keeping that trail intact matters: when a project has a visible record of the requests and disruptions that reshaped it, "why did this cost double?" becomes a five-minute answer instead of a five-day archaeology dig through email.
Before You Kick Off
Run the three questions as a single short document, shared with everyone who'll touch the work:
- Timeline — target date, hard deadlines, the milestones walking backward, and how much slack actually exists.
- Budget — ceiling, committed spend, contingency, and the first thing you'd cut.
- Team — who, at what capacity, with what skills, and exactly one Accountable per workstream.
It won't make the project easy. It will make the project honest, which is the only starting condition that reliably survives contact with reality.
If you'd like a place to keep all of that connected — timelines with dependencies, clear single-owner accountability, and a visible trail from the original request to the finished work — give Casperry a try.