Challenges to Managing a Multiple Team Project

For many years, the focus in project management has been on the effective management of the project team. Its members were selected based on their expertise relative to the requirements of the project; requirements were gathered and documented; a project plan was built and executed; and client change requests were proposed and acted upon in the best interest of the enterprise.

Then along came companies like Walmart with its unique information systems client-centric structure. Its IT Department was organized into independent teams. Each team focused exclusively on a specific line of business or client group, and was able to satisfy their requirements for new and enhanced applications systems. These teams were very effective in meeting their client's specific needs. The IT teams became experts in the client's line of business. In meeting the specific business systems needs of their client group, each team created its own project management methodology with the tools, templates, and processes needed to support their client's line of business. Many of the team members were in fact the Business Analyst/Project Manager (BA/PM) professionals, which are discussed in Chapter 18. At the time they were my client, Walmart's Information Systems Department had more than 250 such teams. Whenever projects involved more than two teams, you can imagine the potential conflicts between methodologies that could occur. The approach used to manage such situations is the focus of this chapter. With so many companies expanding into global markets, their growth as well as the added complexities of gaining and sustaining itself in the world markets, projects are taking on a different character. Most projects now involve integrating two or more independent teams for their effective execution. In mission-critical, enterprise-wide, and other complex cases, several teams must be brought together in order to successfully deliver the expected results. Depending on the maturity of the team processes, integrating independently developed processes could be simple or it could be very complex. Being able to do this effectively without sacrificing the corporate culture and increasing project risk presents new challenges to the project manager. I am not aware of any publications that treat the management of these multi-team projects. This chapter is the first published work on this topic.

As a project manager, you are only concerned about a single project, but when you have multiple independent teams working on that project, it seems as though there are really multiple projects to be managed. The reality is that you are managing a single project and that has to be made clear to all of the involved teams if you are to be successful on these very complex endeavors. In all such projects, there will be several project managers (one from each team and perhaps one who has overall responsibility for the project). It is the job of these project managers to build the management infrastructure that will be responsible for the overall project. The situation presents the project managers with several challenges. I examine them in this chapter.

In today's project management environment, the pace of business initiatives and the lack of resources require many project managers to manage concurrent, multiple, and dependent projects. In years gone by, this scenario was reserved for senior-level project managers. Today, project managers of all experience and competency levels are called on to manage multiple efforts simultaneously. The following suggestions can help multi-project managers keep their head “in the midst of the storm” and establish a consistent methodical approach amongst the inherent chaos of multi-project team management. The emotional maturity of the project manager will surely be put to the test.

To get your creative juices flowing, the following sections raise a number of issues and considerations. These are things you need to think about as you consider possible management structures for your multi-team project.

Working with Teams from Different Companies

Projects that require the participation of two or more organizations are the source of the most complex type of multiple team projects. These range from projects that involve a team from your organization and a team from a contractor's organization to projects that are a collaborative effort from two or more independent companies. The contractor will want to impose their project management process on yours and that can create conflicting processes. How you deal with those eventualities should be part of the terms and conditions of the contract.

Working with Fiercely Independent Team Cultures

Walmart employs more than 10,000 IT professionals who are organized into more than 250 independent teams. Each team serves a single line of business or client group and has their own project management methodology designed specifically for their client. For this client, the structure works very well, until a project involving two or more teams comes along. Recognizing that there can be all sorts of complications in merging the work of two or more teams into a single project, how do you organize and manage such efforts? I have coined the term fiercely independent to characterize this project phenomenon. It seems that the more mature the processes, the more fierce the independence. Although that independence may have served clients well, it doesn't necessarily scale to projects that involve multiple lines of business or client groups. This is a reality that larger or global companies face; therefore, it's a problem that must be dealt with. That is the sum and substance of this chapter.

Working with Different Team Processes

Each of the three models you are going to read about in this chapter requires a different level of integration across the teams. One of those levels involves the integration of processes. A major methodology decision is whether you will establish one process or establish a process that consolidates the deliverables from several processes. Another area of integration deals with human resource management. Is the entire project team to be managed as a single team or as independent teams, each with its own human resource needs and management process? As you begin to think about the organizational structure of your project team, you have to weigh the importance of integration to the successful operation of the team and the project.

Accommodating Competing Priorities

The team members are typically not assigned 100 percent to the multi-team project. They have competing priorities for their time. They most often choose to give priority to their client rather than to the multi-team project. Balancing those competing and often conflicting priorities can be a significant challenge. In cases where the project is a very large enterprise-wide project, its members may be assigned 100 percent. That also can influence your choice of a project management structure.

Communicating within the Team Structure

The extent to which the multiple teams are integrated determines the importance of communications within the entire project team. The more layers of communication you have to deal with, the more likely there will be problems.

Establishing a Project Management Structure

Team independence has spawned a number of project management approaches and structures. Multi-team projects are complex and therefore a challenge to manage effectively. A team structure must be chosen that best meets the needs of the multi-team project and any operative constraints at play. That structure can be relatively loose or very tight. The nature of the project influences the choice. The chosen structure is going to have significant impact on the resulting management overhead.

Establishing One Project Management Life Cycle

The first step in establishing consistency and order in a multi-team project environment is to establish a definitive life cycle for the project. Whether this is one life cycle or several depends on the processes used to support the several client groups involved. Perhaps a custom-designed PMLC model is called for. Life cycles generate certain patterns of thinking among the project teams. This becomes very important when your time will be monopolized by multi-team demands. Not having the time to micro-manage personal behaviors, you need to establish a useful mindset in the project team. Using definitive life cycles and phases is a safe and “low-energy level” way of instilling these behaviors and outlook. But that means a change in process for many of the teams.

The project life cycle should be established at the inception of the project, be documented, and become part of the working project schedules. The phases should be used as high-level summary tasks in the actual project plan. It is also a good idea to distribute a definition of the individual phases, their significance, the roles and responsibilities required for each, and the clear intent of each phase prior to project kick-off or planning.

If multiple projects are serving the same end or result, it may be in your best interest as the project manager to “sell” them to senior management as a strategy versus individually disconnected projects. Other contributing projects, not under your auspices, may also be included under the strategy. When you classify a group of projects as a strategy, it is far more possible for you to do the following:

• Appoint a strategy director. This person, by title, would be responsible for coordinating and securing cross-functional resources, strategic decisions, and general project leadership.
• Establish a consistent life cycle or methodology across multiple teams under the strategy.
• Appoint a shared administrative staff for projects under the strategy.
• Utilize joint risk analysis and joint resolution strategies.
• Perform proper project scoping. This means work is apportioned properly to the team it belongs with; therefore, a more efficient use of resources is achieved.
• Take advantage of the strength that follows from numbers. The project managers under the strategy benefit from the collective experience and intuition of the project manager. Information sharing is more easily implemented due to the strategy nature of the work.

Building an Integrated Project Plan and Schedule

The overall project schedule is perhaps the most important part of the project plan. The range or integration possibilities go from not integrated to fully integrated. Furthermore, integration can be put in place at various depths (milestones, activities, and/or tasks). What level is appropriate for the project and to what extent should that integration span the entire project?

Defining a Requirements Gathering Approach

Several variables have to be coordinated in order to effectively identify, document, and validate client requirements. The first variable is the client. Several client groups are involved, so their requirements have to be gathered and consolidated with those of the other client groups. The second variable is the approach to gathering requirements. There are a number of alternatives, and each client group may have its preferred approach in which they are experienced and which they expect to be using.

The decision as to the approach or approaches to be used is one consideration, but an equally important one is the structure of the requirements gathering exercise. Will it be done as a single group or as multiple groups, or as individual client groups? If done in separate groups, how will these potentially conflicting lists be consolidated? If separate, you must become a shuttle diplomat. That may be a role you have never experienced before! A discussion question at the end of this chapter gives you a chance to develop a strategy for resolving conflicting requirements.

Establishing a Scope Change Management Process

Any request for a scope change can, and probably will, affect several client groups. Project Impact Statements and the approval process are considerably more complex than in single-team projects. Will you establish a Scope Change Control Board to manage all scope change requests? That might work fine for Traditional Project Management (TPM) projects, but what about Agile Project Management (APM) or Extreme Project Management (xPM) projects? Or to really craft a demonic example, what if part of the project were to be done using a TPM model and part using an APM model? Now what does your scope change management process look like? The answer to that is also relegated to the “Discussion Questions” section at the end of the chapter. Here's a chance to exercise your creative juices!

Defining the Team Meeting Structure

Multi-team project structures usually result in additional layers of project management, hence the need for additional team meetings. This structure should be carefully worked out and agreed to by all parties. The danger is that you will have a meeting overload, taking team members from the real work of the project.

Establishing Manageable Reporting Levels

Multi-team project management requires high levels of energy and focus over extended periods of time. To achieve this, you must consider what reporting levels are required on your projects in order for you to do the following:

• Maintain control over the scope and progress of the project
• Maintain control in the time available, with realistic reporting requirements

Milestone reporting is a way to maintain control over the project, yet minimize the amount of time spent in gathering and analyzing the data.

Consider the following issues when establishing the project reporting requirements:

• What are the levels of project complexity and urgency?
• What are the levels of project risk, both overall and within each phase?
• What is the skill level of the person who will be gathering and reporting data?
• How much time will you need to analyze data after it is reported?
• Is there a clear change management policy in place?
• Is there a clear communication protocol set for the project team?

After answering these questions, decide on reporting levels that will yield results and the detailed information required for management decisions. This must be done in a balanced approach, considering the amount of time required from the project team to gather the information and the amount of time required from you to analyze the reporting data.

Sharing Resources across Teams

If the team is structured as a single integrated team, this is a non-issue. If your team is structured as several independent teams, you may have a problem. In this situation, you should get the up-front commitment from each team leader that the use of all team resources is going to be based on a collaborative decision-making process. The actual process for sharing resources has to be jointly developed and approved.

The more complex and uncertain the project, the more likely there will be scarce skills. If this is the case, you should use a team structure that makes the sharing of those scarce skills as easy as possible.

Staffing across the PMLC

It is very likely that each team might have a phase or process within a phase that has been particularly effective in their previous projects. This project can benefit not only from using that phase or process, but also from having a member of that team manage that effort. That will not only benefit the current project but also contribute to the morale of the team that contributes that phase or process.

These decisions should be made during the planning phase. There may be integration issues to resolve ahead of time.

Searching Out Your Second

Who will represent you and speak for you in your absence? Is this one person or several people depending on the situation? The multi-team project has enough management complexity built in to warrant some help. If the total team size is above 30, you might consider having some administrative support in the form of an associate manager. This person could act on your behalf.