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
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
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]