Forty-one days, cut into windows.

Forty-one days, cut into windows.

Every method so far has produced a single number. Forty-one days, claimed as one thing, defended as one thing, and therefore capable of being rejected as one thing.

This method stops doing that. Instead of asking what an event did to the job, it takes the job in periods — usually the periods between programme updates — and asks a different question of each one: what moved in this window, what was driving, and why.

The events do not need to be identified first. The analysis finds what was controlling and then goes looking for the reason.

Week 4 set this up with arithmetic and no method attached: the rock delays piling, the services path carries thirty days of float, and on day thirty-one that path runs out of slack and becomes critical too. Windows analysis is what turns that observation into an answer.

Thirty days where one path was driving and the cause is not seriously arguable. Eleven days where two paths were driving and the argument is real. The lump claim invited a rejection of all forty-one. The windowed one concedes eleven and makes thirty very hard to refuse.

Why the path moves

The method exists because criticality is unstable, and it is worth knowing what actually moves it. Actual progress differs from planned durations. Delay events change remaining durations. Scope is added or removed. Work goes out of sequence — changed intentions, late design information, unforeseen conditions, plant breakdowns, restricted access. And the logic itself gets changed to suit how the job is now going to be built.

Each of those shifts total float somewhere in the programme, and when float moves the critical path moves with it — not once, but repeatedly, month after month. A method that identifies the driving path a single time and applies it across three years isn't simplifying. It is answering a question nobody asked.

What this buys that the last two methods can't

Three things, and the third is the one that matters most for the second half of this track.

It shows gains as well as losses. A window in which the job recovered eight days appears in the analysis, because the analysis is looking at periods rather than at events somebody selected. Nothing in the previous two methods can see recovery.

It finds concurrency in the period the work was actually done, rather than approximating it from a model. That is not the whole of the concurrency question — the hard part of that arrives in the next phase — but it is evidence rather than inference.

And it locates critical delay in the period during which the costs were being incurred. That sounds like a technicality and it is the opposite of one. Week 11 flagged the problem: a prospective analysis produces entitlement in forecast days, the cost ledger records what was actually spent, and joining the two is unbudgeted work. A period-based analysis hands you dated days. Thirty of them fall in specific months, and those months have costs in them.

At $7,100 a month, thirty days is roughly $6,997 and the contested eleven are roughly $2,566. Those are average-rate figures, and the quantum phase will complicate them properly. What matters here is that the days have dates, which is the thing the ledger needs and the earlier methods could not supply.

How far did you touch the data

There is an integrity question underneath this method, and it is easier to answer honestly than to answer later.

The strongest version uses the submitted updates exactly as they were issued. Nothing altered, nothing improved. When the underlying data is left in its contemporaneous condition the analysis is objective in a way no other method manages, because both parties already have the files.

The second version corrects errors in those files. That is often necessary and entirely legitimate — provided every correction is listed, with a reason, and the effect of each on the answer can be seen.

The third version builds updates that never existed, for months nobody updated. It can be done, with an accepted baseline and detailed progress data, and the result may fairly represent what the contractor would have reported. It also imports the analyst's judgement into the contemporaneous record, which is the one thing that record had going for it. Caution is not a formality here.

Where the argument goes

Two choices decide most of the disagreement between two competent windows analyses, and neither is technical.

The first is where the boundaries fall. Monthly windows match the update cycle and are easy to defend on that ground. Event-based windows — cut at the delay events themselves — are defensible on the different ground that a window containing two events cannot separate them. Week 9 used this as the example of why agreeing a method is not agreeing an answer. Here it is, in the method it applies to.

The second is how driving activities are identified in each window. The more that determination follows a stated, systematic rule and the less it depends on the analyst's reading, the harder the result is to attack. Write the rule down before running the analysis, not after seeing what it produces.

Its quiet weakness

Every method in this phase has one, and this one's is easy to miss because the analysis looks so solid.

A window tells you what was driving and by how much the forecast moved. It does not, by itself, tell you why. That still comes from the records — the diaries, the correspondence, the registers from Week 6 — and a window analysis presented without them is a very precise account of movement with no explanation attached.

Which produces a specific failure worth watching for. A window shows eleven days lost and the report attributes them to the nearest available employer event, because it is the only candidate written down anywhere. That isn't analysis; it's proximity. The method is objective about what and completely dependent on your records for why, and the gap between those two is where a well-built windows analysis still gets taken apart.

What it needs, and what that means for you

The requirement is short and unforgiving: updated programmes, at intervals, with actual start, actual finish and progress for each activity in each period.

Phase B spent a week on exactly that list. This is the method that spends it. Where the update series is complete, this technique is available and it is usually the strongest thing you have. Where it isn't, the method may simply not be appropriate, and no amount of skill closes the gap.

There is a small piece of history worth knowing here. After the SCL Protocol appeared, contracts increasingly began requiring regularly updated contemporaneous programmes — typically monthly. The obligation many teams treat as bureaucratic overhead is, in part, the industry arranging for this method to be possible.

Practical insight

Take the six most recent updates on your job and do a crude version of this in an afternoon. You need no software beyond what you already have open.

For each consecutive pair, write down two things: what the forecast completion date was, and which chain of activities was driving it. That gives you six dates and six paths.

Now look at where the forecast moved and where the driving path changed. Every month in which the date slipped is a window with a cause in it, and every month in which the driving path changed hands is a window somebody will argue about later.

Do that once and you will have a one-page table that is more use in a negotiation than most fifty-page reports, because it is built entirely from documents both sides already hold.

Key takeaways

✔ Windows analysis asks what was driving in each period rather than what a selected event did to the job.

✔ It splits a single contested number into the part that is clean and the part that genuinely is not.

✔ The critical path moves for many ordinary reasons, so a method that fixes it once is answering the wrong question.

✔ It sees recovery as well as slippage, because it looks at periods rather than at events somebody chose to include.

✔ It dates the delay to the months in which the costs were incurred, which is what makes time and money reconcile.

✔ State whether the updates were used as issued, corrected, or recreated — and put it at the front.

✔ Window boundaries and the rule for identifying driving activities decide most disagreements; fix both before you run anything.

✔ The method establishes what was driving, never why; attributing a window to the nearest available event is proximity rather than causation.

What's coming next

The methods so far have all started from causes and modelled forward to effects. The rest of this phase turns around and starts from what happened. Next week is the oldest and simplest comparison in the subject — the planned bars against the built ones — what it can genuinely establish, and the reason it survives in a field that has largely moved past it.