Much of our working lives is spent in teams. Many of our leisure activities also involve working with groups of people to realize our goals. Yet, there’s often very little guidance to help teams operate more effectively to improve their performance.
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.
In this large financial services company, the beginning of the teamwork initiative was the recognition by the IT organization that demand for its support was growing. Systems and services were on the critical path for almost 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 development needs and assist the professional 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 reasonably 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 managers for direction and decisions. The challenge was to transform the operating style of this organization.
The CIO and senior IT managers established a performance improvement 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.
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 former 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 consultant to help understand the issues and opportunities 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 interested business partners.
Two key findings emerged during the orientation and introduction stages:
- Most people didn’t really recognize or acknowledge the fundamental differences between the operation of existing teams and the desired operating style of a self-managed team, although participants would nod knowingly if the topic was raised. The ideas behind self-managed teams are not new but they are attractive. Teams and managers were sometimes reluctant to admit that these desirable team attributes were not in place. Consequently, 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 results, the SMT would have to work very hard to undo these beliefs.
- Self-managed teams didn’t just magically 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 difference, the path to self-management was not clear. With all the other demands on managers and teams, it was easy to put off figuring out how to make it happen.
The SMT addressed these concerns by developing 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 covered 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-managed 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 opportunities 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 conducting 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 sessions, members of the SMT began to notice an increase in interest and in requests 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 establish conclusively how they were doing. It was time to practice what they had been preaching 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:
- Clarity of team mission, vision, goals and priorities
- Member and stakeholder acceptance of team mission, vision, goals, priorities
- Clarity of specific measures to track performance against goals
- Amount of challenge in team’s task
- Team’s value to members as a place to acquire new skills
- Support for team from sponsors
- Skill resources in team (including leadership)
- Team’s size
- Facilities, technology and support
- Team’s reporting relationship with sponsor
- Ground rules on team operation, confidentiality, sign-off, etc.
- Team roles, boundaries and authority limits
- Communication between this and other relevant individuals, groups
- Team’s measured performance against established goals
- Sponsor satisfaction
The team assessment was completed in a one-hour review with all team members 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 themselves or with the help of a facilitator.
The assessments were completed on 25 teams over 18 months, fifteen development teams and ten operational groups. The average result 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, assessments revealed an average improvement 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 understood the meaning and significance of the 15 success factors, and team dialogue appeared more open, more honest and more focused on results.
It was 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 definitive method for measuring team performance? Absolutely not! The SMT’s ultimate goal was to be able to track the improvements in team performance on the basis of each team’s own measure as expressed 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 adventure?
- 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, momentum and interest would have dissipated quickly.
- Establish goals and measures up front. This is good advice for any team and absolutely essential for a team charged with implementing high performance principles and practices.
- Communicate! Communicate! Communicate! Celebrate victories. Acknowledge mistakes. Share learnings. Stay on the front page.
If you find yourself in a similar situation, remember to put these points on your checklist of things to do and consider Project Pre-Check’s three building blocks right up front 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
Drew Davison is the owner and principal consultant at Davison Consulting, a senior consultant at Mapador Inc. and a blogger on Project Times. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check – The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at email@example.com.