13 KiB
Duration: 30–35 minutes
Definition
A task is a specific piece of work that needs to be performed.
A milestone is a significant checkpoint that demonstrates meaningful progress toward the project's outcome.
The distinction matters because managers can easily drown in hundreds of tasks when what they actually need to understand is:
Is the project progressing toward its outcome?
Task
Examples:
-
Configure DNS
-
Create database
-
Implement tracking script
-
Write test cases
-
Review documentation
-
Configure deployment pipeline
Tasks represent work.
Milestone
Examples:
-
Infrastructure ready
-
Tracking implementation complete
-
Data validation approved
-
Production launch complete
-
Operational handoff complete
Milestones represent meaningful states reached by the project.
Simple Mental Model
Think:
Tasks tell the team what to do.
Milestones tell the manager where the project is.
Or:
TASKS → TASKS → TASKS → MILESTONE
↓
TASKS → TASKS → TASKS → MILESTONE
↓
TASKS → TASKS → TASKS → PROJECT DONE
You don't necessarily need to know whether task #37 is complete.
You often need to know:
"Have we reached the production-ready milestone?"
How It Works
Consider a project to implement Umami.
The project could contain dozens of tasks:
- Create server
- Configure database
- Configure DNS
- Configure SSL
- Deploy Umami
- Configure authentication
- Add tracking script
- Configure events
- Test page views
- Test custom events
- Validate traffic
- Compare data
- Create dashboard
- Write documentation
- Train users
...
All legitimate work.
But imagine you're managing 12 projects.
You cannot effectively manage:
15 tasks × 12 projects = 180 individual tasks
And that's a small example.
Instead, you might manage Umami through five milestones:
1. Infrastructure ready
↓
2. Tracking implemented
↓
3. Data validated
↓
4. Reporting available
↓
5. Production handoff complete
The project owner manages the tasks required to reach those milestones.
You manage primarily through the milestones.
What Makes a Good Milestone?
A milestone should represent a meaningful state, not merely arbitrary progress.
Weak:
50% development complete
Better:
Tracking implementation complete and ready for QA
Weak:
Worked on infrastructure
Better:
Production infrastructure ready
Weak:
Meeting with Product completed
Better:
Requirements approved by Product
The second versions tell you something important about the project's state.
Milestones should be verifiable
Someone should be able to ask:
"Did we reach this milestone?"
and get a reasonably objective answer.
For example:
Data validation complete
means agreed validation has occurred and the results were accepted.
Compare that with:
Data validation underway
That's a status, not a milestone.
Example
Let's use your Pipeline QA d'automatisation project.
Outcome
Critical website functionality can be automatically validated before production releases, reducing manual QA effort and identifying regressions earlier.
Possible Milestones
Milestone 1: Requirements approved
The team agrees on:
-
Which user journeys are critical
-
What should be automated
-
What remains manual
Milestone 2: Proof of concept validated
A small number of tests successfully run automatically.
This reduces an important uncertainty:
Can our proposed approach actually work?
Milestone 3: Critical test suite complete
The agreed critical scenarios have been automated.
Milestone 4: Deployment integration complete
Tests run as part of the agreed deployment workflow.
Milestone 5: QA acceptance complete
QA validates that the automation meets the agreed requirements.
Milestone 6: Operational handoff complete
Documentation exists, ownership is established, and the system can move from project work into operations.
Now compare that with:
Project is 70% complete.
"70%" tells you surprisingly little.
Knowing:
"The critical test suite is complete, but deployment integration hasn't started"
tells you much more.
How It Fits Into the Bigger Picture
The first four lessons now build directly on each other.
Projects vs Operations
Is this temporary work?
Outcomes and Definition of Done
What are we trying to accomplish, and what counts as finished?
Scope and Scope Creep
What work belongs inside the project?
Milestones vs Tasks
What meaningful checkpoints show us that we're getting there?
Together:
OUTCOME
│
Where are we going?
│
▼
SCOPE
│
What are we delivering?
│
▼
MILESTONES
│
How do we know we're
making progress?
│
▼
TASKS
│
What needs doing?
│
▼
DEFINITION OF DONE
This order is important.
A common mistake is starting immediately with:
"Let's create all the Jira tasks."
But you haven't necessarily established what the project is trying to accomplish yet.
My Company / Real-World Context
This concept is particularly relevant to how you should eventually divide responsibility between yourself and your project owners.
You shouldn't need to manage every task performed by your integrators, analysts, QA, or SEO/WCAG person.
The eventual system could look like:
PROJECT OWNER
│
├── Tasks
├── Detailed sequencing
├── Day-to-day follow-up
└── Contributors
│
▼
MILESTONES
│
▼
YOU
The project owner should be able to tell you:
"We're targeting milestone 3 for August 15."
Your job becomes asking:
"Are we still going to hit August 15?"
rather than:
"Did Jean complete Jira ticket ABC-234?"
That is a significant difference between managing projects and managing people's task lists.
Your Monday board
This also gives us our first clue about what might eventually change in Monday.
Your current portfolio has broad timelines.
For example:
Suppression de Mogador
April 2026 ───────────────── January 2027
That tells you the project exists for approximately nine months.
But imagine instead seeing:
Suppression de Mogador
Health: 🟡
Current milestone:
Replacement synchronization validated
Target:
September 15
Next milestone:
Production cutover
Target:
October 10
Suddenly you can understand the project without opening its entire task list.
We aren't modifying Monday yet, but this is one concept that will eventually influence the design.
Milestones and Dates
Milestones usually have target dates.
This is where something important happens with the problem you've already identified:
Your projects frequently get interrupted by operations.
Suppose:
Milestone:
Tracking implementation complete
Target:
August 15
August 15 arrives.
The milestone isn't complete because the owner spent eight days dealing with production incidents.
Don't simply change:
August 15 → August 30
and move on.
The missed milestone contains management information.
You want to understand:
Why did we miss it?
Possible reasons:
-
Scope increased
-
Estimate was wrong
-
Operational interruptions
-
Dependency wasn't available
-
Owner didn't execute
-
Requirements weren't clear
-
Priority changed
-
Technical problem appeared
Those causes require completely different management responses.
A milestone isn't only a deadline.
It creates a checkpoint where reality meets the plan.
Milestone vs Deadline
They're related but not identical.
A deadline says:
Something must happen by this date.
A milestone says:
The project has reached this meaningful state.
A milestone commonly has a target date:
Milestone: Data validation complete
Target: September 30
This gives you both:
What should be true + when we expect it to be true.
CTO Perspective
As you move higher in an organization, the level at which you manage should change.
An integrator might think about:
What code needs to be written today?
A project owner might think about:
What work needs to happen to reach the next milestone?
You might think about:
Which projects aren't reaching their milestones?
A CTO might think about:
Which strategic initiatives aren't delivering their expected outcomes?
Think of it as levels:
EXECUTIVE
Outcomes
↑
YOU
Projects / Milestones
↑
PROJECT OWNER
Milestones / Tasks
↑
CONTRIBUTOR
Tasks
This doesn't mean a CTO never looks at a task.
It means they shouldn't need to manage through tasks under normal circumstances.
Milestones also create accountability
Suppose one of your project owners says:
"The project is going well."
Your response can be:
"What's the next milestone?"
They answer:
"Data validation."
You ask:
"When?"
"August 20."
Then August 20 gives you an objective point to review.
Without milestones, project updates easily become:
"Still working on it."
"Making progress."
"Almost there."
"Waiting on a couple things."
Those statements are difficult to manage.
Don't create too many milestones
Milestones are supposed to simplify project visibility.
A three-month project probably doesn't need 25 milestones.
If every task becomes a milestone, you've recreated the task list.
A useful starting point might be around 3–7 meaningful milestones for many of your projects, depending on size and complexity.
The exact number isn't the important part.
Ask:
Would I care if this checkpoint wasn't reached?
If not, it probably doesn't need to be a portfolio-level milestone.
Questions to Ask
-
What are the major states this project must pass through before completion?
-
What's the next milestone?
-
Who owns reaching it?
-
What's its target date?
-
What must be true before we consider the milestone achieved?
-
Are we still confident in the target?
-
What could prevent us from reaching it?
-
If we missed it, why?
-
Was the cause scope, capacity, dependency, execution, or something else?
-
Am I managing the project through meaningful checkpoints or micromanaging individual tasks?
Meeting Scenario
Situation:
You ask a project owner:
"How's the project going?"
They respond:
"Pretty good. We completed about 18 tickets. There's still quite a bit left, but we're making progress."
This gives you very little useful information.
Possible response:
What's the next milestone we're trying to reach, and are we still on track for its target date?
They respond:
"The next milestone is production data validation on September 15. Development is nearly complete, but we're waiting on DevOps for the production environment, so September 15 is currently at risk."
Now you have something actionable.
The problem isn't:
"18 tickets completed."
The management information is:
Milestone at risk because of a cross-team dependency.
And because DevOps doesn't report to the project owner, that may be exactly the type of problem that should come to you.
Key Takeaways
-
Tasks represent work. Milestones represent meaningful progress.
-
Project owners should generally manage detailed tasks.
-
Managers should primarily manage projects through outcomes, milestones, risks, and blockers.
-
Good milestones describe verifiable states such as "QA accepted" rather than vague activity such as "working on QA."
-
Milestones should usually have target dates.
-
A missed milestone is useful management information and should trigger understanding of why it was missed.
-
Don't automatically move milestone dates without understanding the cause.
-
Too many milestones defeats their purpose.
-
Milestones help you manage multiple projects without micromanaging every task.
-
As leadership responsibility increases, management should increasingly move from tasks → milestones → outcomes.
Related Concepts
- Projects vs Operations
- Outcomes and Definition of Done
- Scope and Scope Creep
- Milestones vs Tasks
- Dependencies
- Capacity and WIP
- Project Health
- Portfolio Management