Those who don't know, I've spent a large chunk of my career working across the education sector here in New Zealand. Everything from data strategy at a national level to redesigning frontline systems that impact students and schools and funnel, which means family in Maldi here in New Zealand. So in this episode, we're going to talk about what makes education a unique beast for business analysts.
Whether you're already in it, thinking about a role or just curious, here are 10 essential items that you need to know the Better Business Analysis Institute presence, the Better Business Analysis podcast with Kingman Walsh. Welcome back, everyone. We are going to be covering 10 things every BA should know about working in the education sector and I think what I'm going to do is follow up with a couple of other sectors that I've worked in.
So this will be a series that will help you if you're interested in that sector, you're working in IT, or you just want to expand your knowledge. These are 10 tips that I've picked up and please comment if you have any tips yourself. Number one is that education is primarily around policy and people. The education sector exists in a political spotlight. That's really important. Every budget, every reform, every funding model shift comes from policy.
And so there is a massive political overlap in the education sector, but your work hits real people, which is what's growing me to this area. That's teachers, students, families, and they have an emotional investment in what we do. So an example might be you're working on a system to report student well-being metrics. The ministry or your education department wants scalable data for national insights. Schools want flexibility and privacy, and you need to translate both into your design.
So the tip for you as ABA here is don't just gather business requirements. Gather human context, who's impacted and how. Talk to someone who actually does the mahi in the classroom, which means they'll work. So talk to teachers, talk to Farnoo, not just the principals, and elevate that up, communicate it through the channels to political decision makers #2 is that in the education sector because it's a public service outcomes Trump outputs.
So in education, success isn't that the system works, it's that kids are getting better off because it works, right? They're learning more or they're feeling more engaged. You need to link every requirement, the process improvement you do, or dashboard KPI back to the learner's benefit. What are they getting benefit from? And sometimes as I've worked on, for example, attendance or truancy, the the, the learner may not realize that it's good for them to, to go to school.
So it's not always directly that a learner is asking for it. So just be aware of that fact. An example might be a school platform that automates truancy reporting, SMS systems, we call it student management systems. It saves admin time. Cool. But does it actually reduce absences? That's what matters as ABA always ask what student outcome is this enabling? If it doesn't have a clear answer, go back and redefine the
problem. And the voice of the learner, even if the requirement, like I said, hasn't come from them #3 is data is everywhere and nowhere. Very hot topic for me. Expect a mess of fragmented data sources. SMSSLMSSHRISS, the ministry data or the department data. Data feeds, third party applications and data quality like just varies wildly all over the place. So you need to do definitions. You need to figure out what the word enrolled means.
Is it the day they start? It's the day they signed up, you know. Can you be enrolled in more than one school at one time? Well, you actually can if you look at the data. Doesn't mean that it's correct. And you'll get like 5 answers if you ask that question. So if you were tasked with building a dashboard on student achievement, it turns out that achievement means test scores in one school and in another school it might mean if an engagement.
So they might just mean two different things. the BA tip here is always define your terms upfront in any data heavy work and run a quick data source audit. OK. It will save you sanity later. And what I found is an extra extra extra tip and this may apply to your area of the world. It definitely applies in New Zealand and most likely in Australia. The more layers of data interfaces you have from source to reporting system, the worse your data is going to be.
OK. And worse, the finding that term, I mean, in terms of its quality, time to market, accuracy, ability to audit cost, all the rest of it now #4 is that the teachers are your secret weapon. Teachers are the frontline experts that have been in IT people. People do not become teachers to earn lots of money, unfortunately. OK. So they know what works and what waste their time. They really do. They're really experts in that. So if you ignore them, you'll
get ignored. And if you involve them, you'll get traction. So an example here is you might be designing, I don't know, a new student notes feature, right? And a teacher tells you that they need it to work on mobile because they do all their notes between classes. They don't have APC that they have access to. That's the game changer. the BA tip here is that you need to treat the teachers as your design partners, real proper Co design partners.
OK, They really are knowledgeable of this as as opposed to some other sectors we'll talk about in the future. They tell you things that no policy document will ever, well, right. And policy is written generally. Don't get me wrong with this hierarchy of policy writers, but a lot of these people come out of academia. They work in there. They hopefully do spend time with their customers. But policy is is such a
political base. It's very, very, very, very difficult for the policy writers to know everything that's happening on the ground level. And so they estimate, OK. And then our job is sometimes to make that policy real. And we'll get to that point in a minute #5 is that pilots? Be careful of your definitions here. Pilots don't equal progress. Proof of concepts are something different. We'll come to that. And sort of prototypes. But I'll explain what I mean by pilots. The sector loves a pilot.
They the education sector loves a pilot. They try a system. It's very solution focused, OK, but pilots often fizzle out because there is no true path to scale. They haven't thought about operationalizing these systems. There's simply a SAS system
call. You can try Salesforce, but then if you want to scale it, you're now working from a $20.00 a month charge that you tried for your trial license or $100 a month and now you've got $1,000,000 asset you have to invest in. If your analysts are only like fits for five pilot schools, it's not fit for a national roll
out. And, and, and look, I've literally been involved at the Ministry of Education in New Zealand and I heard about a piece of work, I won't name it, but literally, you know, these focus groups might be the best people with the most engaged and you and then then they put their hand up for a pilot. That pilot doesn't equal results. So be careful about that.
So if you had like a well-being checked tool and it might work really brilliantly and it'll diesel 9 Auckland school or area which is affluent doing well, then it might crash and burn in a rural one, which limited IAI, sorry, AI, Wi-Fi or even the diesel's different. It's there's different needs for those students. On average, the BA needs to always ask what would this look like at 2 1/2 thousand schools, OK. Or whatever the demographic
numbers are in your constituent. And in America, I know that Trump's currently getting rid of the Ministry of Education, the National service, but each state will have the supplied. And think about it in your state, if you're in the America or Australia and then in the UK, they will probably just have different regional areas that do it. You need to include scale reading readiness as part of your requirements validation. OK, could, can we scale this? That's got to be part of the pilot.
OK. It's, it's, it's just a testing the water. Use that as a focused, focused exercise on checking some of the common patterns, but not the detailed requirements that need to come later with a much bigger sample set. Number six is that language is totally loaded, OK. Words like assessment, inclusion, attendance, they come with years of emotion and historical language and baggage attached to them. Assumptions about shit understanding are are risky.
I had one where there was a truancy code the other day and I was working with ABA and we were talking about it. I said the schools don't use that code. We don't use that code, but and she was querying if we could get rid of it because it wasn't really providing value.
And I said, well, you know, this is the new term we use and and we both knew that it was going to be a nightmare for her to try and remove something just because of the historical baggage associated with it. You might have an example where ministry or staff member, the analyst asks for real time attendance. I've talked about this before and the school thinks that means period by period and the analyst means once per day. OK. And so you now have a scope implosion.
So that's a really good example. What you should probably do in education, and I haven't been that good at it, but I do have it in my requirements documentation or business case is to run a glossary session literally like you have a glossary terms a 15 minute. What do you mean by and it will prevent so much work and interpretation of those words in in in your context. OK, there isn't a common understanding. The seven is that tech is often
held together with duct tape. Legacy systems are the norm. There's not much money in this sector. You'll deal with platforms built before you had a LinkedIn account like they will be platforms that have been there forever. OK, it doesn't mean they're bad That's but their interfaces need to be good to help their ecosystem. So easy integration, right might be something you suggest it could take six months or a
miracle. An example might be you want to plug in a national SCMS system, so student management system to track absence, right? And it turns out that it's, it's batched only once per day in flat files. And, and this is an example that we've kind of hit, I've paraphrased the problem, but it's effectively what what a problem that we hit as ABA. Document your constraints as clearly as your requirements, OK? It's not being pessimistic, it's being realistic.
People need to understand this because the business case or the money that you're investing, a lot of it might not be on the new. It could literally be getting rid of the old or migrating the old, right? That becomes 60% of the project. And that costs a lot of money and there's no value generated from it. There's value in terms of risk mitigation, there's value in terms of the cost to run those systems. But sometimes they don't look good on a balance sheet.
So you really need to be really clear about that. And also the value of moving away from it #8 is that compliance isn't optional, right? So education data, children's data privacy rules are strict. And for good reasons. You can't chat student data onto the Internet, into AAI tool. You can't do that. OK? There's no way. And you need accessibility, equality and privacy rules aren't just check boxes, they are actual ethical and sometimes legal responsibilities and legislation.
So you have to make sure you've covered all these bits and pieces. So there was an example where we released a product and I asked around it's web standards in terms of accessibility and you know, it wasn't that great. And I thought, well, in education, that's just not good enough. An example is you might build a new parent portal, right? It's fast and flashy, but it doesn't meet, like I said, those web standards, the WCAG accessibility standards. And now in America, it's a
lawsuit risk. The tip here is to add compliance checks into your requirements packed early and it's better to prevent those problems upfront then refit. So if you're working in an agile way, these are must have requirements you need to get on to sooner and later. They can't be done as an optional backlog item or at the end, they have to be designed into the solution. So in education, you find that that it isn't unless you're building on an existing product, very segmented and not worrying
about the rest of the world. And you're just adding features that don't change legislation, which is very rare because you don't have the time to do that. You're usually responding to
change. I would highly recommend you have design sprints or you know something outside of the scrum agile environment and and you do some waterfall upfront planning before going into your development phase #9 is that governance be This is so true and this is one of the reasons why my recent engagement is done. My head in is that governance is political education systems often report to ministers, boards, cabinet. This means your work isn't just operational, it's like decision
support, right? It needs to be sharp and succinct and strategic. And so an example is you're writing a paper on funding options for a student transport. Your artifact isn't a wireframe, it's a briefing note that feeds into policy. And I'm well aware of that part. So the fact that your words can be re litigated or your packs go across the road if you like to the government, that's fine. Great about that. But there's another another
important element here. So I'm going to give you the first BA tip and then I'm going to give you my BN tip. The first BA tip is that you need to learn to write like an advisor, 1 pages, exec sum, cost benefit, language and matters. And so that's fine. And there will be your executive team when want to add their spin. I'm quite good at that. And I think that's a useful tip, all BA. In addition to this, though, that internal governance, the more layers of middle management
makes this hard. And because they want to manage risk and they want to manage reputation, and it's not clear who's accountable or responsible, this internal process can be a nightmare. And I've had it a number of times in education #10 though is that the work is personal, which is why I continue to come back to education people and education care. OK? Your changes aren't abstract. They actually touch light.
Be aware of the emotional impact of that, especially when a change effects teachers or parents, vulnerable learners, OK. Or even people that work in the ministry who really care about a topic of number of times have had some of these personal emotions come out because a change or religious special legislation is against someone's feelings. The example is you might be that you're proposing removing a manual form to streamline workflow, go to automation, and it turns out it's the only way
that some families feel heard. OK, so you need to pause or you need to rethink. So make sure you use empathy mapping, understand the emotional landscape, not just the logical 1, and will make your work more human and more effective. So there you have it, 10 real world truths from the trenches of education. And I've got some battle scarf. If you're ABA already in the
sector, I hope you feel sane. And if you're thinking of moving into education, just know it's some of the most meaningful, complex and human centered work that you will ever do. You're not just analyzing systems, you're influencing futures, and that's a damn good reason to sharpen up your craft. But be aware that it is very political and there is layers and layers of governance and as a result, bureaucracy.
If this hit home for you, share with another BA who needs to hear it. And as always, keep asking better questions.