Determining the Appropriate Deliverables for the Initial Phase of a Project

All complex projects consist of three basic phases: the initial (or preparatory) phase; the project (or work) phase; and the finalization phase. Each of these phases has its own challenges and pitfalls. These can be avoided by having a clear picture of what should be achieved in each of these phases. This blog-post will suggest what the goals and deliverables should be for the first phase of a complex project.


In my experience, there are a number of things that typically go wrong in the first phase of a project that severely reduce the probability of the project finishing successfully. The most common pitfalls I see in the first phase are:

- The project is not set up to deal with the right issues
- The optimal links are not developed between the sponsor and the project team
- The right resources are not allocated to the team (primarily people and time, sometimes access to expertise and/or money)
- The individuals who are assigned to the project team are not developed into a team

My suggestion is therefore that the primary goals of the preparatory phase of a project should all be focused on ensuring that these pitfalls are avoided. Reaching these goals will entail a set of activities involving the sponsor of the project, the project leader, and the team members. These activities should result in a clear set of deliverables for the preparatory phase of the project.

Deliverable Nr. 1: The appropriate sponsor for the project. This should be somebody who has an interest for the key issues to be resolved through the project, and has the time and energy to spend considerable time on the project.

Deliverable Nr. 2: The optimal project manager. The project manager needs to be a person with an affinity and understanding to the key areas to be covered by the project, the right motivation for making the project a success, and the right skills for carrying out the project.

Deliverable Nr. 3: The appropriate goals, deliverables, targets, and scope for the project. This deliverables will initially be developed in an interaction between the sponsor and the project manager, and will later be changed to reflect initial discussions with the project team.

Deliverable Nr. 4: The optimal team for carrying out the project. The composition of suggested team needs to reflect the issues that the project is dealing with, and needs to include the right mixture of skills. These can typically be divided into technical and functional skills, analytical skills, and interpersonal skills.

Deliverable Nr. 5: A realistic plan for carrying out the project. This deliverable should focus on the overall timing of the projects and intermediate milestones. The important dimension of this deliverable is that the suggested timing is realistic and is accepted by all the project team members.

Deliverable Nr. 6: A cohesive team that has joint ownership for reaching the goals and deliverables of the project within the agreed timeframe. This is a "soft" deliverable that is difficult to definitely "tick off", but a set of activities should be defined that will increase the probability of the deliverable being reached. I do not believe in stand-alone team-building activities. Therefore, my recommendation is that the key activity for achieving this is a formal (and structured) kick-off session. This session should include a "get to know" session, a training session on how to become an effective and successful team, a training session in key analytical tools, an explanation of the project (background, goals, and deliverables), and a discussion on the approach and development of a detailed work plan.

If you can honestly say at the end of the first phase of your project that all of these deliverables have been developed, then the project has greatly enhanced its chances of ending successfully. The project can then move to the next phase which will involve carrying out the key activities required for developing the overall project-specific deliverables of the project.

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.

Complexity Reduction For Structurally Improving Profitability

For most of you, the complexity of your business has increased over the last ten years. Key reasons for this include increased competition, the need for segmented offers for meeting specific customer requirements, new technologies, etc. While this may have lead to higher revenues, it has more often than not also lead to structural increases in capex and higher operational costs through-out the supply-chain. In addition, I have seen numerous companies where increased complexity has lead to difficult and slow innovation processes, seriously hampering the companies’ abilities to meet new competitive threats and/or market opportunities.

Today, I see that many companies believe that complexity reduction is a fairly easy way to reduce costs. A project is started to carry out a Pareto analysis of revenues across products, and typically sees that the 80/20 rule holds, and that the tail is not profitable. The project then suggests that the 10% of the product portfolio having the lowest sales are terminated. In spite of protests from marketing & sales this is then carried out. Results, however, are more often than not disappointing, or even non-existent.

In my experience, complexity-reduction is a critical activity for a majority of businesses. While complexity-reduction in the restaurant business appears to be fairly easy, in most companies I consult to it needs to be carried out in a structured and well thought out manner where:

• It is understood that not all complexity is bad, and that the crux is to get and keep the right level of complexity for your specific company situation

• It is realized that the process is complex, will take time, and will result in only limited “low-hanging fruit” opportunities

• It is possible to put a well-organized and broadly supported project team in place to carry out the project.

If you believe that your company is suffering from too high complexity, my experience is that you will need to put in place a project to carefully consider a number of inter-linked aspects related to complexity. The first step in the process will be to understand the complexity in your organization. This will involve understanding the true complexity drivers of your current business. Typical examples include number of customers, number of products (at the lowest level of detail), number of packaging variations, number of ingredients, number of technologies, etc.

You will also need to understand the value of your market-facing complexity (i.e. those aspects which your customers see). This will involve understanding the reasons for the variations in your market-offering, analyzing the value that your customers place on the variation offered, and deciding what the consequences would be of reducing the variety you offer to the market-place. The final analytical activity will involve understanding the costs of complexity by going through a detailed activity-based costing exercise to allocate costs to the different complexity drivers (products, customers, etc).

The next step will involve carrying out a direct pruning of the product portfolio based on the preceding analytics. This portfolio reduction will not focus on the tail of the product portfolio, but will rather seek out products where the strategic value is low and costs can truly be reduced either due to a negative margin or through specific opportunities to reduce overhead through the removal of one or more products from the portfolio.

In addition to reducing the complexity that is visible to your customers, the project team will also need to look at opportunities to reduce below-the-skin (i.e. not visible to your customers) complexity. At one of my large telco clients, this is one of the key issues they are facing. They currently provide many services that are similar from a client perspective, but which are delivered through different technologies. The company is now going through a process to move delivery of all services to one platform, and expects that this will result in major savings. However, it is finding this process challenging as it requires a broad coordination across the commercial and technical organizations.

While these activities related to reducing customer-facing and internal complexity will provide you with considerable benefits through the one-off reduction in complexity, my experience is that complexity will quickly creep back if structural changes are not made to key processes. The most important process to change is the innovation / new product development process. The key goal of the changes to this process is to ensure that only complexity that truly adds value is allowed in new products. A key change to enable this is to ensure that all complexity costs are included in the business case for the new product. In addition, the improved innovation process should ensure that the production of the new product minimizes internal complexity by pushing for the use of modular designs, re-use of components, etc.

Finally, the complexity-reduction team will need to put in place (or improve) a portfolio management process to ensure that an overall portfolio view is taken in decisions related to new products, and that regular reviews are carried out to discontinue low-value / end-of-lifecycle products.

While the described process is intense and requires a substantial investment in time and resources the returns are also substantial both in reduced costs and extra revenues through faster time-to-market for critical new products. 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.