When an IT Project “Goes Red”

When health care insurer WellPoint ran into trouble changing its provider payment system, it only turned things around after putting the project into “Status Red.”

The project’s big vision is to shift from a model where the company pays physicians based on volume (procedures, visits, admissions) to one where it pays based on “value” (ability to manage costs and improve patient outcomes and quality of care).

Making the shift means figuring out how to give doctors more data — and data that’s easier to act on — about patients with chronic conditions. That would help doctors provide more effective care.

But as MIT Sloan Management Review‘s Michael Fitzgerald detailed in a Data and Analytics Case Study “Preparing Analytics for a Strategic Role: Behind WellPoint’s Shift to a New Provider Payment System,” the IT project to bring this level of data integration to life ran into big trouble.

In September 2012, the project missed its first deliverable. Over the next seven months “it was one Band-Aid after another,” according to Ashok Chennuru, a staff vice president of technology. In April 2013, Jill Hummel, WellPoint’s vice president of payment innovation, told her boss that the project should go into Red status. Chennuru was installed as the project’s new lead.

According to the April 2014 case study, flagging the project as troubled was not initially well received by the ranks. “It was not motivating, let’s put it that way,” said one engineer who had been logging 90-hour work weeks.

Still, sending the warning message up the organization ended up having a positive effect. Here the four things the team did once the flag was raised:

• Focus on the upside of admitting a project is in trouble: You get more resources. VP Hummel stressed in her conversations with managers that going Red meant the project would get more help. The company brought in a consultancy and opened up new jobs for IT and business people who had worked in a new software development approach called “Agile,” or iterative development, that project leaders decided they needed to shift to.
• Start holding daily meetings. Project teams began having daily half-hour meetings, called scrums, where IT and the business side talked about what had been achieved since the day before and what work needed to be done that day. Previously, a general status meeting was taking place only once a week, with as-needed meetings for testing and issue resolution. Testing meetings also started happen daily. If testing issues come up, separate meetings were immediately scheduled to address them.
• Figure out what benchmarks will show positive progress. Hummel helped develop measurable criteria that needed to be reached to get the project out of Red status.
• Celebrate small successes to boost morale. Hummel highlighted every success she could find, including when people came up with work-arounds for their reporting issues.

The case study explains that with the new focus on developing a collaborative culture, IT and business began to work together in better and smarter ways.

For instance, an IT developer who was creating a hover-over box that displayed visit counts for a patient sent an Email to the business side questioning the requirements. He thought the design would be confusing to a nurse trying to understand the patient’s medical history. That was a great moment, according to one of the team members working on the analytics part of the project. “Rather than business discovering the issue during testing — after design and development was complete — and then fighting with IT over whether or not this was a defect, here the developer understood the user story and challenged the requirements early in the process.”

Stephanie Woerner, a research scientist at the MIT Center for Information Systems Research, notes that while culture change like what WellPoint was attempting is always difficult, the company’s response was effective for moving the process forward. “Everyone in the organization is affected and they all must buy in,” she writes in a commentary that’s posted with the case study. “WellPoint targeted ground-up cultural change by bringing in training, adding resources, and hiring people who had experience with the desired change. WellPoint executives committed their time to the project and created metrics that aligned with the desired changes. And progress was celebrated.”

The case study says that the new collaborative approach is not perfect: Documentation for how things work is often overlooked in the race to get code written and tested, and business requirements sometimes emerge spontaneously. But project leader Chennuru said that he sees a point in the near future where his team can move out of urgent mode.

The case study, which was made possible by Deloitte, also says that WellPoint hopes to have the majority of the physician practices participating in its value based program using the system by 2015. The new model, sometimes called the “shared savings model,” could help physicians increase their earnings by 30 to 50%.

For more on how WellPoint approached this vast analytics project, read the full case study.