Project Recovery Management in its simplest form is focusing the minds of the constituent parts of a project team to get things back on track and ensure successful delivery. One thing that I have always focused on is the core deliverable or the end game and how to get there in the most efficient way possible. Getting there is all about the core principles of project management; scope, time and cost. It shouldn't be more complicated, but it can be and so often is.

Having been dropped into a Project Recovery Management position with a major global banking group, I'm in a good position to explain how that failing project can be brought back in line. I mentioned the three key principles of project management, a Project Recovery Manager needs to focus on all of these principles and a new one that’s a huge factor but often forgotten or ignored.

  • Scope definition is the key to everything, what I am being asked to recover what is this project delivering
  • What the time frames are I am working with and are they realistic
  • The cost impact and exposure of recovering this project
  • The 4th key principle – People

Scope -

If you can pin that down in the first few hours of Project Recovery Management you’re off to a winner. It sounds easy, but scope can change and will creep without the project manager or delivery board knowing what’s changed or why. Define the deliverable and get the right people to sign up to it, get senior buy in straight away and don’t be afraid to push back and remove the scope creep elements. Warn the stakeholders that the core deliverable is at risk if non-core elements remain. We all know that ‘no’ is never the correct answer in project management, so the scope creep is still achievable but perhaps in slower time. Get the key components delivered then pick up the rest. So what did I do in the UK bank? I talked to the project manager, programme manager, key business stakeholders and the testing teams. I devised a plan that created a test environment in 10 days that would be robust enough to cover the key elements that everyone had agreed to. This didn’t cover all components that needed testing, but by undertaking a Pareto analysis I had a plan to deliver the top elements and a slower time plan for the remainder. Scope definition and an ability to see the ‘wood for the trees’ is key here.

Time -

What time frames am I working with and are they realistic. My experience so far is that there is never enough time at the outset. If you can undertake the scope definition, it’s much easier to fit that into the time frame given or be able to objectively say that there is not enough time to deliver everything that’s required. Is 10 days enough time to deliver a robust testing environment? No its not, but by undertaking the scope analysis a test environment suitable for both the time frame and the defined list of deliverables was created. Be honest with time don’t promise the world can be delivered in two hours and don’t ask for contingency where it’s not needed. Analyse quickly and commit to time frames with confidence.

Cost -

Working with the existing project team to define scope and time frames then leads into what is achievable within the current budget. That test environment had always been planned for but lining it up in the space of 10 days throws in added cost and risk that hadn’t been accounted for. Building a test environment and all its component parts is no easy task and some elements are just too expensive or time constrained to deliver to produce the required outcome. This gives a great opportunity to see what else is available. Can I utilise a different environment at lesser cost but will I be compromising my testing. Is there an opportunity to utilise other tools like Service Virtualisation. Bring the options together quickly and define what’s achievable in the budget.

So that’s scope, time and budget covered. It goes without saying that the decisions made here should always be weighed against the required level of quality, there is no point being able to turn a project around that will be forever in defect resolution or forward fix mode. In my next blog I will explore the 4th factor of Project Recovery Management.

Do you need some assistance with your Project Recovery Management? Contact us today.