Skip to main content

Last reviewed: 16 August 2026

The one-person GIS

Many Māori GIS environments begin with one capable person.

That is not automatically a problem. One person can move quickly, learn the whenua, build trust and keep a small system coherent.

The risk begins when the GIS becomes inseparable from that person.

If only one person knows the passwords, project structure, source history, publishing process and meaning of the layers, the organisation does not really have a GIS capability. It has access to somebody else's memory.

Keep the advantage, remove the dependency​

A one-person GIS can remain lean while reducing risk.

The aim is not to create bureaucracy around the mapper. It is to make the important parts legible to another person.

Start with five questions:

  • Where are the authoritative working files?
  • Which accounts control publishing and storage?
  • Which datasets matter most?
  • Which information is restricted and why?
  • Who can keep the basic service running if the mapper is away?

If those answers exist only in one person's head, document them first.

Accounts belong to the organisation​

Avoid using a personal email account for:

  • ArcGIS administration
  • cloud storage
  • domain registration
  • paid software licences
  • backup services
  • drone accounts
  • shared data portals
  • API keys where organisational ownership is possible

Use organisational accounts and record who can recover them.

Where a service only permits named personal accounts, make sure the organisation still controls billing, recovery and administrative access.

Keep a one-page map of the GIS​

Create a simple document showing:

  • primary storage location
  • restricted storage location
  • backup location
  • main QGIS or ArcGIS projects
  • web publishing platform
  • important external services
  • account owners or administrator roles
  • who to contact for each part

Do not make this an architecture masterpiece. It should be understandable in five minutes.

Document the unusual things​

You do not need a manual for ordinary QGIS functions.

Document what another competent person would not be able to infer, such as:

  • why a particular rohe layer exists
  • why two nearly identical land layers are both retained
  • which cultural layer must never be published
  • which council extract has been manually corrected
  • where the original historical map came from
  • how a recurring report is produced
  • which web map depends on which hosted view
  • what must happen before a public update

Those notes preserve organisational memory rather than software instructions.

Make projects portable​

A project should not work only on one person's laptop because it points to:

C:\Users\Fred\Desktop\new GIS stuff\really final\

Use stable organisational paths where possible.

For small QGIS projects:

  • keep project and related local data together in a predictable structure
  • use relative paths where suitable
  • package required styles and templates
  • avoid hidden dependencies on temporary downloads
  • keep an unchanged source copy separate from edited data

Create a second pair of hands​

The second person does not need to become another GIS specialist.

Teach them how to:

  • open the main project
  • export a standard map
  • find the source register
  • restore the most important data from backup
  • recognise restricted layers
  • identify which account administers publishing
  • stop rather than publish when authority is unclear

That is enough to reduce a major continuity risk.

Reduce cleverness​

One-person systems often accumulate brilliant little scripts, plugins, expressions and automations.

Some are worth keeping. Some make the GIS impossible for anybody else to inherit.

For every custom process, ask:

  • How much time does this genuinely save?
  • Can another person understand it?
  • Is the dependency still maintained?
  • What happens if it breaks next year?
  • Would a simpler manual step be safer for a task done four times a year?

Automation should remove repetitive work, not hide essential knowledge.

Protect relationships as well as files​

The one-person risk is not only technical.

The mapper may hold relationships with:

  • kaumātua and knowledge holders
  • council GIS staff
  • Crown agencies
  • consultants
  • neighbouring iwi and hapū
  • software providers
  • researchers

A handover needs to transfer context around those relationships rather than simply exporting an address book.

Where appropriate, introduce a successor or second staff member while the relationship is active.

Leave a clean trail​

At minimum, keep:

  • a current source register
  • a short change log for important maintained layers
  • a list of public maps and who approves them
  • a backup note
  • administrator and recovery information
  • a list of known risks or unfinished work
  • a START HERE document

A successor should not have to perform digital archaeology on your folders before they can make a map.

If you are leaving​

A practical handover sequence:

  1. Identify the ten most important datasets and projects.
  2. Confirm they open on another computer or account.
  3. Transfer or verify organisational ownership of accounts.
  4. Test backups.
  5. Remove personal credentials from scripts and projects.
  6. Explain restricted information and its tikanga or governance conditions.
  7. Introduce key relationships where appropriate.
  8. Produce one map with the person taking over.
  9. Write down what you would fix next if you stayed.
Last updated on