Medicare Systems Services Team

Have you ever wondered if a High Performance Team could generate itself without a conscious decision on the part of the organization's leadership to create such a team? Well its possible when business pressures are strong enough to force an organization's leadership to adopt new approaches.

The Medicare Systems Services Team consists of seven managers and 82 systems engineers. This group is responsible for maintaining and writing enhancement code for the EDS base Medicare System. The system is used by eight customers who have responsibility for providing Medicare claims processing in various parts of the United States. Four other information technology companies provide their own versions of Medicare systems to support service providers and beneficiaries in other parts of the country. EDS developed its first Medicare system over 30 years ago and has been continuously providing systems support ever since. In recent years, Congress has been pressuring the Medicare program to find new ways to reduce the administrative cost of operating the program. In response to this pressure, the Health Care Financing Administration issued new requests for proposals that encouraged Medicare providers to merge and consolidate operations and systems.

_______________________________________________________________________

"We knew that we wanted to create an environment where everyone was empowered to contribute." Bill Deraleau, Medicare Systems Services Manager

_______________________________________________________________________

By 1993, the MSS team was under heavy pressure to reduce the cost of supporting the system. On the whole this part of the business was losing money. One way to save money is to flatten the organization. A lower manager to employee ratio helps on the cost side. In the past, MSS managers were responsible for administering company policies and overseeing the details of daily operations. Over the next three years four of eleven management positions were eliminated. As the management reductions occurred, the remaining managers felt the need to let go of some of the daily control they had historically exercised.

In 1994, the management team was faced with the need to handle three customer implementations at one time. In the past, implementations had come one at a time and were always handled by a select group of 8 to 10 systems engineers who had prior implementation experience. Now it was clear that the challenge of performing three simultaneous implementations was beyond this group's ability and resources.

In an attempt to deal with some of these pressures, balance the workload between managers, and deal with a shrinking pool of managers, the management team increased the speed at which it was shuffling engineers between managers. Despite its best efforts to balance expertise between various functional parts of the system, management was aware that it was failing to consistently meet customer priorities for system changes. When the employee survey results were published, it was clear that the engineers were concerned about the constant change of people they reported to as well as the shrinking opportunity to become leaders themselves. "We knew that we wanted to create an environment where everyone was empowered to contribute," said Bill Deraleau, the Medicare Systems Services Manager. After further thought and discussion, the management team tackled the issue of constant shuffling between mangers the lack of leadership opportunity, and failure to meet customer priorities.

The leaders began to meet and discuss the problems. Early on, it came up with the idea that the group really had two different kinds of leadership needs: administrative leaders and business leaders. In the administrative leadership role, managers are responsible for budgets, salary administration, and performance reviews. In a business leadership role, managers are responsible for scheduling work, customer care, project management, and control of quality. Out of this discussion the idea surfaced that leadership can arise from expertise and didn't necessarily have to be the sole responsibility of management.

Further discussions and committee deliberations led to two new concepts: The Medicare Systems Services University and the idea that the engineers should be allowed to pick their own leaders.

The management team looked at the proposed changes. Heated discussions centered around the worry that things might be worse if the recommendations were implemented. Eventually the management team decided to take the risk thinking that they couldn't succeed with the current approach and even if they the changes failed they would learn from the experience.

Creation of the MSS university began by having each engineer rate their own expertise and knowledge about 20 different parts of the systems. Engineers decided which parts they were Phd's, Masters, Bachelors, or learners. Then, to the extent that they understood each others skills, each engineer rated the other engineers in the group. In addition, each engineer was asked which parts of the system they would like to earn a new degree in. All this data was consolidated and reviewed in one-on-one meetings between the engineer and his manager to validate the result and coach the engineer on choices for future degrees. A matrix was created showing people on the horizontal plane and expertise on the vertical. Weaknesses and gaps in the total group's expertise coverage were identified and used to coach engineers about the group's expertise needs. As a follow on, a workload planner was developed that displayed customer maintenance and enhancement request priorities. The engineers were then asked to consider their education goals and identify their first and second choices of customer projects they wanted to work on. This step insured that customer priorities were being met in a consistent manner across the group and to the greatest extent possible, that the engineers were working on the projects and areas that they wanted to develop more expertise in. All team priorities were posted and each sponsoring leader decided if he had too many people wanting to work on his priority projects. As a result, the task of assigning work to people shifted from the management to engineers. In this way, the engineers also selected which managers they wanted to work with.

One of the unforeseen results of these changes was the breaking down of walls between functional areas within the Medicare Services group. Talent and energy now aligns easily with changing customer priorities. The engineers now have maximum possible control over the projects they work on and leaders they work with.

Conventional team building wisdom says that you cannot sustain team behavior without having a significant portion of compensation based on team results. In early 1994, the overall manager for Medicare Support announced a group incentive program. He wanted increased emphasis placed on productivity and performing system enhancement work in order to generate increased revenue. Over the years the engineers had developed strong relationships with their customers. The customers call the engineers to discuss and request maintenance changes needed to the system. The cost of these changes is covered under the base contract. In other words, EDS does not receive any additional revenue for maintaining the system. However, additional revenue could be generated by performing enhancements to the system that are requested by the government. The engineers sensed that the group incentive plan would negatively affect their ability to satisfy their customers and consequently ignored the incentive plan. Still, from time to time the idea of a team based incentive plan kept coming up in employee meetings. Generally the engineers were in favor of an team based incentive plan but it would have to be done right.

Resurrecting the incentive idea, the top Medicare Manager sought input from the team. Objectives would have to be measurable, they would have to be directly related to improving the team's cost and revenue performance. Ideas and measures were proposed and ultimately sifted down to four objectives for the second half of1996.

Bill x thousand hours of enhancement work - new system functionality

Maintain the service level agreement (how fast maintenance changes needed to be performed).

Reduce the contract per claim expense by x percent

Keep the IPACs (Computer Usage) run rate below budget.

The value of achieving these objectives in terms of revenue improvement and cost reduction was calculated. A portion of this value is designated to go into a bonus pool to be shared by the entire 83 person team. Initial concerns centered around questions like: "What if we get close but don't achieve all the goals? Do we get a partial reward?" But some of the focus started to shift to "How can we surpass the goal." In just three months the team is well on track to achieving and exceeding all its objectives. The team is currently discussing the best way of distributing the pool when it is earned. An equal share for each? A disproportionate share based on individual contribution? If so, how to measure that? And who measures, management or the team, or both? Stay tuned.

Already behavioral changes are evident: Individual team members are taking on more responsibility, and everyone is more aware of what each of their fellow teammates are taking on. Peers are helping peers, and the university concept is fostering a real learning environment. Is this a High Performance Team in every sense of the word? Maybe...Maybe not. But the environment needed to become a High Performance Team is present and positive results of empowerment and self direction are encouraging the team to stretch, grow, and support one another in ways that were unimaginable in the old environment.

[Return to High Performance Team Home Page]