Nobody sets out to build an unrealistic timeline.
The dates get discussed. People nod. The plan gets approved and shared, and for a week or two everything looks fine. Then it starts sliding, and the slide never really stops.
Here’s the thing worth noticing: that plan usually wasn’t wrong everywhere. Most of it was fine. It failed in one specific way, and if you know where to look, you can spot it before you commit.
A realistic timeline has to pass three tests: achievable, meaning the work fits in the time; agreed, meaning the people doing it actually believe it; and maintained, meaning it still describes reality this week, not just the week it was written.
Miss any one and the plan comes apart. Most plans pass two and fail the third, which is exactly why the failure is so hard to see coming.
Let’s take them one at a time.
Test one: is it achievable?
This is the maths test. Does the work fit in the hours available?
Almost every plan fails this in the same way. It assumes a full week that nobody actually has.
Think about your own week. Standups, one-to-ones, planning, someone’s question that took forty minutes, the support ticket, the interview you’re on the panel for. Real focused work usually lands somewhere between 50% and 70% of a working week. Plan someone for forty hours and you’ve overcommitted them before the first day.
Then there’s the other-projects problem. Your plan sees one project. Your developer is on three. Nothing on the timeline knows about the other two, so it happily books her at full capacity while two other plans do exactly the same thing.
And there’s the work nobody writes down. Review. Rework after review. Waiting for a client to reply. Testing that finds something. Each of these is invisible on most charts, and together they routinely account for a third of a project.
How to test it?
Pick your busiest person and add up everything the plan expects from them in one specific week. Compare that to the hours they realistically have after meetings and their other commitments.
Doing this by hand is tedious, which is why most people skip it. Some tools will do it for you — in Jira, ProScheduler’s schedule board gives each person their own row and colours their week by how loaded they are, green for balanced and red for over-allocated, counting work from every project rather than just the one you’re looking at. That last part matters, because the other-projects problem is invisible any other way.
If the numbers don’t fit, the plan isn’t achievable — and no amount of encouragement will change that.
The fix isn’t always a longer timeline. It might be fewer things at once, or one more person, or scope that moves. But it starts with admitting the sum doesn’t work.
Test two: is it agreed?
This is the belief test. Do the people doing the work think it’s possible?
Not “did they approve it.” Approval is easy to get and tells you very little. The question is whether they’d bet on it.
Plans fail this test quietly, because the moment for honesty is a bad moment to be honest. Someone senior says “so we’re looking at the end of March?” The room goes quiet. The one person who thinks it’s tight now has to speak up, in front of everyone, and be the reason the date slips. Most people don’t. They say “should be okay” and hope.
That’s not dishonesty. It’s just how meetings work. The cost of objecting is immediate and personal; the cost of staying quiet arrives months later and gets shared out.
There’s a subtler version too. Sometimes everyone genuinely agrees — to different things. The sponsor hears a commitment. The manager hears the best case. The team hears a rough target. One document, three readings, and nobody discovers the mismatch until the date arrives.
How to test it?
Ask each person the same question privately. “What are the odds we hit this?” You’ll get straight answers one-to-one that you’d never get in a group. If someone says sixty percent, that’s useful information, not a problem — and it’s information the meeting was never going to give you.
Then ask what would have to change to make them comfortable. People usually know. They’ve just never been asked in a setting where saying it felt safe.
Test three: is it maintained?
This is the freshness test. Does the plan still describe what’s actually happening?
Here’s what makes this one sneaky: a plan can pass both earlier tests and still fail this one. It was achievable in March. Everyone believed it in March. It’s now May, three things have changed, and nobody has touched it.
Plans decay fast. Someone leaves. Scope grows by one “small” request. A dependency arrives late. Each change is small enough to absorb, so nobody updates the chart and after five of them the plan is describing a project that no longer exists.
The reason this happens isn’t laziness. Updating a plan means writing down that things have moved, and in a lot of teams that reads as failure. So the chart stays green, everyone privately knows better, and the gap between the plan and reality grows until it can’t be hidden.
How to test it?
Look at when the plan was last changed. If a project has been running for two months and the timeline hasn’t moved at all, that’s not stability. Nothing runs exactly to plan for two months. It means the plan stopped tracking reality a while ago.
The habit that fixes this is small: a fifteen-minute check every week or two. What moved, what’s new, what’s now at risk.
It also helps to save a baseline at the start ProScheduler and most serious planning tools let you do this so the original dates sit alongside the current ones. Then drift is something you can see rather than something you argue about. It also makes the update conversation easier, because you’re pointing at a comparison instead of delivering bad news.
There’s a step after that most people skip: telling each stakeholder what they actually need to know, in the format they need it in. Your PM wants the risk flagged in Slack. Leadership wants a one-line status, not a Jira export. Customers waiting on a fix want a changelog entry, not an internal ticket ID. Writing all of that by hand, every time something shifts, is its own part-time job. This is where tool like Automated Release Notes & Reports for Jira fits: it turns what’s actually moving in Jira into release communication tailored to each audience, whether that’s a status update, a changelog, or a stakeholder-facing report, so keeping people informed doesn’t quietly become the thing that falls off the weekly list.
Passing two and failing one
Most plans don’t fail all three tests. They fail one, and the pattern tells you a lot.
- Achievable and agreed, but not maintained. A good plan that went stale. Common on longer projects. It feels fine right up until someone compares it to reality.
- Achievable and maintained, but not agreed. The numbers work on paper, but the team never bought in. Motivation is low, problems get reported late, and nobody flags risk early because it isn’t really their plan.
- Agreed and maintained, but not achievable. The most dangerous combination. Everyone is enthusiastic, everyone is updating diligently, and the maths never worked. This one runs longest before it breaks, because the energy in the room looks like health.
If you’re wondering which applies to you, the failure you’re least aware of is usually the one.
Running the tests on your plan
You can do all three in under an hour.
- Achievable — take your busiest person, one week, and check the hours actually fit
- Agreed — ask three people privately what odds they’d give the date
- Maintained — check when the plan was last updated, and whether that matches how much has changed
None of this requires new software or a new methodology. It requires being willing to hear an answer you’d rather not hear, which is genuinely the hard part.
One last thing
Realistic doesn’t mean cautious. It isn’t about padding every task or refusing to commit to anything.
A realistic timeline is simply one that’s likely to happen. The work fits. The team believes it. It still describes the project you’re actually running.
That’s a higher bar than most plans clear but it’s a much lower bar than predicting the future, which is what people often think they’re being asked for. You don’t need to be right about everything. You just need a plan that’s honest about what it’s assuming, and willing to change when those assumptions do.
