If you're thinking it might be time to change School Management System (SMS), you're probably already aware that it's not a small project.
However, whilst there are often many moving parts, the process doesn't have to be overwhelming. With extensive experience helping schools make the switch to a system that better suits their needs, we've put together a guide to help ensure your school has smooth sailing ahead.
In Part 1 of this series, we explored why schools may switch systems, how to identify potential roadblocks, and what the project's first steps should cover internally, before you have any significant conversations with providers.
In Part 2, we're looking at how to research and evaluate your options, ways to request more information from vendors, and what you'll need to make the final decision.
Exploring your Options
Know what you're looking for
If you've been following along, then the information gathered in Part 1 should give you a clear idea of how to gather the functional requirements and key priorities for your SMS project.
These often relate to some of the reasons you may be switching systems, such as:
- Consolidating systems
- Specific additional features or functions
- Easier integrations (i.e.APIs) or better connections between various areas
- Time savings (i.e. through workflows and automation)
- Better value/cost savings
- Moving into the cloud
- Improved security or stability
- Wanting a fully web-based solution
Using this information, you can now create a more formal selection criteria to use when evaluating your software options.
Do your research
With your key requirements on hand, do some research on potential vendors and build a shortlist of at least three options.
It's important not to let your school's current environment dictate what you could be doing in the future. Take the opportunity to really explore what's available in today's market, rather than trying to directly translate your existing systems or processes, which may not be the most effective or efficient.
Even if you already have a preferred solution in mind, comparing a variety of options will give you a better understanding of the current software landscape, and may uncover a solution, area or offering that your school had not previously considered.
This stage is also an ideal time to explore any trial areas or sandbox environments of the systems you're investigating, to get first-hand experience with the software.
Plotting your Course
Once you've narrowed down your shortlist, it's time to decide how you want to formally evaluate the selected vendors.
You may have already had conversations with some vendors, or be ready to move straight to software demonstrations, especially if you have prior experience with that system, or are close with another school that uses one of the alternatives.
In some cases, though, your school may prefer (or be required) to undertake a more formal application and consideration process. The common forms of this are outlined below:
Proposals, Tenders and RFIs
There are several routes you could take in requesting (and receiving) information from vendors.
Whilst the terms are often used interchangeably, there are differences between them. It's best to be clear on what type of response you're expecting, so that there are no misunderstandings between you and potential providers.
Request for Information (RFI)
An RFI is used to learn more about what's available in the market, and so is typically open to all potential vendors, rather than just a shortlist.
While it won't cover the same level of detail as a proposal or tender, an RFI can help you learn more about the businesses and solutions you're considering.
If you've tried to do your own research and are having trouble collating and comparing the features of different vendors, who often use different terminology and offer varying levels of information, this step may help you more accurately compare available systems.
An RFI may also highlight areas of additional value that were not part of your initial selection criteria.
Request for Proposal (RFP)
A proposal will typically be sent to a shortlist of chosen vendors, though it could be posted publicly if your school is open to responses from any potential providers.
When requesting a proposal, your school should have defined goals or outcomes in mind, as well as an idea of the scope, budget, and criteria that the successful response should meet. You should include some background information on your school and an overview of your current systems, to give vendors a complete understanding of your environment.
The response you receive from vendors should go through how they will meet your project goals and include information on prices, timelines, and action plans.
Request for Tender (RFT)
Asking vendors to submit a tender requires more groundwork on your school's side of things. A tender will typically include the information mentioned in the proposal section above, plus drill into the specific functions of each operational area to give more prescriptive requirements for each system.
As it's asking each respondent whether their system performs specific functions, rather than whether their software would meet your school's needs, you'll need to work out every bit of functionality you're looking for first.
To more clearly compare these two, the same goal could appear on either as:
|
Proposal Goals |
Tender Requirements |
|
The system can manage student attendance in class, extracurricular activities, appointments, and other activities. |
Staff can record attendance of individual students in each class. |
|
Staff can mark attendance for extracurricular activities and groups such as sports, choir etc. |
|
|
Record the arrival or departure times of students who arrive or leave outside of regular school hours. |
|
|
Students can self-register via kiosks for scheduled and ad-hoc appointments during or outside of regularly timetabled classes. |
|
|
Staff can see the location of students who are otherwise scheduled to be in their current class. |
These requirements are often listed as part of a spreadsheet, where vendors can mark yes/no against each feature or provide any comments. However, from a vendor's perspective Kate Damant, Sales and Marketing Manager at TASS, explained why this isn't necessarily the best way to structure your responses:
"When giving a response to specific features, it's often not as black and white as 'yes' or 'no'.
Sometimes it's native functionality, but sometimes it's something that the system does through supported integrations or dedicated APIs.
Occasionally it's a feature that makes a lot of sense, but the system doesn't currently do it, and so we're happy to put it down as a development commitment."
To make it easier to compare each vendor's submission, your school may benefit from giving vendors a wider range of set response options, such as:
- Yes - native functionality
- Yes - supported integration
- Partial
- No
- Development commitment
Kate's other advice for schools was to make the features as granular as possible, and separate each out into their own section:
"Don't put multiple requirements in one cell - if there’s 5 bullet points in one, but a system can only do 3/5 of the things, it becomes difficult to respond accurately, which then makes it harder for your school to compare responses."
In general, a proposal may be a more suitable solution if you know what you are looking to achieve but are not set on how, or are open to innovative ideas on how to achieve it.
Otherwise, a tender may be a better alternative if your school has more specific requirements for how the software delivers certain outcomes.
Due to the depth of response required, try to allow more time for vendors to respond to a tender than you would a proposal. A rough timeline for either option could look like:
|
|
Proposal |
Tender |
|
Invitation to vendors |
A month before the closing date |
At least 6 weeks before closing date |
|
Evaluation and final shortlist |
Around 2 weeks after closing |
Approximately 2 - 3 weeks after closing |
|
Shortlist demonstrations and presentations |
4 - 6 weeks after the closing date |
|
|
Final decision and notification |
2 months after the closing date |
|
These timeframes will depend on your school's internal processes, but it is good to provide a rough outline of when you expect to get back to the companies that have responded to either type of request.
Reaching your Destination
Once you've determined a shortlist, whether through a proposal, tender, or your own research and evaluations, you should start conducting demonstrations with your top two - or more, if it has been difficult to narrow down the field.
These demonstrations should give you more clarity on which solution will be suitable for your school and, along with your own evaluation against your selection criteria, will help you make a final decision.
Once you've done that, your vendor should be able to give you a solid idea of when and how the system (or systems) will be implemented.
Your SMS powers your entire school, and any missing or incorrect data can be a major problem. Ensure your vendor is also taking into account things like the added time needed to reconnect and test integrations, and any trial data migrations your school would prefer to undertake when agreeing on timeframes.
Planning ahead for the upcoming implementation will help make it as smooth as possible - we also have some tips on managing this stage of the process, as well as how to ensure your team is on board with the changes.
