Interesting article in Harvard Business Review

In the September number of Harvard Business Review there is a very interesting article, "Mistakes Leaders Keep Making", by Robert H. Schaffer. This article highlights four behavioral traps that thwart organizational change. It is an excellent article, and while the focus is on organizational change and the relationship between executives and subordinates, the issues highlighted and the suggested solutions are directly transferable to teams carrying out complex projects. My translation of his behavioral traps to a team setting is:


• Behavioral trap 1 : Executives and sponsors typically fail to set proper expectations for the teams carrying out critical but complex projects

• Behavioral trap 2: Teams carrying out complex projects are not staffed with the appropriate people because they are "too busy" and/or are protected by their line managers

• Behavioral trap 3: It is safer psychologically to "sign a fat check to a consultant and hope for the best"

• Behavioral trap 4: Delays in reaching key milestones are tolerated if the project team is able to point to dependencies to other company activities (we need a new computer system before we can………………..)



I believe that these behavioral traps are very similar to the "seven deadly sins" I have written about in previous blog-entries. This means that these issues can be addressed by going through a step-by-step process to ensure that the internal project is set up correctly, and by carefully carrying out an ongoing quality and timeliness controls. Follow the links if you are interested in more information on project planning or project management training.

How to Get Buy-In for Project Conclusions and Recommendations

In a recent discussion with a client in the telecoms sector he told me that one of the biggest differences he sees when comparing his internal project teams to the top-notch consulting teams he sometimes uses, is the latter's ability to ensure buy-in for their conclusions and recommendations. His two questions were why the internal teams were not capable of achieving such buy-in, and what could be done about it.

Luckily, there are simple answers to both questions. In my experience, the main reason why internal project teams do not get buy-in for their conclusions and recommendations is that they do not know that a communication process is required. Usually, when I ask the team what went wrong, the answer they give is along the lines of "Nothing went wrong. We carried out the project, and presented the results to the steering committee. What else should we have done?"

This way of looking at the problem is based on a combination of factors. The first factor is related to the scope of the project, as the team has often not been explicitly told that getting buy-in for their conclusions is part of the project deliverable. Secondly, many teams (especially those with a strong technical representation) have a low understanding of the political issues related to their projects. As a consequence, they believe that "the facts will speak for themselves". Thirdly, team members who are not experienced in working on complex projects will typically develop final presentations that focus on the process that the team has followed, rather than the conclusions that they have made. This often means that the conclusions and recommendations are not clearly communicated. Finally, the project team does not usually have any experience in dealing with the group processes that typically take place within a steering committee, nor do they think about also presenting to other stakeholders who may not be represented in the steering committee.

There are three main activities that I tell my clients that need to be carried out to help the project team get the required buy-in and acceptance for project conclusions. The first of these actions needs to take place at the beginning of the project when the sponsor must clearly communicate that the project team bears responsibility for getting the required buy-in and acceptance. The second and third activities by the sponsor takes place at the beginning of the final phase of the project, when the sponsor should force and help the project team to develop a communication plan and must help the team to develop a structured final presentation (using a tool such as the Pyramid Principle). The final point will not be covered in this blog.

When I help teams develop a communication plan, we begin by making an overview of all relevant stakeholders that have an interest in the conclusions and recommendations being developed by the project team. Stakeholders who are expected to be negative towards the results are the most important to identify. For each stakeholder an overview is developed of their "hot buttons" and the dimensions of the solution to which they will need to agree. A detailed plan will then need to be developed outlining how these key issues will be communicated to the individual stakeholders.

The individual members of the steering committee should also be seen as stakeholders. This means that 1-on-1 meetings are planned with them before the final steering committee presentation. In this individual pre-meeting the SteerCo member have the opportunity to ask specific and detailed questions which then do not have to be raised in the overall meaning. In addition, any specific issues that the SteerCo member has raised in the 1-on-1 meeting can then be addressed in a structured manner in the overall presentation.

Carrying out these fairly simple and straight-forward activities aligns the internal project team with the overall methods used by top-tier consultants, and have resolved most of the issues related to the internal team's ability to get acceptance and buy-in for its conclusions and recommendations in the projects that I have carried out at my clients.

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

Determining the Appropriate Deliverables for the Finalization Phase of a Project

In previous blog entries I have suggested what the generic goals and deliverables should be for the first two phases of a complex project. This blog-entry will suggest what the generic goals and deliverables should be for the finalization phase of a complex project.

When a team enters the finalization phase of a complex project, it typically has carried out most (or all) of the key analytical activities that are required for meeting the specific project goals. The overall success of the team's work in this phase is very much determined by the work that has been carried out in the previous phase. In addition, there is seldom an explicit borderline between the project phase and the finalization phase, as the process can be iterative in nature as insights are developed and final analytical activities are carried out.

In this final phase, the main goal of the project team will be to develop and communicate the overall deliverables that have been agreed for the project. However, even if the work in the previous phases has been carried out successfully, there are still two aspects that can go seriously wrong in the finalization phase of a complex project:

- The project team is unable to develop clear-cut conclusions and recommendations based on the work they have carried out
- The team does not communicate its findings appropriately (to the right people and in the right way)

In my experience, complex projects are helped by defining a number of generic deliverables specifically for this phase that are related to avoiding these pitfalls. These generic deliverables will help ensure that the overall goals of the project are met on time and within agreed budgets, and will help ensure that project recommendations are actually implemented.

Deliverable Nr. 1: Clear conclusions and recommendations. This may seem obvious, but one of the most typical problems with internal teams carrying out complex projects is that they do not provide conclusions and recommendations. The requirement that the team must provide clear recommendations needs to be clearly stated at the beginning of the project, but should be re-iterated at the beginning of the finalization phase. This will ensure that the team understands that they are expected to come up with actionable conclusions ("go left" or "go right" not "it is possible to go left or to go right"). The specific deliverable should be a (short) presentation to the sponsor on what the team believes that the conclusions / recommendation coming out of the project are.

Deliverable Nr. 2: A pyramid supporting the conclusions / recommendations. The Pyramid Principle is a tool used by consultants to force the project team to develop a logical supportive structure for their conclusions. The basic methodology is well-defined and easy to learn. Developing a pyramid will serve both as a logical test of the conclusion / recommendation (do the results of our analysis support what we want to say?), as well as providing an excellent starting point for developing presentation and reports for the communication process. The pyramid can be tested with the sponsor at the same meeting as the suggested conclusions and recommendations.

Deliverable Nr. 3: A communication plan. Most internal project teams only work toward a final presentation to the steering committee. This often leads to problems because presenting new material to a steering committee often leads to surprises and unwillingness from the steering committee in accepting the conclusions and recommendations. A process should be put in place that allows the individual members of the steering committee to see the final presentation individually before the final presentation so that they can give their opinions, and ask their specific questions. In addition to the steering committee there are usually also other stake-holders to need to be informed in order to ensure buy-in and implementation.

If you can honestly say at the beginning of the finalization phase of your project that all of these generic deliverables will be developed, then the project has greatly enhanced its chances of successfully reaching its overall goals in such a way that the conclusions and recommendations will be accepted and implemented.

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

The Eighth Deadly Sin

All of you who have read my previous material know that I often speak about the Seven Deadly Sins of complex projects. Through discussions with some of my clients over the summer, I have become aware of what can be seen as the Eighth Deadly Sin. I also must admit that it says something about my long tenure in large consulting companies that this issue was not included in my original list of project problems.

The new "Deadly Sin" was brought forward by a Board member responsible for a group of project managers carrying out transformational projects across a large number of European subsidiaries. He explained that there had been a number of situations where a project lead by one of his managers had worked well and delivered a new, improved process at one of the subsidiaries. There had been a presentation to the SteerCo and with the help of some input from the Board sponsor the SteerCo had agreed to the suggested changes and the high-level implementation plan. However, six months later it turned out that the issues that the new processes were meant to address (late deliveries, low customer satisfaction, etc) had not improved and that the root cause of this was that the new processes had not been implemented. We had a broad discussion of what the reasons for this were, and agreed that one of the core reasons was that there was seldom any structured follow-up of the agreements that had been made at the end of the design phase of the project.

This problem will certainly be included in an updated version of an overview of why projects go wrong (even though "Eight Deadly Sins" does not have the same recognition-factor as "Seven Deadly Sins"). I also have to admit that the main reason that I did not include this in my original list is that the type of blue-chip consultants where I have worked earlier are usually only involved in the early phases of the projects, and are less concerned with the actual implementation. This is, of course, one of the main reasons for using internal project teams with end-to-end responsibilities that includes implementation.

Why are the results of projects not implemented? There are a number of core reasons (some quite valid) for this:

• Very often teams are more optimistic than actually warranted about the real buy-in and acceptance that they have created for their conclusions and recommendations

• Environmental changes may make the agreed changes less attractive than originally believed. An example is if the success of an agreed change to a delivery process is dependent on a new product being launched, but the launch has been delayed

• Priorities within the organization may change. An example could be if the local company has to focus all its free resources on meeting the threat of a new product launch from its main competitor

• The natural inclination of people to give higher priority to the activities that are required for making "today" successful

Issues related to truly getting the required buy-in and acceptance need to be dealt with in earlier stages of the project (see blog entries on interacting with sponsors, dealing with key stakeholders, and getting buy-in for conclusions). The other factors can be successfully dealt with by firstly developing sufficiently detailed implementation plans as part of the overall project deliverables and then putting in place and using a pro-active and structured benefits tracking process. Such a benefits tracking process should follow-up on the overall implementation plan and key milestones, it should measure the fulfillment of agreed targets, and it should include the opportunity to report back on changes in environmental factors and priorities. If the benefit tracking process needs to follow-up on a number of projects (as part of an overall program), then the benefits tracking process should also be multi-layered and focused on exceptions where decisions need to be made rather than giving the same level of detail on all projects.

The advantages of such a benefits tracking system are many, and include:

• There is even more pressure on the project to deliver good work and ensure buy-in as they know the quality of their work will be followed up

• Even if buy-in for the conclusions and recommendations coming out of the project is not 100%, it becomes more difficult not to carry out agreed actions if they are being followed up

• Pro-active follow-up will enable a top-down understanding of environmental developments and changes in priorities, and will allow the development of an agreed "Plan-B"

• The fact that implementation is being followed up makes action much more likely as people will feel the pressure of upcoming milestones and deadlines

Based on the assumption that the project is only successful when the required changes have actually been implemented, ensuring overall buy-in for the results and following up on implementation should be seen as core parts of the overall project. Follow the links if you are interested in more information on project planning or project management training.

Helping a Project Team Develop Meaningful Conclusions

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 last of these signs, a situation where it is difficult to pin the team down on any meaningful conclusions.

Why is this a problem? A key assumption is that the project is meant to develop conclusions and recommendations. There may be projects that have been given a responsibility for "collecting all information". However, in my opinion such a project would be very wasteful. There may be projects that have been asked to only collect data and analyze data about a given issues. In my opinion this is a wrong way to set up a project, as it is impossible to carry out any meaningful analysis without having a goal and a set of hypotheses leading to conclusions.

Assuming that the core reason for the project is to develop conclusions about a key issue, then it is naturally a problem if the project team does not seem interested in doing so. In addition, this is often a fairly scary problem, as it will typically come to light late in the process (sometimes not until the final presentation). This problem therefore can, make most, if not all, of the effort and resources that have been invested in the project a waste.

What is my advice to you, as the project sponsor, to avoid this problem? The most important input from your side is at the beginning of the project. You need to start the project off with clearly defined goals, and deliverables that are very explicit regarding the type of conclusions and recommendations that you expect. You will also need to follow up on the project regularly (default is weekly) to ensure that the project is sticking to its plan and going in the right direction (i.e. will it be able to deliver the required conclusions and recommendations).

When I am helping my clients make complex projects successful I ensure that regular meetings take place with the project team (and sponsor). These regular meetings serve a number of purposes, but should also be used to ensure that the project team is working with hypotheses. Doing so will enable me to test whether proving the hypotheses will bring the team closer to its final goals. In addition, and even more importantly, working with hypotheses enables the project team to work much more effectively and efficiently. Finally, I always strongly suggest that the team is forced to test its conclusions in a Blue Team. This is a meeting with experts who are not directly involved in the project where key ideas and potential conclusions are tested, and the participants are asked for input on key issues and complications.

The previous suggestions are only helpful if the project is starting up or is fairly early in the process. What can you do if you are at the end of the project, and the team does not seem to be close to developing any conclusions? I am often called in to help in this type of situation, and it requires some fairly intense input to correct. The first step is to sit down with the team and go through the overall process of the project. I usually start with a review of the key starting points for the project, and then discuss and agree the goals and deliverables that were given to the project. These should be presented as clearly leading to conclusions and recommendations.

I then go through the work that the team has carried out and find the key data points that have come out of their analytics. These data are discussed with the team with the goal of agreeing what they mean. This is then developed into (preliminary) conclusions. These conclusions then need to be stress-tested. Are they robust? Are they well-supported? If the answer is "yes", the team can start thinking about the communications phase. If the answer is "no", the team and the sponsor need to check how much time is available, and agree the very specific activities that will make the conclusions more robust. The work that the project team carries out in this phase must be followed up very intensely to ensure that every moment is spent on work to make the conclusions more robust.

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

How to Ensure That Key Stakeholders Are Sufficiently Aware of the Project

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 sixth of these signs, a project where key stakeholders are not aware of the project.

Why is this a problem? This is a problem because input from stakeholders is required both for increasing the overall quality of the project results and for getting key recommendations implemented. Stakeholders can be defined as the people within the organization who are interested in the results of the project because they can be impacted by the conclusions and recommendations coming out of the project. Key stakeholders can include managers from specific organizational units (marketing, production, etc), but also unions (in the case of cost-reduction projects).

If the project team has not had any (or only very limited) contacts with key stakeholders it is very unlikely that all key issues that are important to these stakeholders have been included in the overall project analytics. In addition, it is even more unlikely that the stakeholders will have a positive opinion about the project and the project results as they will feel left out of the process and not listened to. As a result, it will be very difficult for the project team to carry out an optimal communication process in the end phase to create the buy-in necessary for implementation. This will mean that the end-phase is likely to be difficult and unpleasant, and that the resistance to the project conclusions will be high.

In many of my projects I find that this is one of the corrective actions that need to be carried out. The best way to do this is to plan a meeting with the project team (again). The key goal of this meeting is to discuss and agree who the key stakeholders are, and what their most important issues are. Based on this, the team develops a concrete plan to sit down with each (type of) stakeholder. In these stakeholder meetings the team should present the project (what are the key starting points, the issues that the project is dealing with, the overall goal, the key deliverables, and the approach) and what the team believes the potential interests of the stakeholder are.

Usually, I need to explain to the team that they must listen very carefully to what the stakeholder has to say. Key points that need to be understood by the team include what the stakeholders sees as the key issues, and how they believe that these issues should be dealt with. I highlight that it is important that the project team does not make any promises (explicit or implicit) regarding how the issues will be dealt with as this will seriously compromise the ability of the team to come up with the optimal answer. Rather, the key goal is that the team knows what the viewpoints of the stakeholder are, and that the stakeholder feels that he has been listened to.

Together with the sponsor, I typically plan a new meeting with the project team after they have seen the key stakeholders. In this meeting we discuss the viewpoints presented by the stakeholders, and agree what the team needs to do in order to ensure that these issues are dealt with in an optimal manner. In addition, an ongoing set of meetings is planned with key stakeholders. The emphasis of these meetings will gradually change from getting information to presenting and testing key hypotheses and possible conclusions and recommendations.

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

Finalizing the "Never-Ending" Project

If you are similar to many of my clients, you may be facing the situation where you are deeply worried whether a critical project that has been going on for some time will end successfully. An example of such a project involved a client who was the CIO of a major energy company. This company was moving a key part of its business to another country. This part of the business relied heavily on its IT systems, and ensuring that the transferred IT-systems were working and were compliant to the local regulatory environment was therefore crucial.

The team had been working for several months, original deadlines had long since passed, but the team kept on requesting more time for additional analytics. Due to these delays, the IT-department was rapidly losing credibility, and was seen as representing a major threat to the move being carried out on time. Due to the commercial and regulatory advantages of the new location, each month delay would represent major financial losses.

The CIO's request to me was to help/force the team to finish its work within two weeks. While the initial reaction from the team was that this would be impossible, the team was able to deliver more than acceptable results within the suggested deadlines. The methodology that I used to achieve this remarkable turn-around is fairly straight-forward and easily transferable to other situations.

The starting point for my work was to sit down with the team and go back to the beginning of the project to discuss and agree the basic issues that needed to be resolved, and to develop a common understanding of the goals and general framework (including time pressure) for the project. In this case, as in many other situations I have come across, it was surprising both to me and the team how much the team’s perception of the goals and deliverables had drifted over time.

The next step was to quickly but thoroughly to review the work that the team had carried out and link the outcomes of this work to the agreed goals of the project. In this process it became clear that much of the work that the team had carried out was in the “nice to have” category rather than critical to reaching the goals of the project. In addition, the team agreed that the same could be said about a large portion of the further work that the team had planned to carry out. Based on this, the team agreed that with a minimal number of additional interviews it would be possible to finalize the project based on the results at hand.

The next step consisted of structuring the results of the work that had been carried out and getting a common understanding of what these results meant and signified. A very helpful tool that I used was the “Pyramid Principle” (see http://www.barbaraminto.com/ for more details). The next step was to translate the team’s conclusions into a communication plan. This involved understanding who had to buy-in to the recommendations from the project, and develop a plan to “sell” the key messages to these individuals (with a special focus on those who would be surprised and/or unhappy with the team conclusions).

In this case the communication plan involved a number of structured presentations and a written document outlining the overall conclusions with supporting arguments (again using the Pyramid Principle). Although there was considerable discussion related to some items, the overall recommendations were accepted and implementation started within an acceptable timeframe.

I have used similar approaches to help a number of teams that have this (fairly common) problem. I therefore believe that following the broad steps I have outlined here will help any sponsor and/or project leader facing a team that is having problems finishing its work in an acceptable manner. Follow the links if you are interested in more information on project planning or project management training.