[By Kevin Phillips]
There are two good reasons to avoid any software implementation process that will take more than two to (at most) six months. The first is cost: IT consultants don’t come cheap, and the business case for your fancy new software can start looking shaky very quickly once you add in all the hidden costs.
The second reason is even more compelling: the world changes fast. You buy software now, to help you meet current challenges. In two years’ time those challenges might be very different. If it takes two years to implement the software, you may find yourself at the end of those two years with a beautiful, expensive solution to problems you 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 you 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 you know it you’re three years in with no end in sight.
The first lesson, then, is to specify your requirements very, very carefully. This sounds obvious but it’s rarely done. I’ve 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 black empowerment 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 you 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 you want is a budgeting system, but if you don’t ask up front it will cost extra later.
It is, in fact, not possible to over-specify a software system. You may not get everything you ask for, but at least you’ll have a good basis for deciding which vendors are most likely to supply what’s most important. If you haven’t got your spec right, you can’t blame the vendor if you don’t get what you need.
Once you’ve constructed your careful spec, 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 you can take that as a fairly strong sign that they’re expecting scope creep — or possibly don’t know the product as well as you’d like them to.
Of course if the project requirements do change you should expect the vendor to re-quote — and again, if those requirements were made clear at the start you have an easy way to agree when they’ve changed.
If you can provide clear requirements, and find a vendor who will meet those requirements on a fixed-fee basis, you will very likely enjoy a fast, hassle-free implementation. That means, in turn, you can actually reap the benefits of your new software while it’s still relevant to your business. As the old saying goes, the only constant in life is change. So meet today’s needs today.
- Kevin Phillips is MD of idu Software
- Subscribe to our free daily newsletter
- Follow us on Twitter or on Facebook