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.

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.

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.

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.

Dealing With a Project Team That is Not Spending Enough Time Together

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 second of these signs, a project team that does not seem to be not spending much time together.

Why is this a problem? A complex project will (almost by definition) require input from different parts of the organization. It will also almost always require a combination of different experience, knowledge, and abilities in order to successfully meet its goals. While there are certainly project-related activities that need to be done on an individual basis, there is a great deal of work that needs to be done jointly by the team.

In my experience, the first, and maybe most crucial, of these activities is getting real agreement on the goals and deliverables of the project, and the translation of this into activities (Other crucial success factors for starting up a complex project are described in another blog-post). This common and joint starting point can only be achieved by spending time together, and is crucial for ensuring that all team members are doing the right things. Another activity that must be carried out jointly is the interpretation of the outcomes of analytical activities (see blog-post on how to get a team to carry out meaningful analytics). While the initial analysis can be done by one member of the team, real quality is added by using the experience and knowledge of the rest of the team. Spending time together for this type of activities is also crucial for ensuring that the rest of the team understand and agree the outcome of specific activities in order to optimally carry out their own pieces of work.

A complex project typically also requires a high degree of coordination between activities. This can sometimes be done face-to-face between two team-members, but broader coordination is often required to ensure that all activities are optimally linked to each other. A typical example of such coordination comes from a recent project where I helped a team develop a business plan. In this project two crucial activities were developing a spreadsheet model and collecting data and developing assumptions for filling the model. One of the major challenges this team had was ensuring that these two activities were aligned regarding type of data and the format of the data to be collected. An additional complexity was that the requirements of the model were changing over time as additional insights were developed. This alignment was done partly in team meetings, and partly in face-to-face meetings between the modeler and the individual team members.

Finally, the development of the overall conclusions and recommendations from the project will require closely working together, as it will be based on analysis and interpretation coming from all the activities carried out by the team. This is crucial not only for the quality of the results, but also for developing the required consensus view on the conclusions (especially if the project is political in its nature and the team members represent different factions within the organization).

Why do project teams not spend sufficient time together? Sometimes I see that it is because they do not understand the need for working together. Often this is combined with a feeling that they do not have sufficient time to spend together, and need to focus on "doing the work". Other times, the team members do not feel comfortable working together. This is especially the case if the project is political in nature.

What can be done to help the team spend sufficient time together? The first step I typically carry out is to sit down with the team to understand why they do not get together more often. Typical answers I l get are that there is limited need and that they do not have the time to spend together. In this case, I make a strong case for why time together is required (using the arguments given earlier). If "time" truly is a key factor, then I have had to ensure that the team members are able to free up sufficient time from their day-to-day activities to give the required attention to all aspects of the project work. This has usually required the assistance of the project sponsor. Finally, I have forced the team to set appointments for getting together (including agreeing an agenda for what will be discussed). In these cases, it has also helped if the sponsor has taken time to sit in on one or two meetings to help the team to work effectively together.

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