Core Objectives and Deliverables: The Two Questions Every Project Must Answer First
Most projects don't fail on execution — they fail because nobody agreed on why the work exists or what exactly gets handed over. Here's how to nail purpose, goals and deliverables before the first task card is created.
5 min read
Ask five people on a project team what the project is actually for, and you'll often get five different answers. One says it's about revenue. One says it's about fixing a customer complaint. One says it's about finally retiring that ancient spreadsheet. None of them are wrong, exactly — which is precisely the problem. A project without a shared, written purpose is a project where every decision becomes a negotiation, and every scope question becomes a debate about first principles.
The antidote is unglamorous and takes about an hour: agree on purpose, goals and deliverables before anyone touches a task board.
Purpose: Why does this project exist at all?
Purpose answers the why. It names the specific problem the project solves, for whom, and what happens if nobody solves it. It should be short enough to say out loud without notes — one or two sentences, in plain language, with no jargon and no hedging.
A weak purpose statement sounds like "Improve the onboarding experience." A strong one sounds like "New customers take 11 days on average to reach first value, and 30% churn before they get there. We're cutting that to under 3 days." The second version tells you what to build, what to cut, and how you'll know when you're done. It also gives you the single most useful tool in project management: a reason to say no. Every mid-project request can be held up against the purpose statement and asked, does this serve it?
The trap here is writing purpose backwards — starting from a solution someone already decided on and reverse-engineering a justification. If your purpose statement mentions a specific technology, vendor or feature, you've probably skipped the problem and jumped straight to the answer.
Goals: Make the finish line measurable
Purpose is directional; goals are the instrumentation. A goal turns "faster onboarding" into "median time-to-first-value under 3 days, measured monthly, by end of Q3." Good project goals share a few traits:
They're numeric. A target you can't put a number on is an aspiration, not a goal.
They have a deadline. "Eventually" is not a date.
They name a baseline. You can't claim improvement without knowing where you started.
Someone owns each one. Not a team — a person.
There are few of them. Three sharp goals beat nine fuzzy ones.
That last point deserves emphasis. Teams pad goal lists to make projects look ambitious, then discover halfway through that the goals conflict with each other. Faster delivery versus higher quality, broader scope versus tighter budget — these tradeoffs are real, and a goal list that pretends otherwise just defers the argument to the worst possible moment.
Deliverables: What actually changes hands
Here's where most kickoff documents get vague. Goals describe outcomes; deliverables describe the specific tangible things you hand over — the physical or digital products, services and results that leave your team's hands and land in someone else's.
Be concrete to the point of feeling pedantic. Not "documentation" but "an admin runbook in the shared Docs space, reviewed by Support, covering the eight most common setup failures." Not "a report" but "a one-page PDF summary plus the underlying dataset in CSV, delivered to Finance by the 5th of each month." For each deliverable, write down three things: what it is, who receives it, and what makes it acceptable. That third item — the acceptance criteria — is the one teams skip and later regret, because "done" without criteria is an opinion, and opinions are litigated at the worst time: the day before the deadline.
A useful test: could a new team member read your deliverables list and produce a rough task breakdown without asking questions? If not, the list is still a wish, not a specification. And once the list exists, it needs somewhere to live that isn't a buried email attachment. This is where tooling earns its keep — in Casperry, work arrives as structured Requests that convert into projects in one click, and each project keeps a Source view showing the requests and events that led to it, so the original ask stays attached to the work forever. Six weeks in, when someone asks "wait, why are we building this?", the answer is one click away instead of lost in a thread.
The counterpoint: don't over-specify what you don't yet understand
There's an honest objection to all of this. Not every project can define its deliverables up front, and pretending otherwise produces a different failure: a beautifully detailed spec for the wrong thing. Research projects, early-stage product bets and genuine R&D work often can't know their outputs at kickoff — the whole point is to find out.
The resolution isn't to abandon rigour, it's to shift what you're rigorous about. In discovery-heavy work, the deliverable is the decision, not the artifact: "by March 15, a written recommendation with supporting data on whether to build, buy or drop this." That's specific, measurable and hand-over-able, without pretending to know an answer you haven't found yet. Define scope tightly around the next learning milestone, then re-plan. What you must never do is leave both the purpose and the deliverables undefined — that's not agility, that's drift with a nicer name.
Making it stick after kickoff
The last failure mode is quieter than the others: the team does all this work, writes an excellent charter, and then never looks at it again. Objectives get agreed in a meeting and evaporate by week three, replaced by whatever's loudest in Slack.
The fix is to attach ownership to every piece of it. Each goal and each deliverable needs exactly one person answerable for it — not a committee, not a department. Shared ownership is the most reliable way to produce no ownership at all. It helps when your tooling refuses to let the question stay open: Casperry enforces a full RACI matrix on every task, with exactly one Accountable person per task, so "I thought someone else had that" stops being a plausible sentence. Then review the objectives at every checkpoint — not as ceremony, but as a genuine question: are these still the right goals, and are we still on track for these deliverables? Sometimes the honest answer is no, and catching that in week four is worth more than any amount of upfront planning.
If you'd like a place where purpose, goals, deliverables and owners live together instead of scattered across docs and inboxes, Casperry is built for exactly that — from the first request to the final handover.