Preparing Analytics for a Strategic Role

Introduction

Ariel Bayewitz was beyond frustrated. One of his employees had just quit, saying, “All I do is pound my fist, and I can’t take it anymore. IT keeps saying we’re going to be iterative, but we’re not.”

Bayewitz works in analytics for WellPoint, Inc., a Fortune 50 company, and one of the nation’s largest providers of health care benefits and insurance. He’s one of the leaders of WellPoint’s major strategic initiative to change how it delivers health care in the United States.

WellPoint wanted to shift from a model where it paid physicians based on volume (procedures, visits, admissions) to one where its payments to doctors were based on “value” (ability to manage costs and improve patient outcomes and quality of care). That model is sometimes called the shared savings model, because insurers share any savings with primary care providers. WellPoint has said that shared savings could help physicians increase their earnings by 30 to 50%.

Getting there meant giving doctors data about patients with chronic conditions to help care for them more effectively. WellPoint also wanted to use analytics to spot patients who were likely to go to the emergency room or be readmitted to a hospital. Emergency room visits and readmissions are an enormous expense, part of the reason why U.S. health care’s share of GDP is more than double the average of other industrialized countries.¹ The Enhanced Personal Health Care project was WellPoint’s answer to this problem.

WellPoint had already run nearly a dozen pilots with physicians to figure out how to get them more involved with patient care. These pilots showed improved quality and a decrease in costs, which caught the attention of WellPoint’s executive leadership team. With the potential to reduce costs by 20% if successful — meaning billions of dollars in savings within a few short years — Enhanced Personal Health Care became a company priority.

But after a series of fits and starts, Bayewitz thought a key part of the project was in jeopardy, and needed to be declared “Status Red.” Such a move would send ripples to the very tops of the company ranks.

First, Bayewitz had to convince his boss, Jill Hummel, WellPoint’s vice president of payment innovation. She had been working on the Enhanced Personal Health Care project since the middle of 2011. It was now March 2013, and she believed the project was meeting its goals and was ready to prove to physicians that WellPoint wanted to improve their patient outcomes and share cost savings. WellPoint had:

• delivered new contracts with value-based payment terms;
• signed up physicians to participate in the program;
• assembled the necessary data and analytics to support it; and
• put together a new team to collaborate with participating physicians in population health management.

Bayewitz knew that Hummel was against having the project go into Red status. She had told him and her own boss, Doug Wenners, WellPoint’s senior vice president for Provider Engagement and Contracting: “There are people on this project who are working hard, and have been for months, to make this program work despite the challenges. It would be devastating to morale to do that to them. Most of the project is going well; it’s just this one piece that isn’t working smoothly.”

But the “just one piece” that wasn’t working was the technology underpinning the new strategic initiative. The reports that had been delivered from the IT teams weren’t good enough yet to support the Enhanced Personal Health Care program: they were too basic — static views that needed to be downloaded into a spreadsheets to be analyzed. They also did not work consistently, and many of the processes built to roll them out were manual efforts cobbled together to meet deadlines.

The bottom line was this: it wasn’t enough for WellPoint to just pass along information to help practices manage their patients. The program would succeed only if that information was truly actionable, accurate and timely. It had to be built on a solid foundation.

But to Bayewitz, the technology behind WellPoint’s key strategic initiative looked like a house of cards. And it was beginning to wobble.

Bayewitz shifted in his chair, and began typing Hummel an email.

Uncovering the Implementation Challenges

This difficult predicament was not what Bayewitz had envisioned when Hummel called him in the summer of 2011. Hummel had just been named vice president of payment innovation, and wanted Bayewitz to join her team. Hummel knew him well. He had worked for her for several years, and she knew he was creative and could figure out new ways to solve problems.

He was excited about the chance. Bayewitz joined Empire Blue Cross Blue Shield in 2005, when it was acquired by WellPoint. He was 25, fresh from getting a Master’s of Public Health at Columbia. At WellPoint, he did analytics and financial modeling used in negotiating provider contracts.

Enhanced Personal Health Care was different. It represented a complete change in the way the company engaged providers, moving from a transaction-based relationship to a collaborative and interdependent one. It could bring down the overall cost of care and improve people’s health. “It’s cutting edge,” he had thought to himself.

He started in his new job in August 2011. He liked that the models he’d be working on applied to all members, not just subsets of them. This included members regardless of whether they were covered by one of WellPoint’s products, or an arrangement with a large national employer, or whether they resided in one of the company’s 14 local markets.

Bayewitz’s excitement about something new and big was exactly why Hummel called him in the first place. She knew the Enhanced Personal Health Care program represented a fundamental shift from WellPoint’s current volume-based payment model — and that one of the key underpinnings of this new model was a solid data and analytics foundation. “It required us to change the way we do business, the way we use our information,” Hummel says. Bayewitz was the right person to help take WellPoint’s wealth of data and convert it into information that could be easily acted upon to improve health care quality and cost.

Hummel hadn’t told Bayewitz her own concerns about the challenges they would face. They’d be building a complex, important program from scratch, in a relatively short period of time, with an IT team that was not known for its consistent execution. “I thought I was being set up for failure,” she says.

For one thing, data would have to be integrated from 14 separate health plans with inconsistent approaches to defining similar types of data. The whole system would need to be scalable, which would require many significant changes to WellPoint’s operating systems. The IT team had little experience producing systems for external use.

The sheer inertia of the market was also an issue. Physicians in the U.S. get paid when they see a patient. There are exceptions — concierge practices charge a retainer, for instance. But the health care system is built around transactions — visits, tests, procedures. Patients suffering from chronic conditions don’t fit into this model. Their care involves giving themselves daily insulin shots, taking prescribed medications, following certain diets or exercise regimens. There’s no financial benefit for doctors to follow up with patients in between visits.

There were two interrelated steps WellPoint could take to change this dynamic: one was to promote accountability by physicians for the quality and cost of the care they deliver, by giving them quality and cost targets and rewarding them financially, generally with a percentage of the savings, when they met these targets; another was to foster the creation of a “medical home,” which has nothing to do with where patients live, but involves reimagining a medical practice as a home base for patient care.

Under this new combined model, primary care providers, supported by a care team, take on a primary role in managing the overall care their patients receive, whether that care is delivered in their own practice or at other sites across the health care system. To effectively practice under this type of care model, physicians must have broad visibility to the care their patients receive and must be active participants in their ongoing care planning.

WellPoint knew it could play an important role in this transformation by changing its compensation models and giving providers the tools and resources they needed to successfully shift to this model of care.

Convincing the Physicians

Hummel knew the program would need good data, and for that she had tapped Bayewitz. But that wasn’t enough. She also had to build an organization that could win the trust of doctors. In November 2011, Hummel hired Julie Schilz, who had developed a Primary Care Transformation program for the Colorado Beacon Consortium.

Schilz was point person for WellPoint’s relationships with doctors. The lack of trust was evident immediately, Schilz says. “They were just very direct: ‘We’ll believe it when we see it,’” she says. “They were worried that we wouldn’t follow through.”

Doctors tend to see insurers as something like overlords, says Daniel Waszkowski, MD, the director of quality at New Hampshire’s Derry Medical Center. “They want to give us as little as possible and have us work as hard as possible, in order to make money for the insurance company,” he says. But his practice was a medical home, and he was very hopeful that WellPoint would deliver on its promise.

There was flat-out excitement at Northern Ohio Medical Specialist in Fremont, Ohio. Jennifer G. Hohman, MD, was helping NOMS to start a medical home when WellPoint came knocking. “In the past, it’s been kind of an adversarial relationship” between insurers and doctors, she says. “Asking permission to get testing done and medications your patients need — it does cloud the relationship sometimes.”

But for the medical home concept, she’d need better data. WellPoint could give her data she didn’t have. To Hohman, it sounded like a gift.

Schilz could also point to WellPoint’s pilot projects partnering with physicians to develop new models of patient care. Those projects gave her data to show skeptical doctors, and also helped her find champions, physicians who wanted to see the system change. And she made sure that WellPoint did the things it said it would, right down to making phone calls when it said it would.

Even so, she was a department of one, and a patient-focused job like hers hadn’t existed before at WellPoint. The company had never offered per-member, per-month payment contracts before, either. That took work to explain and negotiate. Doctors needed to know what value they were being measured on and how it would be delivered.

“You can’t just say, ‘oh, here’s a new payment model, good luck. See you in a year. We hope you succeed in your shared savings program,’” Schilz says.

WellPoint had to develop content to explain the new way of doing business and hire people who can act almost as coaches for the practice, interacting regularly with them. Schilz spoke with Bayewitz almost every day, as they reviewed the data WellPoint had and discussed what would be most useful to physicians. In August 2012, she received budget approval to add staff, including newly created positions such as clinical liaisons, patient-centered care advisors, and community-transformation managers — all roles designed to enhance the company’s collaboration with providers.

The goal was to launch the new program in January 2013.

Cold Reality of the Data Integration Challenge

If WellPoint was going to change its way of working with doctors, there was a lot of work to be done, Bayewitz quickly realized. WellPoint’s data sets, aggregated from 14 different businesses, didn’t treat data the same way, and wouldn’t be easily integrated into a product that could give doctors a useful overview of their patients.

By February 2012, Bayewitz, working with Schilz and Jen Clair, WellPoint’s staff vice president of advanced analytics, had established the data he thought he would need to put into the system. A month later, all the major stakeholders from across the organization met to identify the data reports that would be the heart of the new system. These stakeholders included Hummel’s payment innovation team, care management, analytics, and IT, along with WellPoint’s Resolution Health unit, which managed data across its systems, and Information Management, a separate unit from IT.

The plan from that meeting was clear: have 10 static reports ready to go by September 2012, and then deliver an integrated reporting application, with dynamic drill-down capabilities, by January 2013. (See Table 1.) It was a top priority to give providers the ability to pull the initial static reports into Excel so that physician practices could use them offline to preemptively identify patients in the two highest-cost categories: avoidable emergency room visits and unnecessary hospital readmissions.

There was a lot of money at stake. The median price for a visit to the emergency room was $1,233. Meanwhile, the average cost for a hospital stay in 2011 was $10,000 — $12,600 for adults between 45 and 84.

At the time, Bayewitz was very excited. “It was a great kick-off meeting.”

Hummel believed that if her team could take an incremental approach and keep things simple — focusing on finding the three to five things needed to get the Enhanced Personal Health Care program off the ground — it would happen. “We had to not let ‘great’ be the enemy of the ‘good’,” she says. One of those things was identifying five essential types of data for physicians:

1. physician’s total patient population
2. patients with gaps in care
3. patients visiting the emergency room
4. admitted to the hospital, highlighting those high risk for readmission
5. high-risk patients to focus on with actionable information around their risk drivers

That last, predictive report was paramount. WellPoint called it the Hotspotter report, which identified the top 2.5% of high-risk, high-cost patients.

After the March meetings, Bayewitz got to work trying to make sure the data for the reports would be ready to go. There would also be a lot of waiting, since the program’s IT team operated under what’s called the waterfall development model.

Waterfall processes adhere to a specific workflow, and projects proceed from step to step. It approaches software like a factory process, with defined stages that move sequentially forward but never back. Business would submit a project’s entire requirements up front, IT would then design the project, and finally the full product would be tested and released.

But a problem at one stage could compromise the whole project, and the business might not realize there are issues until the final product is tested immediately before release. There is limited opportunity for business to reassess and reprioritize midstream, which is a real problem when an organization is trying to be current and innovative.

IT also wasn’t used to doing work that would be seen by outsiders. Its deadlines were internal ones; if something slipped, WellPoint could adjust. In this kind of program, however, the stakes were high. If deadlines were missed, WellPoint would fail to deliver the promised information to its physician partners, having an adverse impact on its credibility, trust within the provider community and market reputation.

Developing business requirements took months using WellPoint’s process, which involved trying to repurpose standardized solutions. There was limited prototyping, making it hard to see what was being done. Updates from IT typically happened monthly. At one point, it became obvious that there would be no September pilot, because the hardware needed to run the reports hadn’t been purchased. And as November turned to December, it became clear that technological problems were looming.

Hummel had a contingency plan. The public date for launching the Enhanced Personal Health Care program was January, and the contracts WellPoint was negotiating wouldn’t start until then. Schilz’s team would be limited to demonstrating mock-ups, but it could make do. January itself was a soft-launch date — WellPoint would begin engaging participating physicians differently, educating them on population health management but would not start measuring shared savings for the initial practices until April.

Aside from giving practices the opportunity to prepare for the new payment model, it gave WellPoint some wiggle room in the event that the initial reports were not delivered in January as planned. Moving to a shared-savings model was dependent on being able to deliver the necessary data.

Seeing Red

When the IT team delivered its first report in December 2012, Bayewitz was stunned — it didn’t actually work in Excel. True, the report could be downloaded, but it couldn’t be sorted. “It might as well be a PDF,” he recollects thinking. The point was to give physicians content they could do something with. If they couldn’t sort it, they couldn’t figure out which patients would benefit most from their help. Schilz, the point person for WellPoint's relationships with doctors, had emphasized this from the start; her team would be something like beta testers in software, and flag issues. It was clear, however, that IT didn’t understand what someone would do with the data once it was in Excel.

Now that a report existed, Hummel found herself negotiating with IT over things that astonished her. To her, features that didn’t work as expected were things IT should fix. IT viewed these as changes to what it delivered, and required formal change orders, so it could account for them in its budget. Hummel sometimes felt like the teams were spending more time discussing whether something was a change than doing the work.

In retrospect, Hummel acknowledges that sometimes these really were changes. “The difference between what was in our head and the requirements developed wasn’t evident to us until we saw the end product after a lengthy development process. IT was following the recipe, but sometimes we had listed the wrong ingredients.”

Finally, in February 2013, the first three reports became available. All had problems. Schilz’s team found, for instance, that different units within WellPoint reported an emergency room visit in different ways. The IT team’s explanation: no one told it the definitions had to be the same. That much was true — the business side didn’t think it should have to specify that emergency room visits be defined consistently across reports.

For Bayewitz, his concerns began to mount. These were simple reports, much simpler than WellPoint’s true goal: dynamic reports driven from smart dashboards that would seamlessly fit into a practice’s workflow and allow physicians to drill down into records quickly. Those were supposed to be available by the end of 2013 — only nine months away. If WellPoint could not develop these simple reports, how would it deliver the dynamic dashboards?

Bayewitz worked with others to develop another approach to address these issues. Within the field of software development, an approach called “Agile,” or iterative development, was on the rise. Agile had two benefits over Waterfall approach. One was a focus on “user stories” over requirements. “If you want to teach people how to assemble a bike, before getting into any of the technical details, you should start with telling them first who uses it and what for,” says Bayewitz. “No one would ever sell a bike with a flat tire or a broken chain, since the bike won’t ride; they don’t need requirements to tell them the bike should be rideable.”

The second benefit of Agile was that requirements, development and testing would be bundled in iterations. A given product release undergoes numerous iterations which allows a business multiple opportunities to reassess and reprioritize needs on an ongoing basis.

Bayewitz asked Hummel about using the Agile approach for this project. When Hummel inquired about the idea, however, she says she was told the program’s IT team had already undergone extensive training on iterative development and was, in fact, iterative in its approach to software development. Yet this didn’t appear to be the case to Hummel and Bayewitz.

Looking back, Hummel says that this type of change required much more than training. It required a change of culture within the departments, with the leadership championing the Agile approach and reinforcing it by rewarding behaviors that demonstrated adoption. “If the leaders don’t lead by example, set clear expectations, and reward and celebrate achievements in shifting to a new development paradigm, behavior doesn't change,” she says.

Hummel did not want to see her project escalated to Red status. While the technical portion was troubling, other parts of the project, like Schilz’s, were going well. She worried about the message that going Red would send to a team she knew was working hard and under stress. She didn’t want to see morale fall any further. But she trusted Bayewitz, and even her boss, Wenners, was beginning to question the status of the project given the challenges with reporting.

In April 2013, Hummel told Wenners the project should go into Red status.

Plunging Into Red

The decision to go Red cascaded through certain areas of the organization. The company’s top leaders began meeting about the project every week, where problems were escalated to ensure rapid resolution. WellPoint also committed more resources to the project, including bringing in Deloitte, an outside consultancy with expertise in helping companies adopt Agile, and hiring employees with Agile experience. All in all, WellPoint would spend $50 million on the Enhanced Personal Health Care project in 2013.

At the same time, new leadership emerged in other areas of the company, including IT. In April 2013, Ashok Chennuru was put in charge of the project. Chennuru was both a staff vice president of technology at WellPoint and steeped in the medical field: he was married to a physician and descended from generations of physicians. Chennuru had helped build the business case for the project at its beginnings. And he was responsible for data quality across WellPoint.

Chennuru had already had a few days upended by the project back in September 2012, when the project missed its first deliverable. Chennuru was supposed to be speaking at a conference, and had checked into his hotel at the Orlando Convention Center. He never made that speech. Instead, he worked steadily for the next 28 hours on a document showing how data moved from different systems within WellPoint into the data warehouse then out again, to help get a handle on some of the data quality issues they were having.

“From there it was one Band-Aid after another,” he says. IT was fixing some problems, others were slower to get resolved, and Chennuru could tell that Hummel and her team on the business side were losing confidence in the ability to deliver the project from a technological perspective. “Things were growing intense,” Chennuru says. “We lost a few good people because they didn’t really want to deal with this kind of pressure.”

When Chennuru took control of the whole technology side, he had fires to put out. For instance, data need to be pulled manually from databases, sent via FTP to the data warehouse, and manually extracted to the reporting system. It was slow and clunky, and each data transfer required a ticket to be opened. Those weren’t always closed quickly, due to internal service level agreements WellPoint had with a subsidiary.

Plus, as Hummel had anticipated, moving to Red status hurt morale in IT. “It was not motivating, let’s put it that way,” says Anil Loomba, a business intelligence solutions engineer with WellPoint based in New Hampshire, who came in to fight fires in December 2012. After a series of 90-hour work weeks, he felt by April that they had been making good progress and they were on track to meet the next goal in the timeline.

Hummel didn’t call an all-hands meeting, but stressed in her conversations with managers that going Red meant the project would get more resources. She worked with Bayewitz and other team members to develop measurable criteria that needed to be reached to get the project out of Red status, such as two successful releases for the “day-one” or static reports. And she celebrated every success she could find, including work-arounds for their reporting issues.

As the reports came out, Schilz’s team started working with them, and helping doctors to use the reports. However, there were issues with the data.

In Derry, New Hampshire, Dr. Waszkowski wanted to use the Attribution Report, meant to tell the practice which patients qualified for the Enhanced Care Management Program, but the report was irritating — it didn’t match the number of WellPoint patients that his systems said he had. Meanwhile, the Hotspotter report had a clunky interface that made it difficult to use. It worked better in Excel than online, but even so, it produced perhaps five patients that were high-risk, not enough to create real benefits for either the practice or WellPoint. Still, he thought the reports were giving him valuable information. The zinger: he learned from the ER report that one of the practice’s patients had been to the emergency room 16 times in one year.

Emergence of a Collaborative Culture

Escalating to Red status did have a big impact on the program’s IT team. Besides bringing in a consultancy to smooth the transition to Agile, WellPoint management opened up new jobs, so the company could hire IT and business people who had worked in Agile environments. There was also a major reorganization in the IT department in May 2013.

And with a new, collaborative culture emerging, IT and business began to actually work together. One day, Bayewitz forwarded Hummel an email from an IT developer who was creating a hover-over box that displayed visit counts for a patient. In it, the developer questioned the requirements, which he felt would be confusing to a nurse trying to understand the patient’s medical history. “It was incredible,” Bayewitz recalls. “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.”

By June, project teams were 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. Under the waterfall regime, a general status meeting happened only once a week, with as-needed meetings for testing and issue resolution. In Agile, testing meetings also happen daily, and if issues come up, separate meetings are immediately scheduled to address them. Bayewitz liked it because he also knew when there were problems. “In Agile, we see when problems arise immediately, and we’re part of the troubleshooting,” he says.

In August, WellPoint hired Prasad Annambhotla to become a delivery lead, working on data quality for the database. Annambhotla had spent 22 years at IBM, and by the end of his time he has become an “Agile coach,” someone who had helped others learn how to work in an Agile environment.

It was his job to help get the dynamic dashboard out. Annambhotla says when he started, the project was in “a little bit of a mess. I don’t know what other word to use.” He knew Agile was a challenging transition: people resist shifting from waterfall because they’re used to doing things a certain way. “Unless management puts its foot down, no one is going to sign up for this,” Annambhotla says.

Agile requires commitment from management. Someone from the business side needs to be in a scrum every day, different from traditional waterfall approach. Bayewitz and IT management participate in a “scrum of scrums” twice a week so they can track all of the activities and risks captured in the daily individual scrums.

It’s this tight interaction between the business side and the IT side that makes it work. The business becomes part of the development process. It helps to assess project progress.

The business side and IT side also work together to set, and shift, project scope. Deadlines are imperative in Agile — they cannot be missed. One practical example came in December 2013, as the Enhanced Personal Health Care’s dynamic dashboard was being launched. Some important historical data was missing from data fields for one provider. The data they were using had only been pulled into the datamart the weekend the project was set to go live. It wasn’t planned that way, but the data team, which had not adopted Agile, had slipped its deadline. Instead of holding off the release date, Annambhotla and his business customers scaled back the launch, from 11 providers to eight. If necessary, he says, they would have launched the report for even fewer providers. That’s how Agile works.

Six months after WellPoint began shifting the way the IT department and business side worked together on the Enhanced Personal Health Care program, Anil Loomba says it has created dramatic change in the process. Issues are found and fixed more quickly.

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 Loomba, in large part, does not miss the old style of working.

Chennuru, who has worked every weekend since the September troubles, sees a point in the near future where his team can move out of urgent mode. He sees a schedule of releases every two to three months.

Positive Outcomes

Doctors like what they’re seeing, too. Hohman uses the word “love” to describe the new Provider Care Management Solutions (PCMS) reporting application, which shows patients overdue for routine work. She says she wishes all the insurers would work with her practice in the same way. Waszkowski is cautiously enthused. He says its drill-down capability helps him quickly spot patients overdue for a visit, and sets WellPoint apart from insurers like Cigna and Harvard Pilgrim, who only have static reports.

“Nobody has that — no one,” he says. One doctor who declined to participate in the initial pilot because of its issues was Frederick Kelsey, M.D., medical director at Mid-State Health Center in Plymouth, N.H., an 8-doctor non-profit practice with 77 support staff, including nurse practitioners and clinical psychologists. The new dynamic dashboard “is quite impressive,” he says via email.

Hummel is happy to say she was wrong about not wanting the project to go into Red. Doing so created an opportunity. That’s not always the case with companies the size of WellPoint. But here, it presented a teachable moment. People and teams came together. They shared information openly. Solutions were devised and delivered. And this is what basically saved the project. On January 30, 2014, it moved out of status Red.

For Bayewitz, there’s real satisfaction. He foresees a successful broad release in September 2014 of a system that combines the reporting tools with a financial scorecard that will show practices how well they are doing, based on metrics. It might just be the ground floor, but it’s built on a far more solid foundation than the original project.

And it’s key to creating a healthcare system defined by value, not the volume of services delivered. WellPoint hopes to have the majority of the physician practices participating in its value based program using the system by 2015.

Over time, WellPoint believes that the proactive, coordinated-care model made possible when providers have actionable insights at their fingertips can cut health care costs by as much as 20%. That could work out to billions of dollars, given that WellPoint reimbursed more than $99 billion in health benefits for commercial and individual members in 2013. None of us need complex algorithms to understand the impact of those numbers.

Commentary: Capitalizing on Data by Building Organizational Capabilities

Stephanie Woerner

WellPoint’s effort to update its digital business model by changing the nature of its revenue structure is similar to many of the IT-enabled organizational transformations that we’ve studied. In this time of fast-growing enterprise digitization, companies are finding it necessary to build platforms and services to leverage the data they collect and then deliver it to customers if they are going to do business in new and different ways. Embedding data analytics into its workflow and creating actionable insights for doctors from that data is an ambitious goal for WellPoint, and its stumble on the path to it is not unusual; their recovery from that stumble, however, shows great organizational flexibility.

Three practices underlie WellPoint’s success in this new system: treating the revised project as a cultural change, creating incremental goals, and focusing on the customer. Moving to a Red status may have seemed like an admission of failure, but the executives at WellPoint used it as an opportunity to create new organizational capabilities.

Though a waterfall approach has long been used to spec and develop projects, especially in large enterprises, most companies find it difficult to create accurate specifications. Reasons include a lack of people who understand both the business and IT sides of the equation and a lack of history to draw from. For these reasons and others, over 50% of major IT projects fail. And even when they’re completed, we find companies are not generating the value that they expected. Agile development works for these projects for a number of reasons because it (1) allows the project to fail fast and for interventions to take place early as the team iterates, (2) creates an environment where business and IT must work together and makes project success a joint responsibility, and (3) focuses on the user. But moving to Agile is a huge cultural change.

It’s hard to change a culture. Everyone in the organization is affected and they all must buy in. 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.

This leads to the second success factor. By moving to Agile, WellPoint leaders had perfect opportunity to put the focus on incremental goals and successes. Big goals (those BHAGs [big, hairy, audacious goals] we’ve all heard about) can be motivating in the short run because they signal out-of-the-ordinary targets. However, those kinds of goals can be quite demotivating in the long run, if there are no parallel incremental goals, because there is so much opportunity for failure and only one opportunity for success.

There are two places that WellPoint took an incremental approach. One was in their identification of a small number of must-have data types for the program to be initially successful. We’ve found that great, actionable data is rarely available from day one.

Instead, we see leaders demanding one or two data types and then making operational decisions based on that data. Once a certain type of data becomes a critical input to decisions (and incentives), we see a renewed focus on data improvement in the enterprise. And then it becomes easier to expand the efforts to capture and improve additional data streams.

The second place with incremental goals was in the revised development of the Enhanced Personal Care Program itself. Rather than waiting until the end of the development to assess the overall project, the focus became smaller, modular parts of the program. It’s much easier to diagnose and fix problems in contained modules.

The third practice that helped ensure program success at WellPoint was an effort to think about the problem from the point of view of the customer. We have found a hallmark of success in a digitized company is a relentless focus on the user. Putting customer experience at the center of product development makes good sense — in WellPoint’s case, that means providing timely, accurate, actionable information in an easy-to-use format for doctors. WellPoint knew that the success of the program rested on getting doctors engaged and using the system. Getting them data that was up-to-date and easily analyzable and interpretable was key to increasing that engagement. Once the program went to Red status, the user viewpoint moved front and center. We see developers thinking about users as they write code.

Where does WellPoint go from here? One direction is to involve doctors more in the updates. Leading firms are not just storyboarding products and services but are increasingly engaging their customers in the design to deliver new, innovative solutions. Doctors will be able to suggest new data types and analyses that may not occur to developers and others in WellPoint. A second direction is to expand the use of Agile methods to other IT projects and programs.

With this program, WellPoint made a huge cultural shift, bringing the IT and business together and changing the way people are working inside the company. It’s a good start.

Stephanie Woerner is a research scientist at MIT Center for Information Systems Research. She can be reached at woerner@mit.edu.

Commentary: Technology Solutions for Health Care Need a Continuous Process

Sam Ransbotham

Many unsustainable aspects of our healthcare system can be improved with technology. Opportunities abound with evidence-based medicine, population health analytics, in-home monitoring, as well as with data-driven incentive systems. Organizations like WellPoint can strategically capitalize on the inevitable disruption — or be left behind by competitors that do.

WellPoint’s laudable efforts to use technology to improve health outcomes and lower costs recognize the physician context and use an incremental approach designed to build the credibility required to launch the company’s new provider payment system. They conducted “nearly a dozen pilots with physicians” and focused on “three to five things…to get the Enhanced Personal Health Care program off the ground.” All bode well for achieving significant cost reductions for WellPoint (“20% if successful”) and for earnings increases for physicians (up to “50%”), not to mention the promise of enhanced healthcare outcomes for WellPoint’s subscribers.

Even if WellPoint had the perfect technology, however, the challenge of organizational change would be daunting. WellPoint is attempting to introduce new technology and revamp deeply entrenched compensation systems that reflect diverse incentive structures. Despite trying to minimize the program’s scope, WellPoint still had to integrate data from “14 separate health plans with inconsistent approaches to defining similar types of data.”

This is not unusual — I suspect the new provider payment system uncovered many system integrations put together with duct tape under tight acquisition deadlines. The organizational problem was complicated further by tight deadlines that prevented the IT team from mastering these issues. Ideally, the company would have had the time to decouple certain technology issues from the rest of the program and effectively address them before rolling out reports to providers.

But the reality is that the program team was under significant pressures to simultaneously meet deadlines, adopt a new software development approach (new for them at least — Agile is now a well-recognized approach in the software field), overcome data integration challenges and create a novel product for use by external stakeholders. Given the complexity of the undertaking, it is not reasonable or cost effective to expect IT to become experts in the intricacies of the insurer–provider relationship.

An alternative approach would be to focus IT on areas in which their expertise can be most effective — such as providing technological infrastructure, harmonizing systems and data, and creating components for use by domain experts. Timely, quality data is fundamental to the success of the new system, and IT has exclusive knowledge about the strengths and limitations of WellPoint data. Conversely, IT does not have idiosyncratic capability in the reporting tool. Furthermore, this approach builds off the existing expertise that the internal IT group has in building deliverables for internal customers and avoids introducing the new dynamic of building deliverables for external customers.

What should WellPoint do next? The team should replace the current project approach with a process approach that addresses three distinct perspectives— information technology, business processes, and human elements.

First, the current approach aims at delivering a reporting tool that meets external needs on an ongoing basis. Even if it were perfect at the start, the tool will need to evolve. Processes need to be put in place to develop this information technology —the Agile approach is just the beginning. Future acquisitions, adoption of new medical or administrative systems, integration of interesting external data, etc., will all present new opportunities and require iteration.

Second, WellPoint should plan for changes beyond information technology, as experience with the shared-savings model suggests refinements, such as collecting and integrating lessons learned from physicians into the reporting tool. Even if the changes themselves are not yet known, the expectation of change is known. Business change is itself a process that can undergo change.

Third, as the data and reports become more functional and transition from being novel to routine, WellPoint will need to continue to encourage adoption and use of information in decision making by physicians and ensure that data collection and dissemination by the 14 regional businesses abide by a common set of goals and language. In the history of IT, shelfware is all too common; many current analytics initiatives will unfortunately meet the same fate. To achieve the profound potential of this initiative, processes to nurture the use of analytics and provide feedback on data-based decision making will help avoid ruts.

Analytics of the future will be increasingly real time and require iterative, incremental approaches well-suited to an Agile approach. This approach is not a panacea; however, by incorporating learnings from both the advantages and disadvantages of Agile software development practices, WellPoint can build an ongoing process around their information systems, business processes and people. A possible 20% cost reduction may have been a siren’s song; instead, WellPoint should target 2–3% reduction with each iteration and plan to iterate continuously. Each iteration would demonstrate efficacy, add experience, and build credibility with the critical physician population.

Sam Ransbotham is an associate professor of Information Systems at Boston College. He can be reached at sam.ransbotham@bc.edu.