The Second Site Should Be Easier: Learning as a System

In a healthy repeat program the second build is meaningfully cheaper than the first, the third cheaper than the second, and the fifth begins to approach a floor set by the physics of the work rather than by anyone’s learning curve. Schedule compresses in the same shape. Rework drops. Commissioning finds fewer surprises because the surprises from the last build were written down, argued about, and folded into the standard before the next crew arrived on site.

In most owner programs the curve is flat, and sometimes it slopes the wrong way. The reasons are unglamorous. Different general contractor. Different EPC. Different owner’s team, or the same nameplate with two-thirds of the people rotated out. A new commissioning lead who has never seen the last punch list. A control system that was standard on build one and is somebody’s preferred replacement on build two. Every build starts near zero because the memory of the last build lives in individual heads, and the individuals moved.

The gap between the two shapes is not a gap between good builders and bad builders. It is a gap between owners who run each project as an isolated event and owners who run a program that happens to be delivered as a sequence of projects. The first kind of owner ends up with ten first builds. The second ends up with one first build and nine repeats.

Almost every capital program produces a lessons-learned document. Almost none of them get read on the next build. The document arrives three months after commissioning, runs to eighty pages, is organized by discipline, and lands in the inbox of a project manager who has already been reassigned. On the next build, the new project manager types “lessons” into the shared drive, finds four folders from four prior projects, opens one, and closes it. The knowledge existed. It did not travel.

Lessons that travel look different. They are captured during the build, not after it, because the person who knows what actually happened at the tie-in is available in week thirty-two and unfindable in week fifty-two. They are written in the second person, addressed to the next team, with the answer stated before the story: “When you are setting the switchgear pad, order the embedded conduit two weeks earlier than the current standard says, because the standard was written before the vendor consolidation and their lead time is now nine weeks, not five.” They live inside the standard rather than in a document about the standard, so the next team reads them by reading the design basis they were already going to read anyway.

And they are curated, not accumulated. Somebody with authority reads every candidate lesson, decides which ones are true patterns and which are one-site oddities, and merges the accepted ones into the standard within a defined window. A lessons process without an editor is a filing cabinet with the drawers open.

The center of a compounding program is a standard: a set of designs, specs, templates, sequences, and vendor packages that the next build starts from rather than reinvents. Intel’s version copies the process down to equipment configuration, chemical purity, and facilities hookups, and holds the production fab to the outputs the development fab produced. The best hyperscaler campus programs run the same idea on data centers, treating the reference design as a versioned product that each new campus starts from rather than a document the next region can quietly ignore. In both cases the standard has an owner, a release cadence, and a backlog. It is not a document that gets refreshed when somebody has time.

Treating the standard as a product changes what people do with it. There is a named owner accountable for its state and for the outcomes it produces on the next build. There is a version, and every project knows which version it is building against. Waivers exist, because sites are not identical, but a waiver is a decision on the record, not a shrug in a hallway. The default is the standard, and the burden of proof sits on the deviation.

The alternative is a standard nobody quite owns. It sits on a SharePoint site, some of it current, some of it from the last major program, some of it contradicting itself between the mechanical section and the electrical section. Every project team quietly builds their own working version. Ten projects later there are ten working versions and no standard, and the owner’s question — why is this build taking as long as the last one — has an obvious answer that nobody wants to say out loud.

On most builds, documentation is the thing that happens after the thing that matters. As-builts get compiled at closeout, when the schedule is already blown and the team is fighting to hit substantial completion. The commissioning binder is a proud object on the day of turnover and an unreliable one six months later, after the operator has changed two setpoints and nobody edited the page. The documentation exists. It just does not describe the plant that is actually running.

Compounding programs treat documentation as a first-class deliverable, produced in the same cadence as the physical work. The design basis is a living document maintained by a named engineer, not a PDF frozen at IFC. The operating philosophy is written before commissioning, tested during commissioning, and edited in the first ninety days of operation. Change requests update the drawings before the field crew leaves the site, not in a closeout package nobody will open again. Digital handover, done seriously, means the model, the tag list, the maintenance strategy, and the historian all point at the same asset with the same identifier, so the next build’s design team can search the last build’s reality without translating between three systems.

The test is simple. If a competent engineer arrived on site the day after turnover and had to answer a specific question about how a subsystem was intended to run and why, could she find the answer in an hour, from documents she trusts, without calling somebody? Where the answer is yes, the next build starts weeks ahead of where it would otherwise start, because the design team is arguing about improvements rather than reconstructing what was built the last time.

Documents do not walk between projects. People do. The programs that compound have a small number of continuity roles that follow the standard from one build to the next, staffed by people senior enough that their advice on the second build overrides the second build’s local preference. A program engineer who has been through the last three commissionings and knows which sequences the standard gets right and which it fudges. A controls lead who has seen how the last operator argued with the last integrator and has already answered the argument in the specification. A startup lead whose calendar is booked across builds a year in advance because the value of having her in the room during hot commissioning is understood.

Around those continuity roles sits a center of excellence — a group, not a committee — that owns the standard and the lessons process on behalf of the program. It is small, staffed with practitioners who have delivered, not reviewers who have not. It has the authority to say no to a deviation and the humility to change the standard when the site is right and the standard is wrong. The good ones publish a release, run office hours, and show up on site during the two or three weeks of each build where their answer will save a month. The bad ones publish binders and hold governance meetings, and the projects route around them within a quarter.

The most reliable early warning that a repeat program will not compound is a staffing plan for build two that reads like a staffing plan for build one — new project director, new commissioning lead, new controls lead, recruited a month before notice to proceed. The organization has decided, without saying so, that it will learn the same lessons a second time. The organizations whose curves bend refuse that trade. They hold onto the two or three people who know what the standard means, and staff the rest of the team around them.

A repeat program that only talks inside each project is a set of parallel monologues. The mechanical lead on build three is solving a problem the mechanical lead on build two solved last month, and neither of them knows the other exists. Cross-build communication is quietly the highest-leverage hour on the calendar when run seriously.

A weekly cross-project stand-up, forty-five minutes, one representative per active build and per discipline, run by the center of excellence. Not a status meeting. A pattern meeting. The question is what each build has learned in the last week that another build should know before the end of the current week. A shared issue log where every open problem carries a tag for the standard it touches, so the center can see the same problem on three sites and act before it shows up on the fourth. A rotation program that puts an engineer from build three onto build two’s commissioning floor for six weeks, because reading a lessons document is not the same as watching the sequence run.

These mechanisms are cheap, and they are almost always the first things cut under schedule pressure. Their absence shows up two builds later as a curve that will not bend. The compounding that was supposed to make build five easier than build three does not arrive, because the pipe between the builds was closed for eighteen months while everyone was heads-down on their own scope.

The compounding curve is not a byproduct of doing more builds. It is the output of a decision, made once and defended repeatedly, that the program will be run as a program and not as a sequence of unrelated projects. That decision costs something on build one. A center of excellence has to be stood up before there is a second build to justify it. A standard has to be written before there is enough field evidence to make it obviously right. Continuity roles have to be carried across the gap between builds, when there is no site to charge them to.

Owners who make that decision produce fleets that look like Intel’s at its best: a first build that is expensive because it is genuinely first, and a second, third, and fifth that are each visibly easier than the one before. Owners who defer it end up with a portfolio of first builds. Every site starts near zero. Every closeout produces a lessons document the next team will not read.

The uncomfortable part is that the decision belongs to the operator, not to the delivery organization. A contractor cannot install a learning system on an owner who does not want one. The second site is easier when the operator running the fleet decides, before build one is complete, that the fleet exists — and staffs, funds, and defends the small handful of mechanisms that turn a sequence of projects into a program that compounds.