Using Internal Consultants in Complex Projects

It was recently pointed out to me that a new advisor has started up that assists companies in setting up internal consulting groups. This started me thinking about the possible role that internal consultants can play in improving the way that complex projects are carried out in most companies.


The new advisor is clearing playing in on the trend for large, international companies to set up their own internal consulting groups. These internal organizations are usually staffed with alumni of well-regarded, blue-chip consulting companies, and are then used (sometimes, but not always) instead of external consultants. The paradox that I see from my discussions with executives is that opinions are evenly divided among those having a positive view and those having a negative view on the success of projects carried out by the internal consulting groups.

Some of the executives I speak to tell me that they do not have the typical issues that I usually see with internal teams carrying out complex projects due to the input of the internal consultants. Other executives tell me that even with the presence of internal consultants, their complex projects tend to have many of the issues that I raise and that their projects are therefore often not successful. Based on this, there seems to me to be an issue related to how these internal consultants are being used.

The typical way that they are used by most companies is that the complex projects are outsourced to the internal consultants instead of to external consultants. In other words, a team from the internal consultants group is a replacement for the usual teams of external consultants. This certainly has a number of positive aspects. It will certainly save the company the typically high costs of engaging an external consultant. In addition, the internal consultants have a number of advantages compared to the company's average employees. The internal consultants usually have strong analytical skills, are used to carrying out projects, have fairly high interpersonal skills, and typically know the consulting "tricks of the trade".

While the internal consultants have many of the positive aspects of external consultants, they, unfortunately, also have many of the negative aspects as well. Often, a team coming from the internal consulting group will be viewed as outsiders by the organizational units they are providing assistance to. The team from the internal consultants will typically not have in-depth knowledge of the specific area that the project is dealing with. In addition, it is my experience that internal; consultants often have their own political agenda. The reason many people have switched from a consulting company to an internal consulting organization is that they view this as a stepping stone to a corporate job. These people are therefore often viewed as being on the look-out for situations where they can prove that the current management is doing a bad job so that they can position themselves to take over.

In addition, internal consultants are often viewed as working for top-management, and not having the best interests of the local organization in mind. Finally, using the internal consulting group often brings with it many of the same issues as outsourcing a project to external consultants. A project carried out by internal consultants will typically meet resistance based on the "not invented here" syndrome, and will therefore have low buy-in, typically resulting in a delayed and/or less successful implementation.

My overall conclusion is that there is a role for internal consultants in complex projects. However, they should be given total control of projects only in a limited number of situations. Giving complex projects to an internal consultants group can be a good solution if a) the project is for top management, b) there are specific issues related to speed or secrecy (acquisitions, etc), c) there is a very high need for complex analytics.

In other situations, the internal consultants group should be used as part of the overall resource pool for staffing complex projects across the organization. The staff from this group will typically be extremely well suited for providing the required analytical and communicative skills to the team. However, as shown by the earlier comments made by executives in organizations using internal consultants, even projects staffed by internal consultants should not be left alone, as there is still a good probability that one or more of the eight deadly sins will be committed by the team.

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

Choosing a Project Leader

In a recent discussion with a potential client, he told me that he was in the process of setting up a team to lead a cost-reduction project in his 1000 employees company. He explained that this project was crucial to the company's short-term survival, but that he did not want to compromise the company's longer-term competitiveness due to short-term cost reduction initiatives. His question to me was how he could decide which person to ask to lead this crucial project.

I explained that I agreed that putting together the right team would be crucial for enabling the success of this very complex project, and that choosing the project leader was the first, and maybe most crucial, step in this process. However, I also told him that the choice of the project leader could not be looked at independently of the choices required for the rest of the team. We discussed how the key goal of putting together a project team is to have the right mix of skills and experience. We agreed that this boiled down to the members of the team having the right mix of problem solving / analytical skills, interpersonal skills, and technical/functional skills. In addition, the team should span the parts of the organization covered by the project in order to ensure that nobody feels "left out".

The team required for a project depends on the phase of the project being carried out. In this case, the cost reduction project was just starting up (see Determining the Appropriate Deliverables for the First Phase of a Project) and the focus was on developing a detailed understanding of the situation and key issues faced by the company, to make an overview of key changes required (by how much do costs need to be reduced in order to be competitive and profitable?), and to suggest the overall direction of possible improvements. In this case, I explained that the overall team needed to be fairly small, and consist of people that:
·Know the company well enough to understand where the issues and fat lie
·Are not too constrained by "we already tried that…………:"
·Are analytically strong and able to dig up data to support their conclusions and recommendations
·Are able to think "out of the box" and develop strong ideas on how the main processes of the company could be changed (with reduced costs and (often) improved results)
·Are good communicators able to get input from across the company
·Are sufficiently respected within the company that people will listen to them

The potential client told me that he had some people in mind for the project-team, but was worried about their age and knowledge of the company. I told him that in my experience, a team to carry out this type of activities can be quite young, as it often will be easier for them to carry out the analytical tasks and do the "out of the box" thinking. However, this entails that the key role of the project leader will include managing and quality controlling the work of the rest of the team, and being the main interface between the team and the rest of the organizations. Based on this, I explained that the project leader would need to be somebody who has a fair bit of working experience in the company (ideally in different roles), is fairly strong analytically, but not necessarily an Excel-whizz, is able to mentor and manage a team of younger staff, and is able to communicate well with people across the company and at all levels of the organization (see How to Ensure That The Project Team Has Sufficient Interaction with Sponsors and How to Get Buy-In for Project Conclusions and Recommendations) .

In going through the potential candidates for the project leader role, I quickly focused on a candidate with an MBA, and who had gotten to the mid--management level of the company fairly quickly after having worked in two or three jobs across the company and gained experience in different functions related to marketing and production. My potential client explained that it would be extremely difficult to free this person from his current tasks for the duration of the cost reduction project. After a discussion where we talked about how crucial this project REALLY was, he finally agreed that he would need to use the best person for the project.

While this blog is based on a specific example, following the general rules and ideas suggested here will help anybody who is in the process of setting up a complex project.

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.

Determining the Appropriate Deliverables for the Initial Phase of a Project

All complex projects consist of three basic phases: the initial (or preparatory) phase; the project (or work) phase; and the finalization phase. Each of these phases has its own challenges and pitfalls. These can be avoided by having a clear picture of what should be achieved in each of these phases. This blog-post will suggest what the goals and deliverables should be for the first phase of a complex project.


In my experience, there are a number of things that typically go wrong in the first phase of a project that severely reduce the probability of the project finishing successfully. The most common pitfalls I see in the first phase are:

- The project is not set up to deal with the right issues
- The optimal links are not developed between the sponsor and the project team
- The right resources are not allocated to the team (primarily people and time, sometimes access to expertise and/or money)
- The individuals who are assigned to the project team are not developed into a team

My suggestion is therefore that the primary goals of the preparatory phase of a project should all be focused on ensuring that these pitfalls are avoided. Reaching these goals will entail a set of activities involving the sponsor of the project, the project leader, and the team members. These activities should result in a clear set of deliverables for the preparatory phase of the project.

Deliverable Nr. 1: The appropriate sponsor for the project. This should be somebody who has an interest for the key issues to be resolved through the project, and has the time and energy to spend considerable time on the project.

Deliverable Nr. 2: The optimal project manager. The project manager needs to be a person with an affinity and understanding to the key areas to be covered by the project, the right motivation for making the project a success, and the right skills for carrying out the project.

Deliverable Nr. 3: The appropriate goals, deliverables, targets, and scope for the project. This deliverables will initially be developed in an interaction between the sponsor and the project manager, and will later be changed to reflect initial discussions with the project team.

Deliverable Nr. 4: The optimal team for carrying out the project. The composition of suggested team needs to reflect the issues that the project is dealing with, and needs to include the right mixture of skills. These can typically be divided into technical and functional skills, analytical skills, and interpersonal skills.

Deliverable Nr. 5: A realistic plan for carrying out the project. This deliverable should focus on the overall timing of the projects and intermediate milestones. The important dimension of this deliverable is that the suggested timing is realistic and is accepted by all the project team members.

Deliverable Nr. 6: A cohesive team that has joint ownership for reaching the goals and deliverables of the project within the agreed timeframe. This is a "soft" deliverable that is difficult to definitely "tick off", but a set of activities should be defined that will increase the probability of the deliverable being reached. I do not believe in stand-alone team-building activities. Therefore, my recommendation is that the key activity for achieving this is a formal (and structured) kick-off session. This session should include a "get to know" session, a training session on how to become an effective and successful team, a training session in key analytical tools, an explanation of the project (background, goals, and deliverables), and a discussion on the approach and development of a detailed work plan.

If you can honestly say at the end of the first phase of your project that all of these deliverables have been developed, then the project has greatly enhanced its chances of ending successfully. The project can then move to the next phase which will involve carrying out the key activities required for developing the overall project-specific deliverables of the project.

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

The Eighth Deadly Sin

All of you who have read my previous material know that I often speak about the Seven Deadly Sins of complex projects. Through discussions with some of my clients over the summer, I have become aware of what can be seen as the Eighth Deadly Sin. I also must admit that it says something about my long tenure in large consulting companies that this issue was not included in my original list of project problems.

The new "Deadly Sin" was brought forward by a Board member responsible for a group of project managers carrying out transformational projects across a large number of European subsidiaries. He explained that there had been a number of situations where a project lead by one of his managers had worked well and delivered a new, improved process at one of the subsidiaries. There had been a presentation to the SteerCo and with the help of some input from the Board sponsor the SteerCo had agreed to the suggested changes and the high-level implementation plan. However, six months later it turned out that the issues that the new processes were meant to address (late deliveries, low customer satisfaction, etc) had not improved and that the root cause of this was that the new processes had not been implemented. We had a broad discussion of what the reasons for this were, and agreed that one of the core reasons was that there was seldom any structured follow-up of the agreements that had been made at the end of the design phase of the project.

This problem will certainly be included in an updated version of an overview of why projects go wrong (even though "Eight Deadly Sins" does not have the same recognition-factor as "Seven Deadly Sins"). I also have to admit that the main reason that I did not include this in my original list is that the type of blue-chip consultants where I have worked earlier are usually only involved in the early phases of the projects, and are less concerned with the actual implementation. This is, of course, one of the main reasons for using internal project teams with end-to-end responsibilities that includes implementation.

Why are the results of projects not implemented? There are a number of core reasons (some quite valid) for this:

• Very often teams are more optimistic than actually warranted about the real buy-in and acceptance that they have created for their conclusions and recommendations

• Environmental changes may make the agreed changes less attractive than originally believed. An example is if the success of an agreed change to a delivery process is dependent on a new product being launched, but the launch has been delayed

• Priorities within the organization may change. An example could be if the local company has to focus all its free resources on meeting the threat of a new product launch from its main competitor

• The natural inclination of people to give higher priority to the activities that are required for making "today" successful

Issues related to truly getting the required buy-in and acceptance need to be dealt with in earlier stages of the project (see blog entries on interacting with sponsors, dealing with key stakeholders, and getting buy-in for conclusions). The other factors can be successfully dealt with by firstly developing sufficiently detailed implementation plans as part of the overall project deliverables and then putting in place and using a pro-active and structured benefits tracking process. Such a benefits tracking process should follow-up on the overall implementation plan and key milestones, it should measure the fulfillment of agreed targets, and it should include the opportunity to report back on changes in environmental factors and priorities. If the benefit tracking process needs to follow-up on a number of projects (as part of an overall program), then the benefits tracking process should also be multi-layered and focused on exceptions where decisions need to be made rather than giving the same level of detail on all projects.

The advantages of such a benefits tracking system are many, and include:

• There is even more pressure on the project to deliver good work and ensure buy-in as they know the quality of their work will be followed up

• Even if buy-in for the conclusions and recommendations coming out of the project is not 100%, it becomes more difficult not to carry out agreed actions if they are being followed up

• Pro-active follow-up will enable a top-down understanding of environmental developments and changes in priorities, and will allow the development of an agreed "Plan-B"

• The fact that implementation is being followed up makes action much more likely as people will feel the pressure of upcoming milestones and deadlines

Based on the assumption that the project is only successful when the required changes have actually been implemented, ensuring overall buy-in for the results and following up on implementation should be seen as core parts of the overall project. Follow the links if you are interested in more information on project planning or project management training.

Complexity Reduction For Structurally Improving Profitability

For most of you, the complexity of your business has increased over the last ten years. Key reasons for this include increased competition, the need for segmented offers for meeting specific customer requirements, new technologies, etc. While this may have lead to higher revenues, it has more often than not also lead to structural increases in capex and higher operational costs through-out the supply-chain. In addition, I have seen numerous companies where increased complexity has lead to difficult and slow innovation processes, seriously hampering the companies’ abilities to meet new competitive threats and/or market opportunities.

Today, I see that many companies believe that complexity reduction is a fairly easy way to reduce costs. A project is started to carry out a Pareto analysis of revenues across products, and typically sees that the 80/20 rule holds, and that the tail is not profitable. The project then suggests that the 10% of the product portfolio having the lowest sales are terminated. In spite of protests from marketing & sales this is then carried out. Results, however, are more often than not disappointing, or even non-existent.

In my experience, complexity-reduction is a critical activity for a majority of businesses. While complexity-reduction in the restaurant business appears to be fairly easy, in most companies I consult to it needs to be carried out in a structured and well thought out manner where:

• It is understood that not all complexity is bad, and that the crux is to get and keep the right level of complexity for your specific company situation

• It is realized that the process is complex, will take time, and will result in only limited “low-hanging fruit” opportunities

• It is possible to put a well-organized and broadly supported project team in place to carry out the project.

If you believe that your company is suffering from too high complexity, my experience is that you will need to put in place a project to carefully consider a number of inter-linked aspects related to complexity. The first step in the process will be to understand the complexity in your organization. This will involve understanding the true complexity drivers of your current business. Typical examples include number of customers, number of products (at the lowest level of detail), number of packaging variations, number of ingredients, number of technologies, etc.

You will also need to understand the value of your market-facing complexity (i.e. those aspects which your customers see). This will involve understanding the reasons for the variations in your market-offering, analyzing the value that your customers place on the variation offered, and deciding what the consequences would be of reducing the variety you offer to the market-place. The final analytical activity will involve understanding the costs of complexity by going through a detailed activity-based costing exercise to allocate costs to the different complexity drivers (products, customers, etc).

The next step will involve carrying out a direct pruning of the product portfolio based on the preceding analytics. This portfolio reduction will not focus on the tail of the product portfolio, but will rather seek out products where the strategic value is low and costs can truly be reduced either due to a negative margin or through specific opportunities to reduce overhead through the removal of one or more products from the portfolio.

In addition to reducing the complexity that is visible to your customers, the project team will also need to look at opportunities to reduce below-the-skin (i.e. not visible to your customers) complexity. At one of my large telco clients, this is one of the key issues they are facing. They currently provide many services that are similar from a client perspective, but which are delivered through different technologies. The company is now going through a process to move delivery of all services to one platform, and expects that this will result in major savings. However, it is finding this process challenging as it requires a broad coordination across the commercial and technical organizations.

While these activities related to reducing customer-facing and internal complexity will provide you with considerable benefits through the one-off reduction in complexity, my experience is that complexity will quickly creep back if structural changes are not made to key processes. The most important process to change is the innovation / new product development process. The key goal of the changes to this process is to ensure that only complexity that truly adds value is allowed in new products. A key change to enable this is to ensure that all complexity costs are included in the business case for the new product. In addition, the improved innovation process should ensure that the production of the new product minimizes internal complexity by pushing for the use of modular designs, re-use of components, etc.

Finally, the complexity-reduction team will need to put in place (or improve) a portfolio management process to ensure that an overall portfolio view is taken in decisions related to new products, and that regular reviews are carried out to discontinue low-value / end-of-lifecycle products.

While the described process is intense and requires a substantial investment in time and resources the returns are also substantial both in reduced costs and extra revenues through faster time-to-market for critical new products. Follow the links if you are interested in more information on project planning or project management training.

Helping a Project Team Develop Meaningful Conclusions

In a recent post I outlined eight signs that are leading indicators for a project that can be expected not to reach its goals and targets in a timely manner. This post will highlight how best to deal with the last of these signs, a situation where it is difficult to pin the team down on any meaningful conclusions.

Why is this a problem? A key assumption is that the project is meant to develop conclusions and recommendations. There may be projects that have been given a responsibility for "collecting all information". However, in my opinion such a project would be very wasteful. There may be projects that have been asked to only collect data and analyze data about a given issues. In my opinion this is a wrong way to set up a project, as it is impossible to carry out any meaningful analysis without having a goal and a set of hypotheses leading to conclusions.

Assuming that the core reason for the project is to develop conclusions about a key issue, then it is naturally a problem if the project team does not seem interested in doing so. In addition, this is often a fairly scary problem, as it will typically come to light late in the process (sometimes not until the final presentation). This problem therefore can, make most, if not all, of the effort and resources that have been invested in the project a waste.

What is my advice to you, as the project sponsor, to avoid this problem? The most important input from your side is at the beginning of the project. You need to start the project off with clearly defined goals, and deliverables that are very explicit regarding the type of conclusions and recommendations that you expect. You will also need to follow up on the project regularly (default is weekly) to ensure that the project is sticking to its plan and going in the right direction (i.e. will it be able to deliver the required conclusions and recommendations).

When I am helping my clients make complex projects successful I ensure that regular meetings take place with the project team (and sponsor). These regular meetings serve a number of purposes, but should also be used to ensure that the project team is working with hypotheses. Doing so will enable me to test whether proving the hypotheses will bring the team closer to its final goals. In addition, and even more importantly, working with hypotheses enables the project team to work much more effectively and efficiently. Finally, I always strongly suggest that the team is forced to test its conclusions in a Blue Team. This is a meeting with experts who are not directly involved in the project where key ideas and potential conclusions are tested, and the participants are asked for input on key issues and complications.

The previous suggestions are only helpful if the project is starting up or is fairly early in the process. What can you do if you are at the end of the project, and the team does not seem to be close to developing any conclusions? I am often called in to help in this type of situation, and it requires some fairly intense input to correct. The first step is to sit down with the team and go through the overall process of the project. I usually start with a review of the key starting points for the project, and then discuss and agree the goals and deliverables that were given to the project. These should be presented as clearly leading to conclusions and recommendations.

I then go through the work that the team has carried out and find the key data points that have come out of their analytics. These data are discussed with the team with the goal of agreeing what they mean. This is then developed into (preliminary) conclusions. These conclusions then need to be stress-tested. Are they robust? Are they well-supported? If the answer is "yes", the team can start thinking about the communications phase. If the answer is "no", the team and the sponsor need to check how much time is available, and agree the very specific activities that will make the conclusions more robust. The work that the project team carries out in this phase must be followed up very intensely to ensure that every moment is spent on work to make the conclusions more robust.

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

Dealing With a Project That is Not Meeting Deadlines

In a recent post I outlined eight signs that are leading indicators for a project that can be expected not to reach its goals and targets in a timely manner. This post will highlight how best to deal with the seventh of these signs, a project that is not meeting deadlines.

Why is this a problem? In my discussions with executives across the world, the first complaint that they usually give about internal project teams is that they do not deliver the end-results of the project on time. You can be pretty sure that a project that is not meeting interim deadlines is highly likely not to meet the final deadlines as well (independent of what your project manager tells you).

In addition to this, I find that delays to intermediate deadlines are very often a sign of other potential issues. Typically, the delays are caused by the team not being able to make sufficient time available for the project, the team spending too much on the wrong activities (such as data gathering or interviews), or the team being very uncomfortable with the basic premises of the project (background, goals, expected deliverables, etc).

What can you as a project sponsor do if one of the project teams that you are responsible for is missing intermediate deadlines? My key message is not to let it slide, as it is very unlikely that the problem will go away by itself. The first action you need to take is to sit with the team and demand a fairly detailed explanation of why deadlines that have been agreed in their project plan have been missed (this assumes that the team has had input to the plan and has accepted the key deadlines in this plan). In this discussion, you should be prepared to dig beyond the standard answers to uncover the true reasons for the delays. A standard answer you will hear is that the team has not had sufficient time to carry out the activities. This is almost always true, but should have been known to the team when they agreed to the project plan. You therefore need to push the responsibility for sticking to the plan firmly back to the team.

However, I do also see situations where the project team's opportunity to allocate time to the project has decreased due to changes in priorities within the organization. If you are facing this situation, you will need to be prepared to act. You will need to understand what these new issues are and why they require time from members of your project. You will need to discuss alternatives with the other executives claiming time from your team members. If it is not possible to solve the issues related to the available time, you will need to develop (together with the team) alternative plans. This can involve reducing the scope of the project, delaying key milestones, or adding resources. Each of these solutions has its own pros and cons and needs to be analyzed in the specific context of the project and the organization.

However, in my experience, the most usual reason for a team not meeting deadlines is that the delays are caused by the project team spending too much time on certain activities (i.e. data collection, analytics, etc). If this is the case, you as the sponsor must be prepared to dig deep for the real reasons for this. You will also need to hammer home the need to stick to deadlines. You should also communicate that 100% knowledge is impossible, and that you trust the team to come up with good conclusions and recommendations in the time that they have been given (and have agreed). In this case, you will also need to help the team prioritize its activities going forward in order to get back on plan. My final recommendation is to keep a close eye on the team going forward. This is based on my experience that once a team has shown an inclination not to meet deadlines, it is likely to do so again.

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

How to Ensure That Key Stakeholders Are Sufficiently Aware of the Project

In a recent post I outlined eight signs that are leading indicators for a project that can be expected not to reach its goals and targets in a timely manner. This post will highlight how best to deal with the sixth of these signs, a project where key stakeholders are not aware of the project.

Why is this a problem? This is a problem because input from stakeholders is required both for increasing the overall quality of the project results and for getting key recommendations implemented. Stakeholders can be defined as the people within the organization who are interested in the results of the project because they can be impacted by the conclusions and recommendations coming out of the project. Key stakeholders can include managers from specific organizational units (marketing, production, etc), but also unions (in the case of cost-reduction projects).

If the project team has not had any (or only very limited) contacts with key stakeholders it is very unlikely that all key issues that are important to these stakeholders have been included in the overall project analytics. In addition, it is even more unlikely that the stakeholders will have a positive opinion about the project and the project results as they will feel left out of the process and not listened to. As a result, it will be very difficult for the project team to carry out an optimal communication process in the end phase to create the buy-in necessary for implementation. This will mean that the end-phase is likely to be difficult and unpleasant, and that the resistance to the project conclusions will be high.

In many of my projects I find that this is one of the corrective actions that need to be carried out. The best way to do this is to plan a meeting with the project team (again). The key goal of this meeting is to discuss and agree who the key stakeholders are, and what their most important issues are. Based on this, the team develops a concrete plan to sit down with each (type of) stakeholder. In these stakeholder meetings the team should present the project (what are the key starting points, the issues that the project is dealing with, the overall goal, the key deliverables, and the approach) and what the team believes the potential interests of the stakeholder are.

Usually, I need to explain to the team that they must listen very carefully to what the stakeholder has to say. Key points that need to be understood by the team include what the stakeholders sees as the key issues, and how they believe that these issues should be dealt with. I highlight that it is important that the project team does not make any promises (explicit or implicit) regarding how the issues will be dealt with as this will seriously compromise the ability of the team to come up with the optimal answer. Rather, the key goal is that the team knows what the viewpoints of the stakeholder are, and that the stakeholder feels that he has been listened to.

Together with the sponsor, I typically plan a new meeting with the project team after they have seen the key stakeholders. In this meeting we discuss the viewpoints presented by the stakeholders, and agree what the team needs to do in order to ensure that these issues are dealt with in an optimal manner. In addition, an ongoing set of meetings is planned with key stakeholders. The emphasis of these meetings will gradually change from getting information to presenting and testing key hypotheses and possible conclusions and recommendations.

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

Ensuring That the Project Team Has Sufficient Interaction With Sponsors

In a recent post I outlined eight signs that are leading indicators for a project that can be expected not to reach its goals and targets in a timely manner. This post will highlight how best to deal with the fifth of these signs, a project a team that has very limited interaction with sponsors.

Why is this a problem? This is a leading indicator for problems because it means that the project team is not using a key resource for advancing the project. The project team should be using the sponsors to a) check that that the project is heading in the right direction and to get guidance on key issues, b) to get information about key environmental changes that can have an impact on the project, c) to use the sponsors to help deal with logistical issues (getting into the agenda of key information sources, getting additional resources and/or data, etc), and d) to pre-communicate and test key findings and possible conclusions / recommendations.

If the team is choosing not to use this resource, delays are very probable (as limited time is likely to be the reason that the project team is not seeing the sponsors), and, most importantly, quality of the project results will suffer. Lower quality will primarily be a consequence of not having given the sponsors the opportunity to provide corrective input if the team is going in a wrong direction (due either to wrong assumptions or changes in business environment). In addition, timing and deadlines are likely to suffer due to the project team not using the sponsors pro-actively for logistical issues. Finally, getting overall acceptance for key recommendations is likely to be more difficult if the project team has not pre-communicated initial ideas and preliminary conclusions to important sponsors.

What do I do when I see this problem? A key complexity in this situation is that it is very likely that the main sponsor is part of the problem. The first part of my solution therefore involves a discussion with the sponsor where I ask a series of questions. Does the team understand that you want to be involved? Have you made time available for the team when they have requested this, or have you cancelled the last three meetings?

If the sponsor agrees that he/she is part of the problem, then he/she will need to make a special effort to help get the team back on track. My advice to the sponsor is usually to call in the team for a meeting, and set a clear agenda for the meeting. The agenda should cover issues such as overall progress, key issues the team is facing, logistical road-blocks, initial ideas and theories, etc. The meeting should end with an agreement to meet again in the near future, and an agreed plan to meet the other project sponsors. Typically, I need to explain to the sponsor that he/she will to help the team set up these meetings. My experience with getting the sponsor more involved is that the team is very happy with this input, and that it often is possible to get the project back on track fairly quickly.

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

Helping a Team Carry Out Meaningful Analytics

In a recent post I outlined eight signs that are leading indicators for a project that can be expected not to reach its goals and targets in a timely manner. This post will highlight how best to deal with the fourth of these signs, a project a team that does not appear to be doing any meaningful analytics.

Why is this a problem? There are two main reasons why this should worry you. The first is that it is extremely difficult to conceive of a complex and important project that does not require any analytical activities to arrive at the required conclusions (if the answer was easy, it would not require a project). Therefore, if the team is not carrying out these types of activities, you and the other stakeholders are very unlikely to get the conclusions and recommendations you require. In the best case, you are likely to get a "data-dump" and a set of options to choose between.

The other reason why this is a worrying symptom is what you tend to see such teams doing instead of analytics. What I have often seen is that such teams seem to be working hard, but are spending their time carrying out a large number of interviews, collecting as much data and information as they can lay their hands on, and, often, doing a lot of travel. The consequences of these activities are that project costs are too high, and that it is very unlikely that the key project milestones will be met.

Why do project teams typically not carry out the required analytical tasks? In many of the situations where I am asked to help this is caused by the team having an unclear picture of what is required from them, and therefore thinking that preparing a "data-dump" is the goal of the project. In other companies I see project-teams that are unable to carry out the required analytical tasks. While analytics is second nature to many people (consultants, etc), there are many capable and smart people who are not good at structuring and analyzing (new) problems. Finally, I also often see teams that are unwilling to go beyond data-collection as they are uncomfortable with the possible conclusions and are not willing to deliver unpopular recommendations.

What can you do to help the project team carry out the required analytics? My first step in helping teams with this problem is to recheck the project plan to understand how much analytics are required. The next step I carry out is to sit down with the project team to understand why they are still in the data-collection phase. The next steps will depend on the answers given by the team. In situations where they do not understand that they are required to do the analytics, I ensure that the team understands the true goals of the project and how the required deliverables depend on analytics. This set of actions will also help to push the team that is unwilling to go beyond data-collection to come up with uncomfortable and/or unpopular conclusions. In this situation I find that it helps to explain to the team why they (as individuals) have been asked to carry out this project.

In the cases where the missing analytics is due to inability, then the team composition is wrong, and together with the sponsor I consider what we can do about this. One solution is to add analytical capacity to the team, but the responsibilities of such a person has to be carefully defined in order to avoid team-development issues. The second solution will be to push the team to do their best, possibly combined with a workshop on specific analytical techniques (spreadsheets, statistics, etc). This is the best solution if keeping to deadlines is more important than optimal quality.

Using the process described above, I was able to help/force the team at the utility company to develop overall conclusions and meet the final agreed deadlines. Follow the links if you are interested in more information on project planning or project management training.