If it takes three years, it isn't a project

First contact, survey, consultation, planning, tender, execution. On a building or restoration job, three years can pass between the first of these steps and the last. That’s what it said in an email from a firm whose team oversees jobs like these. The five questions below it all came down to one: where do you put undertakings that stay relevant but need neither attention every week nor a next action?

On the project list, they bloat the weekly review. On the Someday/Maybe list, they drop out of sight. Alongside that runs a shared document library in SharePoint, sorted by year, country, location and building, and how it fits together with your own list is an open question.

That sounds like a sorting problem. It’s a question of definition, and the answer starts with an uncomfortable observation: most of these undertakings were never projects.

Three entries posing as projects

In GTD, a project is a desired outcome that takes more than one step and can be completed within a year. Each part of that definition rules something out.

The area. I often see entries like “Client XY” on project lists in companies. They never get finished. A client, a building or a subject is an area of responsibility, with documents attached to it and a steady stream of new projects hanging off it. So the question of what to do with the project when there’s nothing to do at the moment doesn’t arise. It was never one.

The goal. An undertaking that runs for three years fails on the one-year limit alone. It’s a goal, with projects underneath it.

Someone else’s project. It’s on your list because you know about it, but the person responsible for it is someone on your team.

So the line in the email, that many undertakings need neither attention nor a next action, doesn’t describe a problem with the list. It is the diagnosis. An undertaking with no next action that isn’t waiting for anything either is not active, however important it is. Being relevant is not a status.

Long-term projects are goals with projects underneath

Say your company is bidding to build an opera house. “Win the tender” is a project: a clear outcome, several steps, done in a matter of months. “The opera house is built” is not. Getting there takes years, and many people work on it. That’s a goal, and underneath it projects take shape one by one, such as the east wing or the stage machinery, each with its own outcome and one person who answers for it.

With restorations, the phases tell you where to cut. “Survey complete, findings with the client” is one project, “Tender published” the next. The phase currently under way is on the list; until it’s done, the next one sits as a plan in the project support material. You keep the undertaking as a whole with your goals and look at it once a quarter. A goal with no project under it stays a dream. A goal that sits on the list as a project itself slows the whole list down.

Active, waiting or dormant

Active doesn’t mean something happens every day. It means there’s a next action or an entry on the Waiting For list. After a bid goes in, months can pass before the award decision. The project stays active the whole time, with a single entry: “Client: award decision, bid submitted 12 March”. In the weekly review, it costs you a glance.

Someday/Maybe inside an active project, on the other hand, doesn’t exist. Ideas for a later phase belong in the project support material. If the next action is only missing on paper, write it down. If there really isn’t one and you’re not waiting for anything, it’s an area or an undertaking for later. Someday/Maybe is for what hasn’t started yet: the opera house, for as long as nobody puts it out to tender.

Whose weekly review a project belongs in

Whether an undertaking that runs for years belongs in the weekly review is only the second question. The first is: whose?

Every project has exactly one owner. Not two, not “the team”. If that’s you, the project goes on your list. If it’s the site manager responsible for the east wing, it goes on hers, and how she runs it is her business. On your side, there’s an entry for her on your agenda list: “East wing: status, upcoming dates, where it’s stuck”. You go through it the next time you talk.

That’s how I always handled it with my staff: fixed check-ins, usually once a week, more often with some, every two weeks with others, and in between they could come to me with questions at any time. Their projects weren’t on my list and didn’t come up in my weekly review. When you work with professionals, you don’t need close supervision. You need a reliable slot where the status gets put on the table.

Jörg, who leads a team himself and reports upwards, has a valid objection: sometimes someone else’s project carries a deadline of your own. Senior management wants the status by the end of the month, and you’re the one who owes it. Then something does go on your list, only it isn’t the site manager’s project. It’s your own: “East wing status report delivered to senior management”.

Who owns it?	What’s on your list	When you look at it
you	the project with a next action	in every weekly review
someone on the team	an agenda entry for that person	the next time you talk
someone on the team, and you owe an outcome	your own project for it, plus an agenda entry	in every weekly review
unclear	next action: clarify ownership	straight away

If the list is still too long to get through after that, the sorting is done and a different decision is due: who can take projects over, and which ones you say no to. For freelancers, whose income depends on every contract, that’s especially hard going. There are still only twenty-four hours in a day.

Making sure dormant undertakings resurface

That leaves the undertakings that really are dormant: a client wants to extend, but not for a few years. There are two places for those.

A separate Someday/Maybe list for the company. Many people think you’re only allowed one. That’s not true. In my system, Someday/Maybe is a folder with several lists: personal plans split into summer and winter, plus one list just for the company’s future and dormant undertakings. The hard part isn’t setting one up, it’s looking at it reliably. Strictly by the book, Someday/Maybe goes into every weekly review. For dormant company undertakings, once a month is usually enough for me, sometimes once a quarter, and some lists I take out deliberately ahead of the next budget round, when it’s decided what gets money in the coming year.

The calendar. When I have a sense of when a client or an undertaking might be due again, I put a reminder there, say four months out: take another look at this project. It’s neither an appointment nor a task, but day-specific information, all-day and with no time attached. I pick it up over the course of the day or turn it into a next action.

Company files and your own system need clear boundaries

The document library in SharePoint is the company’s memory. Your system records what you’ve committed to, not which documents exist. The two are connected by a link: in SharePoint you get it via “Copy link” and put it in the note for the project. Copied documents go out of date the day someone carries on working in the original.

The same boundary runs between the personal and the professional, and it comes down to this: every project lives in exactly one place. What doesn’t work is double bookkeeping: company projects in your personal system, and the same projects again in the company’s. One version is always out of date, and at the crucial moment you don’t know which. If the company runs its projects on a shared board, that board is your project list for those projects. In the weekly review, you filter it by your name instead of copying it out.

Where it typically goes wrong

• Client names on the project list. “Client XY” demands a glance every week and never gets a tick. Over time you read straight past it, and along the way you miss the real project for that client.
• The whole undertaking as one project. No next action fits “Opera house built”. The entry sits still for months and produces the same uneasy feeling in every review.
• Every phase set up at once. If you enter all six phases at first contact, you have five projects on the list with no next action, and you get used to entries with nothing to do.
• Two owners. If the site manager and her boss both carry the same project, each relies on the other. Owned twice, in practice, means owned by nobody.
• Dormant undertakings with no rhythm. A Someday/Maybe list you look at whenever you happen to have time is a list you never look at. Without a fixed date, it turns into an archive you feel guilty about.

Common questions

How do I handle long-term projects in GTD?

In GTD, you keep anything that runs longer than a year as a goal, not as a project. Underneath it you set up projects that can be completed within a year, and the project list only holds what is being worked on right now. You look at the goal itself once a quarter.

Does a team member’s project belong in my weekly review?

No, a project belongs in the weekly review of the one person who owns it. As a manager, you keep an entry on your agenda list for that person and get the status at your regular check-in. If you owe an outcome yourself, such as a report to senior management, that’s a project of its own on your list.

Can a project be active and on Someday/Maybe at the same time?

No, a project is either running or dormant. It’s active as long as it has a next action or an entry on the Waiting For list. If it has neither, it belongs on Someday/Maybe or is really an area of responsibility.

Can I keep more than one Someday/Maybe list?

Yes, GTD doesn’t prescribe a single list, and a separate list for work undertakings alongside your personal one makes good sense. What matters is a fixed rhythm for each list, such as in the weekly review, once a month or before budget planning.

What’s the difference between a project and an area of responsibility?

A project is an outcome with several steps that can be completed. An area of responsibility, such as a client, a building or a subject, has no end: documents and a steady stream of new projects are attached to it. That’s why “Client XY” is an area and “Proposal submitted to Client XY” is a project.

---

Before your next weekly review, take your project list and write a single name next to each entry: whoever owns it. Anything with someone else’s name on it becomes an agenda entry for that person; anything that can’t be completed moves to your areas. Then count what’s left.

When your project list, the team board and SharePoint all run side by side, what’s usually missing isn’t discipline but a clear boundary between the systems. In a workflow setup, we draw those boundaries together and put the work already under way where it belongs. Write to me if you lead a team and your weekly review gets longer with every new contract.