Onboarding a New GIS Team: A 30-Day Checklist

The first month with a new GIS team, whether internal hires, contractors or an external partner, sets the pattern for everything that follows. A good start builds trust and momentum. A slow start, spent waiting for access and explaining the same things repeatedly, can cost weeks. This checklist is what we recommend clients prepare, and what we follow ourselves when joining a project.

Before day one

Access

• accounts for the code repository, issue tracker and chat
• GIS platform access: ArcGIS Online or Enterprise roles, or database roles for PostGIS
• cloud or server access for development and staging only
• VPN or remote desktop if data cannot leave your network

Information

• a one-page overview of the project, its users and goals
• architecture diagram, even a rough one
• list of systems and data sources, with owners
• known problems and previous attempts

Data

• a representative sample dataset, anonymised if needed
• data dictionary or schema, if one exists
• the coordinate reference systems in use

Week 1: Understand

• kick-off call with the people who will use the system, not just managers
• walk through current workflows end to end, ideally with screen sharing
• review existing code and data: what can be reused, what needs fixing
• set up development environments and confirm the team can run the system locally
• agree ways of working: daily updates, weekly demo, how decisions are recorded

By the end of week one, the team should be able to describe the problem in their own words, and you should agree with their description.

Week 2: First delivery

Pick a small piece of real work that can be finished and shown within days: a bug fix, a new layer, a data cleaning script or a simple report. A first delivery tests the whole path: access, environments, code review, deployment and acceptance. Problems found here are cheap to fix.

Weeks 3 and 4: Plan and build

• refine the backlog into milestones with acceptance criteria
• document the data model and naming conventions
• set up automated checks: tests, linting, data validation
• agree the release process from development to staging to production
• start the first milestone with regular demos

Documentation to build as you go

Waiting until the end to document a GIS system rarely works. Keep these up to date from the first month:

1. architecture overview and environments
2. data model: layers, fields, coordinate systems, relationships
3. how to deploy and roll back
4. where credentials and configuration live, without the secrets themselves
5. known limitations and decisions taken, with reasons

Signs onboarding is going well

• the team asks precise questions about data and users
• the first delivery reaches staging within two weeks
• you see working software every week
• decisions are written down and easy to find

Signs it needs attention

• engineers still waiting for access after the first week
• no running environment by the end of week one
• weekly updates without anything you can try
• recurring confusion about the same data or requirement

Summary

Prepare access and data before the team starts, get a small real delivery out within two weeks, and document as you go. A well-run first month turns a new team into a productive one quickly, and makes later handover straightforward.