‹ All posts
Behind the buildOct 20, 20266 min read

Project teams that learn deliverable deadlines over timeEvery finished project teaches the next plan.

Ask a team how long the next deliverable will take, and you get the time it should take. Ask how long the last five took, and you get a different answer. Most teams never ask the second question, because nobody wrote the answers down.

Why deadlines slip the same way twice

Late projects are rarely late for new reasons. The scope grows a little after the kick-off. A client decision stays open. A client goes quiet for two weeks. Another team holds a key you need. Each of these shows up in a meeting long before the deadline. And each is forgotten by the time the next project is planned.

Psychologists call it the planning fallacy. We plan from the best case, even when we know our past cases. The fix is not more discipline. It is a record of what happened, kept without extra work.

Step 1: record how each project ended

When a project endsIn the app
Brand auditDue Oct 3 · finished Oct 9

Parley Notes suggests: Finished late

On timeLateCancelled

Why late?

Scope changedClient delayedOur capacityDependenciesOther
Confirm
One tap to confirm. The reason is what the next plan learns from.

When a project is done, Parley Notes suggests the outcome from the due date. You confirm it with one tap, or change it. If it ran late, you pick why: the scope changed, the client was late, the team ran out of time, something else held it up, or another reason.

That is the only extra step. Everything else is already in your notes: every task from the calls, with its owner, its date and the meeting it came from.

Step 2: find your patterns

After a few projects, patterns appear. Parley Notes puts the signals from your meetings next to how your projects really ended: scope changes, open decisions, quiet clients, tasks that waited on someone else.

Scope changes per projectIllustrative
Finished on time6 projects
1 avg
Ran late4 projects
3 avg
Clinic rolloutLive now
3 so far
012345
Each dot is a finished project. The line marks the average. Clinic rollout already looks like the projects that ran late.

In this example, the projects that finished on time averaged one scope change. The ones that ran late averaged three. That is not a rule for every team. It is a rule for this team, learned from its own projects.

Step 3: warn early

When a live project starts to look like the ones that ran late, you hear about it this week, not at the deadline. Clinic rollout has had three scope changes since the kick-off. The warning shows the latest one, word for word:

"Can we also add the second ward before go-live?"Dr. Hale · Weekly check-in, Dec 7

Now you can agree what moves before you say yes.

Step 4: plan the next one from your history

The same record makes the next plan honest. When you set dates for a new project, you see how long the same kind of deliverable took your team before.

How long your deliverables really takeIllustrative
DeliverableYou plannedIt tookProjects
Kick-off recap1 day1 day6
Proposal or price list5 days9 days6
Client sign-off3 days8 days5
Go-live after sign-off10 days16 days4
"It took" is the middle value across your finished projects.

You still pick the date. But you pick it knowing that client sign-off has taken you eight days, not three. Over time, the plans and the outcomes move closer, and the team stops being surprised by its own work.

What the team gets

  • Fewer surprises at the deadline.
  • A reason behind every warning, linked to the meeting where it started.
  • Plans that start from your own history, not from hope.
  • No timesheets and no forms. One tap when a project ends.

Try it on your next meeting.

Download freeSee Projects
Keep readingBlog