There is a long history of change programmes dependent on IT failing. At the very least they usually carry a high level of risk! But you can avoid the pit-falls. This series of posts is based loosely around the UK Government’s “Common Causes of Project Failure” (NAO/OGC) but the interpretation is mine. Here is the next post in the series, (For reasons 1 to 3 follow the link; For reasons 4 to 6 follow the link)
Options are evaluated by price rather than long term value for money
In deciding what supplier to use it is always tempting to go for the cheapest. But you need to think about all the real costs associated with buying and running a system through out its life. It’s important think about on-going maintenance and service as well as the initial investment. What is going to be the cost of training your existing staff and those who join later? Will the system be backed up with right kind of support and is the supplier going to stay in business? How much are you going to need to invest in the future to keep up to date with your business needs and the market? Will the “cheapest” option deliver the quality and security your business needs? Have you balanced the criticality of your business against affordability? At the end of the day, is your approach to evaluating your options really driven by the long-term needs of your business?
Lack of understanding of the supply industry at senior level
What you think you want and what the IT industry can supply might be quite different. What you want may not be achievable technically or only by carrying a huge burden of risk. Check out the state of the market and what is out there before you begin a formal procurement exercise – there are lost of people in the IT industry who are prepared to advise you but do check out the track record of your advisers. Beware of having something developed specially to meet your needs it is full of pitfalls – don’t be “bleeding edge” when with a bit of care you can be leading edge, safely. Go for something that while market-leading is still tried and tested – the alternative can be not only risky but very, very costly! Those who come after will benefit from the money you have spent, but probably not you! And developing something tailored made, in detail, for you may lead you to have your business wholly dependent long-term on one supplier. You will probably need to compromise to some extent and adjust your requirement to what is out there already but that may pay dividends – almost literally! Having said go for tried and tested, you will not want to buy something that is about the overtaken/redundant and not likely to be supported long-term – so you really do need to do your homework and make sure senior managers understand their real options.
Lack of integration between client and supplier project and programme teams and the supply chain
Once the procurement decision has been made, the closer you can get to your supplier the better in IT! You need to understand just what is going on! Is he finding it easy or hard to meet your requirement? If it’s hard, why is it hard and what is he doing about it? Is there continuity in the supplier team – are all those people who impressed you in the procurement exercise still around? You need to understand his strategy and he needs to understand yours, as well as the culture of your respective organizations. A good relationship makes it much more likely that the project will be a success but don’t become complacent – you still need to test, test and test again the product that is being produced – don’t take a chance and let testing slip! As well as that, It’s important to understand what the supplier thinks the risks are and a shared risk log has merit for both sides.
Lack of effective quality assurance
You want to know that projects in your programme will be delivered to time, cost and the right quality. At the beginning of your programme decide how you are going to measure them. Make sure there are time, cost and quality review plans. If you don’t know how to prepare them again there is lots of advice out there but again make sure your advisers have a good track record. Plan the quality reviews at key milestones and bring in people from outside the programme and project teams to do the reviews/ Again make sure they are competent and have experience of undertaking these kind of reviews. Make sure they are sufficiently senior for your board to take them seriously and will be prepared to accept bad news from them if necessary. Then make sure their findings are properly understood and acted upon. If you can, bring the same reviewers in across the life of a project or programme – that way they can give you real assurance about the progress made.
I have set out here what I regard as the 10 most likely reasons why programmes dependent on IT fail. There is evidence to support my view from the collective experience of the UK public sector -“Common Causes of Project Failure” (NAO/OGC). But I would love to hear what you think about this – do you agree or disagree and do you have examples to quote please. If so, I will be very happy to turn your comments into posts!