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.

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.

Determining the Appropriate Deliverables for the Work Phase of a Project

In a previous blog-entry I described the optimal deliverables for the initial phase of a project. This blog-entry will suggest what the goals and deliverables should be for the work phase of a complex project.

The work phase of a project typically covers the most time in the overall project plan and is, in my definition, the part of the project where the basic analytical and development-related activities are carried out. While the success of this phase is determined for a large part by key deliverables developed in the first phase of a complex project, there are a number of things that typically go wrong in this phase of a project as well. Typical examples of things that go wrong include:

- There is insufficient communication and feedback to the project sponsor
- The team work within the project is not optimal
- There is limited control of the project process (timing, scope creep, etc)
- There are insufficient and/or incorrect analytical activities being carried out
- There is not any process in place to control the hypotheses and conclusions being developed by the project team

This phase of the complex project is very likely to have a set of project-specific deliverables related to reaching the overall goals of the project. Examples of such project-specific deliverables could include carrying out a specified set of interviews, developing a spreadsheet model, collecting data, developing assumptions, setting out a new set of processes, etc. In addition to these project-specific deliverables, we believe that every complex project should also strive to develop a set of more general deliverables at the start of the work phase. These generic deliverables will help ensure that the overall goals of the project are met on time and within agreed budgets.

Deliverable Nr. 1: A well defined process for regular communication with the sponsor. This involves planning regular meetings between the sponsor and the project manager and team members, as well as creating the opportunity for ad-hoc meetings on an as-required basis.

Deliverable Nr. 2: An overall setting that enable the team to work together optimally. This deliverable includes a set of activities that ensure that the team members are able to use the time allocated for the project, and that as much of this time as possible is spent working together. One way of achieving this involves ensuring that the project has its own project room, and that the team members commit to being in the room at given times during the week.

Deliverable Nr. 3: A clearly defined process and appropriate tools for ensuring that milestones are met. This should include regular reports to the Steering Committee, and agreed processes to discuss and agree any expansion of scope.

Deliverable Nr. 4: Ongoing training activities for project team members to ensure that they carry out the right analytical activities in the right way. Typical team members in a complex project are not aware of all possible analytical activities that can move their project forward, nor do they have the experience to carry out these activities. A clear deliverable for ensuring project-success should therefore be the ability to provide ad-hoc analytical training and support to the team.

Deliverable Nr. 5: A Blue Team to provide feedback and constructive criticism on the project team's hypotheses and conclusions. A Blue Team is a structured meeting where the project team presents its hypotheses and potential solutions to a selected team external to the project. Such meetings have a proven track-record in improving the overall quality of projects

If you can honestly say at the beginning of the work phase of your project that all of these deliverables have been developed, then the project has greatly enhanced its chances of successfully carrying out the specific project-related analytical and developmental activities required for reaching the project goals in a timely manner.

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

Dealing With a Project That is Not Meeting Deadlines

In a recent post I outlined eight signs that are leading indicators for a project that can be expected not to reach its goals and targets in a timely manner. This post will highlight how best to deal with the seventh of these signs, a project that is not meeting deadlines.

Why is this a problem? In my discussions with executives across the world, the first complaint that they usually give about internal project teams is that they do not deliver the end-results of the project on time. You can be pretty sure that a project that is not meeting interim deadlines is highly likely not to meet the final deadlines as well (independent of what your project manager tells you).

In addition to this, I find that delays to intermediate deadlines are very often a sign of other potential issues. Typically, the delays are caused by the team not being able to make sufficient time available for the project, the team spending too much on the wrong activities (such as data gathering or interviews), or the team being very uncomfortable with the basic premises of the project (background, goals, expected deliverables, etc).

What can you as a project sponsor do if one of the project teams that you are responsible for is missing intermediate deadlines? My key message is not to let it slide, as it is very unlikely that the problem will go away by itself. The first action you need to take is to sit with the team and demand a fairly detailed explanation of why deadlines that have been agreed in their project plan have been missed (this assumes that the team has had input to the plan and has accepted the key deadlines in this plan). In this discussion, you should be prepared to dig beyond the standard answers to uncover the true reasons for the delays. A standard answer you will hear is that the team has not had sufficient time to carry out the activities. This is almost always true, but should have been known to the team when they agreed to the project plan. You therefore need to push the responsibility for sticking to the plan firmly back to the team.

However, I do also see situations where the project team's opportunity to allocate time to the project has decreased due to changes in priorities within the organization. If you are facing this situation, you will need to be prepared to act. You will need to understand what these new issues are and why they require time from members of your project. You will need to discuss alternatives with the other executives claiming time from your team members. If it is not possible to solve the issues related to the available time, you will need to develop (together with the team) alternative plans. This can involve reducing the scope of the project, delaying key milestones, or adding resources. Each of these solutions has its own pros and cons and needs to be analyzed in the specific context of the project and the organization.

However, in my experience, the most usual reason for a team not meeting deadlines is that the delays are caused by the project team spending too much time on certain activities (i.e. data collection, analytics, etc). If this is the case, you as the sponsor must be prepared to dig deep for the real reasons for this. You will also need to hammer home the need to stick to deadlines. You should also communicate that 100% knowledge is impossible, and that you trust the team to come up with good conclusions and recommendations in the time that they have been given (and have agreed). In this case, you will also need to help the team prioritize its activities going forward in order to get back on plan. My final recommendation is to keep a close eye on the team going forward. This is based on my experience that once a team has shown an inclination not to meet deadlines, it is likely to do so again.

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

Helping a Team Carry Out Meaningful Analytics

In a recent post I outlined eight signs that are leading indicators for a project that can be expected not to reach its goals and targets in a timely manner. This post will highlight how best to deal with the fourth of these signs, a project a team that does not appear to be doing any meaningful analytics.

Why is this a problem? There are two main reasons why this should worry you. The first is that it is extremely difficult to conceive of a complex and important project that does not require any analytical activities to arrive at the required conclusions (if the answer was easy, it would not require a project). Therefore, if the team is not carrying out these types of activities, you and the other stakeholders are very unlikely to get the conclusions and recommendations you require. In the best case, you are likely to get a "data-dump" and a set of options to choose between.

The other reason why this is a worrying symptom is what you tend to see such teams doing instead of analytics. What I have often seen is that such teams seem to be working hard, but are spending their time carrying out a large number of interviews, collecting as much data and information as they can lay their hands on, and, often, doing a lot of travel. The consequences of these activities are that project costs are too high, and that it is very unlikely that the key project milestones will be met.

Why do project teams typically not carry out the required analytical tasks? In many of the situations where I am asked to help this is caused by the team having an unclear picture of what is required from them, and therefore thinking that preparing a "data-dump" is the goal of the project. In other companies I see project-teams that are unable to carry out the required analytical tasks. While analytics is second nature to many people (consultants, etc), there are many capable and smart people who are not good at structuring and analyzing (new) problems. Finally, I also often see teams that are unwilling to go beyond data-collection as they are uncomfortable with the possible conclusions and are not willing to deliver unpopular recommendations.

What can you do to help the project team carry out the required analytics? My first step in helping teams with this problem is to recheck the project plan to understand how much analytics are required. The next step I carry out is to sit down with the project team to understand why they are still in the data-collection phase. The next steps will depend on the answers given by the team. In situations where they do not understand that they are required to do the analytics, I ensure that the team understands the true goals of the project and how the required deliverables depend on analytics. This set of actions will also help to push the team that is unwilling to go beyond data-collection to come up with uncomfortable and/or unpopular conclusions. In this situation I find that it helps to explain to the team why they (as individuals) have been asked to carry out this project.

In the cases where the missing analytics is due to inability, then the team composition is wrong, and together with the sponsor I consider what we can do about this. One solution is to add analytical capacity to the team, but the responsibilities of such a person has to be carefully defined in order to avoid team-development issues. The second solution will be to push the team to do their best, possibly combined with a workshop on specific analytical techniques (spreadsheets, statistics, etc). This is the best solution if keeping to deadlines is more important than optimal quality.

Using the process described above, I was able to help/force the team at the utility company to develop overall conclusions and meet the final agreed deadlines. Follow the links if you are interested in more information on project planning or project management training.

Dealing With a Project Team That is Carrying Out Too Many Interviews

In a recent post I outlined eight signs that are leading indicators for a project that can be expected not to reach its goals and targets in a timely manner. This post will highlight how best to deal with the third of these signs, a project team is spending a lot of time carrying out "interviews".

Why is this a problem? This does not have to be a problem, as there are projects that require collecting information from a wide range of people (internal and external) in the form of interviews. However, I have often seen this becoming a problem, because it often is a symptom of a team that is avoiding getting to the conclusion phase of the project. An example of this is a project I carried out for a large utility, where a project team had missed numerous deadlines, and always with the reason that they needed to carry out more interviews. After talking to the team members, it was clear that they were very uncomfortable with the overall goals of the project and the recommendations that they need to deliver (i.e. improving the effectiveness of a process and being able to do things with less people and costs). In addition, the team had to choose where to situate certain activities. This put the team in a very difficult political situation, and it was unable to "bite the bullet" and make the required choice that would, by definition, make some people unhappy.
If this type of situation is left unchecked, it is almost guaranteed that the project team will not make its milestones and key deadlines. In fact, the most likely reason that you as a project sponsor are reading this blog-post is that the a team carrying out a crucial project has already missed deadlines. In addition, the chance that the project team will come up with meaningful conclusions and recommendations is also fairly small as fear related to this is what is driving the excessive interviews.
What can you do if you believe that one of your teams is using this tactic to avoid moving towards meaningful conclusions? The first action you need to take is to check the original project-plan to sanity-check whether the number of interviews being carried out makes sense. If you are still uncomfortable, you then need to talk to the team about why they are doing all the interviews. In this process you should force the team to show you the goal of each meeting/interview that has been carried out and those that are still in the planning phase.
If you at this stage still have doubts about the validity of the interviews, you will need to revisit the background and goals of the project and reinforce the requirement to the team to come up with strong, focused, and structured conclusions and recommendations. You will also need to explain to the team that meeting agreed deadlines is a key part of the commitment that they have made to the overall project. You will also probably need to give the team a "level of comfort" that they will never be able to collect 100% of the data and information that they theoretically would like to have, and that you (and the rest of the stakeholders) trust them to do well with the time and resources that they have.
Finally, it is likely that you will need to help the team to develop a structured plan for carrying out the interviews and other data-gathering activities that you have agreed are required within the available time. It will need to be a judgment call from your side whether it is possible and/or required to give the team more time to carry out these activities. The final recommendation to you as the sponsor is to closely follow-up on the team as they move forward, as it is unlikely that their wish to avoid unpleasant conclusions and recommendations has disappeared.

Using the process described above, I was able to help/force the team at the utility company to develop overall conclusions and meet the final agreed deadlines. Follow the links if you are interested in more information on project planning or project management training.