Identify Teams


0 comments

Strong teams don’t just happen. They are made. Program managers have responsibility for teams on multiple levels and have to make sure that project managers are capable of building strong teams.

Our 6 part guide to Team Building at the Program Level will help you put together the team you need to fill skills gaps, meet goals and exceed stakeholder expectations.

Part 1 of 6: Identify Teams
Part 2 of 6: Know Your Strengths, Weaknesses, and Preferences
Part 3 of 6: Drive Change through Retreats
Part 4 of 6: Use Performance Appraisals in Program Management
Part 5 of 6: Use Recognition Activities for Individuals and Teams
Part 6 of 6: Deal with Breaches of Program Integrity and Ethics

Part 1 of 6: Identify Teams

Before you can build a strong team, you must identify what one is. The program manager needs to think about all the possible teams, internal and external, connected to the program. People take pride in being part of a team, but if no one identifies or recognizes the team, people find it difficult to participate or to have pride in being involved.

It is obvious that within a program the individual projects involve teams, and the operations segments may also be made up of teams. But what about the project managers themselves? The project managers supporting the program are a team and need to be treated as such. The profound but underutilized statement that two heads are better than one applies here. Most of the issues that your project managers face are similar or interrelated.

In a matrix environment, when you have functional managers who support your program, you as the program manager can view those functional managers as a team. Although by design their functions are different, they face a lot of common issues, and when the program manager periodically meets with his or her team of functional managers, great results can happen.

When appropriate, you can treat your suppliers as a team. This allows you to recognize and appreciate their efforts all at once, saving you valuable time. Additionally, it strengthens your relationship with the suppliers. Since suppliers see the program from a different perspective, they often have valuable suggestions for improvement that would not come from inside the organization. Also, because project managers often have to coordinate deliverables or issues between program suppliers, treating them as a team with periodic meetings (typically bimonthly or quarterly) usually results in faster and smoother resolution.

People with a specific skill set within the program or organization are also a team. This means, for example, that all the mechanical engineers in the organization can be viewed and treated as a team. The key to forming teams is that you need critical mass in a skill set. If critical mass does not exist, consider forming a team outside the program provided that the organization is large enough. Once again, recognizing those with a specific skill set as a team creates pride in the skill set, fosters common issues to be raised and resolved, and propagates best practices. In our mechanical engineer example, the engineers may all be doing different things, but part of the team meeting should be a segment in which someone makes a presentation discussing what the engineers do, what their challenges are, and so on.

Once your team has decided on their plan and process, PPM software can help you execute that process. WorkOtter helps you successfully execute your program process strategy for project success. Get a demo of WorkOtter and see how we can make your program management effective.

“The Handbook of Program Management: How to Facilitate Project Success with Optimal Program Management, Second Edition” by James T. Brown is a copyrighted work of McGraw-Hill and McGraw-Hill reserves all rights in and to the Content. ©2014 by McGraw-Hill Education. Purchase the book on Amazon.