The Project Schedule: Common Mistakes and How to Avoid Them

A project schedule is more than a list of dates. It is a model of how work flows from start to finish, and when that model contains errors, the whole project can quietly drift off course before anyone notices. Most scheduling problems are not caused by bad luck — they are caused by a small set of recurring mistakes that are entirely avoidable.

Six Mistakes That Undermine Project Schedules

1. Dangling logic (activities without predecessors or successors). When a task has no predecessor, the schedule cannot calculate when it starts. When it has no successor, delays in that task go undetected because nothing downstream is linked to it. Every activity except the very first and very last should be connected to at least one predecessor and one successor. A schedule with dangling logic will produce unreliable critical path analysis and misleading float values.

2. Resource loading is skipped. Many project managers build a schedule based purely on durations and sequences, then assign resources as an afterthought. When two tasks requiring the same person or piece of equipment run concurrently, the schedule looks achievable on paper but cannot be executed. Build resource loading into the schedule during planning, not after approval.

3. No baseline is established. A schedule without a baseline is a plan with no memory. Without a snapshot of the approved plan, you cannot measure variance, report earned value, or defend your original estimate. Set a baseline at project kick-off and protect it — only re-baseline after a formal change is approved.

4. Durations are set by deadline pressure, not estimating. When a sponsor says "it must be done by October," that date works backwards through the schedule and compresses every activity to fit. The result is a schedule that looks right but reflects wishful thinking. Estimate durations from the work itself — using historical data, expert judgement, or parametric models — then present the outcome honestly.

5. No milestones for external dependencies. If your project depends on a third party to deliver something — a permit, a design approval, a vendor component — that dependency must appear as a milestone with an owner. Without it, the schedule has no way to signal when an external delay is about to cascade into your work.

6. The schedule is not updated during execution. A schedule that is set at kick-off and never touched again is a historical document, not a management tool. Actual start and finish dates must be entered as work progresses. Remaining durations must be re-estimated. Only an updated schedule can reveal where the project stands and what corrective action is needed.

What a Healthy Schedule Looks Like

A well-built schedule has complete network logic with no dangling ends, resource assignments that reflect realistic availability, a protected baseline, and durations that came from estimating rather than reverse-engineering a deadline. It is updated at least weekly during active execution and reviewed with the team. It includes meaningful milestones — not just project start and end, but key handoffs, external deliveries, and stage-gate approvals — so leadership can read progress without parsing every activity line.

Importantly, none of these practices requires expensive scheduling software. They require discipline and the willingness to push back when a deadline is set before a schedule exists. The most common conversation a project manager needs to have is: here is the realistic schedule based on the work; here is how it compares to the target date; here are the options. That conversation is only possible if the schedule was built correctly in the first place.

If your organisation needs help building project controls that your team will actually maintain, XNM's program and project delivery practice works with clients to establish scheduling standards, baseline discipline, and reporting routines that hold up under real project pressure.