Case study 04 · May 2026 – present · Specification, delivery coordination, release sign-off and documentation # Rebuilding two governance tools for school councils, ready for department review I specified, tested and documented two online tools that school principals use each year: a council self-assessment and a council membership declaration. *Part of the training portal project in [Moving a government training portal onto Moodle 5.0, now with 3,800+ users](https://dulitha.net/work/lms-migration-drupal-to-moodle/). This one covers two governance tools added after launch.* ## At a glance - **My role:** specification, delivery coordination, release sign-off and documentation - **Period:** May 2026 – present - **Scale:** 2 tools, each with a principal workflow and an administrator workflow; 124 tracked items over 19 test rounds; a 21-page user guide - **Worked with:** a state education department, a training delivery partner, an offshore development vendor and the studio's director - **Tools:** Moodle 5.0, Excel and SharePoint trackers, Word - **Headline outcome:** both tools and the user guide went to the department for review on the agreed date ## The situation Each year, school principals assess how their council is working and declare who sits on it. The department already had tools for both. As part of the new training portal, they needed rebuilding inside the platform, as they were, so principals would find familiar forms in the place they already go for training. That meant two tools with two audiences each. Principals fill in and submit. Department administrators view every submission and download reports. ## My role I turned the brief into a build specification, coordinated the work with the vendor, tested each release and wrote the user guide. The training delivery partner and the department reviewed the tools on a staging site before anything went further. ## What I did ### Specified the tools against the originals I used the department's existing forms and a reference video of the previous tools as the baseline. Each screen, statement and option was checked against them. Any difference, even in layout, went on the tracker as a numbered item. ### Set out who can do what I wrote down the access rules for each role in one place. Principals can enter, submit and see their own school's records. Administrators can see everything but can't submit. Regional staff see only their assigned schools. Everyone else has no access. I then tested every role against those rules, including by going straight to page addresses, not just following menus. ### Tested in rounds and tracked every item I ran 19 test rounds on staging over 124 tracked items. Items closed only when they passed on staging with evidence saved. ### Wrote one guide for both tools I wrote a 21-page user guide covering both tools for both audiences, with step-by-step instructions for each workflow. It has five sections, 25 annotated screenshots with numbered callouts, and cross-references between sections. It follows the format of the portal's main user guide, so the two read as one set. ### Walked every stakeholder through the tools I also ran walkthrough meetings with the stakeholders and took everyone through both tools step by step. I explained each workflow and showed how the different user roles interact in the system, from a principal submitting to an administrator reviewing and downloading. ### Shared it on time The tools and the guide went to the department for review on the agreed date, 18 September 2026, with the partner kept informed throughout. The tools are now under department review on staging. ## Results - 2 tools rebuilt inside the portal, each with principal and administrator workflows. - 124 items tracked through 19 test rounds, each closed with evidence. - A 21-page user guide with 25 annotated figures, shared with the department on the agreed date. - Walkthrough meetings taking every stakeholder through both tools and how each role uses them. - Access rules written down for every role and tested against the build. ## What I'd do differently - **Record why each field exists, not just what it shows.** When rebuilding an existing tool, I matched the screens closely. I'd also note the reason behind each field and the data it depends on, so nothing quietly changes meaning in the rebuild. - **Agree access rules before the build.** We confirmed the detailed rules during testing. Agreeing them in the specification would have caught gaps before the first build. ## Tools and skills - **Analysis:** specification from existing forms, gap tracking, role-based access rules - **Delivery:** vendor coordination, numbered issue tracking, release sign-off on staging - **Documentation and training:** a user guide with annotated screenshots and cross-references, plus stakeholder walkthroughs - **AI:** an AI assistant (Claude) for drafting and checking, with every result reviewed by me --- *Client, partner and vendor names, and some details, are left out. Any visuals are recreations with invented data.*