It is a common practice in organizations to establish a Project Office (PO) to manage large or mission-critical projects. Such a structure is temporary and exists only to serve the needs of large or mission-critical projects. Some organizations will even establish a PO whenever the team size reaches a certain number (for example, 30 is the rule used by one of my clients). The PO is just another layer of management, to whom the individual project managers report. The PO provides general management support, coordination, and basic administrative services to each of the project managers.
A Project Office (PO) is a temporary management structure established to coordinate and support the work of several independent teams who are concurrently working on the same single project that has task dependencies across the team structure.
Do not confuse a Project Office (PO) with a Project Management Office (PMO) or Project Support Office (PSO). PMOs and PSOs are permanent organizational structures that support the needs of all projects of a certain type.
First note that the PO is a temporary structure. It is managed by a program manager and exists only to serve the needs of the individual teams who are working on the same project. Once the project is complete, the PO is disbanded.
As illustrated in Figure 17-3, the PO structure is very simple.
This structure scales very well to large projects. The support staff ranges from a minimum of a single part-time administrative person (provided by the PMO in some cases) to a practical maximum of several full-time PO administrators and associate managers.
The roles and responsibilities of the PO Manager and support staff are as follows:
The following subsections discuss each of these in more detail.
The PO Manager must bring together multiple teams under one management structure. These teams are accustomed to operating independently, but they must now operate under a common set of procedures and processes. This is best accomplished through an organizational meeting attended by the project leads from each team. A new set of team operating rules will come from this meeting, which all team leads have agreed to support and follow.
The PO Manager should collaborate with the team leads to draft the high-level project plan. Each team lead can then take that high-level plan as input and work with their team to complete their part of the project plan.
There will be a number of inter-plan dependencies that will have to be accounted for and built into a master project schedule. That work will be led by the PO Manager in collaboration with all of the project leads.
Once the project has been launched, the PO Manager will be responsible for monitoring project performance and progress. Adjustments to the project's master schedule will have to be made as tasks are completed (ahead of or behind schedule).
Resource management is a critical responsibility of the PO Manager. 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 project leads and consolidated by the PO Manager for submission to the various stakeholder groups, clients, and senior management.
At the highest level, there should be frequent (perhaps daily) meetings chaired by the PO Manager and attended by the project managers. The project managers, at their own discretion, should hold meetings (probably daily) with their team members.
This is a complex activity that must be managed by the PO Manager or a designated associate. You should expect that every change request will impact the schedule and resources of every team. The PO Manager is 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.
There will be many situations where a project manager is unable to resolve a problem. Cross-team dependencies will lie at the root of many of the problems. These are beyond the authority of the project manager and must be escalated to the PO Manager for resolution.
Some problems may involve two or more teams. In the event that they are not able to resolve the problem among themselves, it will have to be escalated to the PO Manager.
The strengths of the PO approach are as follows:
The PO Manager is basically a coordinator. He or she is responsible for gluing together the deliverables and artifacts from independent teams. This coordination should be minimally invasive of each team's processes and practices. Teams prefer this approach to learning and using different processes and practices, which is a real strength of the PO structure.
On the flip side is the burden placed on the PO Manager. There will be some benefit from getting teams to agree on how their artifacts are reported to the PO Manager. For example, if the PO Manager can convince the teams to report project performance data in a common format, it can cut the administrative time needed to consolidate that information.
As the project grows in size, the size of the PO also grows. There will be a need for increasing the size of the administrative support group as well as the PO management structure. Installing layers of management will be a requirement for very large projects. There is no practical limit on the size of a PO. Early in my project management career, I was acquainted with a PO that managed a seven-year hardware/software systems design, development, and deployment project that had more than 10,000 team members organized into several smaller POs, programs, and projects. Obviously, there were several layers of management.
This will have to be a high-level plan. The Work Breakdown Structure (WBS) will be defined to a few levels of detail and then the individual teams left to plan their own work below that level subject to certain start and end dates for their deliverables. In effect the PO Manager would be managing the deliverables just as she would manage independent contractors.
To some extent, each team manager will provide staff support across the team structure. The changing needs of the project will dictate how much support is to be provided. During the planning phase, the process for sharing staff resources should be agreed to.
The PO structure is minimally invasive of each team's independence. They are free to proceed with their work on the project using the tools, templates, and processes most familiar to them.
The weaknesses of the PO approach are as follows:
When a team member is not allowed to use a tool, template, or process they are familiar with and have had good success with, there are sure to be problems. If you are going to force this situation on part of your team, make sure you have no reasonable alternative. It might be better for you to bear the burden of having to consolidate differing practices than to force compliance. Weigh the advantages of compliance versus consolidation. I have found several cases where the competing tool that a team member suggests may in fact be better. In those cases, I have given the team member the responsibility of leading that part of the project, with all teams using his or her approach. This is good for morale, too!
A team member's annual performance review and raise comes from the manager of his or her home department. When given a choice between competing priorities and all other things are equal, what choice do you think they will make? Unless you have something to offer in return, you will always be fighting an uphill battle for priorities. In some cases, I have helped the client develop a process to receive performance input from the PO Managers they have worked with.
There will have to be a single scope change management process. A formal process managed by a Scope Control Board will have to be established, and all teams must be required to use it. Each team will have some responsibility for analyzing the impact of the change on their project plan as well a role in the approval of changes requested by other teams. Keep in mind that some scope change requests can have major impact on the plans of several projects.
The PO is the least disruptive of current project management practices across the enterprise, so it would be the preferred model for the teams participating in a multi-team project. In a very mature enterprise, it may make sense politically to use this structure. At the same time, it places a significant coordinating burden on the shoulders of the PO Manager. The PO Manager's role is seen as coordinating rather than having direct management responsibility over the team managers. That places the PO Manager in a position where their skills as leaders and negotiators are called into service.
As project complexity and uncertainty increase, the PO structure loses its appeal. In APM or xPM projects, any organizational barriers that can be removed or avoided should be. Using a PO structure for such projects would contradict this goal. If the team size is less than 30, the PO structure can still be made to work for simpler APM projects, but there is a better choice. The PO structure works best for Linear and Incremental projects. You have to make room for creativity and flexibility, and inheriting as many project management practices as there are teams is unnecessarily burdensome on the project manager and increases the risk that a solution will not be discovered. For APM and xPM projects, the Super Team structure discussed later in this chapter is generally the better choice.
18.117.142.141