A telling case study of a project that went wrong.

Picked up a very honest review of a project that went wrong on Tech Republic's blog.

What struck me immediately was the honesty of the piece. Outside of the public sector most projects in difficulty are carefully shielded from public eyes. The dirt is swept under the carpet and the furniture rearranged to make it look like nothing untoward happened. This is understandable but of no use to anyone else out there trying to enact a similar project. Failing Data Migration projects are all too common but the lack of information about them makes it seem like a unique experience to everyone involved. It seems like only us are failing not everyone else.

Without wanting to steal Benny Sisko’s thunder (read the article, it is extremely insightful) the issues he talks about are all too common. The level of Data Quality issues are underestimated and too many come out too late in the time line; the bandwidth of the business to cope with the sudden demand placed upon them has not been factored into the plan; support from the supplier is patchy.

All these are common. It’s easy for me (and probably no comfort to Benny) to say that PDM would have alerted him to these earlier when he could have done something about it:

  • Performing a rigorous Landscape Analysis phase before settling on the final time lined and budgeted plan would have alerted him to the scale of Data Quality challenges
  • Setting up the DQR process and Gap Analysis to find, prioritise and manage Data Quality issues would have given him an earlier heads up on the scale of the problems and the ability of the business side to cope
  • Establishing the DMZ early and reflecting it in the contract would have helped both the supplier and the client

However what his tale illustrates is that having an honest and mature relationship with his business colleagues enabled him to understand their pain early enough and to respond with a courageous decision to pull the project before it was too late. Despite the apparent failures he, the business and the project team are to get a second crack at it albeit wiser and sadder. So in the end the project will be a success. And when the new system is bedded in and providing the benefits it promised some of the pain will be forgotten.

This brings me onto a further point, one that I often make during my training courses. Teams bond better under pressure. On the surface this is counter intuitive. Surely as times get hard there is a falling away? But no, all our experience is that when times get tough teams bind closer to face a common adversary. Provided that is, that they were a team in the first place. So I’d say the take away is - build the team across the business and the technical staff so that even if all else fails there is still the will to make it happen. Where there’s a will there is often a way.

In the end this project will be successful I am sure, which is all that matters (like - we could have done without the pain and expense along the way but heck).

Of course it would be better if we get there first time every time. And for that you have PDM.

Johny Morris

About the author

John Morris has over 20 years experience in IT as a programmer, business analyst, project manager and data architect. He has spent the last 10 years working exclusively on data migration and system integration projects. John is the author of Practical Data Migration.