Back to consulting!!

Life moves in mysterious ways.

In the two previous blog entries I  explained that I had stopped with consulting to focus on setting up a new healthcare business. That business was a huge success. In less than five years we put in place 50 small-scale locations for helping (young) people with autism, had 200 employees, and helped many people with autism reach their targets (finishing school, finishing university, finding and keeping a job, etc). I have now sold my shares in that company and have started the next chapter of my life.

My current focus is "Innovation in Healthcare" and I am doing this through a mixture of consulting to existing organisations and the development of new innovative healthcare organisations. My consulting work with existing healthcare organisations usually involves working closely with teams from the company and utilizes the same techniques as developed for Team Based Consulting. My team members therefore are linked to my article on how best to manage complex projects and to this blog.

If you want to know more about my current activities please go to www.vardetun.com.

Link to article

I had promised that my previous post would be my last; Sorry.

As part of closing down my consulting business I have also decided to shut down the web-site for that business (mainly due to having to update to a new version of Joomla, but also due to overlap in the content of that site and this blog).

One of the things that readers could do on that site was to download an article that I have written about how to best manage complex projects. This article can now be downloaded here.

There is some overlap in the content of the article and the posts here in the blog. The article gives a structured overall view, and the blog-posts give more detail on specific issues. Read and combine as you see fit.

Last and Final Update

In December 1989 when I finished my MBA at INSEAD, my plan was to become a consultant for two years and then to get a Real Job. It has taken 23 years as a consultant, and I have had to develop a company myself, but I have finally reached this goal.

As of today, I am therefore stopping with my consulting activities. From now on I will be focusing all of my time on my role as Finance/Strategy Director for De Arvede Groep. De Arvede Groep provides long-term care solutions to specific segments of people with autism, and  health-care services to small, alternative health-care providers. For the moment, De Arvede Groep is only active in The Netherlands, but we do see opportunities for expanding our services internationally. If you want to know more about what we do (and read Dutch) please go to the website of our current market propositions (Stumass, Capito Wonen, and Arvede Zorgdiensten).

I have greatly enjoyed my consulting career, both as part of larger organizations (LEK Consulting, PwC, and A.T. Kearney), and as a solo-practitioner these last five years. I have been privileged to work with great clients and great people. I know that there will be moments when I will regret my decision to stop. However, the health-care sector is going through a period of transformative change, and the opportunity to play a key role in building a company that will improve the lives of clients by offering better and cheaper services is irresistible.

As part of this process, I have also decided to stop adding new updates to this blog. For those of you who have been regular readers - I hope that you have enjoyed the posts and that they have neabled you to make your teams more effective. For new readers - I think that there is a lot of information in the updates that can help you make your teams more effective.

I wish all of you the best going forward.

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.