The 14-Status Workflow That Nobody Used
Two years ago, I spent an entire weekend designing what I thought was the perfect project workflow for our consulting firm. It had 14 statuses. Fourteen. I mapped them on a whiteboard, drew arrows between them, color-coded the transitions, and documented every single rule about when a project should move from one status to the next.
Here they are, because I think you deserve to laugh at them: Lead, Qualified, Proposal Sent, Proposal Accepted, Scoping, Scoped, Scheduled, In Progress, In Review, Client Review, Revisions, Final QA, Delivered, and Closed.
I presented this to my team of eight people on Monday morning. They nodded politely. I set it up in our project management tool. I wrote a one-page guide explaining each status. I even made a Slack bot that reminded people to update their project statuses every Friday.
Three weeks later, every single project was marked "In Progress." Every one. My beautiful 14-status workflow had collapsed into a single status because that's what everyone defaulted to when the system was too complicated to bother with.
Why Workflows Fail (It's Not Laziness)
My first reaction was frustration. Why couldn't people just follow the process? It wasn't that hard. You finish scoping, you move it to "Scoped." Simple.
But then I actually watched what happened during a typical day. A consultant would finish a call with a client, have 10 minutes before the next meeting, and try to update the project status. But wait, is this project in "Client Review" or "Revisions"? The client gave feedback on the call but didn't formally send revision requests. So is it still in review? And actually, we're also waiting on scope clarification for another phase, so does part of the project go back to "Scoping" while the rest stays in "Revisions"?
By the time they thought through all of this, their next meeting had started. So they left it at "In Progress" and moved on.
The problem wasn't my team. The problem was that I'd designed a workflow that required careful deliberation at every transition. In a busy service company, where people jump between client calls, deliverables, and internal meetings all day, "careful deliberation" is a fantasy. Your workflow has to work in the cracks of someone's day, in the 30 seconds between meetings, or it won't work at all.
The Three-Status Starter That Actually Works
After the 14-status disaster, I stripped everything back. I went to my team and said, "Forget what I built. If you could only have three statuses for a project, what would they be?"
The answers were almost unanimous: Not Started, In Progress, and Done.
That felt too simple. Embarrassingly simple. I resisted it for a week. Then I tried it. And something interesting happened. People actually updated their project statuses. Consistently. Without reminders. Because the decision was trivial. Is work happening on this project? In Progress. Has all the work been delivered and accepted? Done. Is it waiting to begin? Not Started.
Within a month, I had more accurate data about our project portfolio than I'd ever had with the 14-status system. Not more detailed data, but more accurate. And accurate is worth far more than detailed.
When to Add Complexity (and How to Do It Without Breaking Everything)
Three statuses worked as a foundation, but after two months I noticed our team starting to ask for one specific addition. They wanted a way to distinguish between projects that were actively being worked on and projects that were waiting on the client.
This was a real pain point. A consultant might have four "In Progress" projects, but two of them were blocked because the client hadn't sent assets, approved designs, or responded to questions. Those projects weren't really in progress. They were in limbo. And the consultant was getting blamed for not moving them forward when the bottleneck was entirely on the client's side.
So we added one status: On Hold (Client). That's it. One addition. Our workflow became Not Started, In Progress, On Hold (Client), and Done.
This taught me a principle I now follow religiously. Never add a status because it might be useful. Only add one when the team is actively asking for it because the current options don't describe a real situation they encounter regularly.
Since then, we've added one more: Review. This is for projects where the deliverable has been submitted and we're waiting for the client to approve it. Different from "On Hold" because we're not blocked on missing information. We're waiting on a decision. Our team wanted this distinction because it changed their follow-up behavior. "On Hold" means chase the client for assets. "Review" means give them space but check in if it's been a week.
Five statuses. That's where we've been for over a year now. Five works for an eight-person team managing 20 to 30 active projects. It might not work for you. But I'd bet that whatever number you need, it's closer to five than to fourteen.
Making the Path of Least Resistance the Correct Path
Here's something I learned from behavioral design, and it applies directly to project workflows. People don't follow processes because you tell them to. People follow the path of least resistance. If the easiest thing to do is also the correct thing to do, compliance happens automatically.
With the 14-status workflow, the path of least resistance was to leave everything as "In Progress" because any other choice required thought. With the 5-status workflow, the path of least resistance is to update the status correctly because the options are obvious and the decision takes two seconds.
But this principle goes beyond just status counts. Think about where and when you're asking people to update workflows.
We used to ask consultants to update project statuses at the end of the day. They never did. By the end of the day, they were tired, they'd forgotten the details, and they just wanted to close their laptop. So we moved the prompt to immediately after a client meeting. Our project management tool sends a notification after each meeting that says, "Quick update on Project X?" with the five status options right there. One click. Done. People do it because it takes five seconds and it's happening at the moment when the project status is freshest in their mind.
I also removed every unnecessary field from the status update form. The old system asked for a status, a progress percentage, a note, and an estimated completion date. Every time. The new system asks for a status. That's it. If they want to add a note, they can. But the only required action is one click on one of five buttons.
Involving the Team in Design (Not Just Rollout)
One of the biggest mistakes I made with the 14-status system was designing it alone. I assumed that as the operations lead, I knew best how projects should flow. I didn't. I knew how I thought they should flow. My team knew how they actually flowed.
When I rebuilt the workflow, I started with a 30-minute meeting. I put the question to the team: "What information about a project's status would help you do your job better?" Not "what statuses should we have?" That's an abstract question that leads to abstract answers. But "what do you need to know?" is concrete.
One consultant said, "I just need to know if I'm waiting on the client or if the client is waiting on me." Another said, "I need to see which projects are actually moving and which ones are stalled." A third said, "I want to know when something is finished so I can stop thinking about it."
Those three answers gave me the entire workflow design. Active vs. waiting. Moving vs. stalled. Open vs. closed. The five statuses we landed on map directly to these needs. And because the team helped design them, they felt ownership over the system. It wasn't something imposed on them by management. It was something they built together.
Documentation That Lives Inside the Workflow
I used to write process documentation in a Google Doc and share the link with the team. I might as well have printed it out and filed it in a cabinet in the basement for all the good it did. Nobody reads standalone documentation. It's too far removed from the moment you actually need it.
What works is embedding guidance directly into the workflow. Tooltips in the project management tool that explain what each status means. A one-sentence description visible when you hover over each option. "On Hold (Client) means we're waiting on the client to provide something before we can continue. Use this when you've requested information, assets, or a decision and haven't received it."
We also use default templates for notes when a status changes. If someone moves a project to "On Hold (Client)," the note field pre-populates with "Waiting for client to provide: ___." They just fill in the blank. This gives us useful context without requiring people to compose a note from scratch every time. Most people will type three words to fill in a blank but won't write a full sentence from nothing.
The Workflow Audit: Checking If Your Process Is Actually Working
Every quarter, I do a quick workflow audit. It takes about an hour and tells me whether the system is still working or has started to decay.
I look at three things:
Status distribution. If 80% of projects are "In Progress" and everything else is nearly empty, the statuses aren't being used properly. The distribution should roughly match reality. If you know that about 30% of your projects are typically waiting on client input, the "On Hold" percentage should be in that neighborhood.
Status staleness. I check for projects that haven't had a status change in more than two weeks. In our business, no project should sit in the same status for more than ten business days. If it does, either the status is wrong (and nobody updated it) or the project is actually stalled and nobody noticed.
Team feedback. I ask three questions: Is there a status you want that doesn't exist? Is there a status that exists that you never use? Is updating project statuses annoying, tolerable, or easy? If anyone says "annoying," I need to figure out why and fix it.
This audit has prevented us from backsliding. In the early months, I caught that one consultant was using "Review" and "On Hold (Client)" interchangeably. A quick conversation clarified the distinction, and the data cleaned up. Without the audit, that confusion would have spread.
What I'd Tell You If You're Starting From Scratch
Start with three statuses. Seriously. Not Started, In Progress, Done. Use them for at least a month. Watch what frustrations emerge. Those frustrations will tell you exactly which statuses to add.
Ask your team, not your management books, what they need to know about a project's state. Design the workflow around their real daily decisions, not around an idealized process map.
Make updates take less than ten seconds. If it takes longer, people will skip it. If it takes less than ten seconds, people will do it because it's not worth the mental energy of deciding to skip it.
Never add a status "just in case." Every status you add multiplies the cognitive load of every status update. Five options is a glance. Ten is a pause. Fifteen is a burden. And burden leads to "In Progress" for everything.
And be patient. The right workflow is the one your team actually uses, not the one that looks impressive on a whiteboard. I know because I've built both, and the impressive one is gathering dust while the simple one runs our business.
