Hospital Owners’ Worst Project Fear

Posted on November 2, 2011


Is a hospital’s worst project fear an architect with no knowledge of healthcare design? Or an incompetent contractor? Maybe a project that goes 200% over budget, takes twice as long to build, and ends up in the courts? None of these compare to a hospital’s worst project fear.

It is important to dissect the genesis of a typical healthcare project in order to uncover the worst project fear.

Here is how most healthcare projects come into existence:  a hospital experiences a perceived need, or projects a future need in its service delivery. In the short-term, this may be overcome by changes in operations (staffing, flow, space allocation) or small structural changes (minor renovations). Over the long-term, however, the problem creates issues that cannot be jury-rigged for success.  A project is born.

Hospital department heads meet with senior leadership to formulate a needs assessment. An initial space program is developed; a very basic budget is created; and the mechanisms for project approval are begun:  politicking, rallying Board members, initial certificate of need (CON) applications considered, if appropriate, and maybe planning consultants are hired.

Over time, the service need develops further, as does the project program, budget, timeline, and expectations. As it becomes a formal request to hospital leadership, the project is concretized and given definitive shape. Further internal work may lead to an initial draft RFP or early phase interviews with an architect and builder. Soon real decisions are made:  pursue approval from the State if required, acquire land, fund raise.

This is the typical project path:  owner-generated program + budget = RFP package for A/E/C to design, bid and build.

The innate problem here is that the program is a perceived need by the hospital.  The budget is often-times reverse-engineered from what can be afforded—‘what can I get for X dollars’, not what do I really need. In the end, even if the program is designed, engineered and built to the specs of the hospital, it can still be a market failure because nothing was verified. And verification does not mean meeting with users.

The current way of creating projects is outdated and speculative at best. Each project done without modeling the hospital’s existing operation, its intended solution, and then verifying both of these against the real revenue and performance metrics (business case) of the hospital, is done on speculation—speculation that the hospital’s perceived need was correctly identified, and speculation that the project as conceived by the hospital will solve the perceived need.

Healthcare design needs a way to prove a project need does exist, and that a given solution will definitively solve the specified need. Without this certainty, tens or hundreds of millions of dollars are at risk.

How can a project be verified, you ask? Simulation. And likely not even 2% of the 5700 or so current hospitals run simulations on their current hospitals, and then compare how a capital project will affect their future operations.

I touched on the growth of simulation in medical education, and designing for simulation, in a prior post. The ins-and-outs of design simulation is related but different, and another topic for another time. Simulation allows for hospitals do design and build more responsibly. Therefore, the message should be clear:  to meet one of the prime goals of healthcare reform (reduce waste and cost of care), simulation is the most responsible way to verify project need and efficacy, and maximize capital project investments. Project verification is key.