Capturing your requirements when considering/migrating to a new MIS

[psydii]

I've been thinking about this for a bit, but not really got anywhere, hopefully those who have been through the process can offer their experience/learnings?

 

How do you capture your requirements? SLT can be appallingly vague on the details when they have experienced direct reports who do the day to day work in the current MIS for them. But those who do the day to day work, do the work they do because that's the way to do work that they do in the current MIS.

 

How do you identify when a difference will take the form: "oh the new MIS does this differently and we get the same/better outcome" and: "oh the new MIS does this differently, no hang on, its worse. oh we have to change how we do this completely and the outcome we want are almost impossible/impractical now"

 

 

How much / how does one free up time for all admin / leaders to update their skills, and processes to align with the way the new MIS works? How does the data team (for example) keep up with the day to day demands, while also learning and deploying the new ways?

 

 

With some very critical elements like cover and timetable, how do you assess whether the new MIS offer is actually suitable for your needs? Timetablers and the Cover teams always seem *very* attached to their current tools. I've seen timetables abandoned and completely restarted in the legacy tools by those who thought it a good idea to try an newer alternative in the past.

 

What are reasonable success criteria for a migration project?

[Seb1780]

We're currently migrating.

 

To begin with I wrote a review of what we do and how we do it using our current systems. This was broken down by function (e.g. HR, Pastoral, etc) and then by task (e.g. recording absence, staff appraisal, payroll). For each task I identified what we currently use, what current issues we had and what, if anything, was a critical requirement from the new system. Once written this was shared far and wide before being ratified by SLT.

 

That ratified document was then converted into a specification of requirements which was sent to several MIS providers. Again it was broken down by function but it now identified essential, desirable and "nice to have" features and each supplier was asked to identify how they met these requirements. From the responses received we were able to shortlist suppliers to come in to do "deep dive" presentations to various staff.

 

After responses and presentations the matter was returned to SLT for the final decision.

 

Once we made the decision I drew up a schedule for training and implementation of the new system. I started by training myself, then training the support staff who use the systems the most, then support staff with a lesser involvement. After Christmas I will train certain teachers and that training will be cascaded down to all teachers.

 

So far I have watched many, many hours of videos; I have delivered dozens of hours of training to support staff and I expect there will be many more to come.

 

We go live after Feb half-term.

 

I have done 95+% of the work, but involved SLT and others so that they had their say and they had their opportunity to ask for something different.

 

It's a lot of work but it's also, potentially, the biggest thing I'll do. And the rewards for the school and those working here are significant.

[TechMonkey]

On the difference question, I'd say by being very careful about mapping your outcomes, not processes, and ensuring the companies you tender to answer the question fully "Can it do all of these things". Having to do something different is just an inevitable situation and not something that I would even keep track of. Users will always say that because it is different it is worse, until they are used to it and won't remember any difference.

 

Your outcome needs to be precise, "output in a transferable format" is fine but if your next process has to have a JSON file your outcome needs to be "outputs in JSON format". If a company says it does the latter and then your process doesn't work as the output is only in CSV, then that is a lie and needs to be addressed, but if it outputs in CSV then they have fulfilled your requirement.

 

If a company lets you know they do not meet one of your requirements, then it is up to you and your leadership how much weighting that has and to listen to the company to see if they have a reason that requirement is not met.

[ASA-Simon]

I used the template specification provided by Everything ICT and refined it by doing interviews with heads of departments, admin staff etc. I couldn't recommend them more for getting through the process.

[supportman]

I simply used a spreadsheet showing all the different 3rd party systems and costs that were needed with Sims compared to Arbor or Bromcom.

 

Was an easy decision after that as SLT could see how far behind Sims had got.

[nicholab]

Use flow charts like LEO computers used to show managers how systems would work. It should be about what you want to do not how you do it today. Edited December 20, 2024 by nicholab