How to plan a Salesforce implementation in government

Government Salesforce projects succeed or fail in planning. A practical guide to outcomes, procurement, security, records, data and handover.

A government Salesforce implementation succeeds when four things are settled before any build starts: clear outcomes, a procurement path that fits the work, security and records obligations agreed early, and a team that will own the system afterwards. Get those right and the build itself is rarely the hardest part.

This guide sets out how to plan each of them, drawn from public sector delivery since 2019. It is written for programme owners, ICT leads and project managers who have a business need and are deciding how to approach it.

Start with outcomes, not features

Salesforce can do a great deal, which is exactly why projects drift. A list of features is not a plan. Start instead with the outcomes your programme is accountable for: grants assessed within a set time, complaints resolved with a full audit trail, stakeholders managed consistently across divisions, or ministerial correspondence tracked from receipt to signature.

For each outcome, write down who is involved, what information they need, and what decision or action the system must support. This becomes the backbone of your requirements and, later, the basis for testing. It also gives you a defensible way to say no to requests that do not serve an outcome, which matters when every stakeholder has an idea for the new system.

Choose a procurement path that suits the work

How you buy shapes what you get. A large, single approach to market for the whole programme can work, but it forces you to specify everything before you know enough. Many agencies get better results by buying in stages: a short discovery and design engagement first, followed by build, with the design outputs forming the requirements for the next stage.

Common options include:

  • A request for quote to suppliers on a panel your agency already uses
  • A subcontracting arrangement through a supplier who already holds a contract with you
  • Specialist capacity added to an existing programme or consulting engagement
  • A staged approach to market, with discovery and design bought separately from build

Whatever the path, keep licensing separate in your thinking. Licences are a long-term commitment to Salesforce, and the number and type you need should come from requirements, not from an early estimate made before anyone understood the work.

Bring security and records in at the start

Security assessment is the most common reason a government Salesforce project slips late in delivery. The fix is simple: involve your security team in discovery, not in the final month. Agree early which data the system will hold, its classification, who needs access to what, and what evidence your assessors will want to see.

Records obligations deserve the same early attention. Decide which records the system creates, how long they must be kept, how they will be disposed of, and whether they need to be captured in your agency's records management system. These answers affect the data model, integrations and archiving approach, and they are far easier to design in than to retrofit.

On the Salesforce side, the platform offers strong building blocks: hosting in Australia, granular permissions, field-level security, event monitoring and encryption options. The design work is in choosing which of these you need, configuring them on least privilege, and documenting clearly which controls Salesforce provides and which your agency operates.

Plan the data migration early

Data migration is consistently underestimated. Legacy systems often hold years of records with inconsistent formats, duplicates and fields that meant different things to different teams. Discovering this a fortnight before go-live is how projects slip.

Start a data review alongside discovery. Identify the source systems, profile the data, decide what is worth migrating, and agree who in the business will make decisions about cleansing. Plan at least two trial loads, each with reconciliation reports that business owners sign off, before the final cutover.

Design for the team that inherits it

Government systems outlive project teams. Contractors leave, staff rotate, and the people who run the system in three years will not have been in the original workshops. Plan from the start for the people who inherit it.

  • Favour standard Salesforce features over custom code wherever they meet the need
  • Record every significant design decision with the reason behind it
  • Name a business owner and a system administrator before go-live, not after
  • Budget time for handover sessions and written runbooks, not just training

A system that your own staff can understand and maintain is cheaper to run, safer to change and far less likely to drift into the tangled state that eventually forces a rebuild.

Stage the delivery

Large programmes are safer when delivered in stages that each provide something usable. A first release might cover one grant programme or one team's case management, with later releases adding programmes, portals and integrations. Each stage gives you real feedback from real users, a chance to correct course, and evidence of progress for your executive and your minister's office.

Staging also helps procurement and budgeting. It is easier to approve a well-defined first stage than an entire programme on the strength of an early estimate.

A planning checklist

Before you approach the market or start a build, check that you can answer these questions:

  • What outcomes is the system accountable for, and how will we measure them?
  • Which procurement path suits the size and certainty of the work?
  • What data will the system hold, at what classification, and who needs access?
  • What records obligations apply, and how will they be met?
  • Which systems must it connect to, and which system owns each piece of data?
  • What data will be migrated, and who will make cleansing decisions?
  • Who will own and administer the system after go-live?

If any of these are unclear, a short discovery engagement is usually the most valuable money you will spend on the project. It is also the stage where an experienced outside view can save the most effort later. If you would like to talk through your plans, call 0494 743 131 and speak directly with one of our consultants.

Written by

Rami, Syntmatic

Salesforce developer and architect, delivering for the Australian public sector since 2019.

Contact

Talk to the consultants who do the work

A phone call is the quickest way to start. Tell us what you are working on and we will tell you plainly whether we can help.

Send an enquiryhello@syntmatic.com.au

Call 0494 743 131