Changing SIS Implementation Methdologies

Yesterday's Approach to SIS migration:

Australian, independent schools are facing a real challenge with the rollout of Student Information Systems (SIS) with vendors traditionally advising schools to implement their systems module-by-module and switch over as soon as you can to minimize the impact of double data entry. While this approach was intended to streamline the transition process, it required double data entry and exacerbates change mangement issues. 

Without thorough testing of the full system before it's up and running, Independant schools might end up in a tough spot, having already locked themselves into a multi-year contract, only to hit a major snag in the rollout with no easy way out. In the stickiest situations, they could wind up with two failed implementations, and a jerry-rigged connection between the two systems as a makeshift fix for the long haul.

Yet many SIS vendors are mostly stuck in this traditional mindset, struggling to understand the impact that this has on the day to day opperations of an independent school and the long term success of the project.

A Better Option:

What schools have been telling me is that they they are tired of poor and partial implementations that disrupt the daily routines of the school. They want reduced risk and more certainty about the outcome prior to a change occuring.

In short, Indepedent schools have become more mature in their thinking about large IT changes!

To minimize the affect on the daily routine in a school, we suggest purchasing and completely building the new SIS offline in a test environment. This allows you to minimize the risks to the project of almost all of the areas that referenced in Common Mistakes in SIS Implementation. 

While I won't cover it much here, I would also advocate for a model that looks at the entire digital transformation goals of the school, or in other words, look at all of the systems and processes that connect to the SIS and map out how that will change. This is systems archectecture in your edtech stack, or educational technology ecosystem if you will.

How to implement this implementation strategy?

1. Be up front with the SIS vendors during the procurement process about your plans to build the new SIS offline and then go-live all at once. If they try to disuade you, remember this is your project and ultimately you know your school better than they do and your school will live with the consequences of the decisions made here. In particular, be suspicious of the 10 Week implementation timeline as it means the change management components are not being concidered properly and this will impact your school.

2. Plan for this configuration to take a 10-12 months.

3. More time equals more project costs in this case. In truth, it's more known costs and costs spent preventing issues later. Poor implementations on the surface are cheap, but very expensive when inefficiencies arrise and key staff leave out of fustration with bad systems.

4. Plan on post implementation support. Because your change isn't staggered, when you go live you could have multiple fires burning at once. Generally, these fires will be smaller and more easily quenched as you would have had time to see and mitigate most of the issues approaching the go live date. Most people plan for day 1 support. You are just as likely to need support after a litle settling time has occured. Plan on support for the next 6 Weeks.

Verdict:

The changes in SIS implementation strategies over the last couple of years reflect a broader shift towards more comprehensive planning and execution in the independent school sector that we had not largely seen previously. By adopting a more cautious and thorough approach, schools can minimize disruptions, reduce the risk of data loss, and ultimately enhance the educational experience for students and staff alike.