If you were tasked with creating an analytics team in a healthcare provider organization, where would you start? How would you structure it, staff it, run it and grow it? What activities would be in scope for the team, and what would be out of scope? And perhaps most importantly, how would you demonstrate value to the organization?
Recently I had a chance to work with a top-notch analytics development and support team at a progressive healthcare provider organization. Over the years, I have seen and worked with a number of very good teams in a variety of industries. This one, however, is highly effective in demonstrating its value to the organization, as well as engaging the full horsepower of team members to create that value.
Your analytics development and decision support group structure, size and activities may differ a bit, but there are some key lessons to be learned from studying this example. One of the most important lessons I learned was that each person, in their own way, demonstrates a profound professional maturity. Even if this group was just a loose collection of individuals, this one quality alone might be enough to make them highly effective. But this group takes it several steps further with strong purpose, strong methods and equally strong backgrounds.
Setting and Characters
The decision support team in my story works within a progressive, integrated delivery network of three hospitals and several dozen primary care and specialty clinics. In addition, they have a behavioral health division, a durable medical equipment business, several in-house pharmacies and labs, some long-term care units, and a wide variety of professional and patient education operations. They also do a substantial amount of work on community and patient outreach through schools, wellness events and both urban and rural community centers.
For the past three decades, the organization has been working hard to integrate the business, clinical and operational aspects of the enterprise to be more streamlined and more cost effective. Analytics has been a key part of this journey, but as in many organizations has only been formalized in the past few years.
Decision support is part of the organization’s quality and information services group, along with regulatory compliance, patient safety, clinical informatics, information technology and program/project management. In line with lean and Toyota Production System (TPS) methodologies, decision support forms part of the organization’s “system of measurement.”
The analytics team has 22 people and is made up of a roughly equal number of three types of roles – six business analysts, five data analysts and seven nursing informaticists. In addition, there are four people who have specialized roles, and whose duties shift from project to project. One is an analyst who administers the organization’s scorecard system. Another is an analyst whose job it is to develop statistical models for the organization to improve efficiency and timeliness of care. A third is a floating strategic business intelligence requirements analyst whose role follows implementation of major operational software applications around the enterprise. And the fourth is a scrum master for the group, as they are using an Agile development methodology.
The team’s background includes four people from business intelligence consulting, three from a highly successful retail data warehouse team across town, an industrial engineer, a former network administrator, one from facilities management, one from project management at a healthcare payer, six nurses and two IT professionals who have decades of experience with acute, ambulatory and ancillary services reporting at the organization. Taken together, these people know, or know somebody who knows, the answer to virtually any question the group is asked.
The leadership of the analytics group includes a team leader (manager, but more) who reports to the vice president of the quality and information services function. The team leader’s job is to champion and sponsor the group’s activities, including promoting it, funding it, protecting it and funneling the never-ending stream of requests appropriately.
Analytics at the organization are developed in four-week sprints, which are based on a product backlog assembled through a combination of strategic requirements, product improvement initiatives and daily requests. All of the industry-standard Agile methodology components are used, including daily scrum meetings, sprints, user stories, a product and a development backlog and the pre- and post-sprint reviews.
Agile fits right in with business intelligence development methodology, which emphasizes an iterative approach. In addition, it fits with the organization’s lean/TPS approach. Analytics are delivered frequently, in right-sized chunks and are subject to continuous improvement.
Critical Characteristics of the Analytics Team
As mentioned, the team is fairly new. Previously, decision support was provided to the organization through an informal network of ad hoc report developers scattered around the organization, or through a couple of overworked, underfunded report developers working in IT.
Being new, the analytics team is still in the “forming” stage of the “forming, storming, norming and performing” cycle. Despite this, the team seems to be leapfrogging the storming and norming stages right to the performing stage. I had the chance to see them on a daily basis, and noted how fluid they were in pursuit of their goals. They would form one subgroup to tackle a particular task in the early morning, then another task at mid-morning with another sub-team, and two more task with two new sub-teams in the afternoon. It was fun to watch and impressive to see.
The number one characteristic that made the team function so well was professional maturity. The seniority of the group ranged from four months to forty years with the organization. Nevertheless, the elders asked questions of the juniors, and vice versa. No emotion was involved except purposeful helpfulness. I learn, I win, youlearn, you win, the team wins, the organization wins, and ultimately the patient wins.
For example, the more senior people know the complexity of healthcare data. The source systems are varied, and the compliance and management measures are intricate and sometimes overly complicated. A single measure, for instance, may be required by five different governmental or non-governmental organizations, but be called five different names. Conversely, what is called one name by five different requiring organizations can actually have two or more definitions. Add to this the current state of healthcare analytics, where even seemingly simple concepts are subject to legitimate debate. For instance, what is meant by a clinic visit by a patient? Or for that matter, what is the definition of a unique patient across the system?
In the same way that the junior people often had to consult with the senior people, the senior people had to consult with the junior people on other matters. For instance, the former retail data warehousing people understood the concepts of customer satisfaction measurement, which is just beginning to emerge in many healthcare organizations. Likewise, the industrial engineer was often consulted for efficiency, demand and capacity measurement knowledge, as the organization as a whole embraced lean/TPS methodologies.
Another key characteristic of the team was the leadership. On the one hand, managers maintained a close watch on the products of the group to make sure they were of the highest quality and value to the organization. On the other hand, they let the team run itself in terms of the fluid processes involved in developing those analytical products. They promoted the group frequently, and protected the group when necessary.
Caveats for the Team
Teams this strong can, and often do, run into predictable problems. They risk developing dysfunctional behavior where the professional maturity erodes and is replaced by one of three forms of immaturity. I am sure that organizational behavior experts could come up with more potential problems, but here are three that I have seen elsewhere. I would warn this group to be on the lookout for:
I was once part of an analytics development team that seemed to be able to do anything. We built a world-class system, both on the front end (user interface) as well as the back end (the loading and manipulation of source data). The problem was that the team knew they had built something great, and came to regard the business people they served as clumsy and dumb. In contrast, another group I worked with avoided this problem by teaching the business how to use their development techniques in order to use them on non-technology projects. For example, the IT project management methods became the standard for how to onboard new clients. In effect, the second analytics team evolved into a resource for the entire organization instead of an insular, selfish group.
After doing things for a while, people can become bored and lose focus on the original purpose of the group. This boredom manifests often in internal politics. This is a small group with a diversity of skills, knowledge and background, so this particular problem is not likely. But it pays to watch out for any signs of team members turning their attention toward each other, instead of maintaining focus on the mission of the group, which is to serve the organization as its system of measurement.
Of particular concern for this, or any, group using an Agile methodology is burnout. In theory, a team could perform 13 four-week sprints per year. In practice, with holidays and vacations, that number is actually closer to 12 per year. This steady pace can burn people out, especially if the individuals have non-sprint work piling up on their desks. There are always going to be little odds and ends that do not fit into sprints. I would recommend to this group, or any similar group using Agile, to consider one of two options. The first is a four-plus-one sprint cycle. Four weeks on, one week for desk clearing. This has the upside of keeping people fresh for sprints, but has the downside that it reduces the number of sprints from 12 to 10 per year. Another option is to designate one “cleansing sprint” per year, where the odds and ends are tackled all at once. This has the advantage of forcing the users to really justify their requests (is it still important?) or not. Or it could force the organization to determine whether or not a request is so hot it needs to become part of a standard sprint. At any rate, sprints can be a high-pressure way to work and some form of release may be needed.
The Future of the Analytics Team
One of the members of the team asked where I saw the team going. My answer was that it would probably turn over in a good way. These people all started with deep experience in diverse backgrounds, fueled it with a high degree of professionalism, and are working in one of the most exciting analytical fields imaginable (i.e., healthcare business intelligence). As such, they were likely to be “poached” within the organization for larger roles across the enterprise. Healthcare is a bit different from other industries in that many roles require credentials (MD, RN, etc.) for entry. Nevertheless, as healthcare evolves into a service, consumer, production and innovation-oriented industry, so will the opportunities for people who understand this new data-driven world.
What does your analytics team look like? This is just a look at how one healthcare organization built its business intelligence team. Your situation will differ, but the need for strong analytics capabilities will only become greater. Get started now. Talk with your peers about their decision support teams. Look at the ones that are working, as well as the ones that are struggling. Make yours one of the teams that is producing value – business, clinical and operational value. And then organize your team and your methods to help capture that value.
Thanks for reading!