Time Capsule: Sutter’s $150 Million Turned $500 Million Clinical Systems Project: Where Seldom was Heard a Discouraging Word, Apparently

I wrote weekly editorials for a boutique industry newsletter for several years, anxious for both audience and income. I learned a lot about coming up with ideas for the weekly grind, trying to be simultaneously opinionated and entertaining in a few hundred words, and not sleeping much because I was working all the time. They’re fun to read as a look back at what was important then (and often still important now).

I wrote this piece in November 2007.

Sutter’s $150 Million Turned $500 Million Clinical Systems Project: Where Seldom was Heard a Discouraging Word, Apparently
By Mr. HIStalk

Sutter Health didn’t seem embarrassed when the local newspaper recently reported that its 26-hospital Epic clinical systems project will end up costing around $500 million. In fact, Sutter’s COO even hinted that the tab could run higher, saying that EMR projects rarely meet budget and timeline projections. He didn’t sound concerned.

Or, maybe it was gallows humor. Sutter’s original project budget was $150 million. Being off by over 230 percent is scandalous, at least when someone other than Uncle Sam is involved. Luckily, Sutter can afford a gaffe of a few hundred million.

Wildly faulty project budgets and timelines are not uncommon. Project complexity goes up much faster than being simply linearly related to bed size or headcount. It’s closer to geometric: doubling the bed size quadruples the effort (and therefore the cost). It’s anti-economy of scale. Little hospitals have it easy, other than they’re broke.

That’s no excuse for a bad estimate. Complex projects demand sophisticated planning and risk mitigation. Socking a lot of cash in a contingency fund is poor substitute for planning well in the first place.

The main reason for underestimation may be more psychological than numeric. Project costs are often underestimated and riddled with unlikely assumptions because that’s what people want to hear. This is similar to groupthink, in which members of a group are so reluctant to disrupt group harmony that they avoid viewpoints that are contradictory or critical.

Those executives who collectively decide to plunk down hundreds of millions of dollars for software may not be all that enthusiastic about the idea individually and off the record. Everybody else seems to like the idea, so it’s easiest to avoid arguing with peers by just going along as a passive rubber-stamper, especially if the boss clearly favors doing it.

After all, everybody else is hot to get going, too. Consultants urge action, especially when they smell an opportunity to get new engagements. Affected departments love anything new and fun, at least initially, so their appointed representatives can’t wait to get started. Journals, HIMSS conferences, and vendor salespeople encourage action because the industry (and therefore their place in it) depends on churn.

The CIO, being nurtured in an IT advocacy mindset, often naively believes that IT fixes problems, even when available solutions are dysfunctional and collective experiences suggest otherwise. If the other VPs are willing to do it, the reasoning goes, why not get a chance to shine, beef up the resume a little, and move up on the staff-and-budget yardstick they measure each other against?

Many of these big-ticket projects will never even come close to being worth what they cost. Does anybody go back to the people who made the “go/no go” decision and either ask for an explanation or fire them for bad judgment? Not usually. The project’s once-broad circle shrinks to a grim core of IT people stuck with the unenviable task of trying to reconcile unreasonable expectations with the ugly product limitations and internal processes at hand. What started out as a noble collective mission becomes a never-ending IT ground war that no one wants to talk about.

It goes without saying that IT people shouldn’t be initiating or leading projects other than those involving IT infrastructure. What may need to be said, however, is that the process and choice of people involved in making huge IT project decisions may be flawed as well. Seldom is heard a discouraging word when project-friendly allies sit around a conference room table breathing each other’s air.

If hospitals really wanted to make an informed decision, they’d bring in patient advocates, safety experts, physicians, risk managers, finance experts, and process engineers. That’s pointless if the pre-ordained executive answer to the “should we do this” question is already “yes.”