You’ve just gone through a robust procurement process and selected the vendor with the ICT solution that best meets your company’s present and future ICT needs. However, despite this well planned and common beginning, an alarming percentage of ICT programs (almost 70%) fail. So, with that in mind, here are 4 red flags to keep an eye out for (and some tips for managing them) that may help you avoid ending up in that 70%.
Red flag 1: You suspect a divergence between your ICT vendor’s salespeople and their delivery team
Sales people get commission on what they sell, not what gets delivered – sometimes the salesperson promises the death star and the delivery team can only build small moons. Does the ICT solution you’re being pitched sound a little too good to be true? This can be especially true of cloud based solutions that promise to be better, faster and cheaper.
What do you do?
There are ways of checking to see if the sales rhetoric matches the delivery capability – find out where a similar solution has been implemented elsewhere and go and have a look at it for yourself. This can be tricky because it involves approaching an organisation and asking to view their operations, but it’s worth it.
Red flag 2: Your company is the first cab off the rank for a new ICT solution / product
Companies generally avoid being the first to implement a brand-new piece of software because of teething problems. They wait until some other company has borne the pain of (inadvertently) assisting their vendor to improve the software. However, the much bigger issue with buying new software is gaining certainty that what you’re buying will do what you need it to do.
If you’re buying a car that hasn’t been built yet and the dealer gives you the specs, you will know whether that 5-seat hatchback (with a 500 litre boot, 15” alloys and 260kW of power) will meet your needs or not. If an ICT vendor gives you the specifications of a new ICT solution, unless you are very technical, it’s almost impossible to visualise what that will translate to in practice.
What do you do?
If you can maintain and extend the life of your legacy systems until there’s a tried and true alternative in the market, you might choose to wait. A vendor may, as an alternative to waiting, propose finishing off development of their new software (or re-developing an existing solution) with input from your business users to deliver a ‘guaranteed fit-for-purpose’ solution (but you should read about the next red flag before you commit). Sometimes, you will need to take a risk on a new solution – in these situations, having a strong contingency plan is crucial.
Red flag 3 – The vendor is proposing a solution be developed with your organisation’s input so it will be customised to perfectly meet your business needs
Generally speaking the development of software (involving coding, as opposed to configuration) is a time consuming and costly process that all too often blows out from a time and cost perspective in the context of ‘vendor developer’ and ‘customer contributor’. To put it simply, your team of ICT users want the best possible outcome from the software and feel that the more input and ideas they have for the end product, the more value they are adding – wrong. Between your team throwing as many ideas at the vendors as possible and the development team scrambling to make them all happen (not wanting to say no to the customer) you’ve ended up in the NeverEnding story.
What do you do?
If you must venture into Fantasia, select a (very) small team of contributors from your business and set stringent parameters with them and the development team at the outset. This should include an agreed set of core business requirements that your team will oversee but not deviate from, unless signed off by the program manager. It is also wise to establish independent gateway reviews at critical stages of the program.
Red flag 4: The vendor doesn’t want to engage an independent gateway reviewer
No matter how well a program is planned, set-up and run, or how good the teams involved are, problems can and usually do occur. A good gateway reviewer will identify potential issues early and give you recommendations to deal with them before they derail your program. Too often problems go unnoticed or un-reported because they are not recognised as problems, especially by those within (and close to) the program. A gateway reviewer comes with fresh eyes and no agenda.
What do you do?
Insist on it, and early on. If a vendor wants your business, they will deliver within a robust governance framework that includes independent gateway reviews. Keep in mind that you don’t need to have a gateway reviewer from the beginning or for every gateway. If you are sensing something may not be right, you can arrange for a one-off gateway review to be done to check the health of your program.
