There are two good reasons to avoid any software implementation process that will take more than two to (at most) six months, writes Kevin Phillips, MD of idu Software. The first is cost: IT consultants don’t come cheap, and the business case for fancy new software can start looking shaky very quickly once all the hidden costs are added in.
The second reason is even more compelling: the world changes fast. Users buy software now to help them meet current challenges. In two years’ time, those challenges might be very different. If it takes two years to implement the software, users may find themselves at the end of those two years with a beautiful, expensive solution to problems they no longer have.
But here’s the conundrum: no software vendor will ever admit up front that it’s going to take a year to implement the software. They’ll promise a month or two – and then the changes and extras will start to add up. If it’s not in the original spec, it will go into phase two or three, and before businesses know it they’re three years in with no end in sight.
The first lesson, then, is to specify requirements very carefully. This sounds obvious but it’s rarely done. Phillips has seen requests for information (RFIs) in which the actual requirements for the system consist of half a page of bullet points, bulked out by many pages of questions about the vendor’s BEE status.
That kind of RFI is pretty much guaranteed to attract the sort of vendor who will cheerfully spend the next six years consulting to the company at inflated rates.
The converse is the RFI that makes the vendor groan, but will actually get the client what they want: a full list of requirements that covers absolutely everything, right down to stuff that seems peripheral right now.
For example, an RFI might ask whether the software forces users to have secure passwords of a minimum length. It doesn’t seem that important if all users want is a budgeting system, but if they don’t ask up front, it will cost extra later.
It is, in fact, not possible to over-specify a software system. Companies may not get everything they ask for, but at least they’ll have a good basis for deciding which vendors are most likely to supply what’s most important. If users haven’t got their spec right, they can’t blame the vendor if they don’t get what they need.
Once a careful spec has been constructed, there’s another step to securing the right product and a quick implementation: get the consultant to commit to a fixed fee for the project. There’s nothing to focus a vendor’s mind like a profit margin that shrinks with every extra hour they spend.
Conversely, if the consultant isn’t prepared to commit to a fixed price, users can take that as a fairly strong sign that they’re expecting scope creep – or possibly don’t know the product as well as they’d like them to.
Of course, if the project requirements do change, organisations should expect the vendor to re-quote – and again, if those requirements were made clear at the start, there is an easy way to agree when they’ve changed.
If users can provide clear requirements, and find a vendor who will meet those requirements on a fixed-fee basis, they will very likely enjoy a fast, hassle-free implementation. That means, in turn, that users can actually reap the benefits of the new software while it’s still relevant to the business. As the old saying goes, the only constant in life is change: so meet today’s needs today.