Project Recovery – such a frequent topic that I decided to write a 5 post series on the leading indicators of trouble and part of my upcoming book, Recovering Troubled Projects. This is the second post – the first post looked at the leading indicators of trouble to be aware of during the Planning and Kickstarting phases of projects. As a quick recall, here is what was covered.
In the first post we identified the leading indicators of trouble during the planning stage as:
And the leading indicators during kick starting of our project as:
Our analysis of the situation lead us to a particular conclusion as to the health of our project, summarised as “In Good Shape” or “Worried”.
Before we start looking at the obvious question – What do I do with this information? – we will take a look here at the leading indicators of trouble for the next phase, Doing (or Execution as it would often be referred to).
Doing – Leading Indicators of Trouble
The majority of the leading indicators of the early stages of the project are relevant at this stage, so keep an eye out for them. As the project is now into full doing mode, there are some other items that we need to keep our radars tuned for.
Lets start with the first of these, Metrics – Quality, Schedule and Cost. At a minimum, we should now have a clear plan and should be measuring against this plan. If either of these is absent, you need to fix it immediately. It is like trying to drive your car with the front windscreen blacked out and no seat belt on – probably fatal. Fixing it needs to make sure that you have completed the planning deliverables and then built all metrics off the work breakdown structure agreed – a milestone sequence chart which is visible to everyone – we will discuss more details later.
While it may seem that there is a bias towards metrics, the real bias is toward progress and fixing anything that is hindering this. In order to do this, clear, relevant metrics are required and they should be easily measured. The emergence of a culture where there are either too many reports in existence or too many reports being requested is an indicator of a problem, that if left unresolved will detract attention from the important productive work of the project ultimately lead to trouble. Do a review, drop the duplication and non-value add reports and make sure that the rest get the proper attention – they are produced with real data, people take the time to analyse them, and they inform future action.
Allied to the too many reports is the too many meetings syndrome. This is normally an indicator of a lack of clarity with respect to either scope or execution strategy. If this is not corrected early, it will become an assumed practice and will quickly land your project in trouble – this is a downstream problem of some of the issues that we have already discussed. Also keep an eye out for the participants – if too many of your execution team start attending meetings, then you are in serious trouble.
Scope creep – you probably have a change management process in place (if not, then this is even worse). However, if people are just using it to document change as opposed to manage change – if the change is not essential, then it should not be added. You need to focus on the essentials, the business purpose and the associated principles that you signed up to at the outset of the project. If not, you will find many changes, scope creep and it’s first cousin, trouble.
Overcoming inertia early – at the early stages of execution you may experience some inertia and some early delays. The tendency is to pass them off as normal, or we have slack later in the schedule and we will make it up. You should not simply accept this as normal, unless this is the first time the team has ever executed a project. If they are experienced, than all of this should have been anticipated and there is more likely a deeper root cause for delays, that if not fixed, will keep recurring and add further delays to the project. Delays are always a leading indicator of potential trouble, so you should treat them accordingly.
Set the standards early – as with delays, people have a tendency to treat cost overruns or variances with a similar casual dismissal; don’t. For unforeseen and risks, you will likely have assigned a contingency, which should be managed and drawn down as and when such events occur. For all other cost variances, they are indicators of potential trouble (if they are overruns) and you need to understand how many times it may recur and what is the potential liability. If it is a saving, a similar analysis is worthwhile, as perhaps you may have discovered an area where you can make savings if you follow a particular path consistently.
A project delivering business benefits or a technical adventure? How would you describe your project? If there is a significant technical bias towards technical adventure, then it may well be a leading indicator of trouble – I am repeating this particular indicator again, as it occurs so often and it leads to disaster. How many IT projects have we seen over the past year that result in poorly performing companies cripple – supply chain malfunctions leading to empty shelves, payroll systems imploding, airport baggage handling not working – the technical adventure overtook the business imperative.
Up to this point, all of our discussion has been about leading indicators of trouble, so by now there is a possibility that you will be slightly paranoid and beginning to see trouble everywhere – but panicking too early is also a sign of potential trouble. The first actions should be to fix the problems – either with the way you are operating or with the people operating the project. If the problems persist, then you need to start considering some greater level of intervention – don’t panic, take action. Early action, measure the change and then act accordingly, including shaking things up if necessary.
Remember, use this simple tool to gain perspective – however, do remember that some indicators should be weighted differently to others, depending on your goals and constraints. Is project recovery a potential need for any of your projects?
The purpose of sharing this is to get feedback from you on the content and clarity of my writing. Would love to hear you views.