Healthcare Construction Project Controls: Public Record and Framework

The public record and the useful question

I am Ryan Lippmann, an Orange County construction project manager whose career has included senior leadership on complex commercial and healthcare work. Public coverage from DPR Construction and Bisnow identifies me as a DPR senior project manager during the delivery of the Shriners for Children Medical Center in Pasadena and as a participant in a Los Angeles healthcare-expansion forum.

Those sources establish the project context. They do not disclose every schedule update, change log, or owner decision, and this article does not pretend otherwise. The useful case-study question is narrower: what project-controls system gives a healthcare team an honest, decision-ready view of time, cost, and risk? The framework below is the one I use to answer it.

What the public sources establish

This table separates the published project record from the project-controls framework that follows. It attributes team outcomes to the team and does not claim access to confidential project records.

What I owned on this project

As Ryan Lippmann, I was DPR Construction's Senior Project Manager on the Shriners for Children Medical Center. I owned budget, schedule, quality, and overall project delivery — the baseline, the phase plan, the cost forecast, and the risk register were not reports I received; they were systems I ran.

One decision that shaped the outcome: we self-performed the concrete, metal stud framing, and drywall scopes. By controlling those trades directly rather than subcontracting them, we could sequence them to pull the balance of the work forward. The self-performed crews became the pacing element — when they advanced, the downstream trades advanced. That is what drove the parking levels to finish one week ahead of schedule and kept the overall project tracking to early completion.

This is the difference between a project-controls framework on paper and one that has been tested on a $100M+ healthcare build. The system below is not theoretical. It is what I used to keep 164,000 square feet of clinical, surgical, and parking construction honest enough to act on.

Context: technically complex work with no room for fog

DPR's public project release describes a roughly 164,000-square-foot specialty outpatient medical center with clinical, diagnostic, surgery, and rehabilitation functions, three levels of subterranean parking, and green-roof terraces. The release also notes a long preconstruction period and a structural-steel milestone built on collaboration among the owner, designers, contractor, and trade partners.

Bisnow's 2016 interview adds the market context: hospital renovations, seismic upgrades, central-utility work, outpatient facilities, and design-build delivery were active concerns for California healthcare systems. In a separate forum recap, I emphasized that streamlining delivery is less about a magic technology than communication, understanding what people need, and making the process easier.

That is the controls problem in one sentence. A healthcare project contains enormous technical detail, but leadership still needs a small number of reliable signals soon enough to act.

1. Build one baseline that the team can explain

A baseline is not a ceremonial schedule frozen for the contract file. It is the team's written explanation of how the job is supposed to happen. For healthcare work, the baseline has to connect design releases, permitting, procurement, shutdowns, infection-control constraints, enabling work, construction, testing, commissioning, licensing, and turnover.

The first quality test is simple: can the people responsible for the work explain the logic? If a date exists only because someone typed it, it is not a forecast. Each major milestone should have a traceable chain of predecessor work, a responsible owner, and an explicit assumption about access, review duration, or material availability.

I also separate milestones by decision type. Contract dates, regulatory dates, owner-use dates, and internal targets are not interchangeable. When they are mixed together, every delay looks equally urgent and the team loses the ability to protect what matters most.

2. Make phasing visible before it becomes disruption

Healthcare construction is rarely only a building problem. It is an operations problem occurring around patients, clinicians, equipment, utilities, and spaces that may need to remain active. Phasing therefore belongs in the control system, not in a separate conversation after the schedule is published.

A useful phase plan names the handoffs: who releases the area, what temporary condition is required, which shutdown window is approved, what test proves readiness, and who accepts the space back. Those handoffs should appear in the schedule and in the short-term planning process. If an operational constraint is important enough to stop work, it is important enough to have an activity and an owner.

The weekly question is not merely whether construction advanced. It is whether the next operational handoff is still achievable with the access, information, labor, and material actually available.

3. Connect cost movement to the schedule event that caused it

Cost reports become misleading when they show only approved changes. A defensible forecast also carries identified exposure: issues that are real enough to affect the expected final cost even if commercial resolution is still underway.

For each material issue, I want the same compact record: the originating condition, the date first known, the schedule activities affected, the current cost range, the decision owner, and the next date on which action is required. That linkage keeps a change log from becoming a warehouse of descriptions. It turns the log into a decision queue.

The forecast at completion should move when the evidence moves. A flat forecast is not automatically a healthy project. Sometimes it is simply a project whose information has not yet been allowed into the report.

4. Treat risk as dated evidence, not color

A red-yellow-green matrix can be useful, but color is not a control. A risk becomes manageable when the team records the trigger, probability, consequence, mitigation, owner, and decision date. The decision date matters because a correct decision made after the procurement window closes is still a late decision.

Healthcare work rewards early attention to interfaces: owner equipment, utilities, controls integration, regulatory review, testing responsibility, and turnover documentation. These risks often cross organizational boundaries, which means they can survive for months without belonging completely to anyone. The controls process has to make that ambiguity visible.

I prefer a small current risk list discussed every week over a large archive reviewed every quarter. The point is not to prove that the team once identified a risk. The point is to change the outcome while change is still possible.

5. Report for decisions, then preserve the detail

An owner report should be short enough to read and complete enough to audit. I structure the front end around five questions:

• What changed since the last report?
• Which contract or operational milestone moved, and why?
• What is the current forecast at completion?
• Which risks require a decision before the next reporting cycle?
• What evidence supports each statement?

The detailed schedule, cost ledger, change record, and risk register sit behind that summary. Leadership gets clarity without sacrificing traceability. When a claim is challenged, the team can move from the sentence to the source record without reconstructing history from email.

What the controls cadence looks like

The system works only when it runs on a repeatable cadence. Field status is collected against a defined cutoff. The schedule is updated from actual starts, finishes, remaining duration, and revised logic. Cost and change exposure are reconciled against the same period. Risks are aged and assigned. The project team reviews exceptions before the executive report is issued.

This sequence matters. An executive meeting should not be the first place the project discovers that two systems disagree. The controls cycle is the reconciliation process that happens before leadership is asked to decide.

It also creates accountability without theater. The question becomes “what changed in the record?” rather than “whose version sounds more confident?” That is healthier for the owner, the builder, and the trade partners.

The case-study lesson

Public reporting on the Shriners milestone credited safety, teamwork, a supportive client, design professionals, and trade partners. From the PM seat, the deeper lesson is that self-performing critical-path trades was itself a controls decision: it put the pacing work under direct management instead of behind a subcontract interface. Controls do not replace collaboration. They give collaboration a shared record — and sometimes they put the means of production directly in the team's hands.

A good project-controls system does three things. It exposes variance early, connects the variance to a responsible decision, and preserves the evidence behind the decision. Software can make that faster. It cannot make the team honest. The discipline still comes from updating the plan against reality and allowing the forecast to say something uncomfortable while there is time to respond.

That is the standard I bring to construction project management in Orange County and across California: schedules, costs, and risks that can be explained, checked, and acted upon.