Software and analysis for the public sector.
Crown corporations, agencies, health authorities and universities: requirements that survive procurement, systems that meet privacy obligations, and delivery that fits PMO governance.
What we do
- Requirements for procurement
- Specifications and RFP requirements written so that vendors quote the same thing and the evaluation is defensible.
- Fit-gap and vendor evaluation
- Products assessed against your requirements and real scenarios before you commit, with the gaps weighted by what they would cost.
- Platform migrations
- CRM, ERP and payroll migrations with data mapping, validation, reconciliation against the legacy system, and a planned decommissioning.
- Automation
- Data collection, validation and processing workflows automated against business rules and acceptance criteria that are written down and agreed.
- Privacy by design
- Collection limited to what is needed, retention enforced by the system and audit trails on every change, built to the legislation that applies to you.
- Governance-ready delivery
- Decision logs, change impact assessments, test plans and status reporting that fit PMO standards rather than fighting them.
Where it usually hurts
If one of these sounds familiar, it is the kind of problem we are called in for.
- The RFP went out, and every vendor quoted a different project.
- A migration is planned, and nobody has mapped what the old system actually does.
- Staff re-enter the same data into three systems to meet three reporting obligations.
- The project board wants a decision log, and the vendor has never kept one.
- Privacy review comes at the end and sends the design back to the start.
Where this experience comes from
Our lead analyst's career history, described by sector — not an Elarion client list. More on the About page.
- A regional transit authority: a platform upgrade portfolio under PMO governance, and a payroll and reporting migration through to legacy decommissioning.
- A pension administrator: product owner for an enterprise automation programme, with functional designs, business rules and acceptance criteria.
- A public health organisation: a CRM platform migration with business requirements, functional designs, integration architecture and operational dashboards.
- A provincial distributor: a province-wide, regulated supply chain transformation.
- A university: integration of HR and facilities systems for asset and master data.
The format we write in.
Our sample functional design document — the specification for this website — shows the structure every engagement produces.
Questions buyers ask
- Can you work within our procurement rules?
- Yes. Analysis is often bought as a defined, fixed-fee piece of work, and where your rules require it, requirements can be written for a competitive procurement that we stay out of.
- Do you understand public-sector privacy obligations?
- Yes. Collection limits, retention and audit are designed in at the requirements stage, and the specification gives your privacy office what it needs for its review.
- Can you work inside our team and our PMO process?
- Yes — embedded analysis on a retainer or day rate, working to your governance, templates and tooling rather than ours.
Further reading
- How to write a functional design documentA functional design document is the reference a system is priced, built and accepted against.
- Why software projects fail at requirements, and how to stop scope creepWhen a software project fails, the code gets the blame.
- Privacy by design for custom software in CanadaPrivacy obligations are much cheaper to meet in the specification than in a finished system.
Related services
Planning a procurement or a migration?
30 minutes, free. Bring the problem, or the change you already have in mind.