What does done look like?

[RomanS]

I have just read an interesting article on “Definition of Done” in this blog: https://medium.com/@paralloid/the-definition-of-done-and-its-impact-on-productivity-dd34b1126f73. The author lists all the criteria that must be met for a project to be considered completed. He sees these points as part of a project checklist. However, they could also be seen as sub-projects. I found this idea interesting, as GTD often raises the question of how to deal with sub-projects. What do you think of the author's idea? Do you prefer checklist entries in the sense of a “Definition of Done” or sub-projects or a mix of both?

Translated with DeepL.com (free version)

 

[mcogilvie]

When I read the article, it was obvious that the author was not using GTD terminology: giving a presentation was a “task” put on a “task list for the week.” You can substitute “project” for “task”, but seeing project brainstorming presented as if it was a definition of completion seemed wrong. The idea that there must either be subprojects or a checklist seems overly constrained. If I am giving a presentation at 2 pm Friday, then I am generally giving it even if all the boxes are not checked. Absent the need for follow-up, after I give it, it’s done.

 

[Y_Lherieau]

I have just read an interesting article on “Definition of Done” in this blog: https://medium.com/@paralloid/the-definition-of-done-and-its-impact-on-productivity-dd34b1126f73. The author lists all the criteria that must be met for a project to be considered completed. He sees these points as part of a project checklist. However, they could also be seen as sub-projects. I found this idea interesting, as GTD often raises the question of how to deal with sub-projects. What do you think of the author's idea? Do you prefer checklist entries in the sense of a “Definition of Done” or sub-projects or a mix of both?

Translated with DeepL.com (free version)

Thank you for sharing the article on the “Definition of Done.” It’s a thought-provoking take on productivity, though it approaches the topic from a linear, task-oriented perspective that doesn’t fully align with the principles of GTD.

In GTD, every project is defined as any desired outcome that requires more than one action to complete bound to the timeline of less than 12 months or so. What the author calls a checklist for the “Definition of Done” could be seen as the Next Actions required to move a project toward completion. GTD views these actions not as fixed sub-projects but as dynamic and evolving steps that reflect the reality of work—where clarity often emerges as we make progress.

Wearing my project manager/coach hat—whether managing corporate initiatives or personal projects—I find that projects are rarely ever fully completed. More often than not, I don’t take the time to sit down and properly close a project (conduct lessons learned, archive files, or celebrate milestones). Many projects evolve, morph, or transform into new ones, even without us consciously recognizing it. They feel more like living objects rather than static entities.

From this perspective, a master closing checklist—or, as I like to think of it, a proper “postmortem blessing”—wouldn’t be a bad idea. This would ensure that we not only finish the immediate deliverables but also wrap up loose ends, reflect on lessons learned, and transition smoothly into whatever the project evolves into next.

In GTD terms, while such a checklist could serve as a reference list or a someday/maybe trigger for reviewing outcomes, it would also complement the system by encouraging conscious closure—a step often skipped in the hustle of moving on to the next project.

 

[Matt_M]

I have just read an interesting article on “Definition of Done” in this blog: https://medium.com/@paralloid/the-definition-of-done-and-its-impact-on-productivity-dd34b1126f73. The author lists all the criteria that must be met for a project to be considered completed. He sees these points as part of a project checklist. However, they could also be seen as sub-projects. I found this idea interesting, as GTD often raises the question of how to deal with sub-projects. What do you think of the author's idea? Do you prefer checklist entries in the sense of a “Definition of Done” or sub-projects or a mix of both?

Translated with DeepL.com (free version)

For clarity/edification: this is not new per se. The term "Definition of Done" (DoD) comes from the Agile world from over 25 years ago. Specifically, the Scrum flavor of Agile.

DoD's usually are achieved through having explicit acceptance criteria, common standards & conventions, and generally agreed upon best practices. This is all done in a team and organization setting whereby the person(s) defining the work, doing the work, testing the work, and validating/approving the work are not always guaranteed to be the same person(s).

In essence, this is all overkill for an individual. It's really a technique designed and best suited for teams and organizations. Trying to use it an individual level is a lot of extra overhead for not a lot of benefit, if any at all.

Keeping things simple, dead simple, is optimal for individuals since there's not a lot of formality needed for most tasks that an individual has (i.e. "Pay electric bill" is self-evident and self-describing for what "done" is). It can be beneficial to have some pre-canned checklists or notes on what "done" looks like in more detail for some tasks. However, it's usually for the extreme ends of the spectrum of the types of tasks: the new, unknown, and complex tasks and the very familiar, mundane, and monotonous tasks that are delegating/doing when "brain dead". Usually these are less than 30%, combined, of the total amount of tasks in a given system.

Overall, a "Definition of Done" is a good technique but an individual's tasks are the wrong context for execution/implementation of it.

 

[cfoley]

Many of my project notes have a checklist of what I think done looks like.

This is not the same as actions or next actions. It is more a vision of what I want the world to look like.

It's imperfect. Often I call the project complete without all the checkboxes being ticked.

My favourite generic definition of done for a software feature is "deployed to the user with error detection and usage metrics in place."

 

[Tom_Hagen]

I have just read an interesting article on “Definition of Done” in this blog: [...]

I rarely need to use subprojects. I use Evernote and in each note describing the Project I have a section at the top of the Final Result type where I use a checklist. I try to define the conditions for completion quite precisely. For example, if my project concerns a request from a user (IT), my last condition usually sounds something like: I have received confirmation from the user that XYZ is working correctly. In the case of subprojects, I would create a note about the main project and in the Final Result section I would list all subprojects for marking / checking and any additional conditions.