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.

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.

Using Internal Consultants in Complex Projects

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


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

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

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

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

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

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

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

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

Choosing a Project Leader

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

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

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

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

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

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

Running a Successful Product Development Project

In my discussions with executives, innovation, or product development projects, are often given as examples of internal projects that are not successful. When questioned in more detail, usually the "failure" that is being mentioned can be divided into two separate types. The first type of failure is probably the most damaging and frustrating. These failures are usually products that fail in the market place or result in enormous costs and complexity in the production and supply chain process. The second type of failure is less damaging, but probably more frustrating, as it happens more often. This type of failure involves products which are not launched or launched too late.

In my experience, these two types of failures are caused by two different types of problems. The first type (market failure) is typically caused by the product development project having been structured in the wrong way (hand-overs between departments, wrong type of team, etc). The second type of failure (delay) is typically caused by the team being set up, managed, and run in the wrong way. Given this, how can the success rate for product development projects be improved?

The most crucial response is to ensure that the project is set up and staffed in the right way. Product development projects should avoid hand-overs between departments, and therefore need to include a representative of all key departments involved in the process. This will typically include marketing, production, logistics, account management, etc. The chosen project team then needs to be given the end-to-end responsibility for the successful product launch. This responsibility needs to be collective for the whole team, to ensure that they continue to work together across the whole process. In situations where this methodology leads to teams that are too large, careful thinking should be given to working with core and extended teams, and carefully expanding and changing the team composition across time. An excellent explanation of this is given by Deborah Ancona and Henrik Bresman is their book "x-teams: how to build teams that lead, innovate, and succeed".

Once the right team has been put in place to carry out the end-to-end innovation process, the next challenge is to make sure that the project is successful. A product development / innovation project will typically score highly on both internal and external complexity, and a very high number of the problems that this type of projects face are likely across all three phases of the typical project. However, these problems can be avoided or minimized by ensuring that key pitfalls are avoided.

In the initiation phase of the product development project, great care should be given to ensuring that the team has a clear understanding of the project goals and the deliverables expected from the project. As mentioned earlier, this should be to deliver everything that will be required for the successful launch of the new product. This will entail that the team must come up with the product itself, the production process, the supply chain process, the marketing process, pricing, etc, etc. Naturally, the team will need to get specialist input on a number of these issues, but the total responsibility must be clearly placed with the innovation team.

The team will typically consist of people who have never worked together and who probably do not know each other. This means that the team should be given help in forming themselves into a team. They need to understand what is required to become a successful team, how it is to work as a team, how they can best make use of each other's skills and capabilities, etc. Finally, the team should be helped / forced to develop a realistic plan for how they are going to achieve their goals and deliverables. They should be made to understand that they will be held accountable for this plan (especially the overall timing and milestones).

In the work phase key focus areas should include avoiding scope creep, sticking to the agreed milestones, carrying out the required analytics, and communicating with the sponsors and stakeholder. Scope creep is a common problem is this type of projects, as the team is asked to look into related issues, or dives into too much detail on specific issues. To avoid this, a clear process (involving the sponsor) should be put in place to control this. One of the main challenges the team will need to solve (on a continuous basis) is the optimal split between the activities carried out within the team and the use of external experts. When using external experts timing and milestones can become a major problem, as the external experts will not have the same dedication and focus on meeting deadlines. The team should therefore always have a "plan b" for use if the external expert does not deliver (on time).

In the finalization phase the team will need to develop its overall conclusions and the final deliverables. This will typically include the total plan for launching the new product covering all the issues mentioned earlier. In addition, the team will need to develop and carry out a communication process. In my experience, this is something that innovation teams often overlook. Their implicit assumption is that the rest of the organization will automatically accept their conclusions and recommendations. Unfortunately, this is often not the case. Therefore the team must carefully consider who the stakeholders are, what their "hot buttons" are, and how they can be convinced to accept the team's conclusions.

It is in the nature of the process that not all innovation projects are successful. However, it is my experience that companies that make use of a structured process as described in this article, have a much higher success rate than other organizations.

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

Using Project Management Offices in Complex Projects

Occasionally I meet potential clients who do not believe that they need external input for making their complex projects more successful. I know that this is hard to believe, but it does happen……………Very often these executives say that they do not need any outside help because they have a Project Management Office (PMO) that fills this role (i.e. making sure that projects run well). This has always bothered me for two reasons. Firstly, I clearly believe that I can offer valuable input to (almost) any organization carrying out complex projects. Secondly, I often see these same organizations outsourcing projects to external consultants, so there are clearly projects that they believe cannot be handled by their internal teams.

Recently, my thinking on this was brought into focus by an executive from a media company who asked me a slightly different question. He explained that he had mixed results in using people from his PMO in complex projects, and was wondering how he could make best use of them in these situations. There are clearly three alternatives here: 1) Give your PMO total responsibility for this type of projects, 2) make no use of PMO-staff for complex projects, or 3) an intermediate solution.

The cases that I have seen where complex projects have been given to the PMO have generally been a disaster. While Project Management Offices have an important role to play in many organizations, it is important to understand their limitations. In most companies, PMO's have been set up to provide project management for what I call standard projects. These are projects that are closely linked to the core business of the company, and which therefore do not deal with external complexity (openness of goals to interpretation, uncomfortable goals, high degree of communication required) or internal complexity (distance of project from day-to-day business, organizational distance of project participants, sophisticated data collection, and a requirement for "out of the box" thinking). This means that when the PMO uses their "standard" tools on these projects, the results are terrible.

On the other hands, I believe that not using the skills available within the PMO is also a shame, as it is clear that they do have project experience that can be valuable in a wide range of projects. Therefore, the optimal solution is not to give the complex projects to the PMO, but to definitely use the PMO pool of people in staffing the project.

The next question asked by the executive then concerned the role of the PMO-staff in the complex project. Should he use somebody from the PMO as the project leader? In my opinion, this can work, but it is not very likely that this will an optimal choice. Somebody from the PMO will clearly have the required project management skills, but is not likely to score high on other crucial dimensions driving the choice for project leader. These include having sufficient knowledge about the key issues to be covered by the project. Examples of issues where PMO-staff would be unlikely to have sufficient knowledge include a project to look at a new, dramatically different production process, or a strategic pricing project. Somebody from the PMO is also unlikely to have sufficient respect among key stakeholders to be able to "sell" politically difficult conclusions and recommendations.

Using PMO-staff as a participant in a complex project is possible. However, it will not be sufficient if all the person brings to the project are his project management skills. The PMO-staffer will also need to bring some combination of the three skills required of all participants (technical and functional skills directly related to the issues to be solved, analytical skills, and interpersonal skills). If the PMO-staffer has the right combination of these skills for the project, then his additional project management skills can be an asset, and enable him to help the project leader deal with this type of issues.

In conclusion, I would not recommend giving the PMO the responsibility for complex projects. There will also not be many situations where somebody from the PMO is an ideal candidate for leading a complex project. However, using people from the PMO in certain complex projects can be useful, but only if they have additional skills that can be utilized.