You could spend millions of dollars and a year of your life buying and implementing an IT system. Scott Williams,of Investit MENA, offers advice that could reduce the effort.
IT purchases are major decisions that will shape a business for years to come. A client is retiring a banking system that has been stretched to support investment management as far as the IT and operations team can take it. That system has been in place for 25 years. Once the budget for a system has been spent, it will be a brave chief technology officer (CTO) who goes back for another go.
Occasionally, however, it does happen. At one firm, we saw a recently implemented investment management system that met the business requirements perfectly, ripped out by the CTO. It was replaced by the CTO’s favourite, which had broadly similar functionality. The survivors at this traumatised firm point to the massive cost and disruption of this decision as a major cause of the firm’s decline.
Purchase and implementation might cost upwards of $3 million and involve a year or more of effort. And yet the approach to buying software ranges from the absurdly bureaucratic to the simply slap-dash. On more than one occasion, we have been asked to write the business requirements document for a system that had already been bought.
We characterise this as: fire, ready, aim.
No time wasting
Software houses are pretty good at working out business opportunities, but buyers should be careful they don’t buy on the basis of a demonstration that vendors chose to give them. However, this does not mean that buyers need to waste their own and vendors’ time sending requests for proposals (RFP) thousands of lines long to a large list of merchants.
Consider this list as one route between these extremes that leads to a well-structured and defensible decision:
• Universe awareness
• Requirements gathering
• Request for information (RFI) and short-list delivery
• Vendor/client meetings
• Structured demonstrations
• RFP, gap analysis and selection
• Contract agreement and work planning.
Conventional practice is to create a large RFP, send it out to many firms and start to score it. But this takes a lot of time – and money if it is contracted out.
Ten years ago, we were asked to create an approach that is less long-winded and buys to meet the actual need. We use an early investigation of the main business requirements to highlight the ones which are most important to the buyer and which differentiate the firm.
In this way, buyers looking to cut out the “super RF” stage can use a stage-and-gate process, supported by a shorter RFI that tests whether the providers’ products and services meet key requirements. We have found that typically eight to twelve questions are enough to define the shortlist.
For firms with a particular need to demonstrate an auditable process for procurement, this is valuable evidence of good governance – and allows you to explain clearly to the deselected vendors why they are not still in the running.
Having developed the shortlist, your meetings or calls are with vendors who know they are being seriously considered and not just invited to join in a rather unstructured discovery session. And you have not had to mark a lot of RFPs, nor ask the vendors to write one.
In this adult-to-adult relationship it is now possible to explain the basis for selection and that the demonstration that you want is not the vendor’s usual spiel. What you want is live evidence that the system can do what you want it to do.
At this stage, we create a test script that the remaining vendors will all work to. Again, this helps you show that all vendors were considered against the same criteria.
Now you can send out an RFP informed by the key requirements. The vendors can fill that out and create the demonstration with a good understanding of what you want.
Following the script
Each shortlisted vendor is then asked to visit and demonstrate their system. A structured demonstration script should be constructed to cover the working requirements of different sets of business users. These will state clearly what parts of the system are to be demonstrated, and what aspects have to be emphasized, such as flexibility, useful default settings, or speed.
The demonstrations will usually take the format of a number of working scenarios, to show how the system actually works in practice.
The system is being bought to deliver a business outcome. It is very important that the business has been kept involved from initial requirements through to checking that what they are about to be shown is what they actually care about. IT might be running the project; the business should be assessing the functionality. The business representatives should attend all the demontration sessions and all use the same marking system. We suggest a separate session for the vendor with IT to address technical and non-functional aspects.
The RFPs will come back and their scores can be matched with those from the demonstrations.
In the final phase, we complete the due diligence process with the selected vendor and design the implementation project.
A project plan, the full statement of work with estimates of vendor time, and a set of deliverables from the implementation project are combined with the commercial and legal schedules to form the formal contract for the system.
Ten years of lessons in two pages. If you are heading off down the systems selection path, we hope you enjoy the journey with a good clear map.
Scott Williams is senior consultant at Investit MENA, based in Dubai
©2012 funds global