We’ve all done it. When asked about the status of a project task, we reply:
“It’s in progress.”
That’s when the stakeholder pauses, shakes their head, and says,
“That’s what you said last week.”
So what do we really mean when we say a task is “in progress”?
It might mean:
- It’s a large task and we’re working on one of many sub-components
- We plan to start work later this week
- We ran into a snag and it’s going to take longer than expected
- We started, but had to reassign resources elsewhere
- We’re doing rework after failing testing
- Or the uncomfortable truth: we don’t actually know the status
To the stakeholder, however, “in progress” often means one thing:
you don’t have a clear handle on the work.
The problem isn’t the phrase itself—it’s that it hides too many realities.
The Real Issue: Undefined Status
“In progress” becomes a black hole when it’s used to describe everything between “not started” and “almost done.”
The fix is simple: define clearer, mutually exclusive task states.
For example:
- Not Started
- In Progress (actively being worked this reporting period)
- Blocked (include reason and owner)
- In Testing
- Complete
One key addition here is “Blocked.”
If teams don’t have a safe, standard way to report blockers, they’ll default to “in progress” to avoid scrutiny. That’s how work disappears.
Task Definition Guidelines
Clear task sizing is one of the easiest ways to prevent status ambiguity.
Here are some practical guidelines:
- No task should be longer than 80 hours
- No task should be smaller than 8 hours
- Work scheduled for a single day should not exceed ~7 hours
- Tasks should not exceed a single reporting period (e.g., 40 hours for weekly, 80 hours for bi-weekly)
These aren’t arbitrary rules. The goal is visibility and predictability:
Smaller, well-defined tasks move faster and are easier to track—reducing the chance they sit endlessly “in progress.”
Rethinking Status Reporting
Many teams use percentage-based reporting:
- Task started – 50%
- In testing – 75%
- Complete – 100%
While simple, percentages are often subjective and misleading. Two people can interpret “50% done” very differently.
If you use percentages, tie them to objective milestones, not gut feel. For example:
- 0% = Not started
- 50% = Development complete
- 75% = Testing started
- 100% = Work accepted and complete
An even better alternative in many cases is to rely on clear status states plus expected completion dates, rather than percentages alone.
Make Status Updates Specific
The fastest way to eliminate “black hole” reporting is to require structured updates.
Instead of saying “in progress,” every update should answer:
- What was completed since the last report?
- What is being worked on next?
- Are there any blockers? (Include impact and owner)
- Has the expected completion date changed?
If none of these answers change from one report to the next, that’s not neutral—it’s a signal that needs attention.
Project Reporting That Actually Informs
Project managers should ensure status reports show movement, not just labels.
Effective reports:
- Highlight progress made since the last update
- Call out blockers and risks clearly
- Show changes in timeline or scope
- Avoid repeating static “in progress” labels without explanation
A simple rule:
Every “in progress” task should demonstrate change—progress, risk, or resolution.
The Bottom Line
You won’t fix vague status reporting with guidelines alone.
The real shift happens when teams stop accepting vague updates.
When “in progress” is consistently followed by:
“What changed since the last update?”
clarity improves almost immediately.
“In progress” doesn’t have to be a black hole—but without definition, discipline, and accountability, it almost always becomes one.
Comments are closed.