What makes government software projects different (and harder)

01.1. Procurement rules shape timelines

Public bodies buy under formal rules designed to be fair and transparent. They require specifications, evaluations, approvals and contracts. That protects public money, but it also means a project may spend months before work starts, and changes to scope may need a new approval.

What helps is realism. Build the procurement period into the plan. Prefer phased contracts where scope can be adjusted between phases. Write requirements in terms of outcomes, such as applications processed online, not just a list of screens.

02.2. Many stakeholders must agree

A permitting portal touches the applicant, counter staff, technical reviewers, finance, legal, IT, a security team and an elected sponsor. Each has a stake, and each may have a veto.

Drawing a stakeholder map in the first week saves trouble. List who decides, who is affected and who must be consulted. Agree a single product owner who can resolve conflicts. Keep decision logs, so the team does not reopen settled questions.

03.3. Accessibility and language requirements

Public services must be usable by everyone: people with visual, motor or hearing impairments, people on old phones or slow connections, and people who read in different languages.

This is a design requirement, not a final polish. Follow WCAG guidelines from the start. Test with a keyboard and a screen reader. Plan for translation, including longer text and different scripts. Write in plain language, with short sentences and no jargon. Include a way to apply offline for those who cannot use the online route.

04.4. Strict security and data rules

Government systems handle personal data, payments and records that may need to be retained for years. There are rules on where data may be stored, who may see it and how long it is kept. Audits are routine.

Build for that. Use role-based access, record every significant action, encrypt data in transit and at rest, and agree the hosting location early. Keep documentation current, because auditors will ask for it. Treat data minimisation as a feature: collect only what the service needs.

05.5. Legacy systems that cannot be switched off

Most new services connect to something old: a register, a finance system, a records archive. These systems may have little documentation and no API, and they cannot be shut down while the service runs.

Plan integration early. Find out what each system offers: database access, export files or an interface. Test with real data. Run old and new processes in parallel during the pilot. Keep the legacy system as the record until the new one has proved itself, then migrate in stages.

06.6. Success is measured in public trust

A private company can ship a rough first version and refine it. A public service that fails in the first week makes the news, and the loss of trust lasts. At the same time, success is not measured only in revenue. It is measured in applications completed, time to decision and whether people feel treated fairly.

Define a few outcome measures at the start, such as approval time, share of applications submitted online and repeat enquiries. Report them openly.

07.A short planning checklist

• Map stakeholders and name a product owner.
• Confirm procurement and approval steps, and add them to the schedule.
• Choose one service for the first release.
• Agree security, hosting and data rules before design.
• Set accessibility and language requirements as acceptance criteria.
• Plan how legacy systems will connect and how long they will run in parallel.
• Define three measures of success.

08.An example: the approval chain

Suppose a licensing portal needs sign-off from four teams: the case officer, a technical reviewer, finance and legal. In the private sector, one product owner might decide the flow in an afternoon. In government, each team has its own rules and may have written them into policy.

A project that treats this as a delay will always be late. A project that treats it as a design input does better. Map the chain, find which approvals are truly required and which are habit, and ask whether some can run in parallel. Build the workflow so a case waiting on one team is visible to everyone, with a time limit and an escalation path.

The software then does something the paper process never could: it shows exactly where each application is stuck.

09.Phasing the work

Large public projects often fail because they try to deliver everything in one go. A phased plan works better.

• Phase one: a single service, end to end, for a limited group.
• Phase two: wider rollout, extra services reusing the same components.
• Phase three: integration with further registers and retirement of paper steps.

Each phase should end with something people can use and measure. That gives sponsors evidence for the next approval, and it gives the team a chance to learn before the stakes rise.

10.Showing early wins

Early wins are not decoration. They are how you keep a project alive across budget cycles and changes of leadership. A working form in week six, a staff dashboard in week ten, a first set of real applications in week twelve: each is a reason for sponsors to continue.

Share progress openly. Invite staff to try the pilot, and report what worked and what did not. A project that admits a problem early earns more trust than one that hides it until launch.

11.Common mistakes

• Starting with the biggest service. Begin with one where the process is clear.
• Leaving security review to the end. Late findings cost months.
• Assuming staff will adopt it. Involve them in design and train them.
• Hiding delays. Share early wins and early problems alike. Trust grows from candour.

12.Running costs and ownership

Many public projects are funded to build and not to run. After launch, someone has to fix bugs, update forms when rules change, apply security patches and answer staff questions. If that is not planned, the service decays and trust falls.

Agree early who owns the product, which team supports it and how changes are approved. Train in-house staff to handle routine changes such as fees and form fields, so every small update does not need a contract. Write runbooks and keep them current. A service that is cheap to keep running is far easier to defend at the next budget review.

Keep these ownership decisions in a written plan that outlasts any one person on the team.

13.What to do next

Pick one service and hold a half-day workshop with the people who run it. Map the real steps, find the one that wastes the most time, and design a first release that fixes it. Show something working within weeks.

Government software is harder because more people depend on it and more rules apply. It is also rewarding, because improvements are visible to many. At Brandsmashers we work with public bodies in phases, with early demos and clear documentation. If you are planning your first digital service, a scoping call can help you shape it.