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.

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.

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.

When should you not use consultants?

In my previous blog-post I described how you can decide whether a project is complex and therefore either should be outsourced to experts (i.e. external consultants) or be carried out by an internal team, but given special care and attention. Once you have decided that the project you are considering is complex, the next question is therefore how to carry it out.

I have led consulting teams carrying out a broad range of complex projects across Europe for LEK Consulting, PwC, and A.T. Kearney (where I ended up a Partner). The projects I carried out always added value to my clients, but I am convinced that the clients I worked for could have carried out a fair portion of these projects themselves.

What did these projects have in common? Essentially, the answer boils down to the companies in question not having a truly good reason for using the external consultant. In my view companies should only use external consultants when they provide something (knowledge, experience, tool/process, etc) which the company does not have itself. At LEK I carried out numerous projects that helped companies identify and value potential acquisition targets in other countries. This was clearly a task which required local knowledge and specific experience which the clients usually did not have. At A.T. Kearney a number of companies hired us to carry out a cost benchmarking using an extensive database that had been developed by A.T. Kearney. This was clearly an activity which a company could not do itself.

Sometimes there are political reasons for using an external consultant. Examples of this are companies that use a report from a well-known consultant to either get a "quality-stamp" on their plans or to have somebody to blame ("according to Consultancy-A we have to reduce staff by 2000 employees"). While "political" has a certain association with something unsavory,   I do not see anything intrinsically wrong in this type of use of a consultant if it helps speed up decision making and the implementation of difficult change.

The projects I felt that could have been done by the clients themselves where the projects that did not fall in one of the two previous categories. In my opinion, in these cases, the only reasons for bringing in an external consultant (i.e. a team led by me) was doubts about the ability of an internal team to structure the issues, carry out the required analytics, develop conclusions and recommendations, and communicate these in such a way that buy-in and action is created. If this is the case, the focus should then be on understanding why your company does have these abilities and capabilities, and what can be done to improve this situation.

If the key issue is basic capabilities, then there are organizations specializing in improving the capabilities of companies to carry out complex projects. An example in Europe is ICS, based in Belgium but working internationally. If the problem is not so much the available skills and capabilities but rather the ability to define and carry out a successful project then my input is probably better suited. Please go to www.teambasedconsulting.com to get a better understanding of why internal projects tend to underperform, and what to do to improve this situation. Another possibility is to take a look around this blog, as I have written about a large number of specific issues and challenges and how these can best be dealt with.

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.

How to Identify Dangerous Projects

I often get asked "when do I know which projects require special care or input from external consultants?" My advice is always to analyze and understand the overall complexity of the issue and project. Complex projects are more difficult and fail more often than simple projects, and therefore require more care in setting up and following up (or can better be outsourced to your favorite consultant who is specialized in carrying out complex projects).

The follow-on question is invariably "how do I understand which projects are complex, and how can I compare the overall complexity of projects in my portfolio?" his can be done quite easily by understanding the key drivers of project complexity. The overall complexity of any project is driven by a combination of internal and external factors. External complexity consists of factors related to the overall environment in which the project needs to work. Internal complexity is related to the types of activities that the project is required to carry out and the project's internal organization. A project that scores high on both dimensions of complexity (see diagram) should therefore either be given special care, or be outsourced to an external consultant.

External complexity should be analyzed by looking at four specific drivers. Each individual project will have a different combination of external pressure brought on it through the following drivers:
1. Level of pressure from management to achieve concrete and challenging results
2. Openness of goals to interpretation and level of political elements in goal definition
3. Level of expected uncomfortableness to project participants resulting from project results
4. Required level of communication to various stakeholders for getting the necessary buy-in for conclusions

Each individual project will also vary in its internal complexity. Internal complexity is driven by:
1. Distance of project to day-to-day business
2. Organizational distance of project team members
3. Level of fairly sophicated data collection and analysis required for the project
4. Level of "out of the box" thinking required for developing optimal solutions

In my interaction with my clients, I typically go through these drivers and factors individually, and score them on a scale of 1-5. In a recent discussion this went approximately as follows:
• The corporate sponsor requires that we deliver a very concrete plan to turn this company around and make it profitable. However, our own management have very different and individual views on how this should happen, their plans are always to the benefit of their own department, and we will need to communicate extensively with them in order to get buy-in for any plans that are developed (high scores of first two and last driver of external complexity)
• Potential team members feel very uncomfortable about carrying out this project, as they worry that it will require them to "fire" colleagues (high score on third driver of external complexity)
• The people earmarked to do the project are excellent mid-level managers, but they have never carried out any strategic analysis or developed cost reduction plans (high score on first driver of internal complexity), but the advantage is that they know each other quite well and have worked together on previous projects (low score on second driver of internal complexity)
• The project will require sophisticated data collected and analytics and the solutions the team delivers will need to be innovative and different from our current "business as usual" approach (high scores on the last two drivers of internal complexity

Based on this fairly straight-forward discussion and scoring, we were able to agree that the project was very complex and that special care would be required in setting it up and following it on an ongoing basis. Direct actions from my client included ensuring that the project team had a structured kick-off meeting, and that the team planned in ongoing meetings with him to report back on progress, obstacles, and risks. My input included ensuring that the team carried out appropriate analytics, understood the outcomes, developed appropriate conclusions, and communicated these to all stakeholders. Based on this structured process, the team delivered more than 20 initiatives that will improve profits both in the short and the long term.

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

Lessons Learnt

In two previous blog entries I have told you about the turn-around project I carried out with an internal project team. Maybe you are getting sick and tired of hearing about it, but I feel that it was a perfect example of how internal teams can carry out projects that most people think will require a large external team of high-powered consultants. I promise that this will the last update dealing with this theme……….


The key lessons learnt from this process can be divided into general lessons related to the choice for an internal team, and lessons related to how an internal team dealing with such a complex issue can be helped to become successful.

The key lesson must be that internal project teams can successfully deliver "consultancy-grade" results. Sponsors of this project agree that there are only marginal differences between what this team delivered (including the key fact that it delivered on time) and what their favorite top-level consultant would have delivered. In addition, the work carried out by this team has resulted in automatic buy-in through-out the organization, and a fast and (so far) successful implementation.

Key lessons from this project related to ensuring that a team will be successful include:
• Ensure that the right people are made available for the project (skills, attitude, network, etc)
• Give the project a flying start by ensuring that that the goals and expected deliverables have been clearly defined
• Give the team a kick-off that enables the team to take ownership of the project (develop hypotheses and approach, etc)
• Follow-up on work done by individual team members to ensure that it follows a logical and focused structure and gives clear conclusions and recommendations that are supported by facts
• Ensure that the team communicates through-out the whole process (internally in the team, to key stake-holders, etc)

While every situation is specific, I am sure that any project team that follows these fairly generic lessons will be successful. However, the specifics of doing this can be challenging for an organization that is new to this way of working. As evidenced by the testimonials given to me at the end of the project I have played a key role in enabling the success of this team.

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

Use a project team to plan a turn-around (2/2)

In my previous blog-post I described how a project team developed a structured overview of the reasons for an engineering company being structurally loss-making. In this post I will give a short overview of the initiatives that were developed to turn the company around and the implementation plan used to ensure that the initiatives will be carried out.



A total of 20 initiatives were developed by the team in four main areas:
•Improved marketing through more focused use of distribution channels, focus on certain segments, and a move away from selling small (loss-making) projects
• Professionalizing the end-to-end process for selling and carrying out projects (clearer scope definition, value- instead of cost-based pricing, improved hand-overs to the engineering teams, more intense follow-up of budgets, etc)
• Large reduction of supporting costs through a detailed added-value analysis of existing activities
• Structural reorganization of the company, leading to less management layers, clearer and more focused responsibilities, etc

Implementation of the 20 initiatives has been closely linked to the new organization structure, with relevant managers having clear responsibility for specific initiatives. Each initiative has been described in detail and including a high-level implementation plan. The first responsibility for the relevant managers is to develop a more detailed plan (in order to develop ownership) for the individual initiatives under his/her responsibility. Progress on the initiatives will be a key element of the weekly management team meetings and will also be including in the monthly meeting with the corporate sponsor.

My latest update from management and corporate sponsors is that implementation is going well, and that they are optimistic that the company will finally become profitable and better positioned in the market.

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

Use a project team to plan a turn-around

Some months ago I helped an engineering company plan a turn-around. The engineering company is part of a larger company, and has been consistently loss-making for the last five years. New owners decided that "enough is enough" and asked the management to come up with a restructuring plan. The results of this process were an unchanged strategy, minor changes to the organization, and some ad-hoc cost-saving initiatives.


This resulted in a high level of frustration at the corporate level, and the general opinion was that external consultants would need to be called in. Fortunately, wiser minds prevailed and it was suggested to use my proven approach for enabling internal teams to carry out complex projects successfully.

My first suggestion was to move the responsibility for developing the turnaround plan away from the management team to a separate project team. A team was selected consisting of a fairly young group of female middle-managers who had critical minds, good analytical skills, and the ability to think "outside of the box", and were respected within the organization.

A kick-off meeting was spent agreeing the overall approach to the project. Key outcomes was an agreement on a phased approach (with a clear separation between a first phase focusing on fact-finding and understanding the key issues, and a second phase to develop new initiatives) and use of a hypotheses-driven approach (as used by all major consultants).

In the first step we developed a hypothesis that the engineering company needed to leave behind its current approach to its business (offering a coordinated suite of engineering related services to the same customers) and focus on understanding the intrinsic attractiveness of what should be seen as separate business-areas. The CEO attended this meeting, and defended the existing strategy, but accepted the overall logic suggested by the team.

During the next few weeks the team focused on developing proof for the hypotheses developed in the first meeting. This involved understanding the markets in which the company operated, analyzing the operating processes, and developing a financial overview of the individual business areas and projects. The team agreed that the hypotheses-driven manner of working was helpful as it gave the team clear objectives to work toward and enabled a very focused and effective way of working.

The results of the diagnostic phase supported most (but not all) of the original hypotheses developed by the team. A key finding supported the decision to look at the business areas independently. Different from what we originally believed, it turned out that all the business areas provided a positive contribution to the overall profitability of the business. However, the contribution from each business was small. This was caused by a wide range of marketing and operational issues. Marketing issues included too many small loss-making projects, incorrect pricing methods, and insufficient focus on existing, profitable customers. Operational issues included insufficient planning of projects, low follow-up of budgets, and a lax attitude towards scope creep and up/cross-sell.

The final step in the diagnostic phase was to communicate the findings to the management team and the corporate sponsor of the project. The key challenge with the management team was getting buy-in to the radically different picture of the company that the team presented. Based on the thoroughness of the analysis and the pyramid based presentation this went well. The corporate sponsor was very happy with finally receiving a structured analysis of why the company was loss-making and asked the team to continue with the developed of initiatives and an implementation plan.

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