Project statuses: the standard set and when to use each

Most teams end up with four project statuses: not started, in progress, on hold and done. That set covers almost every situation, and the reason to know it is not that it is clever. It is that teams who start inventing statuses on day one usually end up with fourteen of them and no idea which ones anyone still updates.

This is about project statuses rather than task statuses. A task status tells you where one piece of work is. A project status answers a different question, usually asked by someone who is not doing the work: is this project fine, or does it need attention.

The standard set

Four statuses, and what each one is really saying.

Not started

The project exists, it has been agreed, and nobody has begun. This is worth keeping separate from in progress, because the two invite different questions. A project that has not started asks "when does it start". A project in progress asks "will it land".

Some teams call this planned or upcoming. The name matters less than keeping it distinct.

In progress

Someone is actively working on it and nothing is blocking them. This ends up being where most projects live, which is why in progress on its own is not very informative and why teams keep wanting to split it. Resist that for as long as you can. If you need to know how far along something is, that is a progress measure, not a status.

On hold

Work has stopped, deliberately, and the team knows why. A client has gone quiet, a budget is being reapproved, the work is waiting for a season or an event. On hold is a decision.

The value of this status is that it stops a paused project from looking abandoned in a list, and it keeps someone honest about restarting it. If a project has been on hold for six months, that is worth knowing.

Done

Finished and closed. The one thing to decide here is what done means for your team, because it varies more than people expect. Delivered, invoiced, signed off and archived are four different moments, and picking one avoids an argument later.

Blocked, and whether you need it

Blocked is the fifth status most teams add, and it is the one worth thinking about rather than copying.

Blocked and on hold sound similar and mean opposite things. On hold is a choice. Blocked is a problem: the work cannot continue because something outside the team's control is in the way. Separating them is useful precisely because blocked should be uncomfortable to look at. If a project sits blocked for a month, someone should be doing something about it.

If nothing is genuinely blocking your team, do not add the status. An unused status is worse than no status, because it makes everyone slightly less sure the others mean anything.

Project status types beyond the basic set

Once the standard four are working, the requests start. Here are the additions that tend to earn their place, and the ones that do not.

Usually worth adding:

• Cancelled. Different from done in every way that matters for reporting. If cancelled projects get marked done, your completion numbers become fiction.
• In review. Genuinely useful for agencies and anyone with a client approval step, because waiting on someone else is a real state that neither in progress nor on hold describes well.

Usually not worth adding:

• Percentage-style statuses like started, halfway, nearly done. That is progress information pretending to be a status, and it goes stale immediately because nobody updates it.
• Person-specific statuses like with design, with legal. That is an assignment, not a status.
• Anything that duplicates a date you already have. Overdue is not a status, it is what happens when a due date passes.

The test worth applying to any proposed new status: can someone look at it and know what to do next? Blocked passes, because the answer is unblock it. Halfway fails, because the answer is nothing in particular.

RAG status, and how it fits

Plenty of organisations run red, amber, green alongside or instead of the statuses above. RAG answers a different question, and the two are not really alternatives.

A status says what stage the project is at. RAG says how it is going. A project can perfectly well be in progress and red, and that combination is exactly the one a weekly review wants to surface.

The problem with RAG on its own is that it is a judgement, so it drifts. Amber in particular becomes a place to put anything you do not want to explain. If you use it, write down what each colour means. Something as simple as "red means the deadline will move unless something changes" is enough, and it is more than most teams have.

How many statuses should you have?

Four to six. Below four you lose the distinction between not started and in progress, or between on hold and blocked, both of which are worth keeping. Above six, people stop being able to hold the list in their head and start defaulting to whichever option is at the top of the dropdown.

The failure mode is not too few statuses. It is a long list where half the options have not been used in a year, which quietly teaches everyone that the field is decorative.

Making them actually get used

A status field nobody updates is worse than no status field, because people trust it and it is wrong. What tends to work:

• One person owns the status per project. Not the whole team. Shared responsibility for a single field means nobody does it.
• Update it at a fixed moment. A weekly review works well, because it turns updating statuses into a two-minute pass over a list rather than something to remember continuously.
• Make the list visible. If nobody looks at the project overview, nobody keeps it accurate. The status is only worth maintaining if someone reads it.
• Delete statuses you do not use. Once a year is fine. It takes a minute and it keeps the rest meaningful.

Setting project statuses in Breeze

Every project in Breeze carries a status, and the defaults are done, ready, on hold and blocked. You can set one from the projects page or in the project settings, and the projects page shows status alongside due dates, colours and progress, so the overview answers the how-is-this-going question in one place.

If the defaults do not match how your team talks, you can define your own with custom statuses. Worth doing if your team already has words for these states, and worth skipping if you are only renaming things for the sake of it.

Statuses answer where a project is. They do not answer how much is left, which is what project progress charts are for. Most teams want both, and it helps to know which question you are trying to answer before adding another field.

Once statuses are in place and being kept current, the next thing someone usually asks for is a summary of them. That is a different job with its own conventions, and writing a project status report covers it.

Project statuses were introduced in Breeze in January 2019 and have been part of the projects page since.

Written by Lucas

Lucas writes content at Breeze and specializes in project management, team collaboration, and practical workflow advice. He helps small teams and growing businesses plan projects, track progress, and keep work organized by sharing clear, actionable guides.