When only the project manager understands their own plan, the plan has failed in its primary function, which is communicating the state of the project to the team and to management. The proposal: a macro Master Plan in a single view, with the critical path always visible and a review cadence that keeps it alive.
A frequent situation in industrial projects: the project manager opens Microsoft Project in the meeting room and projects a Gantt with 350 tasks, 180 dependencies, overlapping bars, cascading lines and colours that change every time you zoom. Management nods. Nobody asks anything. The meeting ends with no decisions. And everybody goes back to their desk without knowing which task is late or what that means.
The plan has not failed for lack of detail. Quite the opposite: it has failed from too much detail. When the artefact is so dense that only the person who built it can read it, the plan stops being a communication tool and becomes a self-justification document. And a plan nobody can read is a plan that does not exist operationally.
If after a progress meeting somebody on the team — not the PM — has to ask “so which tasks could delay the launch right now?”, the plan is not doing its job. The answer should be visible at a glance, without zooming or interpreting.
This INNsight proposes a distinction that many project management guides assume but rarely spell out: there are two different artefacts in play, not one. The macro Master Plan, which reads at a glance, and the detailed plan, which lives in the scheduling software. Each has its own audience, level of detail and update frequency. Confusing the two is where the dense plan comes from.
The concept of the critical path has a surprisingly concrete origin: DuPont formalised it together with Remington Rand in the late 1950s, as part of the Critical Path Method (CPM), a mathematical technique for planning complex industrial projects. The idea, in one sentence: in any project there is a chain of linked tasks that determines the total duration · if one of them slips, the whole project slips. That chain is the critical path.
Every other task, however important, has float. They can start earlier or later within a range without affecting the delivery date. The operational consequence is enormous: not all tasks are equal in the plan. Half of project management’s attention should go to the 20-30% of tasks on the critical path. The rest gets watched, but it should not obsess anybody.
A 12-month new moulded-product project has three possible paths from kick-off to launch: (1) design → moulds → first trial → industrialisation (8 months), (2) design → CE approval → certification → launch (10 months), (3) design → packaging → commercial pre-series (5 months). The critical path is (2): 10 months. Even though path (1) has more technical tasks, it is not the one in charge. If the PM puts all their effort into optimising the moulds, the project keeps slipping because the bottleneck is in approvals.
El PMBOK Guide from the Project management Institute devotes a whole process to identifying and managing the critical path. Industrial practice adds one more dimension: the critical path is not static. As the project advances, float gets consumed, priorities change and new tasks can enter the critical chain. A living Master Plan is one that recalculates its critical path at every review.
The distinction between Master Plan and detailed plan is not hierarchical, it is functional. Each answers a different question and is updated at a different cadence. When the detailed plan is asked to do the Master Plan’s job — projecting it in a steering meeting, emailing it to management — the result is exactly the situation this INNsight opens with: nobody reads it, nobody understands it.
The Master Plan is read · the detailed plan is executed. Confusing them is the root of the dense plan.
This distinction has an implication few PMs apply: the tool that works for the detailed plan does not work for the Master Plan. Microsoft Project produces excellent Gantts for the detail, but the macro Master Plan is usually better built with something as simple as a sheet of paper, a whiteboard or a purpose-made visual. The reflex of “I open Project to show the plan” is exactly what has to be reversed.
A Master Plan that works has six minimum components. Missing any one of them, it stops doing its job:
A working version of the Master Plan, pre-loaded with a typical 12-month industrial project. You can edit dates, mark tasks as critical path, add or delete milestones and export the result.
| # | Milestone | Start (month) | Duration | Critical path | Notes |
|---|
The bars in thick red are the critical path: the set of tasks that, if they slip, delay the whole project. The bars in thin grey have float · they can move within their range without affecting the final date. The vertical red line is “we are here” in time. The Master Plan test: with this view in front of them, can anybody on the team say which task is the next priority? If so, the plan is alive.
Every project includes safety margin. The question is not whether there is a buffer, but where it goes, who knows it is there and when it gets spent. The difference between an honest Master Plan and a defensive one sits exactly here.
The usual pattern, unintentionally, is the distributed, hidden buffer: every team, every task owner, pads their estimate a little because they “know” something will go wrong. The PM aggregates those estimates and gets a total duration inflated for safety. When something really slips, the buffer has already been spent quietly somewhere else. And nobody knows how much real margin is left.
The Israeli physicist Eliyahu Goldratt proposed in Critical Chain (1997) an alternative: remove the individual buffers and pool them into one visible buffer at the end of the project and at the end of the chains that feed the critical path. Each task is estimated aggressively, with no margin. The buffer is used when it is needed, and you can see how much is left. It is one of the most useful schedule management techniques, and one of the most underused in industry.
In the Master Plan, buffers have to be visible, named and shared. A good practice is to mark explicit zones as “buffer” after the critical milestones · not as accidental float, but as a deliberate decision. The typical sentence is: “this project has 6 weeks of pooled buffer · two in pre-industrialisation, four at the end · if we spend 4 before month 8, the project ships late”. That transparency turns the buffer into a decision tool rather than a shield.
An un-updated Master Plan becomes decoration within weeks. The practice that separates healthy projects from sick ones is not the quality of the initial plan, it is the discipline of periodic review. Without that cadence, all the kick-off work is lost silently.
The right frequency depends on the complexity and speed of the project. As a rule of thumb:
Fast projects · short iteration cycles · small teams · early innovation (low TRL).
Typical industrial projects · new product development lasting 6-18 months · a multidisciplinary team · when there are visible milestones every month.
Multi-year programmes · industrialisation with long lead times · regulatory validations · when milestones are quarterly.
The management committee · a portfolio view · investment decisions · strategic changes.
Every Master Plan review answers three specific questions: (1) are the critical path tasks still the same? If a new task has entered, the team has to be told. (2) how much buffer has been consumed since the last review? If buffer is being consumed faster than progress is being made, the project is slipping even though it looks like it is advancing. (3) what decision has to be taken before the next review? A review with no decisions is a meeting, not project control.
There is an observation practice teaches but few formal guides record: if the PM does not use the Master Plan in every conversation with the team, the team learns that the plan is a dead document. Preaching is part of the job. In every daily, every weekly, every technical decision, the question has to be “does this affect the critical path?”. That repetition is what keeps the plan alive, not the formal review cadence.
A frequent confusion: thinking the Master Plan is exclusive to waterfall projects and that in agile projects “you do not need one because you already have sprints”. It is the other way round. The more iterative the project, the more useful a stable macro Master Plan is to give each iteration its context. Sprints are the zoom · the Master Plan is the full drawing.
The Master Plan reflects the cascading phases with their milestones · the critical path is clear because dependencies are linear · buffers sit between phases.
The Master Plan sets the macro milestones · the Kanban board manages the daily flow of work · tasks are prioritised by whether they affect the critical path.
The Master Plan groups sprints into visible milestones · each sprint is a step towards a macro milestone · each sprint’s planning takes the global critical path into account.
The choice of framework depends on the nature of the project, not on the project manager’s taste. A real industrial project combines all three: waterfall for the approval cascade, sprints for firmware development, kanban for tracking non-conformities in the pre-series. The Master Plan is the common artefact that connects the three worlds.
These three questions reflect how mature Master Plan management is in your team. The result is a starting point, not a verdict.
—
The approach in this INNsight combines industrial practice with established frameworks. For anybody wanting to go deeper into the theory or into specific applications, these are the main references.
The Critical Path Method was born in DuPont’s industrial projects to plan chemical plant shutdowns. The mathematical technique spread in the 1960s to civil construction and product development.
Program Evaluation and Review Technique. The US Navy developed it for the Polaris programme when task durations are uncertain. It uses three estimates per task: optimistic, likely and pessimistic.
Critical Chain. It applies the Theory of Constraints to project management and proposes pooled buffers instead of individual per-task ones. Required reading for anybody running a project portfolio.
The Project management Institute’s body of knowledge devotes its “Project Schedule Management” area to the complete cycle: defining activities, sequencing them, estimating durations, developing the schedule and controlling it.
The American engineer Henry Gantt formalised the chart that bears his name. Originally conceived for industrial production planning, it is still the most used visual format for detailed plans.
A rigorous treatment of flow in new product development. It argues that total project duration is dominated by queues — work in progress — rather than by individual durations. A framework that complements classic CPM.