By Rishi Manchanda MD, MPH, President & CEO, HealthBegins
​
​
With so many emerging initiatives and projects to address social needs & social determinants of health, the opportunity to improve the lives of patients and communities is more real than ever. But we face a real risk of squandering this opportunity.

Remember back to October 1st, 2013 when the first version of healthcare.gov launched. It didn’t go well. After years of planning and hundreds of millions spent, the site didn’t work. In the first week, only 1% of website visitors were able to successfully enroll for health insurance. Thanks in part to a team drafted to rescue the project, the site was soon fixed. Millions have used it since to sign up for insurance. But the question remained: What went wrong in the first place?

The main culprit, we soon discovered, wasn’t a technical glitch or a person. It was the process. More specifically, the first version of the site failed because those involved used the wrong approach to managing the project and the people behind it. They used the “waterfall” approach, a traditional project management approach widely used in health and human services—by executives, managers, and funders alike. You don’t need formal training in project management to know what a waterfall approach looks like. If you’ve seen a Gantt chart, you get the idea.

The waterfall approach is a linear, rigid process that uses sequential phases to define, build, test, and release project deliverables. Everything (we hope) moves forward as the project cascades from one step or milestone to the next. For situations where there’s clear agreement among stakeholders about what solution is required, and when there is little technical complexity and a high degree of certainty about how to provide the solution, the waterfall approach to managing teams and projects works great. Building Healthcare.gov, however, was an unprecedented challenge with a high degree of political and technical uncertainty about how best to design the solution. Using a waterfall approach to manage that challenge, as we all learned, was a costly mistake.

These days, stakeholders from many sectors are busy identifying and implementing solutions to address social needs for patients and social determinants of health for whole communities. As cross-sector partners initially convene, they often don’t have clear insight or agreement about what exact solutions are required to address these upstream needs. We’re seeing lots of high-potential upstream solutions—like new programs, integrated services, data platforms, technology products, and financing models. As promising as they are, these solutions can be complicated to implement, both politically and technically. And while we may have strong hypotheses about what upstream solutions are needed, it is uncertain whether they will work for patients and communities at scale. In these situations, relying solely on a traditional, linear approach to designing and managing solutions does not make sense.

If you’re dismayed that your organization’s traditional waterfall approach to managing people and projects may not be suited to move upstream, don’t worry. That’s because there are other, sometimes far more suitable and efficient ways, to design, build, test, and deploy solutions for these situations. Derived from lean principles, “agile” is a term that covers several of these newer project management approaches. Instead of waiting to see the end result of a lengthy waterfall approach, agile project management uses iterative work cycles and organizes them into mini-phases to rapidly define, build, test, and release project deliverables.

The goal of an agile approach is to engage end-users (e.g. patients) as early as possible to produce working solutions that show value. The process accelerates learning about what works and what doesn’t. The use of agile methods not only rescued healthcare.gov, it also led to a surge of innovation in the federal government. For the upstream movement, I think it’s time we all became more familiar with agile methods and when to use them (See charts below).

Figure 1: Adapted from Stacey Matrix

Figure 2: Cone of Project Uncertainty

 

As an example, my colleagues and I at HealthBegins recently worked with one of the nation’s largest health systems on an interesting idea. We wanted to define, build, and test a new online platform to help community benefits leaders better manage their SDH investments. Instead of mapping out a lengthy Gantt chart to test and build the solution, we agreed to use an agile approach. In less than three weeks, we built a solution that showed value. From narrow projects to large-scale initiatives, we’re helping clients and partners across the country learn when and how to use different approaches—waterfall, agile, or a hybrid of both—to design and manage upstream solutions.

We have a real opportunity to dramatically improve the lives of patients and communities by addressing social needs and social determinants of health. We can’t afford to waste valuable resources, political capital, or time. You can start by finding agile experts in your own backyard. Ask how an agile approach could be used to develop your upstream solution. Get help to become more versatile as an organization—knowing when to use more traditional approaches to managing people and projects and when to be more agile. Because sometimes, when moving upstream, it makes no sense to go chasing waterfalls. 

I’d love to hear your thoughts. Email us info@healthbegins.org to share your thoughts and learn more about agile vs. waterfall approaches to moving upstream.

 

Best,
Rishi