From the Sponsor’s Desk – Fifteen Must-Haves for High Performance Teams

In my last post, we looked at the steps taken by an HVAC contractor to develop and deliver an innovative offering to its clients and the challenges it faced dealing with a number of unknowns and uncertainties. Unfortunately, it failed to identify and engage key stakeholders and manage the project risks and paid the price, in dollars and credibility.

In this post, we’ll look at how one IT organization responded to corporate pressure to deliver more, faster and at less cost by transforming its organization using high performance team principles.

Thanks to reader K.B. for providing the details on this case.

The Situation

In this large financial services company, the beginning of the teamwork in­itiative was the recognition by the IT organization that de­mand for its support was growing. Systems and services were on the critical path for al­most every business initiative, and the ability to deliver was not improving fast enough to meet the demand.

The CIO had a vision: to transform IT on the model of a professional service firm and thus enhance its contribution to the plans, knowledge and results of the business units served. Her plan included a number of changes to support this vision based on three key principles:

• Professional staff would actively manage their own skill and career growth.
• Managers would focus on skill de­velopment needs and assist the pro­fessional staff with their skill and career development.
• Work would be handled by teams, which would form and operate on the basis of self-managed team principles.

Information Technology had a reason­ably good track record and 600 staff, mostly long-service employees. Most were already involved in teams to deliver computing services or develop application systems, but most of these teams operated in a hierarchical fashion, with team members deferring to man­agers for direction and decisions. The challenge was to transform the oper­ating style of this organization.

The Goal

The CIO and senior IT managers established a performance improve­ment target of 30 per cent over 18 months in the twenty teams they designated as priority. Other teams would be supported as the need dictated and the capacity allowed.

The Project

To get the change off to a good start, IT formed a small team, known as the SMT (Self-Managed Team) for lack of a better label. Four of the five team members had from 1 to 23 years of IT experience. The fifth was a for­mer IT staff member working in the Human Resources organization. All worked on the assignment on a part-time basis.

The SMT relied on an external con­sultant to help understand the issues and opportuni­ties and to give added impetus to the rollout of team principles and practices. The consultant assisted the team with exploratory and planning sessions and two full-day orientation sessions for all IT management and inter­ested business partners.

Two key findings emerged during the orientation and introduction stages:

• Most people didn’t really recognize or acknowledge the fundamental dif­ferences between the operation of existing teams and the desired oper­ating style of a self-managed team, although participants would nod knowingly if the topic was raised. The ideas be­hind self-managed teams are not new but they are attractive. Teams and managers were sometimes reluctant to admit that these desirable team at­tributes were not in place. Conse­quently, the SMT would hear comments like ‘we’re already self-managed” or “we already do all those things.” Not only did this not foster the desired re­sults, the SMT would have to work very hard to undo these beliefs.
• Self-managed teams didn’t just magi­cally emerge out of existing teams because someone said it was a good idea. In fact, because of the perspectives described above, many managers and teams concluded that they didn’t have to change anything. For those who did realize there was a differ­ence, the path to self-management was not clear. With all the other de­mands on managers and teams, it was easy to put off figuring out how to make it happen.

The SMT addressed these concerns by de­veloping and producing a 30-page booklet presenting the Information Technology version of self-managed teams. The team borrowed ideas from a variety of sources to ensure the material was relevant to IT circumstances and cov­ered the following topics:

• what is a self-managed team?
• what is a self-managed team . . . not?
• why do we need self-managed teams?
• requirements for successful self-man­aged teams
• team principles
• phases of team development
• team boundaries
• roles and responsibilities
• skills and training
• an individual self-check test
• where and how to get help

With the booklet in hand, the SMT proceeded to arrange and conduct a two-hour introduction to self-managed teams for all Information Technology and involved business staff. The introduction was based on the booklet (distributed in advance) and structured to provide opportuni­ties for questions and discussion. It was also used to advertise the availability of SMT members to assist with the implementation of self-managed team principles and practices. The sessions were conducted on a team-by-team basis, with the team leader/manager in attendance.

Perhaps the most significant benefit from developing the booklet and con­ducting the introductory sessions was the understanding and insight the SMT members developed about how to’ make the team concepts work. As a result of the introductory ses­sions, members of the SMT began to notice an increase in interest and in re­quests for information and assistance. But the misconceptions didn’t disappear:

“We’re self-managed! We don’t need a manager to tell us what to do!” – a team member

“They’re self-managed! It’s not my job to tell them what to do!” – a team manager

“We say we are self-managed, therefore we are.” – a skeptic

“We’ve always been self-managed.” – an optimist

In addition, while the SMT “thought” things were beginning to happen, they had no measures to es­tablish conclusively how they were doing. It was time to practice what they had been preached to others: clarify the mandate with the stakeholders and establish measures to track performance and progress.

In follow-up meetings with the stakeholders, a number of things were revealed:

• The term “high-performance team” was preferred over the term “self-managed team” because it was less open to misinterpretation, provided greater latitude for solutions and placed the emphasis on result rather than method.
• The SMT members agreed among themselves to deliver a 30 per cent performance improvement in the targeted teams as well as the ones they chose to assist.

The SMT developed a team assessment tool based on a variety of sources using the percentage change from the first team assessment over the 18 month period as their measurement framework. The team assessment tool addressed team member perceptions on a scale of 1 to 9 on 15 critical success factors for high-performance teams:

1. Clarity of team mission, vision, goals and priorities
2. Member and stakeholder acceptance of team mission, vision, goals, priorities
3. Clarity of specific measures to track performance against goals
4. Amount of challenge in team’s task
5. Team’s value to members as a place to acquire new skills
6. Support for team from sponsors
7. Skill resources in team (including leadership)
8. Team’s size
9. Facilities, technology and support
10. Team’s reporting relationship with sponsor
11. Ground rules on team operation, confidentiality, sign-off, etc.
12. Team roles, boundaries and auth­ority limits
13. Communication between this and other relevant individuals, groups
14. Team’s measured performance against established goals
15. Sponsor satisfaction

The team assessment was completed in a one-hour review with all team mem­bers and was facilitated by a member of the SMT. Priorities and action items for the team to address were agreed upon in the review. Subsequent reviews were performed by the team members them­selves or with the help of a facilitator.

The Results

The assessments were completed on 25 teams over 18 months, fifteen development teams and ten operational groups. The average re­sult for the initial assessments was 5.2 based on a scale of 1 to 9 where 9 is high performance and 1 indicates a definite need for improvement. Team results ranged from a high of 7.44 to a low of 3.40.

Questions 4 and 5 received the highest initial responses, averaging 7.0 and 7.1, respectively. The lowest responses were reserved for questions 14 and 15, with results of 3.7 and 4.0, respectively.

After eighteen months, assess­ments revealed an average im­provement of slightly over 37 per cent, nicely above the 30 per cent target. Perhaps what was most important was the awareness teams developed when they had been through an assessment two or three times. Team members under­stood the meaning and significance of the 15 success factors, and team dia­logue appeared more open, more honest and more focused on results.

It was also discovered that team performance improvement was seldom linear. Average scores by teams over the eighteen months looked like a chart for the Dow Jones stock index, reaching ever upward and then dropping like a stone in response to some internal or external trauma. Things like the addition or departure of IT or business staff, organization changes that impacted a team’s stakeholders and technology and business process changes accounted for most of the drops. Teams that had internalized the high performance team practices and tools did a much better job of responding to the assessment drop and bringing their scores back up.

It was also discovered that some teams just don’t do very well. Most teams in that category didn’t have the right mix of attitudes and personalities and the collective commitment to learn and grow. Removing problem staff, often initiated by the other team members, and in depth coaching and facilitation usually turned the situation around.

Is the team assessment tool the de­finitive method for measuring team per­formance? Absolutely not! The SMT’s ultimate goal was to be able to track the im­provements in team performance on the basis of each team’s own measure as ex­pressed in questions 14 and 15. However, even when teams have clear goals and measures, the team assessment tool is a useful catalyst to focus attention on the means of achieving those goals.

Finally, business stakeholders felt IT’s quality, responsiveness and cost-effectiveness had improved noticeably in the twenty-five teams targeted. It was a ringing endorsement for the program.

How a Great Team Achieved Success

The SMT did a number of things right.

• They lined up and leveraged the key stakeholders in IT and the business as they went.
• They brought in some external expertise right up front to address their own knowledge and skill gaps.
• They learned as they progressed and adapted their approaches accordingly.
• They built up the organization’s store of best practices around high performance teams, something that was leveraged productively by other departments within the organization that had heard of IT’s success.
• They managed to internalize the high performance principles and practices, even with part time commitment. They walked the talk.
• They used Project Pre-check’s three building blocks to perfection – engaged stakeholders, a defined process and a best practice based decision framework.

What did they learn from this ad­venture?

• Active and sustained sponsorship is essential. Without the vision and commitment of the CIO and visible support of IT and business management throughout the organization, mo­mentum and interest would have dis­sipated quickly.
• Establish goals and measures up front. This is good advice for any team and absolutely essential for a team charged with implementing self-man­aged principles and practices.
• Communicate! Communicate! Com­municate! Celebrate victories. Ack­nowledge mistakes. Share learnings. Stay on the front page.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you and your team mates can be a Great Team too.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll present it for others to learn from and comment on. Thanks.

Don’t forget to leave your comments below.