Seven simple rules leading to successful Steering Committees

In my previous blog-spot I presented my views on how to put together the optimal Steering Committee (SteerCo). The main message was that very many SteerCos are put together for the wrong reasons and with the wrong participants. The only valid reason for having a SteerCo is if there is an ongoing stream of "steering" (usually a combination of decision-making on complex, company-broad issues and quality control from a company-broad perspective) throughout the project (and not only at the end). The participants should be chosen with these goals in mind, and should be the lowest-ranking people that can make the decisions that are needed.

Assuming that you have put together the optimal SteerCo, the next question is how you can make best use of it during the project itself (how to deal with the SteerCo at the end of project will be the subject of a separate blog-spot). The following rules will help you make the most of your SteerCo meetings:

1.    Inform the participants at the start of the project about what you want from them. This may have been done as part of the process leading to the choice of SteerCo members, but is still worthwhile doing again. In an individual face-to-face meeting (before the first official SteerCo meeting) explain to each member of the SteerCo about the project, the role of the SteerCo, and why the individual has been requested / chosen to sit in the SteerCo

2.    Plan and schedule regular SteerCo meetings (and meeting rooms). Most people have very busy diaries and it can be very difficult to schedule a meeting involving several key managers. The best solution is therefore to schedule all expected SteerCo meetings already at the start of the project. Where possible, these meetings should be linked to key milestones and expected issues where input from the SteerCo will be needed. Sometimes it makes more sense to plan regular meetings (monthly/bi-weekly/weekly depending on the heartbeat of the project and the number of expected issues that the SteerCo will need to deal with). When scheduling these meetings, promise that you will cancel them if the meeting is not required.

3.    Plan each meeting well in advance. Find out if you have issues/decisions that need SteerCo attention. If this is not the case, then cancel the meeting. This will save you and the project considerable time, and will give you goodwill from your SteerCo members. The agenda and key issues to be discussed should be communicated to the SteerCo as early as possible so that they can prepare. In some companies where I have worked, there has been a requirement to send out the presentation to be used in the meeting. This has never been my preference, as it tends to lead to disjointed and unstructured discussions in the meeting itself. However, if this is the culture, then you do not have a choice.

4.    Make sure that the meeting room is available and that all the technical stuff (PC, beamer, etc) works. This is a bit of a "no-brainer", but, believe me; I have experienced all of this happening.

5.    Start the meeting by presenting the agenda and agreeing the planning and time allocation (especially important if one or more people need to leave early).

6.    Present your material in a structured and clear manner, and clearly specify what the issue/problem is, what the alternatives are, and what decision you are requesting. Make sure that a decision is given. If the SteerCo is not able to give a decision, agree what concrete steps need to be taken in order for a decision to be made

7.    Send out minutes of the meeting as quickly as possible (the next day at the latest). The minutes should be as short as possible, and if you can agree and use a standard structure, so much the better. The content should be limited to key decisions and a log of agreed action points. The minutes are extremely important as they provide a written record of decisions made, thereby ensuring that everybody has the same recollection of these decisions. The action log gives a written overview of the agreed "to-do's". This helps you and project team remember what needs to be done, and can also help in pushing SteerCo members to carry out activities given to them

If you have put together an optimal SteerCo and follow these fairly simple rules, then your SteerCo should play a valuable role in your project. Unfortunately, there are still a number of things that can go wrong. These will be discussed in a later update.

How to ensure successful start-up of a project

For most of us the summer is over, and we are back to work. For many of you this will mean starting up new projects. In a previous blog-spot I talked about which projects you should do in-house (i.e. not hire in external consultants). I will assume that you have a number of this type of projects under consideration and that your role is either being the sponsor or the project manager.

In my experience, the start-up is the most crucial phase of a complex project. This is due to it very much determining the success of the project, and the difficulties in to correcting many of the mistakes that are often made in this phase.  Many times when I am called in to help projects that are ongoing but are facing difficulties, I have to re-start the project in order to get them on the right track again.

The main goal of the start-up phase of a project is to ensure that the project is defined optimally and clearly. If this is difficult, as it often is for complex projects, then a solution can be to do a scoping project that has the goal of developing a clear understanding of the problem at hand. Examples of such scoping exercises that I have carried out include a project that had as the goal to understand why delivery times were so long for a telecom company. The projects gave a number of clear issues leading to long lead times, and solving these issues then became a number of structured and focused follow-up projects.

Ensuring that a project gets a flying start entails carrying out a structured process that requires careful thinking at each step. The order suggested in the process is crucial, as each previous step provides key information and starting points for the next step.  The steps that you as the project sponsor / project leader need to take to ensure that the project gets an optimal start are:

·         Clearly define the background for the project
·         Develop a clear goal for the project and translate this into structured deliverables
·         Clearly state the scope of the project
·         Decide the approach that the project needs to take
·         Find the staff required for carrying out the project

--------------------------------------------------

I am constantly amazed at the projects I see where the team members cannot clearly articulate why the project is being carried out. In my experience this often means that the team members also do not truly understand the work that they are carrying out, and are therefore very likely to spend time on wrong activities, or develop inappropriate conclusions from the work that they have carried out. The first step you need to take is therefore to clearly articulate the "why" of the project. This should position the issue in the broader context of the organization (strategy, etc), and ideally give a "burning platform" that will motivate team members, sponsors, etc.

A clearly stated "why" for a project makes it relatively easy to develop the goal of the project.  The goal of the project should be a clear and concise statement of purpose. It establishes what the project will do. Examples of goals in recent projects that I have carried out include:

·         Make the company profitable
·         Develop a clear telecom strategy
·         Develop a strategy for positioning the company in the New Energy market

The goal is a fairly broad statement that says what the project will do, and is used to set expectations and establish a stake in the ground regarding what the project will do and the scope of the project. A common mistake is to state a goal that can only be reached far in the future with input from this project and other projects. This is not helpful, and effort needs to be made to ensure that the goal is relevant for the project at hand.

The deliverables of the project are the concrete things that the project will provide. This should always be a noun, and be something that did not already exist. It can cover a broad range of "things" ranging from insight, a plan, an implemented plan, etc. The deliverables can be seen as how the goals of the project will be met. The agreed deliverables of a recent turn-around project I carried out included a) clear understanding of why the company was losing money, b) concrete actions to turn the company around, c) a new organization structure, and d) a focused and structured plan for the implementation phase.

I have seen very many projects that have gone wrong because the scope was not clearly defined. Typical problems have included projects that have gone off on tangents that were not really relevant and projects that have been drowned in "extra" activities from sponsors and other stakeholders. While goals and deliverables clearly state what a project will do, a clear scoping statement states what the project will not do. This helps the project set and exceed expectations. In the cost-reduction project mentioned in the previous paragraph a clear  scoping statement was that the team would not define detailed work-plans for the initiatives that it defined. This enables the team to push back on requests to do this work, and deliver the results within the agreed time-frame.

Based on the deliverables and the scope the next step is to define the approach. I have seen many projects lose valuable time discussing the overall approach when this could and should have been done before the kick-off. Essentially the approach is defining how the deliverables will be produced and includes an overview of key activities to be carried out, key milestones, inter-dependencies between activities, etc. The best way to develop an approach is to start with the deliverables on the left-hand side of a page and work your way backwards.

The final step in preparing a project is to decide on the required resources and staffing. The starting point for this exercise is the overall approach defined in the previous step. The key things that need to be decided is the total amount of resources required (how many for how long), and the specific types of skills and capabilities needed to make the project a success. Skills and capabilities can be divided into three main types:

·         Problem-solving skills
·         Technical / functional skills
·         Interpersonal skills

The challenge is to find the people who have the right skills and who are available. Availability is always a problem, and a tip is not to be too critical, as skills can often be developed during the project.

Once you have gone through all of these steps, the time has come to start the project with a kick-off for the whole team. Based on the work that has been carried out in this phase developing a successful kick-off meeting is easy. The kick-off meeting will then provide the starting point for a successful project that will result in the agreed deliverables within the agreed time-frame.

When should you worry about your internal projects?

Many of you are in a situation where the number of complex issues that need to be dealt with outside of the standard organizational structures is growing. For different reasons, some economic and some related to a wish to build up internal capabilities, less projects are being outsourced to external consultants. Due to this, the number of internal teams dealing with complex projects is growing dramatically.

If you have a portfolio of complex projects then there are almost certainly one or more projects within the portfolio where you have a “gut feeling” that the project is not going well. Since you do not have any conclusive evidence it is difficult to do anything but to hope the best and see what the teams come up with.

Based on my experience, I believe that there are eight warning signals for projects that are not going well. The more warning signals that apply, the more urgent it is to intervene. The eight warning signals are:

1.    The project-team appears to be dealing with a very broad range of issues

2.    The project team does not seem to be spending much time together

3.    The team is spending a lot of time carrying out “interviews”

4.    The team does not appear to be doing any meaningful analytics

5.    The team has very limited interaction with you(and other sponsors )

6.    Key stake-holders, who's by-in will be required for the project to be a success, are not aware of the project

7.    The project is not meeting agreed deadlines

8.    It is difficult to pin the team down on any meaningful conclusions

Dealing with a broad range of issues is a danger signal as it very often means that the project is too broadly scoped to deliver concrete results and/or the team will need to carry out more work that is feasible within the agreed deadlines. The required action is to carefully consider what the project needs to deliver and ruthlessly reduce any activities that do not directly lead to this result. See an earlier blog spot for more detail how to deal with this issue.

If the project team is not spending much time together it either means that they are not spending enough time on the project, or that they are working alone. In my experience achieving strong conclusions and recommendations requires bouncing ideas off each other, combining insights, and jointly developing an understanding of the most appropriate conclusions and recommendations. The best way to deal with this is to ask the team why they are not spending time together, and "gently" push them to do so. See an earlier blog spot for more detail how to deal with this issue.

Interviews are often an integral part of the work required to carry out a complex project. However, I have often seen teams that spend too much time talking to other people (within the organization or externally) without having a clear goal for what they want to get out of the interviews, without writing up the results of the interviews in a structured manner, and without getting any data or support for key assumptions from the meetings. Often, carrying out interviews is a way of looking busy and not having to do any "hard" work related to developing conclusions. My recommendation is to suggest that the team develops an overview of all the interviews they have carried out and what has come out of them. If the team has a program of interviews planned, ask them to provide a structured overview of what is the expected outcome / value added of each interview. Based on this, interviews can be prioritized. See an earlier blog spot for more detail how to deal with this issue.

In my experience it is impossible to develop strong conclusions and recommendations to a complex issue and convince key stakeholders without carrying out a fairly deep and complex analytical process (otherwise the issue is not really that complex……….). Therefore, if a project team is doing a lot of brain-storming and thinking, and is developing a lot of conceptual slides, but is not doing any analytics to really understand the issues and develop support for their hypothesis it is unlikely that the project will be successful.  This type of team will need to be forced to do the analytics that are required, and must be given help if they are unable to do so. See an earlier blog spot for more detail how to deal with this issue.

If the team has very limited interactions with you and other sponsors this can be a sign that the team is uncomfortable with the progress that they are making. If this is not the case then there is a high risk that they are not getting enough feedback on the direction they are taking and/or the key assumptions that they are making. In my experience, this often leads the team to take off on a tangent that is very different from the expectations of the sponsors. The easiest way of correcting this is to force the team to sit down with you and give an overview of their hypotheses and analytics. See an earlier blog spot for more detail how to deal with this issue.

If key stakeholders are not aware of the project it means that the team is not communicating with them. I have seen very many projects where the internal teams thinks that they only need to present their results at a final presentation without any previous communication with key stakeholders. Usually these projects do not get the agreement and acceptance that is necessary for a good implementation of required activities as expectations have not been managed, ideas have not been tested, understanding of "hot-buttons" not developed, etc. The best way of correcting this is to make communication an integral part of the team's workload, and follow up (and help) in this process. See an earlier blog spot for more detail how to deal with this issue.

The most important signal signifying that a project is not going well is if it is not meeting interim deadlines. Sometimes I have seen internal projects that have not even set internal deadlines. These are extremely likely to fail, as there is not even an opportunity to check if the project is on track. The best way to avoid this danger is a) to set clear intermediate milestones that involve developing and presenting clear results, and b) ruthlessly follow up on the agreed deadlines. See an earlier blog spot for more detail how to deal with this issue.

I have often seen teams that are very good at communicating about the process they are going through (we have talked to ten people, we have developed a model, etc, etc) but are unwilling to say anything about the real results (conclusions) coming out of their work. Very often this is a sign that they are not going to present strong conclusions and recommendations at the end of the project. The reasons for this vary. Sometimes it is uncertainty that the leads to believe that they are not "ready" to present conclusions, other times it is mainly driven by the team being uncomfortable with the results and conclusions that are expected of them and/or coming out of the analysis (opportunity to reduce staffing by 20%, etc). The best way to deal with this is to force the team to present conclusions at interim meetings. See an earlier blog spot for more detail how to deal with this issue.

The more of these symptoms that a team shows, the more likely it is that drastic intervention will be required in order to give the team a chance at achieving its overall goals. The earlier such an intervention takes place, the more likely that it will be successful.

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

Should you use my services

In recent meetings people have said that they want to introduce me to colleagues but have not been quite sure how to present me. Thinking about this, I realized that I am serving a rather select group, as three conditions have to be fulfilled before you will want to make use of my services. These three conditions are illustrated in the following diagram.


It is clear that if you do not have a complex issue there is no need to think about a project to deal with this issue. And while you have many issues that need to solved, not all of them are very complex. My short-hand description of a "complex project" is often that it is a problem for which you would consider hiring a team of external consultants (pick your favorite brand…………) to deal with.

If you are happy hiring consultants than this will typically be your first choice. However, there are many reasons for not hiring a team of consultants. Often, price is a consideration (they tend to be expensive) or budget limitations. Sometimes the experience is that using consultants slows down implementation as there are hand-over issues. Other times, companies are just tired of being over-reliant on consultants for dealing with issues they feel that they should be able to handle themselves.

If you now a) have a complex project, and b) do not want to use external consultants, and c) are convinced that an internal team will deliver "consultancy-grade" results on time, then you are very comfortable and ready to go. However, if your experience with internal project teams dealing with complex issues is that they never deliver on time and never deliver clear and useful conclusions then you have a dilemma. At this moment your choice has traditionally been to either go back and bring in the team of consultants or to accept the weakness of the internal team.

This is the "sweet spot" in which my experience and methodologies are of value. In my experience an internal team can deliver "consultancy grade" results if the team works in the right way. Results which are provided at a fraction of the expense of using a team of consultants, and results which, by definition, have a high degree of buy-in in the organization, and therefore are quickly implemented.

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

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.

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.

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.

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.

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.

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.