scoop

Promises in. Work done. scoopapp.co

← All insights
Operations

The 2 PM Promise: Why Daily Work Doesn't Fit Project Software

Jira and Asana are built for work that takes weeks. Most of what decides whether today went well was promised after lunch and is due before the shift ends.

Team ScoopFounding team4 Aug 20268 min read

There's a specific kind of work that almost no software serves well. It isn't strategic, it isn't planned, and it never appears on a roadmap. It is the sentence somebody says at 2 PM that has to be true by 5 — and it is, in most operating businesses, the work that actually decides whether the day went well.

What project tools assume

Jira, Asana, Monday and the rest are good software built on a coherent set of assumptions. Work is known in advance. It is big enough to be worth describing. It has an owner, an estimate and a place in a sequence. Someone plans it, someone works it, someone reviews it, and that cycle takes days or weeks.

Every one of those assumptions is false for daily operational work, and they're false in a way that compounds.

Project workDaily operational work
When it appearsPlanned in advanceMid-conversation, unplanned
How long it livesDays to monthsHours
Who describes itWhoever plans itNobody — it was just said out loud
UnitA ticket with fieldsA sentence
What failure looks likeA slipped sprintA truck leaves without the batch
Right toolJira, AsanaThe conversation it was made in
Two kinds of work that look similar and behave nothing alike

The arithmetic that decides adoption

There's a simple ratio underneath every failed rollout of task software into an operations team. Call it the recording tax: the time it takes to log a piece of work, divided by the time the work itself takes.

The workDoing it takesLogging it takesTax
Rebuild the payment module3 days2 min0.1%
Write and review a client report2 hours2 min1.6%
Send the revised quote to Patil10 min2 min20%
Confirm the dispatch time with the driver3 min2 min67%
The recording tax, at two minutes per ticket

Above the line, logging is obviously worth it and people do it without being asked. Below the line, no amount of policy will make it happen, because the person can see that writing it down costs more than just doing it. They are not being undisciplined. They are being correct.

If recording the task takes longer than doing the task, the task will not be recorded. No training fixes arithmetic.

Backlogs are the wrong shape

There's a second mismatch that shows up a month in, once a team has tried hard to use a project tool for daily work. Project tools accumulate. That's a feature: a backlog is a considered list of things worth doing eventually, groomed and re-prioritised.

Daily commitments don't work like that. “Dispatch batch 3 by 4 PM” is either true by 4 PM or it is history. Carrying it forward for three weeks doesn't make it more likely to happen — it makes a list that nobody can look at without feeling behind. Teams that push daily work into a backlog end up with hundreds of stale items, and then they stop opening the tool at all, which takes the *real* project work down with it.

This is why a short lifespan is a feature rather than a limitation. A promise made for today should be visible today, be chaseable today, and stop occupying anyone's attention shortly after. What matters is whether it happened, not that it stays on a list.

What to do instead

  1. Keep your project tool for the planning horizon. Roadmaps, releases, audits, anything measured in weeks. It's good at that and replacing it would be a mistake.
  2. Stop trying to push daily work into it. You will lose that argument every busy week, quietly, and blame the team for it.
  3. Track the daily promises where they are made — in the conversation, with no extra step for the person making them.
  4. Let them expire. If a promise for Tuesday is still sitting in a list in March, the list is lying to you.
  5. Judge it on one number: how often does a human have to chase another human for a status update? That's the number a fix should move.

Doesn't this just mean two tools instead of one?

Practically, most teams already have two — a project tool that the managers keep updated, and a chat where the actual day happens. The choice isn't between one tool and two. It's between two tools where one of them quietly doesn't work, and two tools where each does a job somebody can name. The second one is cheaper, even when it costs more.

Written by Team Scoop, Founding team, Scoop. General guidance on running a team, not professional or legal advice for a specific situation.

Scoop: the work chat that remembers

Ready to stop holding everyone's promises in your head?

Free to start · Ready in ten minutes · No card