One row per workstream. Effort is person-days of actual work; waiting is calendar days where nobody is doing anything because the answer is with someone else. Keeping them in separate columns is most of the value here, because a plan that adds them together cannot tell you which one is the problem.
| Workstream | Effort person-days | Waiting days | Max in parallel | Only after | Remove |
|---|---|---|---|---|---|
| Workstream | Starts | Waiting | Working | Effort | Finishes | |
|---|---|---|---|---|---|---|
| Site access and safety induction | 0 | 21d | 2d | 2 pd | 23 | |
| Historian extract from customer IT | critical | 0 | 28d | 3d | 3 pd | 31 |
| Vendor firmware drop | 0 | 35d | 1d | 1 pd | 36 | |
| PLC integration on the bench | 23 | 7.5d | 15 pd | 30.5 | ||
| Data pipeline and labelling | critical | 31 | 12.5d | 25 pd | 43.5 | |
| Model training and evaluation | critical | 43.5 | 6d | 12 pd | 49.5 | |
| Controls integration on the line | critical | 49.5 | 5d | 10 pd | 54.5 | |
| Change-control approval | critical | 54.5 | 30d | 2d | 2 pd | 86.5 |
| Commissioning window | critical | 86.5 | 14d | 2.5d | 5 pd | 103 |
The waits that are missing from your plan
Ranges from programmes putting models onto physical systems. The column that recovers schedule is the third one, because most of these clocks are started by a request rather than by finished work, and almost all of them are started later than they had to be.
| What you wait for | Typical | What starts the clock | Startable early? |
|---|---|---|---|
| Site access and safety induction | 2 to 6 weeks | A signed contract and a named site contact | Yes, from day one |
| Historian or database extract from customer IT | 3 to 8 weeks | A written request with the exact tags and date range | Yes, before any pipeline exists |
| Security review or network exception | 4 to 12 weeks | An architecture sketch, not a built system | Yes, from the design |
| Procurement of compute or sensors | 4 to 20 weeks | A part number and a purchase order | Yes, from the architecture |
| Vendor firmware or SDK drop | 2 to 12 weeks | Their release train, which you do not set | Only by asking for the date early |
| Customer sign-off on the test protocol | 1 to 4 weeks | A written protocol | Yes, before the tests are built |
| Change-control or management-of-change approval | 2 to 8 weeks | A complete design package | Partly, by staging the submission |
| Commissioning or line-down window | 1 to 26 weeks | A fixed maintenance calendar | No. Book the slot first and work backwards |
| Regulatory or notified-body feedback | 8 to 26 weeks | A complete submission | No, but pre-submission meetings are faster |
These are calendar weeks with nobody working, and the ranges are wide because they genuinely are. A plan that contains only the engineering will be wrong by roughly their sum, and the overrun will be attributed to the engineering, which was delivered on estimate.
A worked example
A model going onto a plant floor. Nine workstreams, 75 person-days of engineering, two engineers. Read as effort, that is about eight weeks of work.
Scheduled with the queues in it, the finish is on day 103. The critical chain runs from the historian extract through the pipeline, the model, controls integration, change-control approval and the commissioning window, and 72 of those 103 days are waiting. Seventy percent of the programme is time in which nobody on the team can do anything about the finish date.
Now the resourcing conversation. Doubling the team to four engineers takes the finish from 103 days to 98.8. Four days, for twice the cost, and that is with the model letting the whole team pile onto every workstream up to its parallel limit, which is the most generous assumption the argument for hiring could ask for.
Set every wait to zero instead and the same nine workstreams finish on day 31. That is not achievable, but it bounds the two levers against each other honestly: headcount is worth four days here and the queues are worth seventy-two.
The single longest wait on the chain is change-control approval at 30 days, and it sits after controls integration because the board needs a complete design package. Every day taken off it is a day off the finish. Staging that submission so the board sees the design while the integration is still being wired is worth more than any staffing decision available on this programme.
The arithmetic, so you can check it
Each workstream takes waiting + effort / min(team, max in parallel) and starts when its latest dependency finishes. The finish is the latest workstream, and the critical chain is traced back through whichever dependency was binding at each step. Waiting is never divided by anything, which is the whole point of keeping it in its own column.
The doubling comparison re-runs the identical schedule at twice the team size. Because the whole team may work any single workstream up to its stated parallel limit, the comparison is deliberately generous to headcount: if the saving is small under that assumption, it is smaller in reality.
This is a single-project model with no contention between workstreams, so it assumes a team of four can be fully applied to whatever is on the critical chain today and moved tomorrow. Real teams cannot. It also treats each wait as a fixed duration rather than a distribution, when in practice they are long-tailed and the variance is often the thing that hurts: a 30 day approval that occasionally takes 90 damages a plan more than a reliable 45 day one. The parallel limits are judgement calls, and they are where an optimistic plan hides.
Why the engineering is the small half of these programmes is in the model is five percent, and why more people does not close the gap in you cannot hire a gap. To decide what order the integration itself should run in, use the integration order planner.
Questions
Because most of the elapsed time is not effort. Site access, a data extract from someone else's IT department, a security exception, a change-control board, a vendor's release train and the one week a year the line can be stopped are all calendar time with nobody working. They are usually absent from the plan entirely, since a plan built from engineering estimates only contains engineering.
Only the part of it that is effort, and on these programmes that is the minority. On the worked example, doubling the team moves a 103 day schedule to 99. Removing the queues instead would take it to 31. Both numbers come from the same plan, and only one of them is usually discussed.
By starting it earlier rather than by chasing it. Most waits are gated by a request rather than by finished work: a data extract needs a signed request and a contact, not a working pipeline. Ask what actually starts each clock, and how much of the thing it waits on has to exist first. Overlapping a 30 day approval with the work it reviews is worth more than any staffing change.
Any calendar day on which the work cannot progress and nobody on your side is spending time on it. If somebody is preparing the submission, that is effort; if the submission is sitting with a review board, that is waiting. The distinction matters because effort divides by headcount and waiting does not.
Especially then. A plan that omits them is not a plan with some risk in it, it is a plan that will be wrong by the sum of the omissions, and the overrun will be attributed to the engineering work that was actually delivered on estimate. Naming the waits also puts them in front of the one person who can shorten them, which is usually somebody at the customer rather than on the team.