The Four Reasons Deadlines Slip That Have Nothing To Do With Effort

The team worked hard and the date still moved. That is the frustrating version of a missed deadline, and it is the common one. Deadlines slip for four reasons that have nothing to do with how hard anyone tried: dependencies nobody wrote down, scope that grew a little at a time, work sitting in review queues, and people counted as full time who are not.

All four are visible on the plan before they bite. You just have to know what they look like.

One: dependencies nobody wrote down

Every plan has tasks. Most plans do not have the waiting.

A task needs an approval, an account, a file from a client, a decision from someone on leave, access to a system. None of these are work, so none of them get an estimate, and all of them can hold a task for days.

What it looks like early: a task whose description contains the words "once we have". If the thing you are waiting for has no owner and no date, that is not a dependency, that is a hope.

The fix is to give the waiting a line of its own on the plan, with a name and a date, the same as any task.

Two: scope that grew quietly

Nobody added a feature. Somebody asked for the report to also show last month, and somebody else said the form should handle the second language, and each one was ten minutes.

Small additions do not feel like scope because they arrive one at a time in conversation, not in a change request. By the time they add up to a week, they are spread across twenty messages and no single one looks like the culprit.

What it looks like early: work being done that does not map to a line on the plan. If you ask what someone did yesterday and the answer is not on the plan, scope grew.

The fix is boring and it works. Write down every addition, however small, in one visible place, with a rough size. Nobody has to say no. The list itself starts the conversation.

Three: review queues

A task is finished in an hour and delivered a week later, because it sat waiting for review, approval, sign off or a client's attention.

Queues are the most underestimated part of any plan because everyone estimates the doing and nobody estimates the waiting. On a plan where five tasks each need one reviewer, that reviewer is the actual constraint, not the five people doing the work.

What it looks like early: one person's name appearing as approver on many lines. Or a plan with no review step at all, which usually means the review will still happen and just is not planned.

The fix is to name the reviewer, agree a turnaround, and treat review capacity as a resource that runs out.

Four: part time people counted as full time

The plan says a person is on the project. Their week says they are also on two others, plus support, plus hiring, plus a client call that runs long.

This is the most common structural error in planning, because availability is assumed rather than checked. Someone at half capacity finishes a five day task in ten days, which looks like slowness and is arithmetic.

What it looks like early: a plan that adds up to more person days than the people on it actually have. Or a plan that never mentions leave, in a month that contains a holiday.

The fix is to plan against real available days, including leave, and to say out loud what share of a week each person actually has. Whatever protection the plan needs on top belongs in a buffer line you can defend rather than hidden inside each task.

Reading the plan before it bites

Take any plan you are running and ask four questions.

• Which lines depend on something outside the team, and does each of those have a name and a date?
• What has been added since the plan was written, and where is that written down?
• Who reviews, and how long does review take?
• How many days does each person really have this month, after leave and their other work?

If you cannot answer all four in a few minutes, the plan is not wrong yet, but you cannot see the parts that will make it wrong. The questions get harder still when the work is something your team has never done.

Where the answers usually live

In most companies these four answers sit in four different systems. The plan is in one tool, leave is in the HR system, approvals are in email, and the extra requests are in chat. Nobody can see the whole picture, so nobody spots the slip early, and a slip nobody mentions is where the real cost of a missed deadline starts.

SicherOne is our enterprise workspace. It puts project management, HR and AI agents on one set of records, so a project board knows who is on leave, and an agent works with full context rather than a fragment. A human approves an agent's output before it ships. It is sold per seat, the modules are separable, and private models can be self hosted.

Putting the plan and the availability in the same place does not remove the four causes. It makes them visible while there is still time to act, which is the whole game.