[jonathanstrange]

Maybe this system works in a business environment where everything can be measured in terms of effectiveness such as achievements over time, but it doesn't work for me. It insists that projects need to have a fixed deadline. This is not true for creative professionals like me. If I'm writing a book, article, or a long-term software project setting a fixed deadline would be highly counter-productive. Some things are only finished when they are finished. Of course, this requires a certain amount of self-discipline, but that's something that no artificial deadline can give you anyway. Areas of responsibility are too unspecific to replace projects without a fixed deadline. Other activities could have a fixed deadline but shouldn't. To these belong small tasks that are part of a project that can be done whenever one feels in best shape doing it.

GTD recommends to set as few deadlines and calendar dates as possible, and I still think that's the right way to go. If you can, you should work items on your todo list in the order that best suits the context and current abilities.

[joekrill]

I don't see anywhere that the author is suggesting that deadline must be explicitly defined up-front, or even be fixed. If you're writing something, it _will_ be done at some point (or is expected to be).

[CGamesPlay]

His other writings on the topic are very explicit about setting deadlines on every project and goal. Though, I don’t fully agree with the GP. Thiago also advocates freely changing deadlines as desired, so the deadlines become more a scheduling and prioritization helper than a typical deadlines.

[jknecht]

A deadline is not the defining factor of a project; a clear definition of "done" is the defining factor. I have dozens of projects that have no specific deadline, but I know for sure when they will be done, because I will have achieved what I intended to do.

[saidajigumi]

Agreed. Thiago's introductory PARA writings do seem to imply a strict deadline, but like the parent, I use a concrete definition of completion ("completability") as the defining characteristic of a project. If I can't do this, then it's a major red flag and there's some deeper problem and the thing either isn't a project (e.g. it's an "Area" - something you to want to maintain a standard on over time) or it's not well defined enough yet and there's prior work needed.

Case study: Frederico Vittici of MacStories recently wrote about revising his own system to eliminate deadline times from his system as unnecessary overhead that he'd picked up long ago. It was a case of an item from "someone else's system" which was adding stress for no benefit.

All organizational systems are really custom-fit jobs. Look at others' systems and understand the individual techniques and how they fit together. Then apply those to your situation. This is a bit like the advice to not just take someone's complicated dotfile setup (vim, shell, etc.) and add it to your own wholesale. Instead to learn and apply piece-by-piece, understanding that sometimes several pieces must "go in together" to make everything work as intended. (this also applies 100% to every single software team's process in my entire career, btw.)

[slightwinder]

> Some things are only finished when they are finished.

That's how you end with never ending and dying projects. Projects which are dragging for years and decades because the creator just does not "feel it" and at the end abandon them and never releases them. Thinking about the end goal is especially in creative work highly relevant. And a deadline is a good tool for this, as it forces you to think about. And a deadline can be changed, if done with good reasoning.

> GTD recommends to set as few deadlines and calendar dates as possible

GTD also makes a great point about reviewing and analyzing. And a deadline is a tool to force one to review and analyze a project, it's state and goals.