I recently had lunch with an experienced physician executive from a large academic medical center. He told me that his organization was trying to migrate from fee-for-service to risk, and that management had appointed a bunch of large committees to oversee everything from a new cost accounting system to the development of multiple external partnerships.
The going was slow. The large committees were cumbersome. Nobody felt empowered to make hard decisions. Twenty major initiatives were all 10% complete one year into the migration. The problem, he said with a sigh, seemed to be the way that the change initiative was structured. There were too many people moving incrementally.
I’ve spent a lot of time considering the massive challenge that large health systems face in taking on risk contracts. The cultural, technical and structural challenges facing legacy healthcare players are enormous. (I’ve previously written about the corporate structure and changes to the back office that are going to be needed when companies are paid for value).
Is there a more nimble way to approach reform?
This month’s Atlantic Magazine has a fascinating piece on the rescue of the Healthcare.gov website. In short, version 1.0 of the website was a disaster, attributed in large part to the large number of massive and poorly supervised contractors building the site on a “cost-plus-fixed-fee” basis. In response to this embarrassing rollout, the Obama administration appointed a group of Silicon Valley leaders who took over development of the website.
A small group of coders called the Marketplace Lite (MPL) quickly set up shop. The small group worked in hotel rooms, and then a rented suburban house in Maryland furnished with Ikea tables and mattresses. Over sixteen months the team turned the Healthcare.gov site around.
What was the key to MPL’s success? How could a small group of coders working on cardboard boxes and folding chairs fix one of the most complicated web interfaces in America? The Atlantic attributes it to “agile” teams and work processes. It’s a concept that has been around software circles for over a decade, but it’s something new to me.
It’s a development approach, where the entire process – from planning to requirements analysis and design to the programming, test and deployment run through several repeating short cycles (iterations), auto-adapting themselves.
It’s a set of best practices (not a formal process) with roots in many modern management approaches as the lean manufacturing (famously introduced at Toyota), the evolutionary system (Evo) from Tom Gilb, Scrum and the Extreme Programming, and partly a reaction from the heavily regulated waterfall model.
In comparison to more formal and structured “Gantt-chart” type project management techniques, agile is apparently the best way to approach an engineering issue where the problem and solutions aren’t well understood, creating a new product, troubleshooting a complex system, etc. The rapidly iterative process is perfect for handling uncertainty. More formal project management processes can be used when a project is better understood.
The agile manifesto, created by a group of software designers in 2001 describes agile’s core principles. They are:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Compact multidisciplnary teams are key to this approach. Teams that are too large require too many interactions for the work to get done. Ownership of the problem was key.
Robinson Meyer, writing in the Atlantic about MPL notes:
Talking to MPL team members, I was struck by how many of the problems were fixed simply by having a devoted workforce willing to just do the work and fix the bugs… Team members found the government averse to the agile process because, to quote Yu, they asked, “what if there’s bugs?” But there will always be bugs. For a website is not a tank: It’s not constructed piece by piece, and assigning more people to work on it does not get it finished it any faster. Most importantly, the government can’t decree what it wants and expect a perfect deliverable, otherwise the government will receive software that meets every specification except the important one: that it works.
What are the lessons for healthcare? I’m quite struck with the idea of using nimble multi-disciplinary groups to work in rapid and iterative cycles to get complex work accomplished. Agile seems like a promising approach for healthcare systems that are trying to restructure themselves in the face of healthcare reform, especially given the vast uncertainty around what’s required for systems to thrive in risk.
I’ve previously argued that the massive internal inter-dependencies in risk-bearing healthcare systems are going to require systems to seriously rethink their corporate structures. The M-Form corporate structures that we see in most large integrated healthcare systems aren’t well suited for risk.
Beyond this, how will the actual work of building risk-bearing systems occur? For large healthcare systems I could envision, say, multidisciplinary project teams which tackle the infrastructure, accounting and systems overhauls that are needed to thrive in risk. At the same time, having spent enough time working in large healthcare systems, I can also appreciate that technical change is only a small part of the equation. As I’ve written about before, cultural transformation is often 90% of the battle in big companies. Nimble, iterative and multidisciplinary teams can come up with the best technical solutions in the world. Winning hearts and minds is another matter.
Photo: Atlantic Magazine and Julien Harneis Flikr, cc license.