A look at Teamwork

I've decided to write about one of the elephants that can all too often be found in the project room, - namely teamwork. As there's already a vast amount of online information and books already written about teams, I've decided to simply present my own observations and experience about working with teams. So here we go.

To get a level of good teamwork going there needs to be a whole raft of enablers present such as; motivation, a group understanding of objectives, having a good environment to work in, capability, workable constraints, support, leadership, trust and availability to work. In this post I'll use some of these key enablers to identify how to enable a project team. In future posts I'll augment this with my own observations and recommendations on:

• What motivates teams
• Culture and the impact on teams
• Creating trust and understanding within a team
• Team leadership and support

 Definition of a team

I'll start by defining what I mean by a team: It's a group of individuals that work or play together to produce an outcome. I've underlined key words as these help us further understand what I mean by a team:

Individuals - Will have their own idiosyncrasies, needs, commitments, ideas, ways of thinking and wanting to work

Together -   There is a need to combine and attend the dependencies, limitations, and constraints of each other

Produce -     Ways of working   

Outcome -   The end goal or product 

With so many attributes it is not difficult to see why a team is often a highly complex structure. It's also not unreasonable to conclude that the bigger the team, the more complex a team's structure will become. As a project leader, the first question I'm often asked is where and how would I start to address some of the team complexities and go about forming a team that works? To answer this question, I've summarised the 3 key steps I would normally take with forming or re-engaging any team. 

Step 1: Identify the team challenges

Simplifying the complexity is a natural first step for anyone trying to get a team to work together. However, it is often more easily said than done. Personally, I always try to work with the end in mind - mainly because it enables me to envision how the product will be created or the goal achieved. Working backwards helps generate the questions and options that are likely to crop up and, once I have these, I am better placed as a leader to address the needs of a team. Turning the team attributes (re above) on their head and, starting with the last one first, let's take an end-in-mind logic/approach and identify the questions I would typically want to be able to answer:

Outcome - What is it we are making? Why are we making it? What is the value of the outcome? Can I define this outcome, so everyone can relate to it?

Produce - How will we make the product? Can we "chunk" it? What are the options? What are the constraints in how we work? Why are we choosing a particular option? Can we change options later? What are the risks of the chosen option? How will we manage these risks?  

Together -  What are the skills, resources & effort we need to make the product? How many people are required in the team? What limitations or constraints exist on individuals? How can these limitations / constraints be accommodated? How and when should individuals be brought together so they learn, understand, and appreciate each other's contribution?

Individuals - Are the individuals used to working in teams? Do they have any specific needs before they can work effectively? In what way can individuality be celebrated, and contributions acknowledged by the team?

 Step 2: Create the team

Armed with the answers the Step 1 questions, creating the actual team (or teams) is usually bread and butter for most Project Managers. However, there are a few tips I've learnt over the years which, you might want to consider, when securing the right resources. Summarising just 3 of these:

• Checking in with the resource owners: Find if they are sponsors or sympathetic towards the project outcome. If they are, then you can expect them to free up their assigned resources. If they are not sympathetic or have other priorities for their resources, then this is a red flag and you should look for individuals within their team that are very interested in joining he project. If you can't find any individuals within their team, make the project sponsors aware that there might be a problem for the project in this specific area.
• Checking in with the resources: Confirm with the identified resources that they are keen to be a member of the team and are willing to commit a proportion of their time that is required. Seek confirmation from them that they have the skills required and understand their role. Identify with them their key constraints and what might impact their ability to perform.
• Not necessarily accepting the resources that are the best qualified or available: Availability and capability should not be the only criteria for selecting a team member. Motivation, strength of character, willingness to question, learn and contribute are all significantly positive attributes that might outweigh being the best qualified or availability.

Step 3: Enabling the team

Enabling a team is a fundamental step in any project. It needs to be done at the beginning of every phase and whenever a new team or individual joins the project. All the information gathered in Steps 1 & 2 come into use when enabling a team. The information can be summarised into several documents, presentations, induction sessions. These will be invaluable to all team members orientate themselves into the project and help them identify and build their own status and value in the team. Let's take a look at some of these:

• Documents - Project Initiation Document (PID), Project Charter, High level plans, Project organisation charts, Roles and Responsibilities, Status and Progress reports, Risk registers etc.
• Presentations - Project Kick Off and Project phase presentations
• Induction packs - Project org charts, scope, phases, system access, governance meetings, escalations, time and expenses

Experience has told me it’s best not to overload teams with information that they might not be interested in - much better to advise them through a regular meeting the essence of what they need to know and need to respond to, then refer them to where they can obtain further detail.

Weekly team meetings: Are a good vehicle to get a measure of how teams are working and if there is any conflict. Face to face meetings are the best way to not only hear but observe the body language of team members as they present or comment on the work they are doing. Once a team problem is identified by all means discuss it to see if it can be quickly resolved in a positive way. Should the problem be sensitive it's usually best to schedule a separate meeting so the current meeting can move on. If team problems are known about before a weekly team meeting, then the best option is to always see if these can be discussed and resolved before the team meeting.

Other meetings: Outside of weekly team meetings, there are often other regular or ad hoc meetings where teams and team members can be enabled. The more information about the team that can be presented in open forums helps everyone and encourages teamwork. It also helps individual team members see their value and raises the prestige of their contributions. 

Offshore teams: Require special consideration - as do remote workers. Integrating Offshore workers into a team should be done after you have understood their preferred ways of working and established how these will be accommodated with the rest of the Onshore team. The Offshore team need also to understand that they must integrate with the Onshore team and customer to avoid work practices that might frustrate all parties.   

Partners: Often have their own methodologies and ways of working, contractual obligations, or other business opportunities which might conflict with them working optimally within a team. In my experience open conversations with partners is the only way to ensure that they fully participate with the rest of the team. Wherever possible partners should be included in weekly team meetings as well as separate weekly review meetings with the PM.  

Awards and acknowledgements: Awards are good for public recognition and some team members really value these. My only caveat to making public awards is that they are made for the right reason and give the right message. In virtually every awards ceremony I've been to there's always been at least one award to an individual for working long hours over a prolonged period. For me these types of awards give the wrong messages. Much better to make awards to an entire team for a specific goal they have achieved on a project.  

Rebooting a team: When teams or members within a team are not working well together consider using sponsors to re-energise or change management tools to re-boot the team's performance. Clarifying roles and responsibilities, tweaking work processes and team meetings are all ways of getting minor changes in team behaviour. If there are major differences, then I would suggest using change communication tools such as the Johari Window model to facilitate team member understanding and perceptions so they can adapt and work together in a friendlier and more accommodating way.

To summarise, teamwork is not something that everyone finds it easy to slip into. Good teamwork will never just happen, there needs to be a mutual understanding on what is required and how to support others in their work. This will always require a lot of communication and explanation throughout a project. PM's and team leads need to take responsibility for delivering good teamwork and project sponsors need to demand and acknowledge good teamwork throughout any project.