IT

Tender care

Choosing the right software has never been simple. Paul Sypko provides a checklist to help schools select the right financial management package

There was a time when IT systems tended to work in isolation and the decision to buy management software could be narrowed down to a specific set of requirements within the admin department.

However, modern software is quite different. Gone are the days of using a stand-alone DOS-based finance package where you could back up the school’s vital data to a handful of floppy disks. Now, the IT press is littered with words such as “collaboration”, “interoperability” and “workflow”. Suppliers are launching new “.NET” and web-enabled versions of their software, built around high-performance database packages which are designed to function seamlessly with each other – or at least, that’s the idea.

Variety of needs
The school’s financial management software is no longer something that only affects the school bursar. Heads of department don’t just want up-to-date budget reports, they expect it. The school’s senior management team needs accurate monthly reports in a variety of formats. Parents demand that queries about their accounts with the school are answered without delay. School governors expect accurate information about ongoing projects and the school’s finances. Auditors, suppliers, regulatory bodies and numerous other parties also need information in one form or another. And all this is expected to happen alongside the ongoing day-to-day operations.

More than accounts
Financial management software is now more than just an accounts package. The boundaries between different packages are often unclear. Many schools use a number of different packages for different purposes, often with manual data import/export routines where information is shared between more than one system. However, within the environment of an independent school, the financial management software often provides support for the following:

• fee billing and credit control (management of student accounts);
• project accounting (both within individual departments and for the school as a whole);
• management of the overall school accounts;
• reporting of information to numerous different groups of users in a variety of different formats (including via self-service mechanisms); and
• fund and grant management (some schools use manual spreadsheets for managing grants and accounting for restricted funds).

More advanced systems might also provide:

• automatic reminders and control of basic workflow processes, for instance so that the addition of a new student record automatically alerts relevant staff and sets off a chain of events (such as reminders for welcome letters and timetables being sent out) – it is unusual for a school to need advanced workflow functionality, however;
• integration with a fundraising database or separate student management systems; and
• integration with an intranet or website.

Where to start?
The general process for purchasing new financial management software for a school is much the same as you would follow when acquiring any other major new piece of software.

Remember that changing software frequently has a major impact on the organisation, including issues of ownership (do people want to share their data?), staff (are people prepared to undergo training?) and usability, so be sure to involve key staff right from the start.

Setting your framework
Once you have set up a management framework for the project and identified key users (a major change such as this does justify being treated as a project in its own right), you will need to document their current and likely future requirements. This is a relatively slow and timeconsuming exercise, but is worthwhile since a clear picture of the school’s requirements are essential if you are to choose the right package.

Following a standard tender process, a selection of potentially suitable suppliers are asked to propose solutions for satisfying these requirements (supplierindependent consultants or other schools are usually a good place for identifying suppliers to put on the initial long-list). Due diligence – reviewing proposals against the selection criteria, checking references, requesting demonstrations of products (including demonstrations of the software using real data that you have supplied), meeting the account manager and project team – is carried out before a panel of relevant users makes the decision (don’t do this on your own).

The selection process is a significant activity so is not described in length in this article; however, some useful tips and questions to consider are given in the sideboxes.

What next?
If you require further information about financial software for schools or systems procurement in general, speaking to other schools is a good starting point. There will be another bursar who has gone through the same process or who faces the same issues as you. Independent consultants can also be useful. However you choose to proceed, be careful about contacting suppliers before you have documented your requirements, otherwise you could find yourself charmed into buying a package that does not fulfil your current and future needs.

1. Tender checklist: questions to ask when evaluating proposals

• Is the product a good match with your requirements? Are all key user groups satisfied that the solution will meet their current and likely future requirements?
• Has the supplier based costs on assumptions that are realistic and competitive, and provided details about how they are likely to be affected if the project scope changes or if modifications are required later?
• Is the implementation plan realistic and does it take account of busy periods (such as the year-end)?
• Is the system based around modern technology that is compatible with the school’s existing IT applications?
• Is the supplier of suitable size, structure and financial stability, and does it have a proven experience of successfully implementing similar solutions?
• Does the supplier have the technical expertise and resources to complete the implementation in the required timescales? Has the school also committed sufficient resources?
• Has the supplier demonstrated a clear understanding of the tasks involved and identified in detail where the proposed solution does not fully meet the detailed requirements and/or meets them in a different way from that proposed in the brief?
• What, if any, third party software is the supplier proposing (such as for reporting) and are the costs associated with this included in the quote?
• Is the approach to training realistic and cost-effective?
• Will you have a named account manager? Have you seen their CV and will you be able to meet them before making a decision?

2. Tips for ensuring a smooth systems selection and implementation

Do...

• Document your requirements in plain English – write down in detail what you need the system to help you do.
• Treat the procurement exercise as a project in its own right, and resource it accordingly (such as setting aside adequate management time).
• Properly consider ongoing support and maintenance costs (the initial purchase price is only one part of the total cost of ownership).
• Ensure that your requirements document is linked to the final contract as part of a “fitness for purpose” test.
• Be open and transparent about your selection criteria – let the suppliers know how their proposals will be evaluated.
• Give the suppliers sufficient time to prepare their quotes.
• Use moving to a new system as an opportunity to re-think how you do things and improve your processes.
• Ensure that if you use a consultant to help you with the selection exercise, that he or she is independent of any supplier and does not receive any referral income.

Don’t...

• Sign the supplier’s standard contract without checking whether it contains terms you should negotiate (many standard contracts favour the supplier).
• Be too prescriptive about how you want the solution or supplier to work – focus on outcomes and end results.
• Assume that the suppliers are familiar with your organisation and its internal terminology.
• Assume that because similar schools use a particular supplier or software solution, it is necessarily right for you.
• Underestimate the complexity of migrating data from one system to another.
• Assume that your organisation’s requirements are unique – try to avoid bespoke modifications if possible.
• Rely on promises and sales pitches alone – check references and ask for the product to be demonstrated using sample data that you will supply.

Paul Sypko is a consultant with BlueSpark Consulting. He specialises in assisting not-for-profit organisations in the strategic and operational use of IT and can be contacted at paul.sypko@bluesparkconsulting.com

Return to IT