Managing complex team structures

Abstract

Organizations resort to complex team structures in staffing projects of varying sizes and gaining project success in a complex team environment can be challenging even for the most experienced project manager. It is critical for project managers to understand the complexity of agendas of the various teams making up a project. This paper will examines complex team structures in real-life projects providing both observations and pragmatic recommendations throughout the project lifecycle to ensure overall project success.

Introduction

Organizations resort to complex team structures in staffing projects of varying sizes and complexity. Whatever their reasons may be (skill set, budgetary constraints, internal political issues, or contractual obligations, etc.) gaining project success in such environments can be challenging even for the most experienced project manager.

While there are many definitions that would characterize a complex team, this paper limits the discussion to a heterogeneous team structure comprising client and partner resources. The term complex and/or mixed team will be used interchangeably throughout the discussion

This paper will examine a specific complex team structure providing both observation and pragmatic recommendations to ensure overall project success.

Complexity of Agendas in a Complex Team Environment

Considering the many possible combinations of organizational structures typical in today’s projects, this paper focuses on the team structure as shown in Exhibit 1. In this example we consider an IT application development project where the client has engaged two vendors in which:

Vendor 1 (V-Dev) who, with the assistance of subcontractors, is responsible for application development and delivery, and

Vendor 2 (V-QA), an independent entity, responsible for all aspects of testing

All project participants are key to the overall success of the project, bringing with them their own obligations and responsibilities. These include their own actual as well as perceived expectations and specific agendas (i.e. what they want to get out of the project and their personal business objectives they hope to achieve). These agendas may include, for example, account penetration, knowledge enhancement, meeting sales strategy and goals, technology validation.

In order to position a project for success, it is critical for Project Managers (PMs) to understand the complexity of agendas of the various teams making up the project. From this understanding, PMs can develop both a strategy and roadmap to properly manage this complex environment. This situation may be viewed from a “What’s In It for me” perspective and the possible motivational factors contributing to a collaborative vs. an adversarial engagement driven by individual and conflicting agenda’s.

images

Exhibit 1

All of the parties must understand the specific responsibilities and (sometimes hidden) agendas of the various participants to help guide the project to a successful outcome. It must be noted that while a participant may be assigned a specific set of responsibilities, and their agendas aligned, this is not always the case. The client needs to both set and manage expectations within their own internal resources as well as partners (V-Dev, V-QA, and any sub-contractors) forming the direct and virtual teams.

It would be naive on the part of any participant, especially the client, to feel that well written contracts are the key to success. While a well-crafted contract may prevail in a court of law, it does not necessarily lead to a successful engagement. There are both contractual and perceived commitments that drive behavior, and if misaligned, could result in a range of outcomes - from dissatisfaction of stakeholders to total project failure. The client needs to ensure that all participants understand and are aware of what they have contractually agreed to, and equally, if not more important, understand the spirit of the agreement and deliverables.

Certainly, if expectations cannot or will not be met, it is the obligation of each participant to articulate this as soon as possible both to the client and also to the team at large. As good as damage control may be, proactive action and avoidance is still the best approach to a successful relationship.

The customer is responsible for engaging the right partner (not only from a skills and cost perspective) but also one that can share their business vision and goals. Misaligned agendas at this level can and do lead to project disaster. Attempting to correct such fundamental problems can prove to be very expensive in terms of cost, time, and also in terms of the partner’s reputation.

With the wide ranging maturity levels within any organization, it is critical for the V-Dev Project Manager (V-Dev-PM) to ensure that the client understands the real team dynamics, and that the various agendas and expectations are clearly stated by using tools such as a Project Structure Document, plus a Roles & Responsibilities Matrix. Of course, good project management requires getting validation of all project communications to ensure that the message is clear and understood.

Not having direct responsibility over all team participants requires the V-Dev-PM to draw on a reserve of professionalism, project management tools and soft skills to communicate agendas and expectations via carefully crafted status reports, team meetings, formal and informal discussions, etc. However, care must be taken to ensure that the client does not feel the V-Dev-PM is overstepping their delegated level of authority. For the V-Dev-PM, a key component to success is to work toward full transparency within the development team. Using a rigorous selection process for all resources is crucial to build a winning team. This will help facilitate the perception/reality of a single development Point of Contact being the V-Dev-PM.

Activities that facilitate transparency of the team include from the following:

  1. Kick-Off meetings (first, with the V-Dev’s internal team, then with the subs engaged, and finally with the client) to set expectations, roles, responsibilities, and rules of engagement. Clearly setting partner/relationship boundaries will help alleviate future undesired behavior. Capturing this in written form and distributing amongst the management and delivery teams will further reinforce desired behavior by all parties. Careful observation and management of the team during the early stages of formation will help reinforce stated expectations.
  2. Ensure consistency of tools and processes such as time and expense reporting, work products, estimation tools, status report templates and any other project artifacts.
  3. Establish project Conditions of Satisfaction (COS) with the both the client (including V-QA partner) and the subs such that the team is working toward actual and perceived goals and expectations.
  4. Poll the partner and client resources for team and individual career/personal goals. While it may not be possible to accommodate everyone’s needs, understanding such goals will help facilitate a more unified team and provide the V-Dev-PM with necessary motivational leverage. Where appropriate, communicate the findings and show leadership in helping fulfil the career goals of the various team members, if at possible.

Probably the most difficult area for the V-Dev-PM is to work with and manage the V-QA partner over which the V-Dev-PM has little or no authority. Unlike the sub-contractors reporting directly to the V-Dev-PM, the V-QA partner is ultimately responsible only to the client. Understanding the obligations and agenda for V-QA is also critical in allowing the V-Dev-PM to manage and/or allow for the actions of the V-QA partner. These considerations/actions may include:

  1. Understanding what leverage can/may be applied to V-QA
  2. How can the development team assist V-QA partner be successful in understanding where the areas of commonality reside
  3. Being vigilant and keeping an ear to the ground and assessing what V-QA team is saying to the Client
  4. Establishing a sound working relationship with the V-QA partner. This can be facilitated with regularly scheduled meetings to help foster a good working relationship. Engaging the V-QA at lunch or dinner allows for communication outside of the more formal project environment

It takes time to establish a trusted and working relationship between the V-Dev team and selected sub-contractors who typically feel that they operate under the umbrella of an entity that may not be looking out for their best interest. Managing FUD (fear, uncertainty, and doubt) of the subs is another critical component to establishing the trust relationship allowing for the desired transparency. The vision of One Project-One Team with a strong focus on team building and team morale is crucial to creating the development of a winning team.

If the V-Dev-PM fails to manage sub-contractor relations well (by quickly establishing roles and responsibility) the client may feel that they have the need, authority and responsibility to go to sub-contractor resources directly and set/reset project tasks along with sub-contractor obligations. While this may very well be in the best interest of the project, doing so by circumventing the V-Dev-PM sets the project on a slippery slope where the development prime contractor loses control of the resources for which they are responsible.

The V-Dev-PM needs to consider the following key items in managing their sub-contractors:

  1. Identify unique/individual needs of team members and work to meet these if at possible in the course of the project.
  2. Communications – Who, What, When, How – don’t forget the partners communications needs. Because they are removed from a direct client relationship, partners need to feel in the loop. For example weekly status meetings and/or conference calls will help foster such communications
  3. Build Trust at every opportunity and demonstrate that partner needs are being addressed or at the least communicate that there are constraints and limitations. Uncertainty breeds distrust and could develop into a project issue, or even worse, an unpleasant interchange with the client.

Considerations for Off Shore Complex Team Environment

A common and growing practice is to have a component of the team working off-shore (OST) and distant from primary arm of the project where the key decision makers may reside. Let’s consider the elements and special considerations above and beyond those described in the above case study.

images

Exhibit 2

In the case of having to work with a partner team that is located off-shore, all of the previously mentioned strategies are required and are compounded by the additional factors of language and cultural barriers as well as time differences. There may also be technical skills variation between the teams which will further challenge both communications and solution development.

While virtual teams and off-shore work is almost inevitable in today’s “the world is flat” reality. It is critical to establish the client business objectives for the project with the OST and this can rarely be accomplished without a few face-to-face meetings. This should be planned for very early in the initiation and planning of the project and insisted upon by the V-Dev-PM to help provide continuity throughout the project life-cycle. While many OST speak English (or even American), their writing skills (when it comes to business understanding or even technical specifications) are not always comparable to the same level from a US-based partner. It is this “dissonance” of understanding from a business and technical perspective that must be resolved and addressed both by the client and the V-Dev-PM. Sometimes this will require the replacement of resources that may be adequate technically, but cannot understand the project’s requirements from a business or technical architecture viewpoint.

It is essential that someone on the project team be designated as the on-shore coordinator. Ideally, this will be an individual who is bi-lingual and who has played this role as part of a previous project. This individual will be located on-shore and will be the primary liaison for communications to the OST. Of course this adds another “layer” of complexity to the overall project structure. However, this is not a simple task and should not be taken on by the V-Dev-PM, except in the smallest of projects.

Another important consideration in working with an OST is to communicate with the on-shore management for the OST. These individuals are generally responsible for the overall success of their engagement and can invoke resources on the OST, if necessary. It is also essential that the V-Dev-PM establish a formal escalation path to the OST management team as well. It should be considered best practice to make at least one trip to the off-shore location to meet face-to-face with the OST management as well to build a trusted relationship. This also communicates to the OST project manager that there is an escalation path outside of their domain that can be used if the OST does not perform or begins missing deliverables. It is all too easy on a conference call or via email to say “everything is on track.” In fact for many off-shore cultures, they want to be polite and are reluctant to tell the V-Dev-PM the true state of development until it is too late.

Finally, there should be an alignment between the on-shore and off-shore teams with reference to project governance, project management, architecture, and development. Ideally these will be one-to-one mapping, but should be present and clearly identified in both the project structure and the roles & responsibilities documentation. Ultimately, the V-Dev-PM will be responsible to the client and there must be clear lines of authority and escalation developed in conjunction with the client’s expectations for delivery of the project.

Considerations and Recommendations within Project Phases

Having discussed general considerations around the area of client partner management, what are some of the specifics (tools and processes) that the V-Dev-PM can pull from his/her toolkit to facilitate buy-in, transparency, and trust? Understanding some of the major issues that surface in each phase of the project will help us to consider recommendations for Exhibit 3 below.

images

Exhibit 3

Summary

This paper has provided observations and key challenges along with a pragmatic and succinct approach to partner management within a complex team environment. It is critical in such project structures to leverage established tools and processes, as well as understand the specific agendas of the primary participants. Armed with that knowledge, along with applying project management excellence and a strong set of targeted “soft skills” the project manager will unite the team toward the common goal of project success.

These best practices may be summarized by the following ten recommendations. These may be adapted to suit the specific project and the many team structures that a PM may be managing.

  1. Create one homogeneous team from all project participants sharing a common goal for project success.
  2. Clearly set and manage expectations through status meetings and other forms of formal and informal communications.
  3. Understand Roles/Responsibilities and motives of the various stakeholders and partners.
  4. Ensure all players are living up to their commitments both actual and perceived throughout the project phases.
  5. Use data and avoid subjective feelings for communication and behavior feedback.
  6. Communicate clearly and effectively to Customer, Partner(s) and their management.
  7. Be vigilant for signs of trouble and proactively manage any that arise.
  8. Identify triggers and ask for help from customer and/or partner management as appropriate.
  9. Leverage Best Practices - Tools and Processes as available and agreed to by the project team as a whole.
  10. Establish an atmosphere of open and honest communications. Integrity, openness, trust, and respect of each team member are the keys to achieve mutual buy-in from all the project stakeholders and partners.

While these items are not a panacea for delivering a successful project with a complex team structure, failing to follow these recommendations and account for the needs of all the project participants may prevent the creation of a cohesive team. Adopting the above principles, along with quality project management will increase both client and partner satisfaction and position the project for success.

Acknowledgements

The authors would like to thank members of Microsoft’s Consulting Services Division for reviewing this paper and providing valuable input and feedback.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

©2006 Larry Hanthorn and Mahesh Bhatia, Microsoft Corporation
Originally published as part of 2006 Global Congress Proceedings – Seattle Washington

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.