# Project Controls for GC/CM and Progressive Design-Build in Utilities

Water and wastewater utilities are increasingly using alternative project delivery methods — Construction Manager/General Contractor (GC/CM) and Progressive Design-Build (PDB) — to accelerate capital programs, manage cost risk, and bring contractor expertise into the design process earlier. These methods offer genuine advantages for complex projects. They also impose project controls requirements that are fundamentally different from design-bid-build, and most utility PMIS configurations are not built for them.

This article explains how alternative delivery changes the document control and risk environment for utilities, what project controls must do differently, and how to structure your PMIS for GC/CM and PDB programs.

How Alternative Delivery Differs from Design-Bid-Build

In design-bid-build (DBB), the delivery sequence is linear: design is completed, bids are received, a fixed-price contract is executed, construction begins. The owner's project controls job is relatively straightforward: track costs against a fixed contract, manage changes as exceptions, verify work meets specifications.

In GC/CM, the contractor is selected qualifications-based during design. The contractor provides preconstruction services — constructability review, schedule validation, cost estimating, phasing input — while design progresses. A Guaranteed Maximum Price is established at a defined level of design completeness (typically 60–90%), and construction proceeds under that GMP. The owner and contractor share savings if the project comes in under the GMP.

In Progressive Design-Build (PDB), a single team is responsible for both design and construction from the start. The project advances through two phases: a collaborative development phase where design, scope, and cost are refined together, followed by construction under a negotiated price. Unlike traditional design-build with an early fixed price, PDB allows the price to develop progressively as design matures.

Both GC/CM and PDB create a design-construction overlap — a period where design is still evolving while construction or procurement activities are already underway. This overlap is what creates the acceleration benefit. It is also what makes project controls significantly more complex.

What Changes in the Document Control Environment

Document control in DBB operates in a defined sequence: the engineer issues drawings and specifications, the contractor builds from those documents, the engineer reviews submittals to verify compliance, and RFIs resolve questions about design intent. The owner is the arbiter of design; the contractor executes.

In GC/CM and PDB, these roles blur. The GC/CM contractor may identify design issues during constructability review that result in drawing revisions before the GMP is set. The PDB team may issue intermediate design packages — 30%, 60%, 90% — as construction procurement for long-lead items begins. Design information flows in multiple directions among owner, engineer, and contractor simultaneously.

This creates document control problems that DBB tools do not anticipate:

Version control in an overlapping environment. When design is still being issued while construction is underway, field crews must have certainty that they are working from the current version. A document control system built for sequential delivery — where "current" means "the approved design" — struggles when there are multiple active design packages at different completion levels. Drawings must be version-locked by package, and superseded documents must be clearly flagged, not just archived.

RFI attribution. In DBB, most RFIs originate from the contractor seeking clarification on design intent. In GC/CM and PDB, RFIs may originate from design-construction coordination — the GC/CM identifying a condition during constructability review, the PDB team resolving a coordination issue between the design and construction phases. The source of an RFI and the decision it generates can have contract cost implications. If your PMIS does not distinguish between RFI types, you cannot accurately allocate cost responsibility.

Drawing distribution management. In alternative delivery, the contractor's field teams, the design engineer, subcontractors, and the owner may all be working from slightly different views of the design at any moment. A controlled distribution list tied to version-locked documents is not optional — it is how you prevent construction from proceeding on superseded information.

How Risk Shifts Under Alternative Delivery

One of the frequently cited benefits of GC/CM and PDB is risk sharing. The contractor is engaged early enough to identify and quantify risks before the GMP is established, and both parties have an interest in managing those risks efficiently. In practice, risk distribution under alternative delivery is more nuanced.

GMP scope assumptions. The GMP is established based on the design at a specific completion level. If the design is at 60% when the GMP is set, 40% of the design is still evolving. The contractor prices risk contingencies into the GMP for the unknown portion. When design is completed, scope changes relative to the GMP basis create change orders — and disputes about whether a change is a "design development" item (generally included in the GMP) or an "owner-directed change" (generally a legitimate change order).

Your PMIS must capture the GMP basis in enough detail to adjudicate these disputes. That means preserving the drawings, specifications, and scope assumptions that were current when the GMP was established — not just the final contract documents.

Preconstruction cost tracking. GC/CM preconstruction services are a real cost with a real budget. Tracking those costs accurately, and maintaining the connection between preconstruction expenditures and construction cost outcomes, requires a PMIS that treats preconstruction as an integral project phase, not a separate pre-project activity.

Open-book cost management. GC/CM contracts often include open-book cost provisions: the owner's project controls team has the right to review the contractor's cost records. This is a risk management tool, not just a transparency provision. To use it effectively, your PMIS must have a place to receive, organize, and analyze contractor cost data — not just track your own costs.

Common Failures in Alternative Delivery Programs

Utilities deploying GC/CM or PDB for the first time often encounter the same failures, regardless of project type or geography:

Failure to capture GMP basis documentation. When disputes arise about what was included in the GMP price, the standard of proof is the documents that existed when the GMP was established. Utilities that do not formally capture and archive the GMP basis package — drawings, specifications, geotechnical data, scope assumptions — find themselves at a disadvantage in change order negotiations.

Change category ambiguity. Every change order in a GMP contract is either an owner-directed change (legitimate extra cost), a design development item (included in the GMP), or a contractor scope gap (contractor's risk). If your change order log does not track these categories, you cannot defend your position on disputed changes.

Preconstruction-construction cost disconnect. Total project cost includes preconstruction services. Utilities that track these costs separately from construction costs end up with a total project cost figure that requires manual reconciliation — and often understates the true cost of delivery.

Design issuance without distribution control. Issuing design packages to the GC/CM team without a formal distribution and receipt process means you cannot prove that field crews had access to the current design at the time a given section of work was built. In a dispute, that gap is significant.

Inadequate meeting minutes and decision logs. Alternative delivery involves a high volume of collaborative decisions — design review meetings, GMP negotiation sessions, value engineering workshops. If these decisions are not documented in a structured log within the PMIS, they become verbal history. Verbal history does not survive project closeout.

Structuring Your PMIS for GC/CM and PDB

A PMIS configured for DBB needs the following additions to support alternative delivery programs:

GMP module. A dedicated tracking section for the GMP baseline, approved changes relative to the GMP, pending change items, and forecast final cost. This is distinct from the contract value tracking in a DBB PMIS — the reference point is the GMP, not the original contract.

Change category field. Every change event — potential, proposed, and executed — should be categorized as: Owner-Directed Change, Design Development, Differing Site Condition, Value Engineering, or Other. This categorization is the foundation of any future dispute analysis.

Design package version control. A document library structured by design package (30%, 60%, 90%, IFC) with version locking, distribution tracking, and supersession flags. Every package should have a named distribution list and a receipt record.

Preconstruction phase tracking. The PMIS should treat preconstruction as a project phase with its own cost tracking, schedule milestones, and deliverables — not as a pre-project administrative period.

Decision log. A structured log of project decisions — what was decided, when, by whom, in what forum, and with what documentation. Design review decisions, GMP negotiation decisions, and value engineering decisions all belong here.

Open-book cost workspace. A section of the PMIS where the contractor's cost data can be received, organized by cost category, and compared to the GMP budget — visible to the owner's project controls team.

Practical Takeaways

Utilities that manage alternative delivery programs successfully are not the ones with the most sophisticated procurement strategies. They are the ones with the project controls infrastructure to manage complexity, document decisions, and defend their cost positions when the project encounters difficulty. That infrastructure is a PMIS — configured correctly for the delivery method you are actually using.

See AMP in action.

Book a 30-minute demo — bring one capital program. Leave with a deployment plan.

Book a Demo →