The fifth post on identifying the leading indicators of trouble with your project. In this post we will tie all the strands together, look at some other critical elements and briefly discuss what action may be required based on your situation. If you have not read the other four posts, then I would encourage you to go and read them. Part 1, covers early warning signs at the start of your projects – the planning and scoping stage – if you take care of these issues early on, then you save yourself an enormous amount of pain at layer stages. In Part 2, the execution stage of the project is discussed, and we identified some items which can lead to trouble for your project. Then in Part 3, we look at difficulties which can arise when you begin to handover elements of the project deliverables to the customer. These are consequences of earlier poor decision or execution (think cause and effect). Fixing this now, may help with later deliverable. Part 4 looks at how to execute a project health check and gain a good feel for where your project is at. Check them out. Of course it is great to gain an understanding of the state of health of your project. However, it will probably lead to a place where you need to take action on the findings – or maybe not if everything is flowing well. If you do need to take action, then you should look at the items in the following order:
- The team and how it is organised (structure/design).
- The processes that you use to the get work done, including the overall roadmap for the project.
- Only if the above do not address all your issues, then look at the technology being utilised to execute – the tools are rarely the problem.
Make sure that you only experiment with one area at a time so that you can develop a hypothesis, test it with only one change (variable), design a data capture mechanism to measure success or not and then capture and assess the results. Iterate until you get to a better model and limit the rate of change. A key element here is to limit the rate of change. This is important for two reasons. The first is that when you make change you need to access if it is having the desired effect and whether you need to embed it or eliminate it. The clarity of feedback required can only be gained if you make sure that there is a direct link between the change and the effect. The second reason is that people need to assimilate the change. If you bring one change on top of another, this often leads to confusion and partial implementation of changes rather than complete – this invariably leads trouble, the exact opposite to our objective. Invest heavily in your decision-making process, ensuring that you follow a solid process. I recommend that you:
- Collect data/observations of what the undesired effects or consequences are that you wish to eliminate.
- Next, look at identify all possible causes (we often refer to this as root cause).
- Identify the true root cause and/or eliminate suspected root cause – be as data/fact/evidence driven as possible – gut feeling is fine for the last 5%, but not sufficient on it own.
- When you are confident with your analysis, access all options and their upside, but more importantly, their down sides.
- Make a decision, monitor its effect and act accordingly.
If you follow this process (or a similar one), then you will give yourself the greatest chance of making the best decisions for your project. I hope that this topic was of interest and I would love to hear your thoughts, including any particular items you would like to see discussed in further detail.