Three top tipsAugust 2014
JONO TOWNSEND and DR SUE BARNETT offer schools some sound advice for technology procurement.
We all know that high budget, complex IT purchases require more than a couple of clicks on Google’s top links and checking a few user-posted reviews to make a decision. With expensive projects, the stakes are higher, the impact on the organisation is greater, the results – good or bad – are more noticeable, and it will be in use for years to come. No one wants to be responsible for spending large slices of budget with precious few results to show for it.
But in a potentially confusing world where a phrase containing the words host, server, cookie, GUI (pronounced gooey), Java, and byte aren’t referring to a trip to the local café, where do you start to get an IT project delivered well with low risk? There are a few fundamentals that can make or break a project, and in turn, the person responsible for it. Our work responding to and helping to write tenders for a range of websites, online tools, and cloud solutions has shown us the best and the worst out there. Here are our top tips to get you on the right track for a solid project.
Top tip 1: Use the common formats of RFI or RFP to clearly detail the outcomes you want.
RFI (Request for Information) is where an organisation seeks to understand more from vendors about a range of potential solutions available. This process typically rolls into an RFP process once complete. An RFP (Request for Proposal) is a process where an organisation is seeking proposals (normally with quotes) to deliver a solution to meet a specific set of criteria or to understand how vendors would approach achieving a specific outcome (RFQ, Request for Quote, a tighter set of criteria for vendors to cost, is also used, though less so).
The request documents are prescriptive in the format of responses expected and aim to treat all vendors without favouritism or unfairness. The documents typically contain: an introduction to the requesting organisation and any relevant background information; a timeline of the RFI/RFP process and when due dates fall; legal disclaimers; questions for the supplier to demonstrate experience and suitability; assessment criteria; and then a large, numbered list of detailed, solution-centric requirements and outcomes.
At first glance, writing a large, detailed requirements document might seem verbose, and even feel like you are patronising the reader. What is the reason for the recording of such seemingly obvious detail? It’s because assumption is the enemy. On topics of even low complexity, assumption starts innocently but can be fatal. Loose requirements will be interpreted differently by each vendor and any proposals sent back will not be comparable with other responses, rendering an ‘apples with apples’ assessment impossible. Further, a loose set of requirements often leads to a lowest common denominator approach, where competitive pressure causes vendors to assume the bare minimum requirements to provide a cheaper quote or include broad limitation of liability statements – a ‘we’ll charge more if this costs us more’ approach. It is genuinely better for everyone if buyers do some detailed research up front and get a decent set of requirements together to guide the process.
Top tip 2: Understand (at least the fundamentals) of what you are seeking to buy.
We IT types are proud of our craft and how we can understand complex things. Although we won’t admit it, we also tend to feel rather important when we use terms and concepts that others don’t fully understand (refer to the café visit example earlier). Not wanting to sound like the only person in the conversation who is unsure what the latest jargon means, many clients don’t halt the proceedings to ask for a simple explanation. But to buy well, you must. If an IT provider cannot give you the why and fundamental workings of a solution in a way you can grasp, they are not doing their job.
Understanding is needed when deciding who to distribute the request document to. A closed tender (a finite list of those you invite to bid for the work) requires that you know a range of companies well positioned to deliver the right solution, whereas an open tender allows anyone in the market to bid on the project (sometimes distributed through the newly re-launched GETS, the Government Electronic Tenders Service). Vendors will ask questions to clarify the request document (these questions are typically shared, along with answers, to all vendors to keep things fair) and you will need to be able to get answers back fairly quickly. Fight for this fundamental understanding and don’t let jargon or complexity get in the way to remain in control of decisions and the projects. Of course, when in doubt on the detail, Google it.
To write the document that defines in detail the criteria for a solution, more than a fundamental understanding of the subject matter is required. There are cases when it makes sense to hire a business analyst (BA) to create this document for you. A BA will gather requirements through consultation with your team, and having considered a great many things, will collect these in a nice, neat document that can be sent to vendors. An experienced BA will give confidence and shoulder some of the burden, but may charge heavily if a large amount of time is required to get to know your organisation. Another option is to use RFP templates (a large range of Word documents to start from are available from a quick Google search).
Top tip 3: Be realistic and think long term.
We all want projects to be completed quickly. But it is not typically the buyer that causes the delay. On the basis that most responses will be roughly the same number of pages as the request, sending out a 100-page document that is responded to by 100 proposers will result in 10,000 pages of night time reading for the buyer! This will take much more than a week to properly read through (as many request timelines we have seen imply). Similarly, budgets, if stated, need to be realistic to get serious attention from the experienced vendors in a market.
Expensive IT projects are inherently long term. They take a long time to deliver and should have a fairly long use life to justify the spending. Be sure to get pricing that covers upfront build costs and all other operating and support costs for the next five years to run the solution. With an eye on the future, solutions must be extensible to support future needs not yet known. In an increasingly automated and connected world, solutions need to be able to integrate (via an API or other connectors), passing or retrieving information from other systems in an organisation without manual downloading and uploading. We also strongly recommend vendors look for options with multiple strong providers, as opposed to a proprietary solution offered only by one or two vendors. We have seen too often a client tied to a solution that is no longer supported after the provider goes out of business. Ouch.
Well-delivered IT projects have the power to bring great progress and benefit to an organisation. The right vendors responding to considered requirements will result in the best proposals and ultimately, the best solution delivered.