Tasks and projects: what’s the difference?

This is a lightly-edited repost of an article I published on my personal blog in 2021.

I was talking to a colleague recently about leading a volunteer group at work. One of the issues she mentioned was that the group sometimes has a hard time separating tasks and projects. If you look around, you’ll find plenty of blog posts (mostly from software companies trying to sell you their tool). Many of them share a similar adherence to the Project Management Institute’s definition of a project. While that can be useful, it’s more formal than necessary.

In my mind, the distinguishing factor is the number of states. Tasks have two states: “not done” and “done”. Projects have multiple states. This affects which tool I use for tracking. For tasks, I use a todo list application (Todoist, specifically) to track and plan. For projects, I use a Kanban board (Trello, generally, but Taiga for a few things). For particularly complex projects, I’ll add sub-projects or sub-tasks to track them more granularly. Sometimes I’ll link between them so that I remember to do a specific task that’s part of a project.

For example, I treat doing the dishes as a task. There’s not really an in-between state. Okay, there could be. Scrubbing, rinsing, and drying could all be distinct states. In practice, a dish moves between the three so quickly that it’s of no benefit to track the state. Doing the dishes is a single act in terms of my time. I’m not going to start and then pause midway through (barring my kids doing something that requires immediate attention).

Laundry, on the other hand, I treat as a project. It has distinct states of sorting, washing, drying, and folding. And each load traverses through those states independently. Unlike the dishes example, they don’t happen all at once. I’ll load the washer and then I have to wait until I can put the clothes in the dryer. It may take me several days to get it all done.

To use work examples, writing an email is a task. Yes, there’s a state of “writing” and I may not compose it all at once, but it’s essentially a single thing. Writing a release announcement is a project. First I write it, then it gets reviewed, then it gets scheduled.

This brings up another point about the states. Tasks change state in one direction, but projects can move between states. Once they’re done, they’re done. After I send an email, it’s done. New tasks may come as a follow-up, but those are new tasks. The release announcement may go back and forth between “writing” and “review” several times before it’s done.

The astute reader will notice that the states sound a lot like tasks. You can look at the laundry project as a collection of four tasks: sort the laundry, load the washing machine, load the dryer, fold the laundry. That’s a valid approach. For me, it makes more sense to think about it in states instead of a collection of steps.

Sidebar: why PMI’s definition is too formal

The Project Management Institute defines a project as “It’s a temporary endeavor undertaken to create a unique product, service or result.” While this is not unreasonable in the context of my conversation, the page goes on to add a lot of extra baggage. In common usage, a project is something that takes multiple steps to accomplish. The structure, process, and documentation of a Project™ are entirely unnecessary for how most people use the word.

This post’s featured photo by Thomas Bormans on Unsplash

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share