Make-or-buy analysis for admissions and enrollment

1. Define the decision

State whether the school is choosing to build, configure an existing tool, buy a product, integrate systems, improve the current process, or defer. Define the applicant journey, phase-one boundary, users, campuses, calendar, outcome, and decision date.

A make-or-buy decision is not only a technology comparison. It includes data stewardship, permissions, support, training, supplier responsibility, legal advice, continuity, and the school’s capacity to operate the result.

2. Compare workflow fit

Use the same scenarios for every option: incomplete application, duplicate identity, changed guardian, rejected document, decision approval, offer acceptance, waitlist movement, withdrawal, family access, and enrollment handoff.

Record native behavior, configuration, custom development, integration, manual work, roadmap, unknowns, evidence, owner, and exception route. A custom feature is not automatically a better workflow.

3. Compare control and lifecycle

Ask how each option handles identity, data quality, view, create, edit, approve, publish, export, correct, archive, delete, retention, recovery, support access, suppliers, subprocessors, incidents, and contract end.

GOV.UK procurement guidance recommends minimum necessary data, access control, security, supplier accountability, incident notification, and end-of-contract handling. The U.S. Department of Education data governance checklist connects quality, access, security, lifecycle, sharing, disposal, and monitoring.

4. Compare capacity and support

Estimate discovery, data cleanup, mapping, migration, validation, configuration, development, testing, training, family communication, support, monitoring, incident response, updates, reconciliation, and review for every option.

Ask who can respond during peak admissions, staff absence, outages, integration failure, wrong offers, duplicate applicants, missing documents, and family access problems. Internal ownership is a cost and a risk, not a free assumption.

5. Compare total cost and reversibility

Include one-time, recurring, usage-based, infrastructure, integration, payment, training, support, internal capacity, growth, reporting, export, retention, and contract-end costs. Record assumptions, exclusions, dependencies, and variable charges.

Assess reversibility: can the school export, correct, migrate, pause, narrow, or replace the option without losing necessary evidence or creating unsafe temporary work?

6. Decide with evidence

Set hold criteria for identity, privacy, access, document handling, family visibility, recovery, support, and lifecycle. Score preferences only after the gates pass.

Review completion, data quality, access exceptions, support demand, family experience, implementation effort, and outcome at 30, 60, and 90 days. A defensible make-or-buy choice explains residual risk as well as selected capability.

Turn the guidance into an admissions decision

Apply this guidance to one bounded part of make-or-buy analysis for school admissions software. Define the applicant or student journey, the people involved, the source of each value, the permission boundary, the evidence required, and the condition that pauses the next step.

Test a complete case and meaningful exceptions such as an incomplete application, changed guardian, duplicate student, withdrawn applicant, late document, waitlist movement, or transfer. Record what happened, who corrected it, and how the applicant received a clear status.

Keep vendor capability, school responsibility, legal advice, and measured outcome separate. If evidence is incomplete, narrow the claim and the rollout rather than treating an assumption as a promise.

Review the decision at 30, 60, and 90 days. Look at completion, data quality, response time, access exceptions, family experience, support demand, and the original outcome. Decide whether to expand, repair, consolidate, or hold.

Before approval, ask an accountable reviewer to challenge the strongest claim. Replace broad language with the exact evidence, population, date, and limitation the school can verify.

Make the final record readable to an admissions operator and a reviewer who was not in the project. State what passed, what remains manual, what is deferred, who owns the unresolved item, and how a family receives help without creating an uncontrolled copy of applicant data.

Keep the approved record beside its acceptance tests, support guidance, and change history. A new campus, role, field, calendar, supplier, or family-facing output can change the risk even when the original workflow appears unchanged.