Case study · The King's School

Markbook RFQ & RFI

Translating non-technical stakeholder needs into technical requirements, and being a Agile evangelist to an traditional education environment.

TLDR;

I turned teachers' and academic leaders' needs into a clear RFI/RFQ with the context vendors needed to build well, and brought a non-technical school team on board with Agile.

Outcomes

A school team with no prior technical experience adopted an Agile way of working, with shared vocabulary and rituals.
A complete RFI and RFQ released to vendors, with clear deliverables and measurable success criteria.
Integration requirements defined against the Salesforce ecosystem, giving vendors and developers the context to estimate accurately.
Vendor presentations aligned with the school's business objectives.

What I learned

Context is the most valuable thing I can give a technical team. Explaining why a rule exists leads to better build decisions than just stating the rule.
Analogies beat jargon. The house-building metaphor did more for Agile buy-in than any framework diagram.
Bringing people along takes patience: approvals at each step (mockups, ACs, estimates) built trust with stakeholders new to this way of working.
Documenting the current state honestly, workarounds included, is where the real requirements live.

About the King's School & The Markbook Project

The King's School is a 109-year-old private K–12 school across three NSW campuses, in the middle of a major digital transformation onto Salesforce (Education Cloud, Experience Cloud and Workflows), alongside Canvas and Power BI. The mark book is where teachers record every assessment result for a student, where it generates compliance reporting to NESA and the IB, internal analysis for staff, and student reports to parents/guardians.

Users: Heads of Curriculum, teachers and academic staff from Kindergarten to Year 12, parents and guardians.
Team: project sponsors, a domain expert in teaching and reporting, a business analyst, and me as Product Manager.
The wider team had deep education knowledge but no prior experience with technical delivery.

Problem

The legacy mark book, SM Marks, was clunky and unintuitive, with every department using it differently. Some departments typed marks into Excel first, some entered them directly, and some marked in Canvas (Learning Management System) and re-entered everything because the sync between the two was broken.

Double entry and manual workarounds increased the risk of mark errors, which is serious when results count towards public credentials in Years 10–12.
The Synergetic (Student Information System) report sync depended on naming conventions, so any late change meant regenerating reports by hand.
No integration with Power BI limited how data could be analysed, displayed and shared with teachers and parents.
Canvas filled some gaps but couldn't mark at outcome or question level, which the school needed to fulfil subject curriculum.

My role

I owned the bridge between the people who understood teaching and the people who would build the product. The output being asked of me was a comprehensive Request for Quote (RFQ) and Request for Information (RFI) that could be provided to potential vendors who would build the platform, and make a determination on who would be best suited and equipped to fulfil the school's need.

Translated stakeholder needs into epics, user stories and acceptance criteria that technical teams could estimate and build from.
Wrote the technical documentation of the school's Salesforce ecosystem to define integration requirements for the mark book.
Authored the RFI and RFQ, framing the 'why', deliverables, success criteria and methodology so vendors could respond with informed proposals.
Proposed and introduced the Agile framework, and presented it to the Deputy Head of Academics to gain buy-in.
Ran the backlog, prioritisation and JIRA setup as the team's domain expert in delivery.

Discovery

I ran requirements sessions with the domain expert, business analyst and academic stakeholders to map how marks actually moved through the school, not how they were supposed to.

Mapped the current state department by department, which surfaced the three different mark-entry workflows and the broken Canvas sync.
Learned the education domain (assessment tasks, performance outcomes, cumulative marks, NESA rules) and built a shared glossary so both sides used the same words.
Documented the planned digital ecosystem and the status of each module, so integration needs were grounded in what existed and what was coming.

Options and trade-offs

Extend Canvas: it already solved many usability issues, but couldn't mark at outcome or question level. Ruled out as the core mark book.
Keep SM Marks and patch the integrations: didn't fix the usability problems driving inconsistent use.
Build entirely in-house: the school's people also had to keep running BAU, so we went to market through an RFI and RFQ to find an implementation partner, while keeping change management optional in vendor scope.

Solution and delivery

The RFQ and RFI gave vendors the context they needed to make good decisions: what a mark book is, why assessment rules matter, the school's ecosystem, and clear success criteria across organisation and technology.

Structured delivery into Discovery, Implementation, Change Management and Post Implementation stages.
Introduced a product development cycle: epics, user stories ('As a… I want… so that…'), Figma mockups approved by the sponsor and domain expert, and Given/When/Then acceptance criteria.
Added a feasibility step where developers estimated time and cost before sponsors committed.
Set up weekly grooming, two-week sprints, sprint planning and release demonstrations.
Made Agile approachable for a non-technical audience by explaining every term through building a house: epics are the foundation, frame and roof, and a release demonstration is the surveyor's inspection.