The Difference Between Outcomes, Objectives, Phases, Workstreams, Deliverables, Tasks and Actions
How I work
When I’m scoping a new piece of work, I almost always work in this direction:
Start at the top, with the objectives. Clear objectives anchor everything.
From there, I split the work into logical workstreams
Then define the deliverables within each workstream
Then decide if phasing makes sense for rhythm and focus
Only then move into tasks if I think it needs it
Too many projects fall into trouble because people talk about “tasks” when they mean “deliverables”, or “phases” when they really mean “workstreams”.
People mix outcomes with objectives, benefits with success criteria, and expectations with deliverables.
Then everyone wonders why aligning a project team is difficult.
I do not plan from outcomes.
I do not plan from success criteria.
I do not plan from expectations.
I plan from objectives, then workstreams, then deliverables.
Outcomes and benefits explain why.
Success criteria shape how.
Only objectives define what.
At Wrixle, I separate these layers because they do different jobs in a project. Some give context. Some provide direction. Only a few help you work out what to do.
When teams use the same words to describe different things, projects unravel. When people use the right terms with confidence, everything accelerates.
It gives everyone shared language: no more muddled conversations about “tasks”, “bits of work”, or “to dos”.
It prevents over planning: early scoping stays strategic, not tactical.
It improves ownership and alignment: workstreams and deliverables make it clear who owns what and why.
It keeps plans clean and useful: it makes status reporting meaningful. You can talk about progress on objectives, phases, workstreams, and deliverables without drowning people in minutiae.
Here is how I define them, and why it matters.
Outcomes
What the organisation hopes will be true after the change has landed.
Outcomes are powerful and important. are the top of the hierarchy. They answer the question: Why are we doing this at all?
They help stakeholders make decisions. They help teams stay aligned with the bigger picture.
But outcomes mainly occur after the project has delivered its work. You cannot directly “do” an outcome. You deliver something, and the outcome happens downstream.
This is why outcomes are not the most helpful tool when your team is trying to work out specifically what they need to do next week.
Examples:
More customers convert without needing help
Faster onboarding experience
Higher renewal rates
Reduced call handling times
These are all excellent, meaningful statements. They just sit above the plan rather than inside it.
I tend to keep outcomes alongside benefits. That is their natural place. They help with context, quality and direction, not task-level clarity.
Objectives
The specific organisational aims the project must achieve.
Objectives are not the same as outcomes. They are sharper. They define the scope boundary. They tell the team what must exist or change by the end of the project, not what might happen in the months after launch.
Objectives answer the question: What are we doing in this project, and what must it accomplish?
Objectives directly shape the work. Move the objectives, and the plan changes. If the plan changes but the objectives do not, something has gone wrong.
Examples:
Launch a new product by Q3
Replace the legacy platform
Implement a compliant set of customer communications
Build a self-serve portal for a specific customer segment
Objectives are high-level, but they are actionable. They tell the project team what must be delivered.
This is why I start with objectives in scoping. They anchor the work. They stop us drifting into solutioning. They give the team a shared understanding of what “done” means.
Success Criteria and Expectations
The standards the project must meet while achieving the objectives.
Success criteria are not deliverables. They are not work. They are the guardrails for how the work must be done.
Examples:
Maintain BAU service throughout
No customer detriment
No regulatory breaches
These are essential because they define “acceptable delivery”. They sit beside objectives rather than beneath them. They influence design decisions and risk management, but they still do not tell the team what to do.
Success criteria and expectations are quality measures. They belong in the project initiation documents, RAID logs and governance, not in the timeline plan.
Phases
The broad time-based stages that show how the project will unfold.
Phases describe when things happen, not what they are.
They give the programme rhythm. They help stakeholders understand timescales at a glance. And they make it possible to manage expectations.
Common phase examples:
Discovery
Build
Test
Launch
Stabilisation
You can run all workstreams through the same phases, or different workstreams may have slightly different phase patterns. Phases are a simple navigational “chunking” tool rather than a detailed breakdown.
Workstreams
The major strands of work that run in parallel.
This is where I go next in scoping, straight after agreeing objectives.
Workstreams reflect how the real world divides the work. That might be by functional areas in a business - product, marketing, operations, data, systems, service, or commercial. Workstreams help you assign ownership, spot dependencies, and structure conversations.
A workstream is not a deliverable. It is a grouping of activity and expertise, often with an owner.
Example workstreams:
Product
Workflow automation
Marketing and Comms
Costs, Contracts and Supplier Mobilisation
Workstreams are a healthy level to stay at early on. They stop you disappearing into the weeds too soon.
Deliverables
The tangible outputs that must exist at the end of the workstream.
Part of my scoping process is to define deliverables within each workstream because deliverables make the work real. They are the things you can pick up, point at, test, sign off, or use.
Deliverables answer the question: What must we produce to meet the objective?
Examples:
A full set of product specifications
Rating tables and underwriting rules
Customer communications for go live
A trained customer service team
A functioning portal with quote and buy journeys
Deliverables create clarity. They prevent teams from wandering. They provide checkpoints that mean something.
Tasks
The pieces of work that teams complete to create the deliverables.
Tasks belong in the plan. I do not define them during scoping because it is too early. When you try to go down to task level before the deliverables are clear, you waste time, you miss steps, and the plan becomes inaccurate the moment it hits reality.
Examples of tasks:
Draft the IPID
Configure GA4 tracking
Update the chatbot flows
Validate the product documentation
Run user testing sessions
Tasks can expand infinitely, which is why discipline is essential. Stop at a sensible level. The purpose of tasks is progress tracking, not micromanagement.
Actions
Small, often reactive, pieces of activity that keep the work moving.
Actions are different again, and they do not belong in the plan.
Actions are the comments, follow ups, reminders, clarifications, emails to send, and decisions to chase. They emerge from conversations rather than from the structure of the project. You should keep them in a separate action log. Planner is my favourite one for this, or a Sharepoint list.
Examples:
Confirm with legal whether the wording can be reused
Ask the supplier for revised dates
Circulate the updated brief
Actions are the lifeblood of delivery, but they are not part of the structural hierarchy. Keeping them separate stops your project plan becoming a to do list.
