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.

Ensure Project Success by Demanding Proposal

I am sure that most of you have been the sponsor of projects that have not reached their objectives in a satisfactory manner. In these situations, you have probably wondered if you as the sponsor could have done something to make the project a success.


In my experience, there is one action that you as a sponsor can take that will greatly increase the success rate of internal projects. This is to demand that the project manager (and team) develop a proposal similar to what you would expect from an external consultant. You will the need to evaluate the proposal in the same way that you would evaluate a proposal from your consultant. This includes concluding whether the proposal from the internal team:

• Shows that the team truly understands the core issues that you need to have dealt with
• Suggests goals and deliverables that will actually help you deal with your core issues
• Presents an approach that makes sense by suggesting a reasonable set of activities, use of time and resources that both meet your deadlines and are reasonable, and presents a set of milestones that show how the project will move forward and gives you the opportunity to easily understand whether the project is on-track

If you are not satisfied with the proposal you then have the option of sending the project team back to the drawing board or to consider other options (including external consultants).

While a well-structured and agreed proposal is a key success factor, it really shows its value when it is used as part of your top-level management of the project. A key component of this process is to insist that the project team sticks to the agreed deadlines and milestones (as is second nature to external consultants).

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

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.

Getting a Project Team Quickly Up To Speed

I am currently in the process of carrying out a project at a European energy company. In this project I have helped the project team recover from a disastrous first phase by helping set up a structured and fast start to the second phase of the project.


The project was originally staffed with a team of eleven technical people from across the company. The people chosen for this team represented a wide range of departments that dealt with the technology. The team worked for four weeks, and presented its results. The Steering Committee was disappointed with these results, as it felt that a) the team had not addressed the key issues, and b) had not developed a sufficiently detailed analysis of the "facts and figures" related to the technical elements being analyzed. A number of things went wrong in the first phase, and my key role has been to correct these issues in the second phase of the project.

The main problem the project team faced was that it had too little time to carry out any actual analytics. This was caused by an unrealistic deadline imposed by the steering committee, but also by the project using almost two weeks of the available four weeks in starting up the project and carrying out "team building" activities related to agreeing the goals and deliverables of the project. The excessive time spent on starting up the project was due to a number of inter-linked reasons. The key reasons are cultural, habit, politics, and insecurity in project leadership:
• The company in question is from Northern Europe, where egalitarianism is important. This general cultural trait is strengthened by the culture of the company itself which is also fairly flat in its structure, and believes in everybody having the right to state their opinions. This results in "open debate" being the default solution for setting up this type of projects.
• Habit was in this case mainly driven by the use of an internal process manager, who (rightly or wrongly) believed that this was the way that projects should be run. In this company, the type of team building through the bottom-up development of goals, deliverables, approach, etc is "the thing" that project managers do, and which probably work fairly well in this culture if the project has sufficient time.
• Politics played a key role in this project, as the best way forward for the technological asset being discussed was a highly political issue with extreme differences in opinions across the various departments of the company. This meant that all the team participants felt that they had to "push" their preferred solutions rather than focusing on the work to be done.
• The project leadership (both the formal project manager and the internal process manager) were open about not being used to running this type of complex project. This meant that they were not sure about how best to structure such a project, and were uncomfortable with "pushing" their views in a group of experts.

The second phase of the project was set up to minimize the problems encountered in the first phase and to maximize the probability of the project team being successful. The project started with the project leader. The project leader developed a very clear and structured overview of what the Steering Committee / key sponsors were looking for (goals and deliverables). This was put on paper, and tested with the sponsor / steering committee, and adjusted as required to ensure that the expectations on what will be delivered were 100% clear. Based on this, the project leader developed an overall approach for reaching the goals and deliverables. This plan included a small core team and a realistic estimate of the time required for reaching the agreed deliverables.

When agreement was reached with the steering committee and sponsor the project leader brought together the chosen team, and communicated the results of the first step. He asked the team for comments and feed-back, and adjusted the details of the plan for the good ideas and comments that were given. The structured and hierarchical start of the project meant that this process took less than one week instead of the two weeks in the first iteration of the project, and was also much more efficient as the total man-hours used were 25% of that used the first time around.

The structured and hierarchical start has also meant that politics have been minimized and effective use of the available resources maximized. The core project-related activities have been carried out through a mixture of sub-teams doing specific analytical tasks (within agreed milestones) and presenting and discussing the results with the rest of the project team. The role of the project manager in this phase has been to strictly follow-up on scope (is the team focusing on what they should be doing?), analytics (is the work being carried out correct?), quality of results (are the outputs from the team's work what it needs to be), and coordinating the work of the different work-streams.

At agreed moments the project manger and the core team have brought together the work of the individual teams and developed the overall conclusions and story-line. This has been presented to the whole project team and discussed (and revised) until the team agreed to the overall conclusions. The results were then presented to the steering committee in the form of interactive workshops.

The project is now in the final phase and the results are being discussed with the individual steering committee members before the final presentation. This will ensure a broad agreement to the conclusions that the project has developed and commitment to the follow-up actions suggested by the team.

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