Ensure Project Success by Demanding Proposal

I am sure that most of you have been the sponsor of projects that have not reached their objectives in a satisfactory manner. In these situations, you have probably wondered if you as the sponsor could have done something to make the project a success.


In my experience, there is one action that you as a sponsor can take that will greatly increase the success rate of internal projects. This is to demand that the project manager (and team) develop a proposal similar to what you would expect from an external consultant. You will the need to evaluate the proposal in the same way that you would evaluate a proposal from your consultant. This includes concluding whether the proposal from the internal team:

• Shows that the team truly understands the core issues that you need to have dealt with
• Suggests goals and deliverables that will actually help you deal with your core issues
• Presents an approach that makes sense by suggesting a reasonable set of activities, use of time and resources that both meet your deadlines and are reasonable, and presents a set of milestones that show how the project will move forward and gives you the opportunity to easily understand whether the project is on-track

If you are not satisfied with the proposal you then have the option of sending the project team back to the drawing board or to consider other options (including external consultants).

While a well-structured and agreed proposal is a key success factor, it really shows its value when it is used as part of your top-level management of the project. A key component of this process is to insist that the project team sticks to the agreed deadlines and milestones (as is second nature to external consultants).

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

Interesting article in Harvard Business Review

In the September number of Harvard Business Review there is a very interesting article, "Mistakes Leaders Keep Making", by Robert H. Schaffer. This article highlights four behavioral traps that thwart organizational change. It is an excellent article, and while the focus is on organizational change and the relationship between executives and subordinates, the issues highlighted and the suggested solutions are directly transferable to teams carrying out complex projects. My translation of his behavioral traps to a team setting is:


• Behavioral trap 1 : Executives and sponsors typically fail to set proper expectations for the teams carrying out critical but complex projects

• Behavioral trap 2: Teams carrying out complex projects are not staffed with the appropriate people because they are "too busy" and/or are protected by their line managers

• Behavioral trap 3: It is safer psychologically to "sign a fat check to a consultant and hope for the best"

• Behavioral trap 4: Delays in reaching key milestones are tolerated if the project team is able to point to dependencies to other company activities (we need a new computer system before we can………………..)



I believe that these behavioral traps are very similar to the "seven deadly sins" I have written about in previous blog-entries. This means that these issues can be addressed by going through a step-by-step process to ensure that the internal project is set up correctly, and by carefully carrying out an ongoing quality and timeliness controls. Follow the links if you are interested in more information on project planning or project management training.

Getting a Project Team Quickly Up To Speed

I am currently in the process of carrying out a project at a European energy company. In this project I have helped the project team recover from a disastrous first phase by helping set up a structured and fast start to the second phase of the project.


The project was originally staffed with a team of eleven technical people from across the company. The people chosen for this team represented a wide range of departments that dealt with the technology. The team worked for four weeks, and presented its results. The Steering Committee was disappointed with these results, as it felt that a) the team had not addressed the key issues, and b) had not developed a sufficiently detailed analysis of the "facts and figures" related to the technical elements being analyzed. A number of things went wrong in the first phase, and my key role has been to correct these issues in the second phase of the project.

The main problem the project team faced was that it had too little time to carry out any actual analytics. This was caused by an unrealistic deadline imposed by the steering committee, but also by the project using almost two weeks of the available four weeks in starting up the project and carrying out "team building" activities related to agreeing the goals and deliverables of the project. The excessive time spent on starting up the project was due to a number of inter-linked reasons. The key reasons are cultural, habit, politics, and insecurity in project leadership:
• The company in question is from Northern Europe, where egalitarianism is important. This general cultural trait is strengthened by the culture of the company itself which is also fairly flat in its structure, and believes in everybody having the right to state their opinions. This results in "open debate" being the default solution for setting up this type of projects.
• Habit was in this case mainly driven by the use of an internal process manager, who (rightly or wrongly) believed that this was the way that projects should be run. In this company, the type of team building through the bottom-up development of goals, deliverables, approach, etc is "the thing" that project managers do, and which probably work fairly well in this culture if the project has sufficient time.
• Politics played a key role in this project, as the best way forward for the technological asset being discussed was a highly political issue with extreme differences in opinions across the various departments of the company. This meant that all the team participants felt that they had to "push" their preferred solutions rather than focusing on the work to be done.
• The project leadership (both the formal project manager and the internal process manager) were open about not being used to running this type of complex project. This meant that they were not sure about how best to structure such a project, and were uncomfortable with "pushing" their views in a group of experts.

The second phase of the project was set up to minimize the problems encountered in the first phase and to maximize the probability of the project team being successful. The project started with the project leader. The project leader developed a very clear and structured overview of what the Steering Committee / key sponsors were looking for (goals and deliverables). This was put on paper, and tested with the sponsor / steering committee, and adjusted as required to ensure that the expectations on what will be delivered were 100% clear. Based on this, the project leader developed an overall approach for reaching the goals and deliverables. This plan included a small core team and a realistic estimate of the time required for reaching the agreed deliverables.

When agreement was reached with the steering committee and sponsor the project leader brought together the chosen team, and communicated the results of the first step. He asked the team for comments and feed-back, and adjusted the details of the plan for the good ideas and comments that were given. The structured and hierarchical start of the project meant that this process took less than one week instead of the two weeks in the first iteration of the project, and was also much more efficient as the total man-hours used were 25% of that used the first time around.

The structured and hierarchical start has also meant that politics have been minimized and effective use of the available resources maximized. The core project-related activities have been carried out through a mixture of sub-teams doing specific analytical tasks (within agreed milestones) and presenting and discussing the results with the rest of the project team. The role of the project manager in this phase has been to strictly follow-up on scope (is the team focusing on what they should be doing?), analytics (is the work being carried out correct?), quality of results (are the outputs from the team's work what it needs to be), and coordinating the work of the different work-streams.

At agreed moments the project manger and the core team have brought together the work of the individual teams and developed the overall conclusions and story-line. This has been presented to the whole project team and discussed (and revised) until the team agreed to the overall conclusions. The results were then presented to the steering committee in the form of interactive workshops.

The project is now in the final phase and the results are being discussed with the individual steering committee members before the final presentation. This will ensure a broad agreement to the conclusions that the project has developed and commitment to the follow-up actions suggested by the team.

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

The Business case For Improving Complex Projects

As you probably know, my core business is to help improve the performance of internal teams carrying out complex projects. In discussions with executives concerning input from my side I am often asked to define the business case for using my services. This question has become steadily more usual in the last year, as it has become progressively more difficult for companies to hire in external help.

The direct value of my input is difficult to quantify as my service is secondary. Therefore, my initial reply focuses on helping the executive understand the business case for the project he thinks is in trouble.. If this is non-existent, or very difficult to quantify, my advice is that the project should be stopped. For some projects, such quantification is fairly easy. If the project in question is a cost reduction project, the value of the project is driven by the size and timing of the savings to be implemented. If the project focuses on product development, the value of the project is driven by the revenues and profits expected to result from the new product.

For other types of projects, such quantification is more difficult, but can usually be carried out. For a strategy project, the value can be very high, but the quantification needs to take into account follow-up projects required for implementation, etc. For a reorganization project, the value should come from improved decisions, better use of resources, etc. This is all fairly indirect, but clearly has value.

If the overall project has value, it is then critical to understand that this value can be radically reduced by a number of issues related to how the project is carried out. Any of the "8 deadly sins of complex projects" will lead to such a loss of value, but I will focus on a few concrete examples.

If a project is delayed because it is not meeting its deadlines, then this has a direct effect on the value of the project. Let us assume that the project will increase annual profits by €1 million. This can be the result of a cost reduction program with a €1 million bottom line effect, or a new product launch with annual sales of €4 million, 25% margins, and negligible "fixed" costs. In this case, a one-month delay in the project means that your company will have a one-off (but permanent) loss of €0.1 million in profits.

Lower quality results from the projects will also have direct consequences on the value. Let us assume that the cost reduction project mentioned earlier does not identify all the cost saving opportunities that were available and/or expected. If the project only identifies €0.9 million bottom-line effects instead of the €1 million that is believed to be available, then the annual loss is €0.1 million. In the product development example used earlier, then a fairly minor mistake in the product definition and/or pricing that leads to 3% less revenues will lead the same ongoing annual loss of €0.1 million.

A project team that does not communicate optimally can lead to the same type of value-loss. If the work carried out is good, but the results are not accepted and therefore not implemented, then the loss of value is 100%. If the unsuccessful communication leads to lower buy-in resulting in either delays or only partial implementation then the consequences will be the same as in the previous example (i.e. ongoing annual losses).

My experience is that using the Team Based Consulting methodology to provide structured help to project teams (including the executive sponsor) in a) defining and setting up the project, b) carrying out the project, and c) developing and carrying out a communication process can easily help avoid the type of value-loss given in these examples. Given the fairly focused and limited input that is required from my side to help the internal teams, the business case for such an intervention can almost always be made.

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