Project Disaster Recovery - Part ONE

USING SIX SIGMA AND CRITICAL THINKING

Brought to You by Dave Litten

Recovering your project from disaster

Despite the best laid plans, sometimes you realize your project is getting badly off track and you need to take some form of corrective action to rescue it from disaster.
NOTE. There is a whole slew of people’s opinions on what the structure and content of a project disaster recovery plan should look like. If you have the time and resources to sit down and come up with a detailed plan – then your project is already a disaster!
What I am focusing on, is something far more valuable – the steps to manage a project out of deep trouble so YOU are the HERO.

It is important to ‘think of wide’ when considering possible actions to get your project back on track.

A common knee jerk reaction is to throw more staff resource or money at the problem, but that is not always the best thing to do. Indeed, for some problems simply throwing more people into the work just makes matters worse.

A great help is to bring in the team leader and possibly team members to talk about the problem.

It is most often the case that your specialist team members can see solutions, indeed, can help you identify the root causes. After all, if your team are specialist experts, they will bring a wealth of experience and ideas to help implement corrective actions that will work.

Avoid the temptation to micromanage your project schedule and budget, after all if it is just a little off track, the best solution might be to keep things going the way they are but simply fast track the effort for the next few days to get your schedule back.

It’s also important not to panic and throw together a hastily thought through action plan without considering the full consequences.

Finding out why the project is off track

When you get a problem, first look at the underlying causes and try to understand the characteristics of the problem.
It is only when you properly understand both the characteristics and the causes of deviations from the plan that you can come up with sensible corrective actions.

If your project goes off track, it probably is not anybody’s fault, it is simply that the project is not proceeding the same way as you anticipated on the plan.

You need your team members on board to keep the project momentum going and probably to help solve the problem.

Try using the FIVE ‘WHY’s

It’s human nature. You have a crisis and dive straight into fixing “it” without first stopping to think ‘why did it happen?’ If you identify the root cause FIRST, then you can identify options to recover the situation.

This is a powerful technique I am teaching in our forthcoming Lean Six Sigma Masterclass that helps identify the root cause of a problem. It is important to first determine the relationship between different root causes of a problem – and so here is a suggested sequence:

Write down the specific problem, this helps you formalize the problem and encourages you describe it in detail. It also helps everyone focus on the same problem
Ask Why the problem happens and write the answer down below the problem statement
If the answer you just provided doesn't identify the root cause of the problem that you wrote down, ask Why again and write that answer down
Repeat until the team agrees that the problem’s root cause has been identified. This may take fewer or more times than five Whys

When carrying out your initial analysis, consider the following:

Is the project going off track or is it that the project is ‘right’ and it’s the plan that is ’wrong’? In other words, is the plan unrealistic? You may need to adjust the plans for the rest of the project in the light of this experience
Is this a problem with planned work, or has extra necessary work been discovered that was not anticipated on the plan? This problem is made less likely if you have done proper planning using breakdown structures and work-flow diagrams in the first place.
If you have only done activity planning, then this is likely the cause of your current problem (check out our “product-based planning” technique)
Is there a problem because the work requires more effort than expected, or is the work estimate right and the problem is that the team members have not been able to put in the planned time and effort?
For example, have team members been called away and repeatedly to do unforeseen operational, non-project, work?
Are the team members going more slowly than expected because of unfamiliarity or inexperience? Would it help to ask for more experienced staff, or would the learning curve of new staff getting to understand the project, only makes things worse?
Have the teams been held up because necessary equipment is not available? For example, have delays in other projects held up the release of equipment that is needed for this project?
Is the problem because something is more complicated than anticipated? Does that mean that other products within this project, will also be more complicated?
Is this a one-off problem that affects only this part of the work? Or is the problem the first sign that that everything is going to take longer than expected. In other words, are the estimates understated throughout the whole of the project?
Were your assumptions correct? It’s quite normal for these to be tweaked as the project progresses. If assumptions need to be adjusted, do it now and update your plan. This may need to be agreed with senior management.
Is the cause of the problem something you can control or is it, by its very nature, outside of your control, such as higher than normal sickness levels due to particularly nasty bug that is circulating?
Is the activity on the Critical path? Delayed activities on the Critical path will delay your overall project schedule. If the activity is on the Critical path, you will need to take more extensive controlled action than if it has spent time (float) that can absolve some or all the delay
Is the activity on a path that is close to being critical? Activities on non-critical parts can have some delays before the pols become critical. The maximum delay for non-critical activities is called slack or float. If the activities float is very short, a small delay can cause that above to go critical
Has the work already been identified as involving risk? If so, have you got some management actions planned already and set down in your risk log. Such actions will normally take time and effort, and so the next thing to check is that such time and efforts have been built into your project schedule
Perhaps you set up a risk budget. If you are off track to due to risks that occurred, perhaps you should use that budget to get back on track
Have you already encountered problems with this activity? Unless new factors have arisen, the recurrent problem suggests that previous controlled actions are not proving adequate

Its’ Much Worse Than That Dave …

Okay, so thus far, I have covered aspects of taking ‘corrective action’ to grab reality by the scruff of the neck and bring it back into line with your project plan.

But let’s talk about a project crisis, shall we?

Something has happened either from within or outside of the project that has truly rocked the boat…

So, my next list of approaches (some to get the project spend back in control, others to redeem the project schedule – or both), may help in that regard:

Can you negotiate a reduction in project scope so that you can still meet important deadlines? Perhaps renegotiate the sequence of key deliverables to meet interim milestones?
Split your delivery project into two ‘phases’ or tranches. The first to deliver ‘must-have’ customer prioritized products/services, the second to deliver ‘should-have/could-have’ products services
Outsource key aspects of the project to a third party. They may have higher skills levels and get things done more swiftly; on the other hand, they may be cheaper/more expensive. Time/cost priority will dictate here
Hire in contractors to supplement the team to fast-track progress, or again, to use higher skills to speed up the schedule
The Project Approach. If you are designing one or all of your products ‘in-house’, investigate the option of buying some products ‘of-the-shelf’ – either as they are, or customizing them in some way. This is the “Make or Buy” approach and should be financially justified

Taking Corrective Action
If your project is behind in terms of schedule, then check out your Gantt chart and see if there are any tasks soon that have available float, in which case you could use that float to bring a project back on schedule.

In a similar way, available float may not be needed, and hence the opportunity arises to slow down the rate of costs. When considering your options for bringing the project back on track, include the following in your thinking:

Use contingency to absorb an overrun if you are out of float. You should have time, and sometimes cost, contingency in the plan to allow for problems – in which case use it!

Accept an overrun but ‘buy back’ some contingency. If the activity is something that you cannot put extra people on, you may have to just accept the overrun, as I’ve said, it is what the contingency was there for in the first place

However, if you are unhappy that it has taken up too much of your contingency for this point in the project, you may be able to buy back some contingency time by putting more staff on a later activity and so shortening its duration

Split the work. It may be that part of the work must be done now, and although it was preferable that the whole job was completed, in fact some of its can be done later in parallel with other activities

Shortening an activity, usually by putting more stuff onto its where that would be effective, is called crashing the schedule. It’s not a particularly good word because it sounds more like a disaster than a corrective action, but that’s what it’s called!

Deciding what you will do

Having considered a range of options for action, now is the time to make your mind up on what action or actions you are going to take. Your decision is likely to revolve around three factors:

What you think will be the most effective
What the cost is likely to be in terms of money and staff time
What the impact will be on other projects

To determine the last of these factors, your plan must be up to date. Project planning and control tools can help when looking at impacts, because you can do ‘what if’ projections using the tool.

Remember to save a baseline copy first before you start making changes.

This will also be helpful in comparing such changes against the original plan. It’s maybe that you need to run your actions passed your project board to get their approval before implementing.

Implementing Your Actions

Having reached a decision on what to do you must adjust your plans to include those actions and then adjust the work in line with the revised plans.

The implementation may involve talking with others in the project, including individual team members, to explain the problem, what you are doing about it and how it will affect their work.

This will have an added advantage in that your team will be committed to making your revised plan work.
Monitoring the effectiveness of your actions
In some cases, after the controlled action is put into effect, that is the end of the matter. But in many cases, you need to check that your actions are proving effective.

If the actions are working, then fine, but if not, you will need a look at why that is, see what the range of actions are now possible in the light of this new information, choose what to do (going through the above steps for a second time), then monitor again.

Improvement Opportunities

It occurred to me some time back, that in the cut-and-thrust of project management, once a project is underway – while the project manager is monitoring progress (or otherwise!) and controlling by taking action, their seems to be just two situations:

Managing Issues (these are situations that have already emerged or are about to). They need to be managed of course and you can use all the techniques that I discuss in our Project Disaster Recovery Part 1 and Part 2.

Managing risks. (these are situations that have yet to occur – they may or may not occur at some point in the future).

The Risk Twist

But the way our brains are wired, we, the human species are notoriously bad at managing risks.

Now, I do NOT intend to turn this into a risk management training, but in the spirit of project disaster recovery, there is a Lean Six Sigma technique that is particularly powerful when it comes to risk management …

Let me suppose, you have used all the advice and guidance I have given you thus far, and you are on your way to getting your project out of the quagmire.

Probably, the very reason you got into difficulties in the first place was mediocre project risk management.

I am sure you know all about how to estimate a risk’s severity (probability multiplied by its impact), and also how to use various different responses to manage and deal with the risk (such as Avoidance, Contingency, Mitigation, Transfer and so on…)

Considering Risk Proximity

This is what us humans are bad at managing!

Proximity defines how soon it can happen and how soon you will be hit by the impact. Broadly, there are THREE categories that you need to manage to get the full benefit of disaster recovery:

Immediate
Some risks always have a proximity of now and the impact will be immediate. They can happen at any time during the project with no notice at all. An easy example is with a team member going sick. They may walk up to you in 5 minutes time and say that they are feeling dreadful and needs to go home, or that could happen in five weeks’ time or in five months’ time.

Fixed date
Some risks are pegged to a point in time. The new rocket cannot fail to launch until it is time to launch it. The team cannot find a product is more complicated to build than they thought, and so will take longer, until they get to grips with the product as they start to build it.
For this category, note that the proximity will get shorter and shorter as you approach the date when the risk can occur.

Fixed Period
The impact of some risks will always be a fixed time ahead. Today the proximity is four weeks, that if the risk occurs in five months’ time, the proximity of the impact will be four weeks after that.

Consider the simple example of someone resigning from your organization and so leaving your project. If that person resigns today, they will leave in four weeks’ time, after they have worked their four-week notice period.
If they resigned in five months’ time, they will leave for weeks after that.

Which brings me to how you need to manage proximity.
The traditional way is to estimate such proximity for each risk and keep that updated in the project Risk Log. Fair Enough.

But that does not help with project disaster recovery – indeed, vital proximity information buried in the Risk Log may have contributed to your current crisis.

The Risk Proximity Frame

Whether recovering from a project disaster, or preventing it in the first place, there is a Lean Six Sigma tool that you will find irreplaceable – The Risk Proximity Frame.
It is a perfect example of an Information Radiator that keeps looming risks front-of-mind:

As you can see, it consists of a relevant time-line – I have just chosen 12 weeks in the above example. This could typically be the time-frame you would use in recovering from a project disaster.

You will want to use TWO different types of data to represent individual risks in terms of their severity and their proximity:

Use the circle diameter to represent each risk severity – small, medium and large. Include a risk reference number in each circle

Use the colour of each risk circle to denote its manageability from controllable, partly controllable and uncontrollable

Finally, place each circle on the time-frame. This time starts from today, and should be keep updated on a regular basis

Managing Risk in Disaster Recovery

I would recommend a daily review of the current risk situation. Be clear, what you are doing is implementing risk responses as usual, but noting on the Risk Proximity Frame, the results from these responses – in particular, those responses that are NOT having the desired effect.

This is key.

As a project manager skilled in disaster recovery, you will want to check and re-check that your recovery actions are steering the project back into a controllable situation.

Get your hands on Project Disaster Recovery – Part TWO, when you and I will take a detailed look at your Critical Thinking Skills!

Meanwhile, check out our Projex Academy extensive range of project management resources HERE!

Want to Pass Your PMP Exam?

find out how

PROJEX ACADEMY -- A Certified PRINCE2 Training Organization

Wordmarks -- PRINCE2®, PRINCE2 Agile®, MSP®, MoP®, P3O®, M_o_R®, MoV® and ITIL® are registered trademarks of AXELOS Limited. All rights reserved. PMP®, CAPM®, PMI-ACP® and PgMP® are registered marks of the Project Management Institute, Inc. PMI is a registered mark of the Project Management Institute, Inc. AgilePM®, AgileBA® and AgileDS™ are registered trademarks of Agile Business Consortium Limited. All rights reserved. APMG International Change Management, APMG International Finance for Non-Financial Managers, APMG International Managing Benefits, APMG International Project Planning & Control, APMG International Earned Value and APMG International PPS are trademarks of The APM Group Limited. All rights reserved. The Praxis Framework™ is a trademark of Praxis Framework Ltd. All rights reserved. CBAP® is a registered certification mark owned by International Institute of Business Analysis. IASSC Certified Lean Six Sigma Green Belt Exam™. IASSC Certified Lean Six Sigma Black Belt Exam™.