In software and IT project forensics, being on schedule means your deliverables match the dates on a plan. Being on track means the work is converging on a viable outcome. The two are not the same. A project can be on schedule and already dead: milestones are green, burndown charts look fine, and the team is building the wrong thing, or building the right thing on a foundation that will not hold. This article is for the people who have to explain later why the plan said yes and the result said no.
This is not a motivational piece. It is a field guide to the gap between calendar compliance and actual progress, and to the failure patterns that live inside that gap.
What “On Schedule” Actually Measures
On schedule is a comparison between planned dates and actual dates. It is a variance metric. If the test plan was due Friday and it was approved Friday, the project is on schedule. If the integration milestone was set for the 15th and the build was deployed on the 15th, the project is on schedule. None of that tells you whether the test plan covers the right risks, or whether the integration build can survive contact with real data.
Schedule variance is easy to report and easy to game. Teams pad estimates. Managers redefine scope. Status meetings reward the phrase “no schedule impact.” Over time, the schedule becomes a document that is true in the same way a horoscope is true: it reflects what people wanted to hear, not what the system is doing.
The Green Dashboard Problem
Most project dashboards are built to show green. A milestone is green if the date has not slipped. A workstream is green if its tasks are within their planned windows. The dashboard does not measure whether the work is coherent, whether the architecture is stable, or whether the product owner still believes the requirements are correct. It measures whether the plan is being followed.
In post-mortems, I have seen dashboards that were entirely green two weeks before a project was cancelled. The schedule was healthy. The project was not.
What “On Track” Actually Means
On track is a judgment about trajectory. It asks a different question: given what we know now, is this work likely to produce a useful result within an acceptable cost and time envelope? That question cannot be answered by comparing dates. It requires looking at the substance of the work: the quality of the code, the stability of the requirements, the realism of the test coverage, the health of the team, and the distance between what has been built and what was supposed to be built.
On track is not a status. It is a forecast. And forecasts can be wrong. But a forecast based on evidence is more useful than a variance report based on a plan that was optimistic before it was written.
Signals That a Project Is On Track
- Working software exists early. Not a prototype, not a slide deck. Something that runs, even if it is small. The earlier real software exists, the earlier the project can collide with reality.
- Risks are being retired, not renamed. A risk that is “mitigated” by adding a meeting is not retired. A risk is retired when the team can point to evidence that the bad thing will not happen, or that the impact is now understood and bounded.
- Estimates are getting narrower. Early estimates are wide. As the team learns, the range between best case and worst case should shrink. If the range stays wide or grows, the project is learning that it knows less than it thought.
- Scope is being cut deliberately. Projects that are on track usually cut scope. They cut features that do not matter, they cut gold-plating, they cut work that exists only because someone put it in a plan six months ago. Projects that are merely on schedule tend to keep all the scope and hope for the best.
The Failure Pattern: Schedule as a Substitute for Progress
The most common failure pattern in software projects is not that people miss dates. It is that people hit dates and mistake that for progress. The schedule becomes the product. The plan becomes the proof. The project becomes a machine for producing status reports.
This happens for a reason. Schedules are legible. They can be printed, reviewed, and defended. Progress is messier. It lives in code reviews, test results, architecture decisions, and the quiet judgment of the people doing the work. When a project is under pressure, the schedule is the easiest thing to point to. “We are on schedule” sounds like an answer. It is usually a deflection.
Case Pattern: The Integration Mirage
A common version of this failure looks like this. A project is divided into workstreams. Each workstream has its own plan, its own milestones, and its own dashboard. Each workstream is on schedule. The integration milestone is at the end. When integration arrives, the pieces do not fit. The interfaces were never tested together. The data models do not align. The performance assumptions were never shared.
Every workstream was on schedule. The project was never on track. The schedule hid the absence of integration risk management until the moment the risk became a fact.
Why the Gap Exists
The gap between on schedule and on track exists because software projects are complex systems, and schedules are linear documents. A schedule assumes that work can be decomposed into tasks, that tasks can be estimated, and that completing tasks produces a working system. That assumption is false often enough to matter.
Software projects are full of feedback loops. A design decision made in month one changes the cost of a feature in month four. A performance problem found in month six invalidates an architecture choice from month two. A requirement that seemed clear in the kickoff meeting turns out to be ambiguous when the first user sees the screen. Schedules do not handle feedback loops well. They handle them by pretending they do not exist.
The Role of Optimism Bias
Plans are written by people who want the project to succeed. That is not a criticism. It is a fact. The people who write plans are usually the same people who will be held accountable for the plan. They have an incentive to be optimistic. They also have an incentive to believe their own optimism. The result is a schedule that represents the best plausible case, not the most likely case.
Optimism bias is well documented in project management research. The planning fallacy, identified by Kahneman and Tversky, describes the tendency to underestimate the time and cost of future tasks even when past experience says otherwise. Software projects are especially vulnerable because the work is intangible and the feedback is delayed. You can read more about the planning fallacy in the Nobel Foundation’s summary of Daniel Kahneman’s work.
How to Tell the Difference in Practice
You do not need a sophisticated model to tell the difference between on schedule and on track. You need to ask better questions and look at different evidence.
Questions That Reveal the Gap
- What has been built, not just what has been completed? A task can be marked complete and produce nothing that runs. Ask to see the artifact, not the status.
- What has been tested, and what did the tests find? A project that is on track has test results that are boring in a good way: failures are found early, fixed, and the fix is verified. A project that is merely on schedule has test results that are either missing or suspiciously clean.
- What has been cut, and why? A project that has never cut anything is either perfect or not paying attention. Perfection is rare.
- What is the team worried about? The people doing the work usually know where the bodies are buried. If the team is worried and the dashboard is green, the dashboard is lying.
Evidence That Matters More Than Dates
Dates are the weakest form of evidence. They tell you when something was supposed to happen, not whether it happened well. Better evidence includes:
- Code review comments. The tone and substance of code reviews tell you whether the team is catching problems or rubber-stamping work.
- Defect arrival rates. A project that is on track sees defects arrive early and decline. A project that is merely on schedule sees defects arrive late and spike.
- Architecture decision records. If the project is making and recording architecture decisions, it is thinking. If it is not, it is drifting.
- User feedback. The earliest possible contact with real users is the best possible test of whether the project is on track. Most projects delay this contact because it is uncomfortable. The discomfort is the point.
The Cost of Confusing the Two
Confusing on schedule with on track is not a harmless semantic error. It is a failure mode with real costs. The most obvious cost is the project that fails after months of green status. The less obvious cost is the project that succeeds but takes twice as long and costs twice as much as it should have, because nobody noticed that the schedule was hiding waste.
There is also a human cost. Teams that are pushed to hit dates regardless of substance learn to game the system. They pad estimates. They hide problems. They stop telling the truth because the truth is not rewarded. The schedule becomes a weapon, and the project becomes a contest between the people who want to look good and the people who want to do good work.
The Forensic View
From a forensic perspective, the gap between on schedule and on track is one of the first places to look when a project fails. The question is not “Why did the project miss its dates?” The question is “Why did the dates miss the project?” The answer is usually that the project was never on track, and the schedule was the thing that kept everyone from noticing.
What to Do About It
The fix is not to abandon schedules. Schedules are useful. They create coordination, force decisions, and give people a shared frame of reference. The fix is to stop treating the schedule as the primary source of truth about project health.
Separate Schedule Reporting from Progress Reporting
Schedule reporting should answer one question: are we doing what we said we would do, when we said we would do it? Progress reporting should answer a different question: is the work we are doing likely to produce a useful result? These are different questions. They should be asked in different meetings, with different evidence, and by different people if possible.
Make Progress Visible
Progress is visible when the team can show working software, test results, and user feedback. It is invisible when the team can only show a Gantt chart. The more a project relies on the Gantt chart to prove it is healthy, the less healthy it probably is.
Reward Honesty About Problems
The fastest way to kill a project is to punish people for reporting problems. The second fastest way is to reward people for reporting green status. If the culture rewards honesty, the project has a chance. If it rewards optimism, the project will get optimism and nothing else.
FAQ
Can a project be on track but behind schedule?
Yes. A project can be behind schedule and still on track if the work is converging on a viable outcome and the delay is the result of learning something important. For example, a team that discovers a performance problem in month three and spends an extra month fixing it may be behind schedule but on track, because the fix prevents a much larger failure later. The schedule is a plan. The track is a trajectory. They can diverge in either direction.
What is the most reliable early warning sign that a project is not on track?
The most reliable early warning sign is the absence of working software. If a project has been running for months and nothing runs, the project is not on track, regardless of what the dashboard says. Working software is the only evidence that the team has actually built something. Everything else is a promise.
How often should a project be assessed for being on track?
At least every two weeks, and more often if the project is in a high-risk phase. The assessment should be based on evidence, not on status reports. The evidence should include working software, test results, defect trends, and user feedback. If the assessment is based only on the schedule, it is not an assessment. It is a ritual.
What is the difference between a milestone and a checkpoint?
A milestone is a date on a plan. A checkpoint is a moment when the team stops and asks whether the work is still worth doing. Milestones measure schedule compliance. Checkpoints measure project health. Projects that are on track have regular checkpoints. Projects that are merely on schedule have milestones and hope.
Next Steps for This Site
This article is part of a series on schedule and progress forensics. A natural follow-up is a deep dive into the integration mirage pattern: how workstreams that are individually on schedule produce a project that is collectively off track. Another follow-up is a glossary entry on the planning fallacy and its role in software project failure. If you have a project that was on schedule and still failed, the details of that failure are the raw material for the next article. You can also review our glossary entry on the planning fallacy for a more detailed treatment of optimism bias in project planning.