One of the greatest compliments I ever received as a Project Manager came from a major stakeholder. He said: “I can’t tell who on the team are are IT provider staff and who are the end-users.”
The stakeholder’s observation was passed on to our team. He and his team had just completed a Gate Review of our project. During the review, they interviewed a number of our project leads and team members. The organization they represented was funding our project. It also mandated the rules and policy that we were required to implement in the new system. Not only had we passed the Gate Review, but the stakeholder commended us for the healthy team collaboration and productivity that he had witnessed.
So, how were we able to succeed in this way, to build a great team that won accolades from an otherwise jaundiced reviewer? I believe we succeeded because we met together at the outset of the project – with intentionality – to build an effectively performing team.
And we did so based on this project, at this time, with this project team, for this client. Nothing cookie-cutter. All efforts intentionally focused on the project at hand.
What is a team?
So, what is a team? Specifically, what is an IT project team? While I believe the development of a team has many of the same characteristics no matter the industry and regardless of the purpose, I also believe that developing IT project teams has nuances unique to IT that can best be met from inside the industry; that is, from someone who’s been there, done that, and has the scars and victory wreaths to prove it.
The simple answer is that a project team is composed of a group of employees brought together because of their expertise and skillsets to collaborate on a specific task or project or objective. Though it is seldom that simple.
In my experience, an IT project team is comprised of a group of employees, subcontractors, and end-users. It is overseen by one or more stakeholders, each with his own objectives. Adding to the dynamic of an IT-focused team are team members from a variety of cultures, languages, and experiences; team members that are co-located, work remotely, or both; and team members that may be juggling work priorities in addition to those for this project.
Forming, storming, norming, performing, adjourning
Enter the Project Manager. Hers is a daunting task, requiring strong interpersonal and organizational skills to bring together the disparate values and work experiences, cultural differences, team members’ personal goals, and differences in expectations and levels of understanding of what it takes to work together on a project team. She must endeavor to build a team with a clear purpose that works collaboratively and cohesively towards the single goal of implementing a successful system.
During my MBA studies, in an organizational behavior class, I distinctly recall a concept of team development called the Tuckman model for building high-functioning teams. In 1965 Bruce Tuckman proposed his model, postulating that teams go through five stages of development from their inception to the end of project:
- Forming. This first stage is the period during which the team comes together, many of the team members meeting for the first time. They are excited to start the project. Roles and responsibilities are defined, and relationships begin to form. Project goals, schedules, rules of conduct, and the overall project objective are all laid out. The team has not yet begun to be productive as they begin to familiarize themselves with the project requirements.
- Storming. Inevitably, and often early on, irritants begin to creep in. The scope and reality of the project begin to sink in, and the pressure of work products and deadlines shows. Personalities clash. Disagreements take place. Guidance is questioned. Client demands seem unreasonable. IT staff are short with their end-user counterparts.
All is normal!
Team members have gotten over their initial excitement from the forming stage and are now faced with the reality of project execution. This is often expressed as storming. Project Managers must remind themselves to deal with the conflicts early, while realizing that it is perfectly normal behavior.
- Norming. As individual team members reach their stride in their daily tasks, they begin to appreciate each other’s strengths and contributions to the project. The teams begin to gel and work cohesively. Cross-team collaboration is happening. IT staff begin to understand their end-user counterparts better, and the end-users develop an appreciation for the skills and experience of IT. Many of the annoyances from the storming stage are now overlooked in light of the team members’ contributions.
- Performing. During the performing stage, the teams that gelled in the norming stage are now clicking. Team members are confident in their own and their teammates’ abilities to complete tasks timely and with excellence. They are motivated. They push forward as fast as possible. They often act on their own without direct supervision.
In my opening example, this is the team that the stakeholder saw. Not only was the team performing well, but we were so interconnected – IT and end-users – that each individual knew exactly what needed to be done, when it needed to be done, and what the end result would be.
- Adjourning. This final stage involves wrapping up after project completion. The initial excitement of the forming stage now gives way to the sadness of the adjourning phase. Team members have grown close and celebrate their accomplishments.
Rewarding for me personally is that over the course of my career, 10, 20, 30, and 40 years later, I still maintain strong personal relationships with members of past project teams, the result of our time together in teams on IT projects.
How does one develop a successful team?
So, how does one develop a successful team? Having now recalled the Tuckman model for building high-functioning teams, I will address this topic by referring to the forming and norming stages. In future articles, when I discuss the PMBOK® Guide topic “Manage Team” I will address the other three stages.
And kudos to Bruce Tuckman. So much of what I learned in college I relegated to the pile of “theories not implemented” in real life; but Tuckman’s model made so much sense to me.
As I mentioned earlier, we set the goal for success by meeting at the outset of the project with intentionality to build an effectively performing delivery team. In our minds, “team” included the IT staff we brought to the project as well as the end-users and subject matter experts that the client provided for the duration of the project. This is the same process that I typically followed when developing any project team.
During the forming stage, we did the following:
- Formed clear expectations of how we work together and communicate as a team. We set clear objectives for project success, beginning with the initial tasks to be completed and how they fit into the big picture.
- Began the process of building trust and loyalty among leadership and team members through transparency, approachability, and showing our humanness. We also explained how delegation would occur.
- Began to develop a culture within which we would operate. This included such items as rewards and recognition for excellent teamwork, appreciation of the cultural and experiential diversity on the team, building trust amongst each other, and delineation of roles and responsibilities both at the individual and team levels.
- Introduced the concept of autonomy and empowerment to foster stronger teamwork and to give permission to act without constant direct supervision.
- Emphasized the value of communication. We emphasized the communication techniques that would be used throughout the project to build inter-and intra-team camaraderie. We also promoted a supportive working environment.
- Defined the project cadence of team meetings, client meetings, work hours, handling of approaching deadlines, and preparing for successor tasks.
- Developed expectations around team interactions, keeping commitments, meeting deadlines, supporting decisions, supporting each other, listening to each other, handling disagreements and conflicts, and celebrating wins. We stressed the concept of cooperation and collaboration among team members and across teams.
- Invited contributions from individuals as they worked on the project to raise ideas of how productivity could be improved, and the client better served.
- Conducted initial team building exercises that were appropriate to the team at hand and that tied directly to project objectives. Additionally, we organized off-site outings to help build relationships.
- Introduced the concept of lessons learned. Our goal was to observe team interaction on the project, always mindful of areas for improvement, always noting where we performed well. We took these observations to the next project phase and into future projects.
Following the forming stage, we naturally progressed into the norming stage as we worked our initial project tasks. During the norming stage, we explicitly implemented the concepts that we had introduced to the team during forming.
I often tell the story of how my father taught me to swim when I was very young by throwing me into the deep part of the river that flowed near our farm. In some ways we did the same with our project team members – except that we ensured each person was wearing the life preserver of management support. Norming meant getting thrown into the deep end of the project, and as we stayed true to the concepts described above, we developed a sense of team.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.