A content management system (CMS) can help a school district a lot by organizing material and improving communication. However, the choice of whether to build your own or go with an external vendor is difficult. One communications manager and their district decided to build their own system. They spoke to us under conditions of anonymity about why they regretted this decision and what they could have done differently.
"At the end we had a CMS, but it was not at the level of the ones we had originally looked at and created a vital weakness in the tool based on the core team that designed it when one of them left."
The initial decision to go with an in-house system was made after the district mapped out their requirements for a CMS and then did an RFP.
The costs appeared very high. They decided to build their own CMS in-house under the mistaken belief that this would be cheaper. A team was put together by borrowing individuals from communications and IT, who were assigned to the project full-time. The goal was to get it done within a year, after which time normal IT could handle ongoing management and maintenance.
So, what happened?
Their original plan was to make it a one-year project. At the end of this time, the idea was that they would have a fully functional CMS, which could then be used to support the entire district.
Unfortunately, nothing went right. The internal team had little experience building and managing a CMS, especially one for education. This meant that a lot of time was wasted on training and getting them up to speed. Even then, they didn't have the knowledge to avoid costly missing features, like accessibility, which had to be added in later through another outside vendor.
The tool they started building on was discontinued about 6 months into the project. As a result, the team had to start over again. Meantime, other departments that had loaned team members struggled. Ultimately, they were left without personnel for far longer than planned.
The cost of add-ons also added up. It cost at least $10,000 for an accessibility checker and the same for a school locator.
Finally, the migration process took an extended amount of time, with thousands of pages to move over. This then broke over 3,000 links that had to be fixed. The original plan was for all staff to take care of their own migration. However, the learning curve was substantial and the staff needed a lot of help. On top of that, the teaching faculty already had enough to do and ended up exhausted from dealing with the extra workload.
Overall, the cost looked good when comparing it to the RFPs. However, once the process started it became clear that it was far more expensive than predicted with direct costs, employee time and time lost to other projects as personnel were moved over. All of this for a system that was not as robust or well-designed as the ones they could have purchased.
Building their own system ended up being a poor choice from a cybersecurity perspective as well. Numerous holes were found in the system, which then had to be patched. The potential risk of a data breach reduced trust throughout the district.
Nobody wants to be afraid that their child's personal data is at risk, and employees also felt the system was insecure. A lack of trust in the CMS is likely to lead to people bypassing it. Ultimately, the CMS will not serve its purpose.
On top of that, other cybersecurity needs became neglected while the team desperately tried to get the project done.
Another issue was the unexpectedly high ongoing needs in management and maintenance. The internal team needed to provide 24/7 support to students, parents and teachers. This proved to be a lot for the IT team to manage, slowing other work down and placing a lot of stress on team members. Outsourcing support was not feasible due to the custom nature of the system.
Had they gone with a vendor, they could have received help with this. On their own, they were left struggling with an inferior system not everyone wanted to use. Then things got worse. A member of the original team left their job and took with them key institutional knowledge that was not easily replaced.
Staff turnover is not something people always think about when doing projects in-house, but even in the best situations it happens, and this did not turn into the best situation. It became nearly impossible to continue to maintain the system, with people not on the original team not understanding it sufficiently to keep it running.
The final result of all this headache, time and cost was still only a basic CMS. The school would have liked to add other features. These included a mobile app, a parent portal and the ability to integrate voice calls.
The communications needs of the school district were not met, and the financial and opportunity cost was high.
"Overall this project cost far more than using a dedicated vendor would have, between full-time staff working on the project and the delays and pushbacks on other projects."
The lesson learned was that for many schools, going with an in-house project can be a costly and time-consuming endeavor. Are there schools and districts that have made it work? Of course, but they already had the in-house expertise to develop these kinds of systems.
In the end, the school district's communications manager had no choice but to issue a new RFP and look for a vendor to create a system that was actually functional and would not take so much of ITs time to struggle to maintain. A new system could then expand into the other areas needed.
Ultimately, this district wasted over three years and a lot of money trying to produce a system which would work, and ended up failing. While the cost of a vendor may seem high, consider whether the value of a vendor is, in fact, better than trying to do things yourself. Check out our guide to In-House versus a Vendor CMS here to ensure you have the full picture before starting on your CMS journey.
Join our List
Sign-up for our email list to get exclusive access to content, sneak previews, updates and more!
Zero spam. Unsubscribe at any time.