Making it compute - top tips for starting a successful IT system procurement project
When procuring a new IT system, much of your success and avoidance of problems arising later on, will depend on how you approach the early days of the project - the tips below should help you to navigate those challenges.
When procuring a new IT system such as an MIS or ERP system, you are putting a lot of trust, and to an extent your school or trust's reputation, in the hands of the provider. It can be a major step, and ties the school into a long-term relationship that is not easily migrated to another provider if things go wrong. The process for implementing a significant new system can often be a lengthy and onerous one. This article shares some key tips and considerations.
Sales and due diligence
Providers often market their outstanding system functionality, ISO certifications, security and robustness as part of the sales process, eg on their web-site or in marketing materials or presentations. But, when it comes to answering detailed questions in a diligence questionnaire and ultimately negotiating contract terms, all too often these eye-catching features go missing. In the diligence process, make sure the claims made as part of the sales process are backed up with consistent and detailed responses from the provider. Most importantly, make sure that those claims make it into contractual terms as warranties, service level commitments, standards and detailed and clear specifications. Make sure the people doing the due diligence for the school also coordinate with those responsible for negotiating the contractual terms. This will ensure consistency and make sure important standards and performance commitments do not fall between the gaps.
The power of visual aids
During the DD process ask for a system architecture diagram or blue-print. This is especially important if procuring a more complicated system (rather than a single application). It can help all stakeholders understand how the IT system being procured is comprised and fits together, and how it will integrate with the school's and potentially third-party systems. This visual is a useful aid to understanding, and helps avoid different stakeholders starting off with varying assumptions about what is being procured. Most providers will be willing to provide such a visual provided the specification and requirements are sufficiently clear from the outset of the project.
Testing
There is often a testing phase early on in the project. Comprehensive testing can help avoid problems manifesting later in the project. It becomes more difficult to remedy issues that may have become baked into the system at a foundational stage. There is real benefit in testing comprehensively and early on. If more than one provider is involved in the project, also consider requiring the parties to collaborate in early testing, including via a sand-box environment where providers can coordinate, compare methodologies, trial various applications, including APIs if necessary, and jointly understand where more difficult aspects of integration and configuration may need careful planning across the project and within the technical teams working on it.
The product and the technical team standing behind it
The software provider's technical team that works with the software, every day, is the engine of a successful system. The platform engineers, security technicians and system managers are the ones who know where the system's strengths and inevitable weaknesses lie. They are the ones responsible for sorting out problems, crashes, updates, interruptions and service level failures. Make sure you have an early understanding or chart illustrating who's who, where people are located, what their experience is and who will be assigned to your project, both in the development and implementation phases and following go-live over the long-term. Build the relationships as much as possible between technical teams.
So many problems can be avoided, and resolved without the need to reach for the contract, where there are close and positive working relationships between technical teams. Ask:
- Can you meet the technical team early in the due diligence process?
- What are their qualifications and relevant experience?
- Are they willing to take you on a tour of their data centre?
- Will there be key personnel assigned to you for the whole project, and will they remain involved after go-live?
Clarity of contractual structure
It is common for an early set of terms and conditions or licence to be shared at about the same time as due diligence is being undertaken. Consider this carefully and raise questions about it early on, as it may only present a partial picture of the contractual arrangements - or may indeed be an outdated or flat-out wrong document (unfortunately an all too familiar occurrence). When the customer realises this, time may have gone by, the procurement process advanced, and there is suddenly huge pressure to enter the agreement, and rush it, to the disadvantage of the school customer.
As soon as the terms are available (if shared by a provider), sense check if the document make sense in context of the project, is it complete, does it refer to other policies or terms not provided, is it up to date, does it address data protection where relevant, does it present clear SLAs, does it fit together if there are multiple documents forming one agreement? These are the sorts of questions that should be asked early on. If the documentation is unclear, out of date or inconsistent, it should be for the provider (at their time and expense) to remedy these issues.
As the old saying goes "Best begin with the end in mind".