Five ways a summary schedule lies — and how to keep it honest
A one-page summary schedule is the most-read artefact in the room and the least-scrutinised. Everyone trusts the rolled-up bars because they're clean. That's exactly the problem: cleanliness hides things. Here are five specific ways a summary quietly misleads a sponsor — and, for each, the tell that gives it away and the fix that keeps it honest.
I like a good summary schedule. A director shouldn't have to wade through four thousand activities to know whether the project lands on time. But every act of summarising is an act of hiding — you throw away detail on purpose, and detail is where the truth lives. Done well, a roll-up shows the shape of the plan. Done carelessly, it launders a bad schedule into a reassuring picture, and no one notices until the picture is wrong in front of the board.
These aren't hypotheticals. Each of the five below is something I've watched slide through a monthly report, get presented with confidence, and then quietly explode. The good news: every one has a tell you can spot in seconds, and a fix that costs almost nothing once you know to look.
The five lies
1 · It buries the critical path
This is the big one. A summary rolls up ten phases into ten tidy bars, all the same colour, and the eye reads them as equally important. They aren't. One of those phases drives the completion date and the other nine have float. A roll-up that treats them alike hides the single most decision-relevant fact on the page: which phase, if it slips a week, moves the end. Directors then obsess over the longest bar or the busiest-looking phase, when the driver might be a short, quiet one buried in the middle.
The tell: every summary bar is the same colour and weight, and nobody in the room can point to the critical phase without opening the detailed schedule. If the answer to "what drives the finish?" is a shrug, the summary is lying by omission.
The fix: mark the driving phase. Colour it, weight it, annotate it — whatever it takes so the critical path survives the roll-up instead of dissolving into it. In Sketchedule you keep the critical phase highlighted on the summary: drive a bar's colour from a status or "critical" column so the driver stays red while the rest sit grey, and it holds through collapse/expand and into every export. Be honest about the division of labour, though — Sketchedule presents the critical path; your P6 or MS Project network still computes it. The engine finds the driver; the summary's job is to not hide it.
2 · Milestones that don't trace to a real activity ID
Someone drags a diamond onto the summary labelled "Structure complete — 12 Aug" because that's the date the client wants to hear. It looks authoritative. But there's no activity ID behind it; it's a hand-placed date that agrees with nothing in the detailed schedule. When the network moves, the diamond doesn't — it just sits there, decorative and wrong, radiating false confidence right up until the day it's missed.
The tell: ask "what activity ID is this milestone?" and the honest answer is "it's… just a milestone we added." A date with no ID behind it is a wish, not a forecast.
The fix: every milestone on the summary must map to a real finish/start of a real activity in the source schedule, so when that activity moves, the diamond moves with it. In Sketchedule you bring milestones in from the P6/MSP import and keep them tied to their activity ID — and with conditional milestone symbology the diamond can flip colour or shape when its own date breaches a threshold, computed locally. No hand-placed dates that quietly detach from the network.
3 · Roll-ups over dirty inputs
A summary bar is only as honest as the child activities it spans. Feed the roll-up a phase where half the tasks are on the wrong calendar, or where progress was never brought to the data date, and the summary bar's span is simply wrong — it starts or ends on a date the real work will never hit. The roll-up doesn't validate its inputs; it faithfully summarises rubbish into a smooth, believable bar. Garbage in, tidy garbage out.
The tell: the summary bar's finish doesn't match what the site actually expects, and when you drill in you find a task on a 7-day calendar that should be 5-day, or a % complete that implies work done after the data date. The bar looks fine; the arithmetic underneath is broken.
The fix: fix the inputs, then re-summarise — never the other way round. Confirm calendars, and bring every activity's progress honestly to the current data date before you roll up. In Sketchedule the summary bars are automatic — they span their children — so the moment you refresh to the current data date the roll-up re-spans over clean inputs rather than stale ones. That refresh is only meaningful, of course, if the durations and calendars in the source P6/MSP file are right in the first place; Sketchedule spans what it's given, it doesn't re-calendarise the network for you.
4 · The moving baseline
Here's the quietest lie of all. A phase slips. Rather than report the slip, the baseline gets "re-approved" to the new dates — and next month's summary shows the variance against that, so everything reads on plan again. Do this a few times and you've walked the end date out by months while every monthly report showed green. The baseline was supposed to be the fixed thing you measure against; if it moves whenever reality does, it measures nothing.
The tell: variance is suspiciously small month after month despite obvious drift, and the baseline dates in this report don't match the ones from two reports ago. A baseline that keeps agreeing with the current schedule isn't a baseline — it's a mirror.
The fix: hold one approved baseline and show variance against it, with any re-baseline a formal, visible, dated event — not a silent edit. In Sketchedule you compare or redline the current summary against the real, frozen baseline, so accumulated drift stays visible instead of being absorbed. Keep the approved baseline in the source of truth, snapshot it once, and let the redline show exactly how far the plan has walked.
5 · Bars with no logic behind them
The prettiest summaries are often the emptiest: a row of hand-drawn bars with no links between them. It photographs beautifully and it's completely inert. Because nothing is tied to anything, the picture cannot feel a slip — push one bar out and its successors sit blissfully still, open-ended, promising a finish that no logic supports. A schedule with open ends isn't forecasting; it's drawing.
The tell: move one bar in your head and ask what should happen downstream — if the answer is "nothing moves," there's no logic there. Dangling activities with no predecessor or successor, and a total float that's implausibly generous everywhere, are the fingerprints.
The fix: the logic has to live in the network — and this is the honest limit of any presentation layer. Sketchedule is a presentation front-end with a light scheduler; the driving logic, the critical path and the float belong in your P6 or MS Project model, and that's where open ends must be closed. What Sketchedule does is refuse to launder the problem: refresh from the source and the summary reflects the real linked network, so a summary built over a properly logic-linked schedule stays honest, and one built over dangles has nowhere to hide the fiction.
Keeping it honest, in practice
Notice the through-line: every one of these lies is a place where a clean picture drifted away from the messy network underneath it. The fix is never "make a prettier summary" — it's "keep the summary tethered to the truth." A presentation layer earns its keep precisely by not breaking that tether: highlight the driver instead of flattening it, trace milestones to IDs, span automatically over clean inputs, redline against the frozen baseline, and refresh from the real linked network rather than redrawing it by hand.
- Highlight the driver. Colour the critical phase on the summary so the roll-up can't hide which phase moves the end — and keep it through collapse and export.
- Trace every milestone. Import milestones tied to their activity ID so a diamond moves when its activity moves, never a hand-placed date.
- Clean before you roll up. Fix calendars and bring progress to the data date, then let automatic summary bars re-span over honest inputs.
- Redline against the real baseline. Compare the current summary to the original approved baseline so accumulated drift stays visible.
- Refresh from the linked network. Relink from the source P6/MSP model — where the logic and critical path live — so the picture reflects a schedule that can feel a slip.
| The lie | The tell | The fix |
|---|---|---|
| Buries the critical path | All bars alike; no one can point to the driver | Highlight the driving phase; compute it in P6/MSP |
| Milestones tracing to nothing | "What activity ID is this?" → a shrug | Map every milestone to a real activity ID |
| Roll-ups over dirty inputs | Summary finish doesn't match site reality | Fix calendars + data date, then re-span |
| The moving baseline | Tiny variance despite obvious drift | Freeze one baseline; redline against it |
| Bars with no logic | Move one bar → nothing downstream moves | Close open ends in the network; refresh from it |
Key takeaways
- A summary schedule hides on purpose — the risk is it hides the wrong things. Audit it against the five tells.
- The critical path must survive the roll-up. Highlight the driving phase; don't flatten every bar to the same grey.
- Every milestone needs a real activity ID, and the summary must roll up clean inputs — right calendars, progress brought to the data date.
- Freeze one baseline and redline against it — a quietly re-approved baseline launders drift into green reports.
- The logic and critical path live in P6 / MS Project; Sketchedule presents them honestly and refuses to launder open ends — it doesn't replace the engine.
Keep your next summary honest
Open Sketchedule in a browser — free, no install, nothing uploaded. Highlight the critical phase, tie milestones to IDs, and redline against the real baseline.
Primavera and P6 are trademarks of Oracle Corporation; Microsoft Project is a trademark of Microsoft Corporation. Sketchedule is an independent product and is not affiliated with, endorsed by or sponsored by Oracle or Microsoft. Figures are illustrative, drawn in Sketchedule; Fig 2 is a faithful redraw of a buried-vs-highlighted critical-path summary built in the app.