Showing posts with label Identification of high-risk projects. Show all posts
Showing posts with label Identification of high-risk projects. Show all posts

28 February 2010

The Business case For Improving Complex Projects

As you probably know, my core business is to help improve the performance of internal teams carrying out complex projects. In discussions with executives concerning input from my side I am often asked to define the business case for using my services. This question has become steadily more usual in the last year, as it has become progressively more difficult for companies to hire in external help.

The direct value of my input is difficult to quantify as my service is secondary. Therefore, my initial reply focuses on helping the executive understand the business case for the project he thinks is in trouble.. If this is non-existent, or very difficult to quantify, my advice is that the project should be stopped. For some projects, such quantification is fairly easy. If the project in question is a cost reduction project, the value of the project is driven by the size and timing of the savings to be implemented. If the project focuses on product development, the value of the project is driven by the revenues and profits expected to result from the new product.

For other types of projects, such quantification is more difficult, but can usually be carried out. For a strategy project, the value can be very high, but the quantification needs to take into account follow-up projects required for implementation, etc. For a reorganization project, the value should come from improved decisions, better use of resources, etc. This is all fairly indirect, but clearly has value.

If the overall project has value, it is then critical to understand that this value can be radically reduced by a number of issues related to how the project is carried out. Any of the "8 deadly sins of complex projects" will lead to such a loss of value, but I will focus on a few concrete examples.
If a project is delayed because it is not meeting its deadlines, then this has a direct effect on the value of the project. Let us assume that the project will increase annual profits by €1 million. This can be the result of a cost reduction program with a €1 million bottom line effect, or a new product launch with annual sales of €4 million, 25% margins, and negligible "fixed" costs. In this case, a one-month delay in the project means that your company will have a one-off (but permanent) loss of €0.1 million in profits.

Lower quality results from the projects will also have direct consequences on the value. Let us assume that the cost reduction project mentioned earlier does not identify all the cost saving opportunities that were available and/or expected. If the project only identifies €0.9 million bottom-line effects instead of the €1 million that is believed to be available, then the annual loss is €0.1 million. In the product development example used earlier, then a fairly minor mistake in the product definition and/or pricing that leads to 3% less revenues will lead the same ongoing annual loss of €0.1 million.

A project team that does not communicate optimally can lead to the same type of value-loss. If the work carried out is good, but the results are not accepted and therefore not implemented, then the loss of value is 100%. If the unsuccessful communication leads to lower buy-in resulting in either delays or only partial implementation then the consequences will be the same as in the previous example (i.e. ongoing annual losses).

My experience is that using the Team Based Consulting methodology to provide structured help to project teams (including the executive sponsor) in a) defining and setting up the project, b) carrying out the project, and c) developing and carrying out a communication process can easily help avoid the type of value-loss given in these examples. Given the fairly focused and limited input that is required from my side to help the internal teams, the business case for such an intervention can almost always be made.

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

15 July 2009

Identifying the Projects That Are Most Likely to Fail


If you are in the same situation as many of the people I consult to you are responsible for a portfolio of projects, and are having to spend too much time checking on how these projects are performing. When my clients are in this type of situation, I recommend that they get out of this trap by focusing their attention on the projects that are most likely to fail, and spending less time on the projects that are likely to go well.

How can you know which projects are most likely to get into trouble? While my previous blog-entry suggested Eight Signs, these are signals that are visible after a project has started. What is required is a method for to identify these projects before they start. Luckily; in my experience project failure is mainly driven by project-complexity. Therefore, if we can objectively measure the complexity of your projects you can rank your projects on the likelihood of each project getting into problems, and can prioritize your time accordingly. How do we know which projects are the most complex? Again, this can be done fairly easily by understanding the complexity drivers for projects, and scoring each project on these dimensions.

Based on my 20 years of experience, I find that project complexity can be measured on two main dimensions. These are a) internal complexity, and b) external complexity. Internal complexity is based on issues related to the way that the team members need to interact, and the type of work that they need to do. External complexity, on the other hand, is driven by the overall environment in which the project needs to work. For each of these two dimensions, I have defines four key complexity-drivers, and the higher the score on each driver (using a scale from 1-5) the more complex the project is.

The internal complexity of a project is driven by:
1) The distance of the work to be carried out by the project to the day-to-day activities of its members
2) The organizational distance between the units where the project participants come from
3) The level of sophistication required in the data collection and analysis to be carried out by the team
4) The level of the "out of the box" thinking required for developing optimal conclusions

External complexity is driven by:
1) The level of pressure from management for achieving concrete and challenging results
2) Openness of project 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 results

We can use the scores on each of these dimensions to determine the overall complexity of the project. A project that scores higher than fourteen on each dimension is a complex political project, and should be followed up very closely. If you focus your attention on the complex political projects in your portfolio, you are sure to increase the overall success rate of your projects, as the other, less complex projects are much less likely to experience problems. Carrying out this prioritization process has helped many of my clients prioritize their overall work, and has also helped make individual projects more successful by focusing project activities on crucial issues.

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

08 July 2009

Eight Signs That Your Project is in Trouble




Many of my clients are in a situation where the number of complex issues that need to be dealt with outside of the standard organizational structures is growing. The companies that earlier tended to outsource the most complex of these projects to outside consultants are now less able to do so due to economic constraints. Due to these two factors, I see that the number of internal teams dealing with complex projects is growing dramatically.

If you are also facing this situation then there are almost certainly one or more projects within the portfolio of projects you are responsible for 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.

In my career I have had the opportunity to improve a large number of projects that were not going well. Distilling my experience across these projects, 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 given below, and each title links to a separate blog-entry giving more details on the individual signal:
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

My generic answer for dealing with a project that is showing a number of these warning signals, and is therefore heading toward failure, is to regroup. An example of such a situation was described in an earlier blog-entry. Regrouping involves bringing together the core team members in a meeting. This meeting should have sufficient time reserved for it (suggested minimum is two hours), and be set up to minimize the possibility of external distractions (possible off-site, no mobile-phones, etc). This meeting should start off with a review of the issues the project is meant to deal with, the original goals set for the project, and the deliverables the team is expected to come up with. The next step should be to go through the work the team has carried out, and to discuss the key signals that served as a starting point for your worries about the project. Based on a reconfirmation of the goals and deliverables a realistic time-span should be agreed with clearly articulated milestones where you expect concrete updates on progress. The team should then be forced to allocate responsibilities and get a (realistic) commitment from each member on the time that they will invest and the activities they will carry out.

One of the problems that I have often encountered is that the team has conflicts with their daily work or other activities. In these situations, I have needed the help of the sponsor to help free up time and deal with conflicting priorities. This has also meant that the sponsor, has needed to get more actively involved in the day-to-day work of the team with intense follow-up and active assistance in the form of “running interference” for the team and guaranteeing that they are given sufficient time to carry out the required work. In my experience such a “re-grouping” of the team activities is usually sufficient to get the team back “on-track”.

Using these fairly simple steps to bring a project back "on track" has served me well in project management consultancy work that I have carried out at a range of companies. The suggested activities can also be used to kick-start a project management training. Follow the links if you are interested in more information on project planning or project management training.