Avoid usual mistakes in setting up your Steering Committee

Last week I had an interesting discussion at a project I am working with for a leading European energy company. The project involves the development of strategic tool for the company's smart grid roll-out, and is key part of the future development of the company. The project manager felt that the Steering Committee that had been set up for the project was not providing him with any value and was taking away valuable time from him and other key project members. This was an interesting statement, as I had been told that many members of the SteerCo were also unhappy. Their complaints were centered round the reasons for their participation, the information they were provided, and the structure of the meetings themselves.

This got me thinking about steering committees and how these should be set up and used optimally. In this blog-spot I will focus on how an optimal steering committee should be set up. In later blog-spots I will talk about how to best use a SteerCo during the project itself and how a project can ensure that its goals are met through the SteerCo.

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

My assumption is that you are the sponsor or the project manager of a complex project and are in the process of setting it up. This means that you have carried out all the other steps required for a successful start-up of a complex project ( you have a well-structured understanding of the reasons why the project is required, you have defined clear goals and deliverables, you have set up a structured approach that includes key activities, dependencies, and milestones, and you have formed the best  (available) team for carrying out the project.

You are now in a situation where you believe that you need to set up the Steering Committee. Either because somebody has told you to do so, or because you believe that "all" projects have such an entity. However, you also have some doubts as you do not really have a good idea what the role of the Steering Committee will be or who you should put in it.

I have seen very many situations where a project either has a SteerCo that is too big or consists of too senior people (misuse of resources). Projects run by external consultants often have this, as for them having a Steering Committee consisting of many senior executives is an excellent marketing tool. I have also seen many projects that either did not really need a SteerCo or had a SteerCo with the wrong participants. Thinking carefully about your SteerCo is therefore well worth your time.

The first step in this process is to get a clear understanding of why you want a SteerCo. Essentially there are four reasons for a complex project to have a SteerCo (sometimes overlapping):

1.    Decision-making - The SteerCo accepts the final results of the project, makes go/no go decisions for the implementation of project recommendations, and makes decisions during the project that are relevant for the overall direction that the project takes
2.    Ensuring support - The SteerCo is used to organize staff for the project, to provide ad-hoc access to staff in the organization and to get buy-in for the final results of the project
3.    Provide knowledge - The SteerCo is intended to primarily provide knowledge and experience to the project-team
4.    Control quality and progress - The SteerCo is a group of people ensuring that everything's OK with the project at a higher level than the Project Manager

You should also keep in mind that a SteerCo is often not the only solution that will help you deal with your needs. In my experience, the need to have a Steering Committee to make decisions is very often over-rated. If the only decision that needs to be made is at the end, then seeing the management team once at the end of the project can be sufficient. Only if there is an ongoing stream of relative complex decisions to be made, do you need a traditional Steering Committee that meets regularly during the whole project. Any smaller / less complex decisions can be made by the sponsor of the project.

The idea that having a Steering Committee will ensure support for the project is based on an assumption that being the SteerCo will result in key people having more knowledge of the project, and that they will be "invested"  in the process and conclusions developed by the project. Hopefully this then translates into help getting access to staff and buy-in for the results of the project. A key point to keep in mind is that finding staff is an activity that only takes place at the start of the project, and can therefore not be a reason for keeping an ongoing SteerCo. Buy-in for the need for a project and its conclusions and recommendations can also be created (often better and with less use of resources) through a series of one-to-one meetings with key managers.

I have often seen a SteerCo be used to provide knowledge to the project team. If this is the only reason for having a SteerCo I would recommend alternatives such as an expert group or Blue Teams. This enables the project team to make direct use of the real experts instead of management, and also reduces the likelihood that they persons involved will believe that they need to make decisions (which is usually not the case).

The final reason for having a SteerCo is often quality control. This is based on an assumption that the project manager and sponsor cannot do this themselves, and that it requires more senior executives with a broader view of what is key for the overall company. This can be a valid reason if the project is very complex and "steering" is required based on a broad overview of the company. In my experience, the type of discussions that take place in this type of SteerCos is very similar to the SteerCos making decisions

Based on this overview you can conclude that a Steering Committee is only required when a project required senior-level "steering" as an ongoing process during the project. The "steering" provided in these situations can be seen as a mixture of "quality-control" and ongoing decision-making. All other reasons for having a SteerCo can usually be provided by other means that place lower time-demands on both executives as well as project-team members.

The final question is then who you should put in your SteerCo. The first rule is to keep the group as small as possible (less use of resources, easier logistics for planning meetings, easier discussions, etc). The second rule is to find the lowest-ranking people that can make the decisions that are needed. A rule of thumb that has served me well is to discuss participation high in the organization, and clearly present the type of decisions that are likely to be made. The senior executive can then chose the person that he/she feels comfortable allowing to take the relevant decisions.

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.

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.

Choosing a Project Leader

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

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

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

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

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

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

Determining the Appropriate Deliverables for the Initial Phase of a Project

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


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

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

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

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

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

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

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

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

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

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

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

Helping a Project That is Dealing With a Very Broad Range of Issues

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. Many of you have requested more details on the individual issues. In this post, the focus lies on how to deal with a project team that is dealing with a very broad range of issues.

Why is this a problem? In my experience, projects that are not dealing with a relatively narrow range of issues have great difficulties in keeping focused and have problems in knowing precisely which activities are required for reaching the agreed goals. In addition, they tend to spend a very large amount of time communicating with potential stake-holders. The main consequence of this is that it is almost guaranteed that these projects will not be able to keep to the agreed timelines and meet key deadlines. In addition, due to the broad range of issues, they will have great difficulties in developing crisp and concrete conclusions and recommendations, thereby not delivering value related to any of the issues the project set out to deal with.

My recommendation to clients is to start every project with a crisp and focused set of objectives. If you have different, but related, issues, you should strongly consider setting up specific projects to deal with each issue (either in parallel of sequentially). If the problem itself is difficult to structure, consider setting up a phased approach where the goal of the first phase is to develop a better understanding of the situation, to suggest the possible ways that the issues can be dealt with, and to give advice on how a project should optimally be set up.

What can you do if you believe that you have a project in your portfolio that is dealing with too broad a range of issues? My recommendation is to sit down with the project team and go back to the starting point for the project. Key questions that need to be answered include a) what has changed in the business environment that the project needs to develop a response to, b) what are the key issues that the project needs to deal with, and c) how well do we understand these issues?

Based on the answers to these questions, I have helped many teams to develop an overall goal and a set of concrete deliverables for the project. The goals that we have agreed have been measurable and the deliverables have represented something that clearly did not exist earlier (a marketing plan, a new process, etc). The concrete goal and agreed deliverables have then been used as a starting point for analyzing the activities being carried out by the project team. Any activities that are not absolutely required for meeting the concrete goal should be stopped immediately. If they are important for reaching other goals, they should be given to a separate team. Based on the new set of activities, a new and realistic plan has been agreed with the team, and the team has set to work again with a renewed focus and increased energy. Typically, the process of getting the team focused has taken two or three meetings in a course of a week.

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

Setting Up a Successful Cost-Reduction Project

Almost every organization in the world today is looking at ways to reduce costs. Some companies can do this fairly simply by closing factories or giving top-down targets to all relevant departments (costs to be reduced by 20%). Other companies that I talk to feel that they require a more fundamental approach that will restructure the way that they do their business. Sometimes this includes a strategic review of which products and services should be offered to the market, other times the markets served are seen as stable. In the second case there is usually a need to fundamentally re-assess how the products / services are brought to market in order to radically decrease the costs and/or to improve service levels.

Carrying out such a task will, almost by definition, require a project, and such a project will always be extremely complex (both due to political issues and the required out-of-the-box analytics). Based on experience in setting up and carrying out numerous strategic transformation projects for A.T. Kearney (definitely the consultant to go to if you need broad external help in carrying out a transformation (see http://www.atkearney.com)/) I believe that there are a number of very dangerous pitfalls for such projects, but that these pitfalls can easily be avoided by carefully thinking through how the project is set up. The key pitfalls and how these can be avoided will be covered individually.

A very common problem that I have seen in very many situations is that the transformation becomes an endless and uncontrollable process with different parts of the organization moving forward at different speeds. In my projects I have solved this problem by dividing the overall transformation into clear phases, and forcing all the individual parts of the transformation process to stick to the same overall milestones. Typically I have divided the transformation into three phases. The first phase of my cost-reduction projects have focused on understanding the key issues and setting realistic targets for improvements. The second phase has focused on the actual re-design of the new processes, while implementation has taken place in the third phase.

Many transformation projects I have seen have been plagued by unclear goals and targets. I agree that the start of a transformation process should include broad high-level goals that are, almost by definition, not tightly defined. However, in my projects I have always used the first phase of a transformation to develop a detailed understanding of the situation and key issues faced by the company, to make an overview of key changes required (by how much do costs need to be reduced in order to be competitive and profitable?), and to suggest the overall direction of possible improvements. Combining the results of these activities has typically given the project clear goals and targets for the individual parts of the transformation process.

Transformation projects are often plagued by difficulties in avoiding departmental politics and getting real end-to-end improvements in processes. To avoid this pitfall I have set up an appropriate small team at the beginning of the transformation and expanded this team over time. For the initial phase of a transformation I have strived to put in place a fairly small team that consists of a selection of people from across the company representing different organizational units and skills. The people chosen for this task have been analytically strong, open for change, and well respected through-out the organization. In the re-design phase the members of this team have typically become team-leaders for the sub-teams looking at individual processes or parts of the organization.

Transformation projects often have problems in enforcing decision-making and the implementation of agreed changes. To avoid this, my transformation projects have always included a steering committee that consists of key decision makers. If the transformation covered a total company this was the management team. The key challenge that I faced was to ensure that the steering committee understood and agreed with the overall process (phased approach, etc). In addition, they had to agree to a governance model that included clear decision points (certainly at the end of phase 1 and phase 2, but probably also at other key milestones). The steering committee also needed to agree to a generic set of rules that included free discussion up-front, but a commitment to the implementation of made decisions (agreed is agreed).

Carrying out these fairly simple structural changes to the transformation process has served me well in all the projects I have carried out, and I believe that they will also help you in setting up a successful transformational cost-reduction project. Follow the links if you are interested in more information on project planning or project management training.

Team Building is a Waste of Money

You would think that one of the consequences of the current recession is that the demand for "team building" would decline. However, a quick search via Google seems to indicate that this industry is flourishing. This is strange, as my experience is that, even in the best of times, what passes for "team building exercises" is a total waste of time and money.

This is certainly the case if your goal for the "team building" is to help ensure that a team tackling a complex project is happy and comfortable in dealing with each other. There is a lot of research that shows that increasing the internal satisfaction of the team has negligible effects on the success of the team in reaching its goals. In my experience, the only possible useful outcome of such an event is that the team members get to know each-other better. It might be the Norwegian in me, but it seems that this same goal can be achieved by including a nice dinner with some bottles of good wine at the team kick-off dinner.

The question then remains: what can be done to quickly create an excellent team? Luckily, this is fairly simple. What you (as a sponsor) need to do is:
1) Set clear goals and targets for the team (if they do not know exactly what they need to do, they cannot be successful)
2) Bring together people in the team with the right knowledge, skills, and experience (the team cannot be successful if it is not able to do the activities required for meeting the goals and targets)
3) Give the team tough deadlines early in the process, and force and enable them to work together (this creates the required "us versus them" feeling that excellent teams often have)
My friends in the "team building industry" will say that this is exactly what they do with their team-building exercises. They may be right, but why spend money doing this temporarily in an artificial setting, when you both should and have to do this in the real setting in any case?

My recommendation is to skip the external team-building exercise, and put the team together in a room (preferably latish in the afternoon) and 1) give them a clear explanation of the background to the problem that they are being asked to solve, 2) present the goals and targets that they need to reach, 3) present a first-cut plan for how you believe that these goals and targets should be met (including a stretch initial milestone), 4) explain why each team member has been included in the team, and finally 5) ask the team to develop their own detailed approach and plan. When this has been developed and discussed, the final activity should be dinner (spending a small part of the money saved by skipping the "team building exercise".

Finally, there is one part of a successful project where the "team building industry" can play a role. A key part of building a successful team is to celebrate success. This means that after a team has reached key milestones, it may want to celebrate by going wild-water rafting or some other team-building exercise.