Short answer: Teams stop updating the project tool when updating costs them more than it returns. That trade is usually created by one of seven specific things — the update has no reader, the shortcut is faster, the board doesn't match the real workflow, the form asks too much, the plan is already wrong, some people have no access, or nobody ever closes the loop. Each has a different fix, so the first job is telling them apart rather than asking people to try harder.
The pattern
It goes the same way almost everywhere. A team adopts a tool, uses it properly for three or four weeks, and then the board starts drifting from reality. Tasks sit in "In Progress" that shipped a fortnight ago. A column fills with cards nobody has touched. Someone asks in chat what the status of something is — inside a system whose entire purpose is answering that question.
The usual response is a reminder in the standup, which works for about a week.
That response assumes the cause is discipline. It rarely is. People maintain systems that pay them back and abandon systems that don't, and they do this quite rationally. If your board is stale, something in it is charging more than it returns. The seven causes below are the ones worth telling apart, because they look identical from the outside and have completely different fixes.
1. The update has no reader
Symptom: People update when asked and stop when not asked.
If a status field is only ever read by the person who wrote it, maintaining it is pure cost. Teams sense this quickly, even if nobody says it out loud.
Fix: Make one visible artefact depend on the board — a weekly summary, a client-facing view, a capacity chart — and let people see it. The moment someone's update shows up somewhere that matters, the cost-benefit flips. If you cannot name a downstream consumer of a field, delete the field.
2. The shortcut is faster
Symptom: Decisions and status live in chat; the board is a slower copy.
Sending "done, moving to the API bit" in a chat takes three seconds. Opening the tool, finding the card, moving it, and writing a comment takes ninety. People will take the three-second path every time, and they are right to.
Fix: Shorten the path or accept the shortcut and connect it. Either put updates one click from where people already are, or route chat into the tool so the fast path also records. Fighting the shortcut with willpower loses.
3. The board doesn't match how work actually flows
Symptom: Cards pile up in a column that doesn't mean anything, or a stage exists that people skip.
Most boards are copied from a template and never adjusted. If your work really goes brief → draft → internal review → client review → revisions → ship, but the board says To Do / Doing / Done, then every card sits in "Doing" for two weeks and the board stops carrying information.
Fix: Watch one real piece of work end to end and write down the stages it actually passes through. Then make the board that. A board that mirrors the real flow updates itself almost as a side effect, because moving a card is how you tell someone it's their turn.
4. The form asks too much
Symptom: People create tasks outside the tool, or don't create them at all.
Every required field is a toll on the person adding work. Estimate, priority, epic, labels, due date, assignee — each is defensible alone, and together they mean adding a small task takes longer than doing it.
Fix: Make everything optional except a title and an owner, and add fields back only when a specific report actually breaks without them. Most teams discover they need two of the eight fields they were requiring.
5. The plan is already wrong
Symptom: Updating stalls right after a deadline slips.
This is the subtle one. When a plan is still roughly right, updating it is bookkeeping. When it is badly wrong, updating it means publishing that fact — moving nine dates and having a conversation about why. So people quietly wait for the plan to become right again, and it never does.
Fix: Make re-planning routine and cheap rather than an admission. A standing fifteen-minute weekly slot where dates move without anyone defending them removes the reason to hide. Boards go stale in silence far more often than in disagreement.
6. Some people can't get in
Symptom: A recurring set of people ask for status by email.
Under per-seat pricing, teams ration accounts — the finance lead, the client contact, the part-time designer don't get one. Those people then rebuild their view of the project elsewhere, and their questions pull everyone else out of the tool with them.
Fix: Count the people who need to see the work, not the people who work in it, and get them access. If that is expensive under your current pricing, the pricing model is the constraint, not your team's discipline.
7. Nobody ever closes the loop
Symptom: Old cards never die. The board grows and grows.
If nothing is ever archived, the board becomes a landfill and reading it costs more each week. Once scanning it takes real effort, people stop scanning it, and shortly after that they stop feeding it.
Fix: Archive on a schedule, not on inspiration. Anything untouched for sixty days either gets a next action or gets closed. A board's value comes from what is not on it as much as what is.
How to tell which one you have
You can find your cause in a week without a survey.
- Look at the last twenty updates. All from one or two people? You have a reader problem (#1) or an access problem (#6).
- Find the last three decisions the team made. If they happened in chat and never reached the board, that is #2.
- Check where cards sit longest. One column holding everything for weeks is #3.
- Try adding a task yourself and count the required fields. More than three is #4.
- Check when updating slowed down. If it stopped the week a deadline slipped, that is #5.
- Count the people who ask for status by email. More than one, repeatedly, is #6.
- Look at the oldest open card. If it is older than a quarter, that is #7.
The weekly ritual that actually holds
Rituals survive when they produce something someone wants. Twenty minutes, once a week, in this order:
- Close what is done. Anything shipped gets closed now, not later.
- Move dates that are already wrong. Without discussion of blame. This is the step that keeps #5 from returning.
- Name what is actually next. Three to five items, not the whole backlog.
- Say who is unavailable. Leave, holidays, someone at a conference. This is what makes the next week's plan survive contact.
- Send the summary somewhere. A channel, an email, a client. This is the step that gives every other step a reader.
Where a tool can help — and where it can't
No tool fixes causes #1, #3, #5 or #7. Those are habits, and a tool that promises otherwise is selling.
Where product design genuinely matters is #2, #4 and #6: how many clicks an update takes, how many fields are mandatory, and whether everyone who needs to see the work can. Those are decisions the vendor made before you arrived.
For what it's worth, this is why Poitim prices per team rather than per seat and keeps required fields to a title and an owner — cause #6 and cause #4 are the two a vendor can actually remove for you. The other five are yours, and no purchase will change that.
Frequently asked questions
How do I get my team to update the board? Asking harder rarely works for long. Find which of the seven causes applies — most commonly the update has no reader, or the shortcut through chat is faster — and remove the cost rather than adding pressure.
Is a stale board a sign of a bad tool or a bad team? Usually neither. It is a sign that updating costs more than it returns for the people being asked. Three of the seven causes are product decisions and four are team habits, so the honest answer depends on which one you have.
How often should a project board be updated? Often enough that someone would notice if it stopped. In practice that means a light touch when work actually changes state, plus one structured weekly pass. Daily updates without a weekly reader produce noise, not accuracy.
Should status live in chat or in the project tool? Chat is where status is produced and the tool is where it should be kept. The teams that manage this well either connect the two or accept a short daily lag. Trying to ban status from chat does not work.
What is the first thing to fix on a dead board? Archive aggressively, then give the board one reader. A shorter board that produces a weekly summary someone actually reads recovers faster than any process change.