First-30-days plan for school management, ERP, and SIS

Interview for work, not opinions alone

A stakeholder interview should reveal what a person does, decides, receives, corrects, protects, and escalates. “Do you like the current system?” may start a conversation, but it will not map the workflow needed for selection or implementation.

Choose stakeholders from admissions, administration, academics, finance, family support, IT, leadership, and any central or local campus team affected by the phase.

Use a consistent question set

Ask every stakeholder a common core of questions, then add role-specific prompts. Consistency makes differences useful rather than accidental.

• What triggers the work and what result is required?
• Which record or definition do you trust?
• Where do you re-enter, wait, correct, or reconcile information?
• Which exception creates the most risk or effort?
• Who may view, edit, approve, publish, or export the result?
• What support or evidence would make a change safe?

Probe the exception and boundary

Ask the stakeholder to describe a recent incomplete, duplicated, late, or wrong record. Trace what happened, who knew, what was visible, how the issue was corrected, and whether another team or family received the right result.

Ask what the person must not be able to see or change. This surfaces role and relationship boundaries that a feature list often misses.

Separate need from solution

Record the underlying need separately from the proposed feature. “We need a spreadsheet” may mean the school needs a report, a calculation, a temporary list, or an authoritative record. Each need has different data, access, retention, and support implications.

The U.S. Department of Education data governance checklist provides prompts on quality, access, security, lifecycle, sharing, disposal, and monitoring. GOV.UK procurement guidance recommends attention to data protection by design, minimum necessary data, access control, security, subprocessors, incidents, and data return or deletion.

Synthesize without flattening differences

Group findings by workflow, definition, data, permission, training, support, policy, supplier, and product fit. Keep local differences visible. A central team may need consistency while a campus needs a legitimate local rule.

Validate the summary with interviewees and workflow owners. Mark assumptions, unresolved conflicts, evidence needed, owner, and review date before converting findings into requirements.

Use interviews in the decision

Interview evidence should inform scope, acceptance tests, training, communication, support, risk, and commercial assumptions. It should not become a popularity vote or a promise that every request will be built.

Revisit the same stakeholders after launch at 30, 60, and 90 days. Their experience can explain measures that a dashboard cannot and identify when a workflow has drifted from the approved design.

Close the interview cycle by sharing the themes, not personal commentary. Ask workflow owners to confirm the source of each finding, the affected population, the proposed response, and the evidence still needed. Keep disagreements visible until the decision maker resolves them; silently averaging them can hide a permission or data-quality risk.

Record the interview date, role, workflow, and evidence reviewed so the conclusion remains useful when staff or requirements change.

Ask the owner to confirm what will be tested next and how the result will be communicated to the people affected by the decision.

Apply the guidance to one school decision

Before approving this guidance for first-30-days plan for school management software, translate it into one school-specific decision record. State the workflow, roles, data fields, permissions, evidence, support route, academic-calendar constraint, and condition that would hold the next phase. Note which answer still depends on product configuration or local policy.

Run the decision with controlled data and the people who will operate the workflow. Record what was observed, what remains unknown, who owns the unresolved item, and when it will be reviewed. Revisit it after launch at 30, 60, and 90 days. Keep the record beside the acceptance tests, support guidance, and change log so later reviewers can see why the school proceeded, narrowed scope, or held the next phase.