How collective intelligence can prevent business meltdowns

Image from
Jun 03 2019 by Rod Collins Print This Article

On April 19, the car rental giant Hertz hit its former digital services partner Accenture with a $32 million lawsuit claiming breach of contract for a failed redesign of its website and mobile apps. Hertz hired the consulting firm in August 2016 to redefine the customer experience on its online platforms. The new tools were to be available in January 2017. However, after Accenture missed two deadline extensions and requested an additional $10 million over the original $32 million already paid, the car rental firm lost confidence and terminated Accenture’s services.

Some of the problems cited in the lawsuit included Accenture’s failure to incorporate a digital design that would scale to different devices, the lack of a common core of libraries across all its brands including Dollar and Thrifty, and insufficient testing of the software it developed.

Accenture disputes the claims and has issued a statement through a spokesperson that said, “We believe the allegations in this lawsuit are without merit, and we intend to defend our position.”

We don’t know all the facts in this dispute nor the extent of the responsibilities for the flawed project. However as Liz Miller, senior vice president of marketing for the CMO Council, told CMS Wire, the project “was a catastrophic relationship meltdown of epic proportions.”

If Miller is correct, it begs the question of whether this breakdown could have been avoided. And if so, how? The answers are important because anyone who has worked in a business for an extended period probably has a story to tell about an actual or near catastrophic meltdown. These meltdowns can happen between unrelated parties or among different areas within organizations. Understanding how to avoid them can literally save millions of dollars, as I personally learned when I encountered just such an issue some years ago.

A Serious Problem

When I arrived at the office on May 8, 2002, I expected another ordinary work day. A few months earlier I had been appointed the chief executive of the Blue Cross Blue Shield Federal Employee Program (FEP), an alliance of the then 39 independent Blue Cross Blue Shield organizations to provide health insurance for U.S. federal employees.

The business was on solid ground with happy customers, affordable premiums, and extensive provider networks. The major project for the year was the installation of a new claims processing system that was to go live on January 1, 2003. Up to this point, everything appeared to be moving according to schedule.

Over the previous evening, we had run the first major test of the new claims system. Two managers were waiting to see me when I arrived on that Wednesday morning to inform me that the test was a disaster. Nothing worked as expected and there was an infinite list of problems to be fixed.

But what made the situation particularly problematic was that while we knew the overall system wasn’t working, we had no usable data on the performance of the individual companies. Consequently, we had no idea where to focus our work to correct the problems. We had no analytics to guide the building of an action plan, and without a plan, organizing our efforts would be a misguided shot in the dark.

An Innovative Way to Build a Plan

One of the reasons that our business had been doing so well is that our leadership team was highly skilled at leading networks, which is a very different challenge from leading top-down hierarchies. In particular, we were highly proficient in leading-edge ways to rapidly aggregate the collective intelligence of our people in large group facilitated sessions and to use this unusual asset to guide us in crafting product strategies and improving our regular business processes. As we pondered how to build an action plan in the absence of specific data on each of the independent companies, we decided to explore if collective intelligence might serve as a useful guide.

The following day, we assembled a meeting of forty members from our central office staff. In addition to people from our systems and operations areas, we had representatives from every functional group and every level. I opened the meeting by explaining that our task was to place the names of every one of the thirty-nine companies in our alliance on one of four flip charts at the front of the room.

Each chart had a different color written across the top of the page. Blue meant that the group expected the company would perform well without needing any help from our central office. Green was for companies that were likely to perform well but might need for us to check with them periodically to make sure that they didn’t go off course. Yellow designated those companies that would need to be managed very closely because they were likely to be the ones driving the problems we experienced in the test. And finally, Red was for those companies that would likely fail and where no amount of tactical intervention would make a difference because the local CIOs had elected to assign minimal resources to the systems conversion project.

I then reviewed the two rules for color coding each of the companies. The first rule was that no company would be listed on the flip charts until there was unanimous agreement among all forty people. The second rule was that no one should go along with the group just for the sake of moving us along. If even one person truly felt the color designation was wrong, she had an obligation to continue to present her concerns until she was satisfied, because she might be seeing something that no one else recognized. This second rule was most important because it helped ensure that we were tapping into collective intelligence rather than groupthink.

It took us the full three hours to categorize all the companies. When we were done, we had our corrective action plan and a shared understanding about where to focus our work. We left the Blue companies alone, periodically checked in with the Green companies, and worked very closely with the Yellow companies. As for the Red companies - there were two of them - a phone call was made to each of their CEOs to put in place the resource commitments necessary to move those organizations to the Yellow list.

Gathering Everyone into the Same Space

Once we had our plan, we put in place a continuing practice to accelerate the collective intelligence distributed throughout the thirty-nine organizations. Every Friday afternoon, we held two-hour conference calls that were open to anyone in the Blue Cross and Blue Shield organizations who worked with FEP. The calls were forums for updates, problem solving, and the sharing of best practices. These facilitated conversations were open and candid, and when word spread of the real progress we were making, a surprising and unexpected thing happened: both the business and the systems staffs began showing up on the calls.

When we first put the weekly calls in place, we had intended them for the systems staff at the various Blue Plans throughout the United States. When the business staff began participating in the calls, we realized that we had stumbled into a way to effectively bring both the systems people and the business people together in the same space.

The benefits of this regular cross-fertilization were immediate and powerful. Because systems requirements - like everything else in fast-changing times - keep evolving, continual connection between the systems designers and the end users is essential if systems initiatives are to succeed.

When you meet in two-hour conference calls in open conversations every week, a community of systems and business partners starts to form, and the participants begin to find each other off-line when issues arise. The shared understanding that evolved over the course of these conference calls drove a level of execution that clearly exceeded our expectations. When we threw the switch on the new system on January 1, 2003, not only did the system work as designed, but remarkably, we did not have a single customer-facing issue. Thanks to our capacity to aggregate and leverage collective intelligence as well as our commitment to find a practical way to gather everyone into the same space at the same time, we successfully avoided what could have been a catastrophic meltdown.


About The Author

Rod Collins
Rod Collins

Rod Collins is the Chief Facilitator at Salt Flats and the author of Wiki Management: A Revolutionary New Model for a Rapidly Changing and Collaborative World (AMACOM Books).