Using Project Management Offices in Complex Projects

Occasionally I meet potential clients who do not believe that they need external input for making their complex projects more successful. I know that this is hard to believe, but it does happen……………Very often these executives say that they do not need any outside help because they have a Project Management Office (PMO) that fills this role (i.e. making sure that projects run well). This has always bothered me for two reasons. Firstly, I clearly believe that I can offer valuable input to (almost) any organization carrying out complex projects. Secondly, I often see these same organizations outsourcing projects to external consultants, so there are clearly projects that they believe cannot be handled by their internal teams.

Recently, my thinking on this was brought into focus by an executive from a media company who asked me a slightly different question. He explained that he had mixed results in using people from his PMO in complex projects, and was wondering how he could make best use of them in these situations. There are clearly three alternatives here: 1) Give your PMO total responsibility for this type of projects, 2) make no use of PMO-staff for complex projects, or 3) an intermediate solution.

The cases that I have seen where complex projects have been given to the PMO have generally been a disaster. While Project Management Offices have an important role to play in many organizations, it is important to understand their limitations. In most companies, PMO's have been set up to provide project management for what I call standard projects. These are projects that are closely linked to the core business of the company, and which therefore do not deal with external complexity (openness of goals to interpretation, uncomfortable goals, high degree of communication required) or internal complexity (distance of project from day-to-day business, organizational distance of project participants, sophisticated data collection, and a requirement for "out of the box" thinking). This means that when the PMO uses their "standard" tools on these projects, the results are terrible.

On the other hands, I believe that not using the skills available within the PMO is also a shame, as it is clear that they do have project experience that can be valuable in a wide range of projects. Therefore, the optimal solution is not to give the complex projects to the PMO, but to definitely use the PMO pool of people in staffing the project.

The next question asked by the executive then concerned the role of the PMO-staff in the complex project. Should he use somebody from the PMO as the project leader? In my opinion, this can work, but it is not very likely that this will an optimal choice. Somebody from the PMO will clearly have the required project management skills, but is not likely to score high on other crucial dimensions driving the choice for project leader. These include having sufficient knowledge about the key issues to be covered by the project. Examples of issues where PMO-staff would be unlikely to have sufficient knowledge include a project to look at a new, dramatically different production process, or a strategic pricing project. Somebody from the PMO is also unlikely to have sufficient respect among key stakeholders to be able to "sell" politically difficult conclusions and recommendations.

Using PMO-staff as a participant in a complex project is possible. However, it will not be sufficient if all the person brings to the project are his project management skills. The PMO-staffer will also need to bring some combination of the three skills required of all participants (technical and functional skills directly related to the issues to be solved, analytical skills, and interpersonal skills). If the PMO-staffer has the right combination of these skills for the project, then his additional project management skills can be an asset, and enable him to help the project leader deal with this type of issues.

In conclusion, I would not recommend giving the PMO the responsibility for complex projects. There will also not be many situations where somebody from the PMO is an ideal candidate for leading a complex project. However, using people from the PMO in certain complex projects can be useful, but only if they have additional skills that can be utilized.

How to Get Buy-In for Project Conclusions and Recommendations

In a recent discussion with a client in the telecoms sector he told me that one of the biggest differences he sees when comparing his internal project teams to the top-notch consulting teams he sometimes uses, is the latter's ability to ensure buy-in for their conclusions and recommendations. His two questions were why the internal teams were not capable of achieving such buy-in, and what could be done about it.

Luckily, there are simple answers to both questions. In my experience, the main reason why internal project teams do not get buy-in for their conclusions and recommendations is that they do not know that a communication process is required. Usually, when I ask the team what went wrong, the answer they give is along the lines of "Nothing went wrong. We carried out the project, and presented the results to the steering committee. What else should we have done?"

This way of looking at the problem is based on a combination of factors. The first factor is related to the scope of the project, as the team has often not been explicitly told that getting buy-in for their conclusions is part of the project deliverable. Secondly, many teams (especially those with a strong technical representation) have a low understanding of the political issues related to their projects. As a consequence, they believe that "the facts will speak for themselves". Thirdly, team members who are not experienced in working on complex projects will typically develop final presentations that focus on the process that the team has followed, rather than the conclusions that they have made. This often means that the conclusions and recommendations are not clearly communicated. Finally, the project team does not usually have any experience in dealing with the group processes that typically take place within a steering committee, nor do they think about also presenting to other stakeholders who may not be represented in the steering committee.

There are three main activities that I tell my clients that need to be carried out to help the project team get the required buy-in and acceptance for project conclusions. The first of these actions needs to take place at the beginning of the project when the sponsor must clearly communicate that the project team bears responsibility for getting the required buy-in and acceptance. The second and third activities by the sponsor takes place at the beginning of the final phase of the project, when the sponsor should force and help the project team to develop a communication plan and must help the team to develop a structured final presentation (using a tool such as the Pyramid Principle). The final point will not be covered in this blog.

When I help teams develop a communication plan, we begin by making an overview of all relevant stakeholders that have an interest in the conclusions and recommendations being developed by the project team. Stakeholders who are expected to be negative towards the results are the most important to identify. For each stakeholder an overview is developed of their "hot buttons" and the dimensions of the solution to which they will need to agree. A detailed plan will then need to be developed outlining how these key issues will be communicated to the individual stakeholders.

The individual members of the steering committee should also be seen as stakeholders. This means that 1-on-1 meetings are planned with them before the final steering committee presentation. In this individual pre-meeting the SteerCo member have the opportunity to ask specific and detailed questions which then do not have to be raised in the overall meaning. In addition, any specific issues that the SteerCo member has raised in the 1-on-1 meeting can then be addressed in a structured manner in the overall presentation.

Carrying out these fairly simple and straight-forward activities aligns the internal project team with the overall methods used by top-tier consultants, and have resolved most of the issues related to the internal team's ability to get acceptance and buy-in for its conclusions and recommendations in the projects that I have carried out at my clients.

Follow the links if you are interested in more information on project planning or project management training.

Determining the Appropriate Deliverables for the Finalization Phase of a Project

In previous blog entries I have suggested what the generic goals and deliverables should be for the first two phases of a complex project. This blog-entry will suggest what the generic goals and deliverables should be for the finalization phase of a complex project.

When a team enters the finalization phase of a complex project, it typically has carried out most (or all) of the key analytical activities that are required for meeting the specific project goals. The overall success of the team's work in this phase is very much determined by the work that has been carried out in the previous phase. In addition, there is seldom an explicit borderline between the project phase and the finalization phase, as the process can be iterative in nature as insights are developed and final analytical activities are carried out.

In this final phase, the main goal of the project team will be to develop and communicate the overall deliverables that have been agreed for the project. However, even if the work in the previous phases has been carried out successfully, there are still two aspects that can go seriously wrong in the finalization phase of a complex project:

- The project team is unable to develop clear-cut conclusions and recommendations based on the work they have carried out
- The team does not communicate its findings appropriately (to the right people and in the right way)

In my experience, complex projects are helped by defining a number of generic deliverables specifically for this phase that are related to avoiding these pitfalls. These generic deliverables will help ensure that the overall goals of the project are met on time and within agreed budgets, and will help ensure that project recommendations are actually implemented.

Deliverable Nr. 1: Clear conclusions and recommendations. This may seem obvious, but one of the most typical problems with internal teams carrying out complex projects is that they do not provide conclusions and recommendations. The requirement that the team must provide clear recommendations needs to be clearly stated at the beginning of the project, but should be re-iterated at the beginning of the finalization phase. This will ensure that the team understands that they are expected to come up with actionable conclusions ("go left" or "go right" not "it is possible to go left or to go right"). The specific deliverable should be a (short) presentation to the sponsor on what the team believes that the conclusions / recommendation coming out of the project are.

Deliverable Nr. 2: A pyramid supporting the conclusions / recommendations. The Pyramid Principle is a tool used by consultants to force the project team to develop a logical supportive structure for their conclusions. The basic methodology is well-defined and easy to learn. Developing a pyramid will serve both as a logical test of the conclusion / recommendation (do the results of our analysis support what we want to say?), as well as providing an excellent starting point for developing presentation and reports for the communication process. The pyramid can be tested with the sponsor at the same meeting as the suggested conclusions and recommendations.

Deliverable Nr. 3: A communication plan. Most internal project teams only work toward a final presentation to the steering committee. This often leads to problems because presenting new material to a steering committee often leads to surprises and unwillingness from the steering committee in accepting the conclusions and recommendations. A process should be put in place that allows the individual members of the steering committee to see the final presentation individually before the final presentation so that they can give their opinions, and ask their specific questions. In addition to the steering committee there are usually also other stake-holders to need to be informed in order to ensure buy-in and implementation.

If you can honestly say at the beginning of the finalization phase of your project that all of these generic deliverables will be developed, then the project has greatly enhanced its chances of successfully reaching its overall goals in such a way that the conclusions and recommendations will be accepted and implemented.

Follow the links if you are interested in more information on project planning or project management training.

Determining the Appropriate Deliverables for the Work Phase of a Project

In a previous blog-entry I described the optimal deliverables for the initial phase of a project. This blog-entry will suggest what the goals and deliverables should be for the work phase of a complex project.

The work phase of a project typically covers the most time in the overall project plan and is, in my definition, the part of the project where the basic analytical and development-related activities are carried out. While the success of this phase is determined for a large part by key deliverables developed in the first phase of a complex project, there are a number of things that typically go wrong in this phase of a project as well. Typical examples of things that go wrong include:

- There is insufficient communication and feedback to the project sponsor
- The team work within the project is not optimal
- There is limited control of the project process (timing, scope creep, etc)
- There are insufficient and/or incorrect analytical activities being carried out
- There is not any process in place to control the hypotheses and conclusions being developed by the project team

This phase of the complex project is very likely to have a set of project-specific deliverables related to reaching the overall goals of the project. Examples of such project-specific deliverables could include carrying out a specified set of interviews, developing a spreadsheet model, collecting data, developing assumptions, setting out a new set of processes, etc. In addition to these project-specific deliverables, we believe that every complex project should also strive to develop a set of more general deliverables at the start of the work phase. These generic deliverables will help ensure that the overall goals of the project are met on time and within agreed budgets.

Deliverable Nr. 1: A well defined process for regular communication with the sponsor. This involves planning regular meetings between the sponsor and the project manager and team members, as well as creating the opportunity for ad-hoc meetings on an as-required basis.

Deliverable Nr. 2: An overall setting that enable the team to work together optimally. This deliverable includes a set of activities that ensure that the team members are able to use the time allocated for the project, and that as much of this time as possible is spent working together. One way of achieving this involves ensuring that the project has its own project room, and that the team members commit to being in the room at given times during the week.

Deliverable Nr. 3: A clearly defined process and appropriate tools for ensuring that milestones are met. This should include regular reports to the Steering Committee, and agreed processes to discuss and agree any expansion of scope.

Deliverable Nr. 4: Ongoing training activities for project team members to ensure that they carry out the right analytical activities in the right way. Typical team members in a complex project are not aware of all possible analytical activities that can move their project forward, nor do they have the experience to carry out these activities. A clear deliverable for ensuring project-success should therefore be the ability to provide ad-hoc analytical training and support to the team.

Deliverable Nr. 5: A Blue Team to provide feedback and constructive criticism on the project team's hypotheses and conclusions. A Blue Team is a structured meeting where the project team presents its hypotheses and potential solutions to a selected team external to the project. Such meetings have a proven track-record in improving the overall quality of projects

If you can honestly say at the beginning of the work phase of your project that all of these deliverables have been developed, then the project has greatly enhanced its chances of successfully carrying out the specific project-related analytical and developmental activities required for reaching the project goals in a timely manner.

Follow the links if you are interested in more information on project planning or project management training.