I was in a client meeting recently to clean up a project list that had stopped moving. There was plenty on it, all of it important, and almost none of it actually finishing. If you have ever looked at a list that grows faster than it shrinks, where things go on and then just quietly live there, you know exactly the feeling in that room.

Halfway through the tidy-up, one of the client's own team said the sentence that made the whole hour make sense. He said they were good at starting projects and not good at finishing them, and the reason was that they never agreed what a finished project actually looked like before they started one.

That was the diagnosis, and it was correct.

Teams that start lots of projects and finish few usually share one root cause: they never define what "done" looks like before they begin. If you have not described the finish line, you can never declare that you have crossed it, so work never leaves the list and simply accumulates. The second, closely related cause is that not everything on the list is a project. A project does something different from normal work and then hands the result back to business as usual, so it has a clear end. Ongoing work like a recurring audit or a monthly reconciliation never ends by design, so it is not a project and should not sit on a list of things you are trying to finish. It still needs to be watched, but on a dashboard with a tolerance you review, not clogging the project list. Fix those two things and a stuck list starts moving again.

Below is how to define done so projects can actually close, how to tell a real project from business as usual, and the simple parking trick that made the client's list honest again.

The reason an undefined project never ends is almost mathematical. Finishing is the act of comparing where you are against where you said you would get to. If you never said where you were getting to, there is nothing to compare against, so there is no moment that counts as complete. The work just continues, or stalls, or drifts, and it stays on the list forever because nobody can honestly tick it off.

One of the client's projects showed this perfectly. They had set out to reconcile their inventory so the system matched the physical stock. Sensible goal. But nobody had defined done. Was done 100% reconciled? One person thought so. But some items, rentals and edge cases, might never reconcile perfectly given how the system worked. So the project had no achievable finish line, which meant it could sit on the list indefinitely, always making progress, never arriving.

The fix is to have the "what does done look like?" conversation before the work starts, not after it stalls. In that case, done might be defined as 98% reconciled with a documented reason for the rest, because getting from 98 to 100 could take five years while getting to 98 takes a month. A finish line you can actually reach beats a perfect one you never will.

When a project is already underway and nobody can say what done is, the fix is a short reset. As I said to the client, you do not need a big ceremony. Even twenty or thirty minutes to re-run the kick-off and agree what you are actually going after is enough to turn a drifting project back into a finishable one.

> If your project list has stopped moving and you would like to fix the underlying operating rhythm, I am gauging interest in a small group programme that works through exactly this over a few months. Reply "ACCELERATOR" on any of my emails and I will keep you posted.

The second discovery in that meeting was even more common, and it was quietly making the whole team feel more stuck than they were.

Roughly half the items on the list were not projects at all. The clearest example was an audit. The team receives audits regularly, as a normal part of billing. This particular one was bigger than usual, so it felt significant, and someone had put it on the project list. But an audit that happens every month is not a project. It is the job. Putting it on the project list did nothing except make the list longer and the team look more behind than they really were.

The test I use is simple. A project does something different from business as usual, and at the end it hands the result back to business as usual. It has a beginning, a middle, and an end. Ongoing work has no end by design, because its whole nature is to keep happening.

The audit was a good stress test of the rule, because the team debated it in real time. One person pointed out that if the audit came back with an unfavourable result and forced them to change their procedures, then a project might actually appear: a piece of work to update the process, make the change land, and return the new way of working to business as usual. That is exactly right. Responding to the audit is business as usual. Overhauling your process because of what the audit found would be a project, because it does something different and then ends.

The same came up with the inventory reconciliation. Once the team realised it was going to be an ongoing monthly activity handled in a regular meeting, they recognised it was business as usual, not a project, and took it off the list.

Getting this distinction right is not pedantry. A project list that is stuffed with permanent, never-ending work is a list you cannot trust, because you can never clear it. Keeping ongoing work off it is what lets the list mean something.

There is a trap on the other side of this, and it is worth naming. When you decide something is business as usual rather than a project, the temptation is to simply take it off the list and move on. That is fine, as long as the thing still gets watched. Important ongoing work that nobody is watching is how quiet failures happen.

The inventory reconciliation was a good example. It was being handled in a regular meeting by two named people, so for now it was caught. But I pointed out the obvious risk: what if one of those people leaves? The safe answer is not to keep it on the project list. It is to put a metric on a dashboard that you review in your regular operations meeting, with a tolerance. You are fine while reconciliation stays above a certain level; if it drops below the tolerance, that is your signal to jump on it.

So the rule has two halves. Ongoing work comes off the project list, and ongoing work that matters goes onto a dashboard with a tolerance you actually review. One without the other either clutters your list or drops the ball.

The last thing that made a visible difference took about two minutes to explain and transformed how the list felt.

The team had a stage-and-gate setup, where work moves through stages: ideas at the top, then approved, then live, and so on. Their problem was that everything half-started had been dragged into "live", so the live list was enormous and most of it was not actually being worked on. It looked like chaos because it was showing every stalled thing as if it were active.

The fix was to move stalled items back a stage. If a project could not move forward, because it was waiting on another piece of work, or the owner had three bigger priorities in front of it, we moved it back from live to approved. Nothing was deleted. The work was still there, still visible, still going to happen. But the live list now showed only what was actually being worked on right now.

The effect on the room was immediate. As I put it at the time, a shorter live list helps with the mental clutter. When the live list tells the truth about what is actually in motion, people can see their real priorities instead of drowning in a wall of everything that has ever been suggested. You do not have to do this constantly; when there are only a handful of live items you can just adjust dates. But when the live list has swollen with stalled work, parking things one stage back is the fastest way to make it honest again.

Underneath all of this sits a principle worth stating on its own, because it prevents the mess forming in the first place.

The whole point of a staged list is that certainty should increase as work moves down it. At the top, in the ideas stage, things are vague and unproven, and that is fine, because anyone can drop an idea in. As work moves down towards live, it should get more and more defined, until by the time something is live you are completely certain what you are going after and what done looks like.

The gates between stages exist to stop you kicking off too much work too early. An idea does not get to jump straight to live. Someone looks at it, asks a few questions, and decides whether it is worth exploring further, whether it needs a business case, and whether the person who raised it is even the right person to work on it. That gate is cheap, and it saves you from a list full of half-baked work that was never really thought through.

Most teams do not lack ideas. They lack gates. Adding a light one at the top, an idea box that gets a quick review before anything becomes real work, is what stops the list filling with things nobody ever agreed to properly start.

If you want the wider operating rhythm this sits inside, my thinking on running a proper [operations review](https://www.meetimeservices.com/blog/how-to-organise-microsoft-teams-small-business) and keeping work visible covers the surrounding structure.

Here is the whole approach in order, so you can run it against your own list.

For every project, agree a finish line you can actually reach and describe in a sentence. If you cannot describe done, it is not ready to be a project yet.

For each item, ask: does this do something different and then end, or does it just keep happening? Keep the never-ending work off the project list.

Ongoing work still needs watching. Give it a metric and a tolerance you review in your regular meeting, so you know if it drifts.

If something is not being actively worked on, move it back a stage. Nothing is lost, and the live list starts telling the truth about what is really in motion.

Let anyone raise an idea, but review it before it becomes real work. Increasing certainty as work moves down the stages is what stops you starting more than you can finish.

Get this right and your list becomes a tool instead of a source of dread.

The live list shows only what is actually being worked on, so people can see their real priorities. Every live project has a finish line someone can describe, so it can actually be completed and cleared. Ongoing work sits where it belongs, watched on a dashboard rather than clogging the project list. And new ideas pass through a light gate, so you are not constantly starting things you were never going to finish.

Compare that with the default, where the list grows without end, everything important sits on it forever, half of it is not even a project, and the sheer length of it makes a capable team feel like they are failing when they are not. Same team, same work. The difference is knowing what done looks like, and knowing what is a project in the first place.

Why does my team start projects but never finish them?

Usually because you never agreed what a finished project looks like before starting. Finishing means comparing where you are against where you said you would get to, so if you never defined the finish line, there is no moment that counts as done. The work then stays on the list indefinitely. The fix is to define an achievable, describable finish line before any work becomes a live project.

How do I know if something is a project or just business as usual?

A project does something different from normal work and then hands the result back to business as usual, so it has a clear beginning, middle, and end. Business as usual, like a recurring audit or a monthly reconciliation, has no end by design because its nature is to keep happening. If a thing never ends, it is not a project and should not sit on a list of things you are trying to finish.

Where should ongoing work go if not on the project list?

Onto a dashboard with a tolerance that you review in your regular operations meeting. Ongoing work that matters still needs watching, but it does not belong on the project list because you can never clear it. Give it a metric, decide the level at which you are comfortable, and treat a drop below that tolerance as the signal to act.

What should I do with a project that has stalled?

Move it back a stage rather than leaving it cluttering your live list. If it is waiting on another piece of work or sitting behind bigger priorities, park it at an earlier stage like "approved". Nothing is deleted and it stays visible, but your live list then only shows what is actually being worked on right now, which reduces the mental clutter.

How do I stop my team starting more than it can finish?

Put a light gate in front of new ideas. Let anyone raise an idea, but review it before it becomes real work, checking whether it is worth exploring, whether it needs a business case, and who should do it. Certainty should increase as work moves from idea to live, so that by the time something is live you are sure what you are doing and what done looks like.

If your project list has stopped moving and your team feels great at starting and hopeless at finishing, there are two ways I can help.

If you would like to work on it over time alongside a small group of other business owners, I am gauging interest in an Accelerator programme that builds exactly this kind of operating discipline. Reply "ACCELERATOR" on any of my emails and I will keep you posted on timing.

If you would rather have someone look at your specific setup directly, it might be worth a conversation to see if we would be a good fit to work together. [Book a discovery call here](https://www.meetimeservices.com/how-we-can-help).

---

Gavin Jones is the Founder and Director of MeeTime Ltd., where he helps small and medium businesses get far more out of the Microsoft 365 tools they already pay for. He has run dozens of Microsoft 365 assessments and implementations for SME teams, and writes and records regularly on making work simpler.