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.