Using a Kanban Board for Project Management Beyond Software

A kanban board for project management is a shared view of work: cards moving through a few explicit stages, from request to done. It works outside software when the columns match how the work actually moves, each column has a cap, and someone owns whatever card is stuck. You can see what is in progress this week and what is blocking it.

A spreadsheet can list tasks. A board also shows the queue in front of each person and which work has sat still.

What a kanban board for project management is (and is not)

A kanban board is a set of columns and cards. A card is one piece of work with a clear finish, and a column is a stage that work has to pass through. The point is flow: start less, finish more, and see where things wait.

That makes it different from a task list, a Gantt chart, or a sprint board.

A task list is a pile. It won't tell you which items are waiting on a review, a client, or a vendor. A Gantt chart is a date plan. It helps when tasks have hard dependencies and a fixed end date, and it goes stale as soon as a dependency slips and nobody redraws it. A sprint board resets on a timer and commits the team to a batch. A project management kanban board stays up, and new work enters when there is room.

People take the next card when they have capacity instead of getting a fresh pile every Monday. Atlassian's kanban guide describes the same core: visualize the work, limit what is in progress, and manage the flow.

Use a board for a stream of similar items, like campaigns, client requests, hiring steps, content, or operations changes. Use a dated plan for one effort with a fixed sequence and an external deadline. Plenty of teams keep both: the board runs the week, and the plan holds the few dates that are real.

A board beats a list when work arrives continuously, more than one person touches each item, and the waiting takes longer than the doing. A post goes from brief to draft to edit to design to publish. A facilities request goes from intake to quote to approval to scheduled to done. The columns make "sitting in someone's inbox" visible. If one person finishes their own work, a personal list is enough. And twelve columns with no limits won't change what ships.

Design the board around the work

Copying "To Do / In Progress / Done" is fine for a weekend. It breaks down once the work involves a review, a client, or an outside party. Name stages you could point at in real life.

Columns that match the handoffs

Write down the path a finished item took last month. Every handoff that regularly stalls gets its own column. Stages that always happen in the same hour can be merged.

For internal operations, this set works well: Inbox, Ready, Doing, Waiting, Done.

For a content or campaign team: Brief, Draft, Edit, Design, Scheduled, Published.

If you need to see who owes the next move, split Waiting into "Waiting on client" and "Waiting on us." One "In Progress" column hides that difference, and the stand-up turns into guesswork.

Kanban board examples from software and ops teams are patterns to borrow from. Take a column shape you like and rename it if your work isn't tickets and pull requests.

Cards, owners, and exit rules

One card per deliverable. "Q3 campaign" is a project; "Landing page copy for the Q3 campaign" is a card. If a card needs several people at different times, split it.

Every card needs an owner for its current stage, who either moves it or says why it can't move. Put the requester, a real due date if there is one, and a link to the source on the card. The card points to the work. The document lives somewhere else.

Write an exit rule for each column. "Edit" is finished when a named editor has approved it, which may be later than when the author feels done. "Ready" only accepts work once the audience, the asset, and the deadline are filled in. Without exit rules, cards drift backward.

WIP limits

A WIP limit caps how many cards can sit in a column. People tend to skip it, and it's the part that turns the board into a management tool.

Start smaller than feels comfortable. A column with one person working in it often caps at 2. A review column often caps at 3, because review queues rot. When a column hits its cap, the next move is to finish or unblock a card there, not to pull a new one.

Limits feel rude for the first week. Someone will sit idle while a review is stuck, and that idle time is the signal: help with the stuck card, or chase whoever is blocking it. If you raise the limit because the column is full, you lose the signal.

Three policies

Decide what may enter the inbox, and what belongs on a dated plan or a "not now" list instead. Decide who may pull the next card. Decide what "blocked" means, and how quickly a blocked card gets named out loud. When anyone can grab any card, the easy ones move and the awkward ones sit.

A worked example: a three-person client team

A lead, a writer, and a designer serve four retainer clients. Work comes in by email, through a shared channel, and on a weekly call. The lead used to keep a private list and hand out work on Monday, and cards died in "with the client."

The columns are Inbox, Ready, Writing, Design, Client review, Done. The limits: Ready 5, Writing 2, Design 2, Client review 4. Inbox has no cap and gets emptied daily. A card enters Ready only with a client, a deliverable, a due date, and the source link. Anything in Client review for more than five business days gets a chase from the lead. Done means the file is in the agreed place or the page is live.

On Monday the inbox has nine items from two clients, and the lead spends twenty minutes on it. Four are clear and move to Ready. Three are duplicates or questions, so they get a reply and no card. The last two stay in Inbox with one open question each and don't go to Ready yet.

Writing already holds two posts, so the writer doesn't pull a third. The writer finishes one and moves it to Design, which had a free slot. Now the designer is at the cap, so the next finished draft waits in Writing. Everyone can see that wait on Tuesday instead of being surprised by it on Thursday.

Client review holds four cards, and one has been there six days. The lead sends the chase before anyone pulls new work. Two cards come back with small edits and return to Writing as the same cards. A rewrite only becomes a new card if the original was accepted and the new request is extra scope.

By Friday, Done has seven cards and two are still in Client review. The team can say which client, since when, and what was asked. Nobody keeps the private list anymore.

These counts illustrate a team this size and aren't a benchmark. If a column is always full, that's a staffing problem or a problem with the client agreement. The board makes it visible, but setting the policy is still up to you.

How the work should move

Kanban flow is about the movement more than the picture. Three habits keep a non-software board honest.

Pull, don't push. Someone takes the next card when they've finished one and the next column has room. A manager who tops up a column "so people stay busy" is rebuilding the task pile.

Walk the board from right to left. Start with the column closest to done, then the blocked cards, then new pulls. Going left to right steers the conversation toward what people started.

Age the cards. A date or a mark on anything that has sat five days in one column is enough. Handle the oldest blocked card first. You don't need a statistics package to notice a review that has been open since last month.

Refill Ready twice a week, using the priorities you already have: client commitments, real dates, and the cost of waiting. The board doesn't invent priority. What it does is stop item eight from starting while items one through three are unfinished.

Common ways boards fail:

• Columns named after departments, so every card waits on "Marketing" and nobody owns it.
• A Done column nobody trusts, because done still means "probably needs another pass."
• Cards so large they sit in Doing for a month.
• One board per person and no shared board, so handoffs stay invisible.
• Limits that exist on a slide but not on the board.

Choosing a kanban project management tool

A kanban project management tool has four jobs. It shows the board to the people who move cards, makes WIP limits obvious, keeps enough history to tell how long a card sat in a column, and lets someone file a request without a training session.

A simple board is enough when the team is small and you archive Done every month. Free kanban board options cover that, usually with less history and weaker permissions. Trello is easy to learn but gets awkward when engineering and everyone else have to follow one strict workflow. Jira suits teams that already use it; keep the columns few, or a coordinator ends up working inside someone else's system. Notion sits next to your docs, but extra views pile up until "done" depends on which database you opened. Keep one source board.

Some teams outgrow a board that is only a picture. Requests still start in chat, on a call, or as an error, and someone retypes them onto a card. Falrow is a workspace built for that loop: messages, call notes, and errors become tickets with stages and triage, and the roadmap is counted from those tickets. The ticket workflow is what replaces the retyping. How the delivery loop runs covers the rest, including cycles and forecasts. It's in private beta, with access by request. You don't need it to run the board described above. It only becomes worth it when the board works fine but the work still starts in five other tools.

Whoever builds the board, give it an owner and review the columns once a month. No tool will fix a Done column that means "we hope so."

FAQ

Can a non-software team use a kanban board for project management?

Yes. The whole method is cards, stages, a cap on started work, and a visible wait. Marketing, hiring, agencies, and internal ops already run on repeated handoffs, so rename the columns after those handoffs. Leave out sprint ceremonies unless you have a reason to batch work into fixed weeks.

How many columns should the board have?

Enough to show each real wait, and no more. Five to seven still fits on one screen. Merge stages that always happen together, and delete any column that exists only because a template had it. Add a column when cards keep stalling for a reason you can't see, such as legal review or client approval.

What WIP limit should you start with?

Roughly one or two cards per person in the active column, with a slightly higher cap on review. For three people, that often means two in Doing and three or four in Waiting. Treat the first numbers as a guess; you'll know within a week whether they fit. Tighten any limit that never binds, and don't raise one just because the column is full.

How is this different from Scrum?

Scrum plans a fixed sprint, commits to a batch, and reviews that batch at the end. A kanban board takes new work when there's room and measures progress by what finished and how long it waited. Scrum fits a team that can protect a planning rhythm. A continuous board fits interruptions, client requests, and small operational changes. A weekly replenishment meeting gives you a rhythm without turning the board into a sprint.