When selecting a new system you need to apply no less due diligence than you would were you acquiring
another company. Your due diligence needs to cover (a) the software (b) the company delivering it, (c) it's
fit to your business and, never to be overlooked (d) the consultants implementing it.
You have to objectively consider your own resources balanced with the skills of the vendor to be able to deliver an application which meets your needs. In order to do this effectively you have to have a clear compelling reason as to why you're changing systems.
This reason, or group of reasons, can provide you with a high level scoring system to measure prospective solutions and their ability to meet your key requirements. In addition to being the cornerstone of your business case, these reasons are the starting point for the RFI which you will circulate to vendors. They will outline the scope of the project and give it its overall direction.
Throughout the project you need to check these reasons to make sure they are still valid, i.e. is there still a business case to support the project.
New IT System?
Your business won't stop while you select and implement a new system. The project will be in addition to your day job, and this will be one of the key challenges faced during a system change. The need to keep the momentum of the project, the need for objective quality control over development or process change, the need to deliver to budget and without surprise, the need to manage the project team, frequently around their jobs, these and more are all constraints affecting the successful outcome of a new system project.
Companies do get it wrong
Companies do get it wrong. Car rental firm Avis binned their new £30m ERP system citing substantial delays, higher costs and fundamental problems with product design and implementation. Their share price crashed 20% when they broke the news to the City. Having spent an estimated $200m on trying to get their new Oracle purchasing system to work Ford finaly gave up and returned to their legacy system.
The NHS programme to enable electronic patient records is already predicted to be over two years late. Lord Warner, the health minister, had to clarify why costs will be closer to £20.0bn rather than the quoted figure of £6.2bn. That's just one example, in fact a massive 70% of all IT projects in the Public Sector end in failure.
Sainsburys sunk £3bn into supply-chain and IT improvements which left stock in warehouses rather than on shelves. They took a charge of £550m and had investment banks put a sell tag on their stock. Hewlett Packard lost an estimated $160m with problems migrating to a new ERP system, more than five times the actual cost of implementation.
The Chaos Chronicles
That landmark survey from way back in the 90's known as the Chaos Report, by the Standish Group, into IT project failure can, but shouldn't, make for gloomy reading.
In the updated research contained in the "the Chaos Chronicles", polled almost ten years later, management, it seems, has improved. The project success ratio is now one in three compared with one in five achieved a decade earlier. This is still a pretty poor statistic, and is not much better than the public sector, i.e. there is a 66% chance your system project will run over time and over budget .
With numbers like these what can you do to even the odds? What makes the one in three successful?
The planning stage is key
The planning stage along with your due dilligence are key to the project and cannot be underestimated. Key risks can include data and people which you need to consider objectively. Not having your data ready for migration is a surprisingly very common reason for project delays, as is overestimating internal resources and skills available.
Inspired Notes
Resources