How to Write a GIS Project Brief That Gets Accurate Quotes

Two GIS providers can quote very different prices for what sounds like the same project. Usually the difference is not the providers but the brief: each one fills the gaps with different assumptions. A clear brief reduces those gaps, produces quotes you can compare and starts the project on the right foot.

You do not need a long document. Two or three pages covering the points below are usually enough.

1. The problem and the goal

Start with why the project exists:

• what is difficult or slow today
• who is affected and how often
• what a good outcome looks like in six or twelve months

"Field teams spend hours each week re-entering inspection data from paper" tells a provider far more than "we need a mobile app".

2. Users and their tasks

List each type of user and what they need to do:

• public visitors: find a plot, check availability, view a route
• staff: edit records, approve changes, run reports
• field workers: collect data, often offline
• managers: see dashboards and trends

Include rough numbers. Ten internal users and fifty thousand public visitors need different architectures.

3. Data

Data usually drives cost more than screens do. Describe:

• what data exists, its formats and approximate size
• where it lives now and who maintains it
• coordinate systems, if known
• quality: is it clean, or full of duplicates, gaps and errors?
• how often it changes
• any data you will need to buy or license

Attach a small sample if you can. Providers can then estimate cleaning and conversion work properly.

4. Integrations

List the systems the solution must connect to, such as CRM, ERP, SCADA, asset management, document storage or identity providers. For each, note whether an API exists and who can provide access.

5. Platform, hosting and licences

State any constraints:

• existing platforms, such as ArcGIS Enterprise or PostgreSQL
• preferred cloud or on-premise hosting
• security or data residency requirements
• licences you already hold, and whether you are open to open source alternatives

If you are unsure, say so. A good provider will recommend options and explain the cost implications of each.

6. Must-haves and nice-to-haves

Separate essential features from those that can wait. This lets providers propose a sensible first release and gives you room to negotiate scope rather than quality.

7. Acceptance and handover

Explain how you will decide the work is complete:

• who will test and approve each milestone
• what documentation you expect
• whether your team will maintain the system afterwards
• where code and data must be stored

8. Timeline, budget and support

Share any fixed dates, such as a launch event or a software retirement deadline. A budget range, even a broad one, helps providers propose a realistic scope instead of guessing. State whether you need ongoing support and what response times matter to you.

What to ask for in return

Request that each provider includes:

• their understanding of the problem in their own words
• assumptions they have made
• proposed approach and technology, with reasons
• milestones and what you will see at each one
• who will do the work
• relevant examples, with their role in each

Summary

A good GIS brief explains the problem, the users, the data and the constraints, and is honest about what is unknown. It takes a few hours to write and saves weeks of misunderstanding. The quotes you receive will be easier to compare, and the project that follows will start with a shared understanding.