1. Which solution type: On-premise or Cloud-based?
Deciding which solution you want to buy at the outset is important. On-premise and cloud-based solutions are very different, certainly in the architecture involved as well as the commercial wrap and contractual terms that surround them.
We find that where clients focus on only one of these solutions, rather than requesting tenders for both solutions and leaving it to the evaluation methodology to decide, yields better results.
2. Which procurement procedure?
The procurement procedure you choose will depend on a number of factors including: timescales, resources, access to legal and procurement support, whether a suitable framework can be identified, the extent to which you are able to specify your requirements at the outset, and whether you want the opportunity to discuss the project with the bidders during the procurement. See our page here that addresses these issues in more detail.
Whichever procurement procedure you choose, flushing out bidder issues as part of the procurement and planning phase, so that they can be anticipated and addressed during the procurement, will be particularly important. This can be achieved in a number of ways:
- conducting pre-market testing to improve your understanding of the market, the products available, and what the market can tolerate;
- invite bidders to comment on the contract during the tender period;
- holding clarification meetings during the procurement;
- addressing key contractual issues through dialogue or negotiation, where permitted by the procurement procedure.
3. Contract Structure
Adopting your preferred contract structure should be considered at the outset. There are various options, including:
- prime (SaaS) with sub-contractor (Implementation);
- prime (Implementation) with sub-contractor (SaaS);
- separate contracts for SaaS and Implementation; or
- separate contracts for best of breed across applications.
Taking soundings from the market pre-procurement is one of the best ways to gauge how the market will receive any of the above. Most commonly, we find that the third option of two separate contracts is used, potentially with a collaboration agreement overlaying the two contracts.
4. Implementation Approach
The public sector is still fairly wedded to the traditional waterfall approach, whereby Milestones, Deliverables, Acceptance Criteria and Milestone Dates for the entire implementation project are agreed in advance and hard coded into the contract documents, primarily to benefit from a fixed price. However, agile development and delivery has been around in the technology sector for a while, and may be more suited where requirements are uncertain at the outset. A key feature of agile delivery is its iterative nature, with short development/delivery cycles (or sprints). It allows changes to requirements to be accommodated throughout the implementation phase. An agile delivery usually requires more input from the customer.
5. Contract ‘redlines’
Your organisation should consider its ‘redlines’ or ‘must haves’ at an early stage. However, these positions should always be considered in light of the services you are procuring and the availability of products in the market – simply rolling out your standard or template positions is unlikely to yield the best result. For example, if you wish to have a system that is only hosted in the UK, that is likely to arrow the availability of SaaS products and/or level of service as some ERP providers provide 24 support by having support centres in different time zones across the world. It is important when identifying your redlines to ensure they are genuine and realistic.
This article is for general awareness only and does not constitute legal or professional advice. The law may have changed since this page was first published. If you would like further advice and assistance in relation to any of the issues raised in this [article][blog], please contact us today by telephone or email email@example.com.