Why Your HR Leave Calendar and Your Project Board Disagree

Your HR leave calendar says three people are off next week. Your project board has all three assigned to sprint work. Both are being maintained by people doing their jobs properly. The reason your HR leave calendar and your project board disagree is that they are updated by different people, at different moments, for different reasons, and nothing forces them to agree.

The drift is not a discipline problem. It is a structural one, and it starts earlier than most teams think.

Where the drift starts

Follow a single leave request and you can see every gap.

• Request. Someone asks for time off, often in a chat or a form. At this point the project board knows nothing, and correctly so, because the leave is not confirmed.
• Approval. A manager approves it in the HR system. This is the moment the information becomes real. It is also the moment it stops moving, because the HR system has no reason to tell the project tool anything.
• Planning. A sprint or a delivery plan gets built, sometimes weeks later, by someone who was not in the approval loop.
• Discovery. The absence is noticed on the day, or the day before, usually by whoever was waiting for the work.

The gap between step two and step four is where the damage happens. Nothing went wrong at any single step.

Why each system is behind in its own way

The HR calendar is usually accurate but slow to matter. It records what was approved. It does not know which sprint that person was in, which client was promised what, or that they are the only person who can sign off a release.

The project board is usually current about work and stale about people. It reflects what someone typed last, and the person typing is thinking about tasks rather than staffing. Assignments stay pointed at whoever normally does that work, absent or not.

Both are correct within their own scope. The error only exists in the space between them, which nobody owns. The same unowned space produces the handover gap between recruiting and the first sprint.

How far behind the board usually is

There is no universal number here, and anyone quoting one is guessing. What you can measure is your own lag, and it is worth doing.

Pick the last ten approved leave requests. For each, find the date the leave was approved and the date the project plan first reflected it. If the plan never reflected it, count that separately, because that is the worst case and usually the most common one.

That distribution is your real drift. Teams that run this exercise are typically surprised in two ways: the average is longer than expected, and a meaningful share never got reflected at all.

What breaks when a sprint is planned on stale leave data

The obvious failure is a missed commitment. The quieter failures cost more.

• Silent reassignment. Work moves to whoever is around, without a decision being made. Nobody records that someone's own tasks just got pushed, which is the same failure as two teams booking the same person for one week.
• Handover that never happens. The person going away did not know their tasks were in the sprint, so nothing was written down before they left.
• Client dates set on fiction. A date agreed in a plan that assumed full capacity is not a date. It is a hope.
• Trust erosion. After a few of these, managers stop believing the board, and start asking people directly. That works, and it does not scale.

Fixes that do not require new software

If you are staying with two systems, close the loop deliberately.

• Make approval the trigger. The manager who approves leave updates the plan in the same sitting. It takes a minute and it is the only reliable moment.
• Run a leave check at planning. One named person reads the HR calendar aloud before commitments are made. Boring, effective.
• Look further than the sprint. Check leave for the sprint after next as well, because that is where handover time needs to be booked.

These work as long as the person doing them is present and not busy. The same is true of skills matrices that do not rot after three months: they hold only while somebody tends them. That is the honest limit of process fixes.

The structural fix

The reason this problem is stubborn is that two systems hold two halves of the same fact. Any join between them is either a person or an integration, and both need maintaining.

SicherOne removes the join by putting project management and HR on the same records. When leave is approved it is already part of the data the board reads, so a board knows who is on leave without anyone syncing anything. There is no drift to measure because there are not two copies.

Whichever route you take, start by measuring your own lag. A team that knows its board is routinely a week behind on staffing will plan very differently from one that assumes the board is right.