Tuesday, March 20, 2012

What should I do if my database project is failing?

Boot fail 

There may be times when your database or CRM implementation (or other projects) may be failing. Or apperar to be failing. In one way or another. In which case, other than obey the first rule of Douglas Adams, what should you do?
  • The first thing you should do is ask, What do you mean by failing? Based on what? And who says it is failing? Is it really failing, really out of control, or is it, for example, just a bit behind schedule at the moment but in reality should pick-up fine next month? Do consider carefully if you have proper targets/metrics which say it is definitely failing – if so, then the rest of this post might help. If not, then consider and discuss more why someone thinks it is failing – it may be that it is not as bad as you or they think and/or that it is not being considered in quite the right way...
  • However, if the project is failing then you need to pause and review it. i.e. which means, probably interviewing all the relevant parties involved with the project, plus reviewing the business case/PID, the project structure, targets, constraints and anything else similarly relevant. And use an “outsider” to do this review, whether it is someone from within your organisation but not involved with your project or an external person/consultant or maybe even a trustee.

    This will mean you can understand what is really happening, what has happened which has meant you are where you are now and hopefully why it has happened; and it will start to mean you can work out what you need to do and change to resolve the failure and hopefully turn the project around. Thus, it will show you not just the analysable, financial status of the project but the possibly more subjective but no less important “cultural status” or “people problems” too.
  • Depending on what comes out of that review, you will have different options. Is the original business case, the interpretation of which might mean that the project is now failing, no longer viable or up-to-date? Do you need to go through the correct steps of reviewing/adjusting that? And if so, with what implications? Do you need to change a significant aspect of the project: Resource(s) in the project team – either changing them or supplementing them? The scope – maybe scaling it back? The timeline or expected benefits – re-targeting the project?

    Or is it a good idea to review how to move the project on in terms of ‘breaking it down’ into different parts – smaller chunks with smaller goals, scope and budget? Or…
  • Or, do you need to consider if you really should can the project now? Is it really beyond repair? And if so, is that necessarily a bad thing?! Maybe your revised requirements or the original business case have changed so much that this really makes sense. Or do you just need to stop, either completely and recognise and accept the project is no longer viable, or alternatively, maybe start again with a similar but new project, implementing the lessons learned from the failed one so that you can do it right this time.

    But do also consider: if you do stop now then what is the cost - the real cost? There are not just the sunken costs you have already spent + the commitments you have to make; but ideally you should also add in what the additional expected income was to be if you did finish the project or the savings you planned to get. And compare that total cost to the (possibly new) cost if you did continue. And also, is there any "cost" of lost reputation internally or externally if you stop the project now? Is that acceptable or worse than stopping?
  • And if you are using a third-party supplier, which is especially likely in a database implementation, don't immediately just blame the supplier! It may be just as likely (more likely?!) that there are issues with any of the above points I have listed or with your own staff or processes. That said, it may of course be that the supplier really is at fault, in which case you do need to consider what you should do. Can the supplier change enough for your needs? Or do you need to change supplier? What can you rescue from the project which can be re-used either with the same or a different supplier? How can all the above listed ideas and issues be discussed and adjusted with the supplier?
I have been brought in to manage a project where I have indeed recommended we stop there and then. But I have also been with projects where it appeared to be failing but where, with a few changes, we did turn it around and it was successful. And that can be as great an achievement as anything else.

No comments: