A capital project at a running plant lives on one of two calendars. Either it can be built with the unit online, in which case its clock is its own, or it needs the unit down, in which case its clock belongs to somebody else. Most of the capital at most sites is the second kind, and most of the trouble comes from treating it like the first.
Two anchors, two owners
A stand-alone project is anchored to its own start of field execution, and every activity in its plan is an offset from that date. The project manager proposes the date in the charter, tests it at every gate, and confirms it at construction readiness. The project owns its clock.
A turnaround-coupled project has a second anchor it does not own: the window start, the day the unit comes down. That date is pinned by the turnaround organization, on the turnaround’s own long-range plan, for the turnaround’s own reasons, and the project has no vote. The project’s tie-ins, its in-window scope, and its pre-window verification all hang off a date set in another system by another team.
The consequence most processes miss is which way the front end is calculated. A coupled project’s definition phases are not laid out forward from an idea date. They are laid out backward from the earlier of two dates: the window start and the turnaround’s scope freeze. And the scope freeze is almost always the one that binds.
The scope freeze is the real deadline
A turnaround freezes its scope months before the unit comes down, so the planners can plan it. Anything a project wants done inside the window, a tie-in, a valve replacement, a nozzle, a foundation the crane needs, has to be defined, on the turnaround’s work list, and screened before that freeze. After the freeze, an addition has to clear a rising hurdle, and late in the countdown it needs executive approval and a very good reason.
So the project’s definition gate, the point at which its tie-in list is real, has to land before the turnaround’s freeze, not before the outage. On a sixteen-day window in May with a scope freeze in the previous November, a project sanctioned in January has not missed the outage. It has missed the freeze, and every one of its tie-ins is now a late addition arguing for its place. The window was never the deadline. The freeze was.
Why the link belongs in one system
The practical failure is that the two calendars live in two places. The turnaround has its countdown, its scope register, and its freeze date in one system. The project has its gates and its tie-in register in another, or in a spreadsheet, or in a project manager’s head. The link between them is a line in a meeting minute. When the turnaround moves, and turnarounds move, nobody re-lays the project. When the project adds a tie-in, nobody tells the turnaround until the freeze has passed.
The fix is structural: the link is a first-class object, made from either side. The project pins its field start to the window’s start, so a moved window re-lays the project and records that it did. The turnaround’s capital-integration view lists the projects riding it with their gate position and their mechanical completion dates, reconciled against the freeze. The turnaround manager holds a seat on the coupled project’s team from the first gate, and the project’s readiness review carries “window confirmed” as an expectation, while the turnaround’s readiness review carries “linked capital projects” as one.
This is the reason CAP Intelligence shares a spine with a turnaround practice rather than standing apart from one. The capital project platform and its turnaround sister run on one record, so a project and the window it rides are one thing with two views and one sign-in. The standard behind the coupling rules is PL-09, STO Integration and Window Planning, the project-side twin of the turnaround system’s capital integration standard. Two documents, one seam, written to agree.