GIS Projects: Triaging Considerations Series - Part 4

March 5, 2025

Nathan Enge

Continuing in this 6-part series on a 6-pillar framework to help navigate and prioritize GIS projects - Part 4 addresses understanding technology. By the end of the series, you'll have a handy guide to assist you in triaging projects, making the process smoother and more manageable. If you stay tuned until the end, I’ll also include a cheat sheet to help.

As prefaced in parts 1, 2 and 3, it's important to note that this framework is based on my experiences as a consultant and technical solutions specialist. It draws from personal project-level experience and relative risk assessments and may not fully align with your organization's stance on technology, training and capacity, business workflows or security and privacy.

The Six Pillars for GIS Project Triage Consideration

Graphic of Image - Framework for triaging contains 6 pillars

Framework for triaging contains 6 pillars

Just to review from my previous posts, this framework considers six pillars for triaging GIS project requests:

Return on Investment (ROI): Does the project have a tangible return on investment?
Risk: What associated risks are anticipated with the project?
People: What capacity is required for the project and its sustainment throughout its typical lifecycle?
Technology: What pieces of technology or equipment are required to ensure the project's success?
Data: Is the data involved in the project accurate, secure, accessible and timely?
Application & Project: What are the project deliverables, outcomes and measures of success?

This blog post will focus on understanding technology considerations to a successful project implementation.

Understanding Technology

Graphic of Image – Technology

Understanding Technology

Understanding How it Helps

Graphic of Image - 5 suggested pillars for a municipality</>

5 suggested pillars for a municipality

A proposed GIS project must have a clear business value proposition. What value will this project bring to my organization? Let’s assume we’re a local government; I’ve suggested five pillars where a project would bring business value. Pro-tip, take a look at your organization’s core values and mission statement and build your pillars from there.

Upgrading an ArcGIS Enterprise with a modern enterprise-level geodatabase, accessed through web-services and integrated into other crucial business systems would further enhance our ability to manage authoritative content. Imagine this ArcGIS Enterprise deployment also participated in a distributed collaboration with another department’s enterprise deployment, allowing for authoritative content to move seamlessly between data owners and data stewards.

Leveraging that authoritative content, we can summarize, analyze, visualize and report on city conditions using business intelligence applications such as ArcGIS Insights or ArcGIS for PowerBI. With an enterprise-level GIS, integrated with our permits and licensing application or powerful asset management software, we can gain even more insight.

Another key pillar is enabling location-awareness. In the context of a local government, a GIS project that – for example, implements a location-aware infrastructure management system such as Cityworks would optimize resource management, improve maintenance and operations and lead to data-driven decision making. If one of the city’s values is to promote equitable and equal access to its services, having an application visualize areas of underserved neighbourhoods can help drive initiatives and new policies.

Perhaps leadership and decision-makers are lacking easy access to timely information they can use in council and committee meetings. Rather than drawing upon GIS resources on ad-hoc basis, providing self-service tools such as web maps, apps and dashboards enables and empowers executives to visualize information quickly and at-a-glance. ArcGIS Dashboards, specifically is designed to show summary statistics, KPIs and even visualize comparative statistics.

Municipalities serve their residents and sometimes must make difficult decisions for the betterment of the community. Community or public engagement activities are opportunities for the staff to present the problem and potential solutions and it’s also an opportunity for all stakeholders to provide feedback. A potential GIS project in this space would be the implementation of visualization tools such as ArcGIS Storymaps, 3D visualization, single-focus applications, etc. These tools provide an interactive experience for stakeholders to explore scenarios and to think about the questions and assumptions they had going into these events. For stakeholders unable to attend in-person events, organizations could deploy virtual public engagement platforms such as ArcGIS Hub – empowering citizens to have their unique voices heard in a private and secure environment.

Although we used an example city for context, identifying pillars where the technology can help in any context will greatly improve the business value proposition and therefore buy-in from leadership.

Understanding Integration

When triaging projects, it's crucial to understand the potential integrations involved. Projects with no integration, such as configuring an ArcGIS Dashboard, typically represents lower risk. However, if further discovery reveals that a layer required for the dashboard needs to be integrated via API, the project's risk increases slightly. This depends on how well the API is documented and whether real-time Extract, Transform, Load (ETL) tools are available.

Database-level integration poses a higher risk because it requires a database engineer's expertise to write SQL and create triggers and other functions for the integration to work. This increases the project's cost, time and resource requirements.

I further categorize high risks into "known unknowns" and "unknown unknowns." Known unknowns are integration risks where we know an integration is needed but don't yet understand the solution. Unknown unknowns are projects with potential integration points we are unaware of. These factors significantly influence how we triage a project.

Understanding Service Level Performance Expectations

When triaging and evaluating a project, it's essential to consider our stakeholders' expectations regarding service level performance. The criticality of the project delivery will significantly influence these expectations.

Non-Critical (Low Risk): If some downtime is acceptable, the project is considered non-critical. This scenario typically involves lower risk and less stringent service level requirements.
Critical (Medium Risk): If minimal downtime is preferred, the project is deemed critical. This requires a higher level of service performance and involves medium risk, as stakeholders expect the system to be available most of the time.
Mission-Critical (High Risk): If no downtime at all is expected, the project is mission-critical. This scenario involves high risk, as it demands the highest level of service performance. Any downtime could have significant consequences for the business.

Understanding these expectations helps us better assess the project's risk and allocate resources accordingly.

Understanding the Esri Stack

When evaluating the technology component of a potential project, it's crucial to consider the Esri software required. Here's a breakdown of the risk levels associated with different scenarios:

Use What We Got (Low Risk): Projects utilizing Esri software and licensing that is already available in the system through a purchase agreement or enterprise agreement. These projects are considered low risk because the software is already implemented and familiar to the team.
Need to Include Other Software Not Yet Implemented but in our EA (Medium Risk): Projects that require Esri software not yet implemented but included in an enterprise agreement. These projects carry a medium risk as they necessitate a certain level of training and familiarity to be deployed successfully.
Needs New Software (High Risk): Projects involving entirely new software, whether Esri or otherwise. These projects pose the highest risk to success due to the steeper learning curve and potential integration complexities.

Understanding these risk levels can help in making informed decisions and ensuring the successful deployment of Esri software in your projects.

Understanding the Environment

This is one of those examples where your organization’s IT policy is not in alignment with my perspective. This is why on either side of the above likert scale I have indicated SaaS as both green and red and on the On-premises side as well. An organization may deem that having a cloud-hosted and managed application is high risk, while another organization may find that it lowers their risk. Again, we are looking at this from a technology perspective.

An implementation project for an asset management system that will be wholly managed in the cloud, for example, lowers the technology risk for some organizations as it is more cost-effective and reduces the requirement for IT specialists needed for upgrades, maintenance and troubleshooting. Applications involving Infrastructure as a Service (Iaas), for example, where an entire enterprise GIS is deployed in the cloud like Azure or AWS and managed in-house – this requires significant resources to maintain, upgrade and troubleshoot. However, if the IT policy of the organization is to migrate business applications into the private cloud environment, this reduces the risk as there will already be associated resourcing available.

Projects that involve implementing systems in a hybrid or partly cloudy environment may become higher risk due to several critical factors. Firstly, there is a necessity for a robust interconnected network, which must seamlessly integrate various components and services. This integration often requires identity federations to ensure secure and efficient access management across different platforms and environments. Additionally, these projects must prioritize the security of data both at rest and in transit. This means implementing strong encryption protocols, regular security audits and compliance with relevant data protection regulations. The complexity of managing these aspects can increase the overall risk, making it essential for organizations to have a comprehensive strategy and skilled personnel to mitigate potential vulnerabilities.

I would consider projects that implement systems and applications on-premises as highest risk due to the nature of hosting physical hardware and the resource-intensive workload it represents including evaluating the project’s business continuity plan, disaster recovery, high availability and generally – its security and privacy.

For each of these environments, a critical factor to consider is the level of effort it requires to promote your project through its development – testing – staging and production environments.

Understanding the Pervasiveness of the Project

Understanding the project’s pervasiveness

Implementing a project deliverable accessible from a connected environment is relatively straightforward. However, more consideration is required when the project needs to be mobile-first. This could involve a web application that incorporates adaptive UI/UX practices for users switching between mobile and desktop screens or a project that delivers an application using the native app SDK (downloadable applications from various operating system app stores).

When users require an application to work in a disconnected or offline environment, the level of effort and complexity of the project significantly increases. Understanding this technical requirement early in the proposal process will help guide discussions on offline data storage, data synchronization, security and permissions, user experience and acceptance testing. Consider out-of-the-box configurations of ArcGIS solutions such as ArcGIS Pro offline capabilities, ArcGIS Enterprise in a disconnected environment and mobile applications configured as offline-first.

A project requiring a seamless transition between connected and disconnected environments on mobile devices in an ad-hoc manner demands significant planning. This involves many of the same considerations as a “disconnected-only” environment, with an added focus on understanding how the seamless transition will occur and exploring performance optimization options. While out-of-the-box configurations of ArcGIS solutions are ideal, Esri developer tools can provide additional capabilities.

In this post, we explored the key technology considerations when evaluating a project proposal. It's crucial to understand how the technology will support the organization's mission. We also examined the effort required to integrate various technologies, including Esri software and licensing, which helps us gauge service level expectations, the operating environment and user access to the deliverables. With a comprehensive understanding of these technology aspects, we can delve deeper into the data requirements that will drive our technology decisions. Stay tuned for our next blog post, where we will discuss data considerations in detail.