Competing With Data & Analytics
What to Read Next
Already a member?Sign in
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.