Ensure that Projects Finish on Time by Avoiding Scope Creep

In my discussions with executives, the most common complaint they have about internal project teams is that they hardly ever deliver the agreed end-results on time. While there are a number of reasons why this typically happens, one of the most common reasons is scope creep. Scope creep can be defined as the tendency for project team to carry out more work than originally agreed and/or is required for making the project a success. There are two different types of scope creep (external and internal). The reasons for the two types are different, as are the steps required to ensure that it does not happen, or that the consequences are limited. These two types will therefore be described separately.

External scope creep is caused by sponsors or other stakeholders asking the project team to carry out more work than was originally agreed. The natural tendency of most project managers and project teams is to blindly say "yes" without thinking about the consequences. In fact, sometimes extra work is welcomed by the team, as it gives the team an excuse for not finishing on time. The primary responsibility for guarding against external scope creep lies with the project manager.

The project manager needs to guard against scope creep by ensuring that all requests for additional work are known to him. When he is made aware of a request for additional work he should carefully assess whether the requested work fits within the scope of the project and whether it can be done within the agreed resource and time limitations. If this is not the case, then he and the team should discuss the issue with the sponsor and agree the solution. The solution can be a) not performing the extra activities, b) performing the extra activities but dropping another activity, or c) performing the extra activity and extending the available time or increasing available resources. The project manager should use the project charter as the basis for discussions on this topic. While this will not “magically” ensure that the project is completed on time, it will, at the very least, enable a structured discussion on priorities.

Internal scope creep is when the project team decides to do more work than agreed and/or is required for meeting the project goals. A clear example of such a situation is a project I am currently helping. In this project the team consists of people from different technical departments within a large network company. The team has been given the responsibility for developing a telecoms vision for the next ten years. The team has been given considerable freedom in defining its specific deliverables and project approach, but has also been given a very tight deadline. The naturally tendency of such a team is for everybody to raise the issues that are critical for their department, and make suggestions for activities that they personally find interesting. Because the team is democratic in its approach, it is very difficult to prioritize or censor, resulting in a very broad list of activities to be carried out.

My help so far to this team has focused on helping them to understand the exact need driving the request from their management team. Using this, we have been able to focus the goals of the project on helping to resolve the core issues that the management is facing. Using this as a starting point, we have then carefully developed a work plan focusing only on understanding the key drivers for the requirements to be placed on the company's telecom services in the next ten years. In parallel, we are defining a work stream that will help us understand how the telecom service provider environment will evolve. Combining these two activities will enable the team to give the management team the vision it required for making key asset-related decisions.

This step has only given a starting point for controlling scope creep, as the real danger will lie in the day-to-day activities being carried out by the team. We have therefore agreed that in the ongoing review of the activities being carried out by the team members and sub-teams we will use a "scope test". Essentially, this "scope test" consists of a diagram showing the inner-most circle of telecoms related assets, services, requirements, etc, and an outer ring which includes all the direct influencers of the internal ring. If there is doubt about an activity being carried out, it will be placed in the diagram. If it is not located in the two inner-most circles, it will be seen as being out-of-scope and discontinued.

In addition to this "yes/no" decision regarding activities, we have also agreed to have an ongoing dialog on the depth of the analysis being carried out. The team mainly consists of engineers, whose normal work requires 100% accuracy. Given the time frames of this project, this will be impossible. In addition, this level of detail and accuracy is not required for developing the high-level vision required by management. We have therefore agreed to have an ongoing dialog with the team members to prioritize their activities and agree when to stop a given activity. Given my experience in putting together presentations for executive boards, this will be one of my key activities going forward.

In conclusion: scope creep is a very common problem for teams carrying out complex projects. However, the effects can be controlled and minimized by using some fairly simple approaches and tools.

Running a Successful Product Development Project

In my discussions with executives, innovation, or product development projects, are often given as examples of internal projects that are not successful. When questioned in more detail, usually the "failure" that is being mentioned can be divided into two separate types. The first type of failure is probably the most damaging and frustrating. These failures are usually products that fail in the market place or result in enormous costs and complexity in the production and supply chain process. The second type of failure is less damaging, but probably more frustrating, as it happens more often. This type of failure involves products which are not launched or launched too late.

In my experience, these two types of failures are caused by two different types of problems. The first type (market failure) is typically caused by the product development project having been structured in the wrong way (hand-overs between departments, wrong type of team, etc). The second type of failure (delay) is typically caused by the team being set up, managed, and run in the wrong way. Given this, how can the success rate for product development projects be improved?

The most crucial response is to ensure that the project is set up and staffed in the right way. Product development projects should avoid hand-overs between departments, and therefore need to include a representative of all key departments involved in the process. This will typically include marketing, production, logistics, account management, etc. The chosen project team then needs to be given the end-to-end responsibility for the successful product launch. This responsibility needs to be collective for the whole team, to ensure that they continue to work together across the whole process. In situations where this methodology leads to teams that are too large, careful thinking should be given to working with core and extended teams, and carefully expanding and changing the team composition across time. An excellent explanation of this is given by Deborah Ancona and Henrik Bresman is their book "x-teams: how to build teams that lead, innovate, and succeed".

Once the right team has been put in place to carry out the end-to-end innovation process, the next challenge is to make sure that the project is successful. A product development / innovation project will typically score highly on both internal and external complexity, and a very high number of the problems that this type of projects face are likely across all three phases of the typical project. However, these problems can be avoided or minimized by ensuring that key pitfalls are avoided.

In the initiation phase of the product development project, great care should be given to ensuring that the team has a clear understanding of the project goals and the deliverables expected from the project. As mentioned earlier, this should be to deliver everything that will be required for the successful launch of the new product. This will entail that the team must come up with the product itself, the production process, the supply chain process, the marketing process, pricing, etc, etc. Naturally, the team will need to get specialist input on a number of these issues, but the total responsibility must be clearly placed with the innovation team.

The team will typically consist of people who have never worked together and who probably do not know each other. This means that the team should be given help in forming themselves into a team. They need to understand what is required to become a successful team, how it is to work as a team, how they can best make use of each other's skills and capabilities, etc. Finally, the team should be helped / forced to develop a realistic plan for how they are going to achieve their goals and deliverables. They should be made to understand that they will be held accountable for this plan (especially the overall timing and milestones).

In the work phase key focus areas should include avoiding scope creep, sticking to the agreed milestones, carrying out the required analytics, and communicating with the sponsors and stakeholder. Scope creep is a common problem is this type of projects, as the team is asked to look into related issues, or dives into too much detail on specific issues. To avoid this, a clear process (involving the sponsor) should be put in place to control this. One of the main challenges the team will need to solve (on a continuous basis) is the optimal split between the activities carried out within the team and the use of external experts. When using external experts timing and milestones can become a major problem, as the external experts will not have the same dedication and focus on meeting deadlines. The team should therefore always have a "plan b" for use if the external expert does not deliver (on time).

In the finalization phase the team will need to develop its overall conclusions and the final deliverables. This will typically include the total plan for launching the new product covering all the issues mentioned earlier. In addition, the team will need to develop and carry out a communication process. In my experience, this is something that innovation teams often overlook. Their implicit assumption is that the rest of the organization will automatically accept their conclusions and recommendations. Unfortunately, this is often not the case. Therefore the team must carefully consider who the stakeholders are, what their "hot buttons" are, and how they can be convinced to accept the team's conclusions.

It is in the nature of the process that not all innovation projects are successful. However, it is my experience that companies that make use of a structured process as described in this article, have a much higher success rate than other organizations.

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

Has Your Project-Team Considered All the Key Dimensions of the Problem?

Many readers have mentioned to me that they feel that a lot of the projects they sponsor (even the successful ones) are often on "automatic pilot". This typically happens once the project teams feel that they understand the problem and have decided on what they believe to be the most appropriate direction for solving the key issues facing the project. The consequences from this can be severe. The most dangerous consequence is often that key aspects of the problem are overlooked. More common is that the team has not analyzed all the relevant dimensions to the problem, and therefore has not developed complete and optimal solutions.

An example of a similar situation from my own work was a project-team in the insurance sector that was developing a new structure for a company in response to key legislative changes. A key component of the project team's work was to look at the key business drivers for succeeding in the new environment. In a meeting the team presented their key hypotheses, which seemed to make sense. However, a clarifying question was asked about one of the success-drivers suggested by the team, and this lead to a broad discussion in which several new success drivers were identified which the team had not considered. Luckily, this did not happen in the final presentation to a SteerCo, but in a pre-meeting.

This type of situation can easily be avoided by borrowing a methodology used by consultants called a Blue Team (sometimes it has a different name). The methodology helps ensure that project teams are shaken out of the "automatic pilot mode" and have considered all relevant aspects before the end of the project. This methodology can easily be adapted to internal project teams as well, and is guaranteed to improve the overall quality of the work delivered.

A Blue Team is a structured meeting typically held once, maybe twice, during a project. In this meeting, the project team gives a short presentation on what it believes to be the key issues (if the meeting is early in the project) or key hypotheses (if the meeting is later in the project). The presentation is given to an invited group of people who are not directly involved in the project. The guest list for the Blue Team should include people with relevant knowledge and experience to the issues being dealt with by the project. Typically the people invited have market knowledge, technical expertise, and/or process experience.

The invited group needs to be able to quickly understand the issues being discussed, and is meant to be critical in the questions they ask, the comments they give, and the suggestions they make. However, the participants also need to understand that their comments and questions are meant to be helpful to the team. The Blue Team therefore needs to find a balance between criticism and support. One way of achieving this is to clearly state upfront that the process is meant to help the project team, and therefore only the project team can decide how to use the criticisms, ideas, and suggestions coming out of the meeting.

Even in the best of cases, the Blue Team is tough on the project team, as they (by definition) will get criticism on the work that they have carried out. Given the psychological barriers related to receiving criticism, even a project team with good previous experiences may have to be forced to carry out the Blue Team. My recommendation is therefore to make Blue Teams a standard part of all complex projects that you sponsor, thereby avoiding any choice or discussion on the process.

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.