Why Important Work Stays “Almost Done” for Weeks

Projects often seem to make little progress over time, even when teams are actively working on them. This phenomenon is driven by a lack of clear definition for what "done" truly means. Without a precise understanding of completion, projects can linger in an indefinite "almost done" status for weeks or months.

Software development teams are particularly prone to confusing activity with progress. Commits, pull requests, tickets, meetings, and other visible signs of work do not guarantee that the business outcome is achieved. A project can generate a lot of motion without actually completing its goal.

For a project to truly be considered finished, several key aspects need to be defined and addressed:

1. Unresolved decisions: Sometimes, the team is blocked not by implementation but by a decision that needs to be made. This could involve choosing an approach, determining scope, or deciding what to exclude. Until this decision is clarified, work continues around the edges without reaching a true end.

2. Unmanaged dependencies: Projects often rely on various factors such as other teams, vendors, data migrations, security reviews, content approvals, legal clearance, or leadership sign-off. When these dependencies exist but no one is accountable for resolving them, progress stalls.

3. Scope creep: As teams get closer to release, it's tempting to keep adding features or improvements. Each incremental request, while reasonable individually, can collectively undermine the project's completion. At some point, the team must decide when the version is done and that subsequent enhancements become new work.

4. Lack of shared ownership: Multiple departments or individuals may be responsible for different aspects of a project, such as engineering, product, operations, and leadership. While clear ownership of individual tasks is important, the project itself should have a single owner responsible for getting it to completion.

To combat these issues, projects should be treated more like state machines with well-defined states and clear exit conditions. For example, a project could progress through states like Defined, Owned, Dependencies Cleared, Execution Complete, Validated, and Closed. Each state should have specific criteria for moving forward, preventing indefinite limbo.

Ultimately, having a dedicated "Closure Role" or Integrator can be beneficial. This person is accountable for ensuring the project reaches a closed state, answering questions such as what the definition of done is, what remains outstanding, what is blocking progress, and when the project can be closed. By clearly defining what completion means and establishing a single point of ownership, projects can move past the frustrating state of being "almost done" and achieve true closure.