For multi-team projects in which team size is not a deterrent to successful project performance, a Super Team (ST) structure can work quite well. It does require that the project manager be experienced in managing large (even very large) projects. This is not a job for the faint of heart. The team will have one person leading it (a senior member of one of the teams). In most cases, there will be at least one other management layer within the team. These subproject leads will be responsible for some of the deliverables. It would be a mistake to organize the subprojects along strict client-centric lines. This smacks of the PO structure. The structure of the project should suggest how those subprojects might best be defined. Using the concept of maximum cohesion and minimum coupling would be a best practice that has good application here.
A Super Team (ST) is a temporary management structure used for a single project that integrates several independent teams into a single team managed by a senior-level project manager and supported by several subproject managers.
Having a single team structure means that all of the tools, templates, and processes in the five process groups can now be used. As the project size increases, the following things happen:
As shown in Figure 17-5, the ST structure is very simple.
This is a very dynamic structure that can easily expand or contract as a project's size increases or decreases. So you should be asking: “How big is big enough?” Here are some factors that I have used successfully in my consulting practice to help my clients decide whether or not to use the ST structure.
The first factor is the size of the support team. To compute the number of full-time equivalent (FTE) positions you need on your support team, add up all of the estimated labor time associated with the tasks from the WBS. Take a percentage of that number. In my experience, this is in the range of 7–20 percent. The percentage increases as the size of the project increases. For example, suppose the project duration is 12 months, and the total labor hours are estimated at 50,000. Ten percent of 50,000 hours is 5,000 hours spread across twelve months. That averages 416 hours per month. The average work month has 160 hours, so you will need about 2.6 FTE positions to support your administrative needs on the project. Some organizations don't think like this when it comes to staffing, so you may have a selling job to do. Somebody has to pick up an estimated 2.6 position duties. Look around you. The team members are your resource, and what you can't or shouldn't do yourself someone on the team will have to do. Look for administrative duties that you can pass on to others on the team. Rotate those duties around. Don't make the mistake of thinking that one team member should do all the meeting minutes, for example.
The second factor is the size of the team and the disposition of the senior, associate, and assistant project managers. Again from my experiences, the number 30 is the key to calculating the need for a structural change. Every team increase of 30 members triggers another structural change to the management of the project. The structural changes are bottom-up changes. For example, my preferred disposition of 30 team members would be to teams of five or six members, so the 30 team members would be split into five or six teams. Say five for the sake of the example. As the ST Manager, I can handle five direct reports, so I don't need any other project managers yet. You should also set the maximum number of direct reports any one project manager should have. For a team of 30, that number would be six, which is acceptable. As for the number of ST support staff needed, you can calculate that following the discussion in the previous paragraph. As overall project team size increases, you add to the subteams until you need more subteams, in which case you need at least one Assistant Project Manager (PM) to cover the increased management needs. There is no exact formula that I can give you, because it is basically a judgment call on your part. What makes sense for the project should be the final guide.
The roles and responsibilities of the ST Manager and the team leaders are as follows:
The following subsections discuss each of these in more detail.
There should be one ST Manager for the ST structure. This individual must have solid experience managing large and complex projects. The ST Manager must gain each team's approval of the operating rules that bind the teams into a single working unit. In the ST structure, individual teams lose their identity. They are fully integrated into a single project team. A major organizational task is to decide how the scoping and planning tasks will be organized and managed.
The senior members from each team should work as a single team to draft the high-level project plan. Working with a smaller number of associates for this initial step is sufficient. Once the infrastructure has been established, the full planning team can be assembled to work out the remaining details. The planning task can easily get out of hand, so careful preparation will be required to make sure the plan is kept on track and doesn't waste the time of the team.
Once the project has been launched, the team leads will be responsible for monitoring project performance and progress. The ST Manager is accountable for the entire project and should receive periodic status reports from the team leads.
Resource management is a critical component of the project. As required, resources will have to be shared across the teams. Adjustments will have to be made to accommodate approved scope change requests and solve other schedule-related problems.
Project status reports should be submitted by the team leads to each other and to the ST Manager. These reports will have to be consolidated by the ST Manager for submission to the various stakeholder groups, clients, and senior management.
At the highest level, there should be frequent (perhaps daily) meetings of the team leads chaired by the ST Manager. Each team lead may also choose to hold meetings (probably daily) with their own team members.
This is a complex activity that must be managed by all of the team leads. You should expect that every change request will impact the schedule and resources of every team. The team leads are responsible for receiving, processing, and closing all scope change requests. This is no small task, because both the master schedule and resource allocation must be considered. Given that there are cross-team dependencies, this task must be dealt with using the most intense due diligence.
The strengths of the ST approach are as follows:
The baggage of managing across disparate teams is not an issue here, but there are still management problems to attend to. You will need to deploy a time-tested PMLC and management style for this project, which could be very large. If you haven't depended on technology to help with the management burden in the past, you will have to now. Human resource management decisions can be overwhelming on even a moderately sized project. Of the three models, this one is least affected by the process and practice baggage that team members might bring with them. The team members will expect to comply with the processes in place for projects of this magnitude.
Similar to the PO structure, the ST structure really has no practical limit to the size. Although larger teams are often structured within a PO structure, that is not necessary. The project can be decomposed into several subprojects and those subprojects into sub-subprojects, and so on. Those layers of management also fulfill a reporting and planning role.
All team members are accountable to the ST Manager through a number of management layers. This allows the managers to utilize team resources to the maximum. It also creates many opportunities for professional development through OJT assignments.
The full range of TPM, APM, and xPM models and their supporting tools, templates, and processes are available. This is a chef's delight!
The weaknesses of the ST approach are as follows:
As project manager of an ST project, you have all of the responsibility and authority to select best-fit approaches. You must be very cautious about how you actually exercise that authority. I firmly believe that the recipients of the standardization should participate in deciding what that standardization will include. As I said earlier, don't expect your team to claim ownership just because you directed them to do so. Give them a chance to be part of the process, and they will automatically have ownership of it.
The home department is a strong draw. That is where your team members get paid, and that is where they grow professionally. This is a strong bond. So when it's time to decide which of two competing tasks they will work on, guess which one gets picked?
The ST structure works for all sizes of multi-team projects. All you need in order to use it is the agreement of the key team leaders to abide by the standards. You should tell them that the standards to be used will be their decision under your guidance. I recall one such project where one of the team leaders had been very successful with a particular approach to requirements gathering. He presented his argument to the other team leaders and won them over. With the support of the other team leaders, he was given the responsibility to manage that part of the project. The message that I want to convey to you is that the entire team needs to participate in establishing those standards. Delegate the management of project phases or processes to team leaders who have earned the right to have those responsibilities. This can be a great motivational tool, too.
The ST structure is adaptable to several different project types, regardless of the total team size. It should be the structure of choice for APM and xPM projects. If the organization is at Level 3 maturity, the ST structure is the obvious choice. This doesn't mean it is the default choice, but when you are in doubt, you should use the ST structure.
18.117.170.226