Project vs. operational GIS: a framework to help you prioritize
In this blog post from Esri Canada’s Cameron Wallace, learn the difference between project and operational delivery modes and find out how distinguishing between the two can help you prioritize more effectively.
In working with the GIS (geographic information system) functions at many different organizations, I’ve observed that GIS groups are tasked with two competing types of delivery. These two types of delivery can be termed project and operational delivery.
Project work is temporary, in that, no matter the length of time it takes (and this could be many years), it has a start and an end. It also produces a unique result.
Meanwhile, operational GIS generally consists of repetitive, permanent activities that produce similar results with no planned completion. Operational GIS changes with new processes, technologies or capabilities.
Operational GIS is focused on maintaining systems, functionality or data, while project GIS is focused on delivering a result within the iron triangle of cost, time and quality. The priorities of your activities are in part determined by whether or not you’re doing project or operational work.
Why is it important to consider these two types of delivery? Each type of delivery needs to be approached differently, both individually and organizationally. Within this post we’ll examine the following areas to consider when you’re determining which approach you’re going to take, and to help prioritize related activities:
- Budget and resourcing
- Priority
- Scheduling
- Access to technology
- Stability/change
In this blog post, I’ll go over how operational and project GIS will require you and your organization to consider all of these areas differently. Better understanding these elements will allow you to more effectively allocate resources, evaluate gaps in your approach and better deliver GIS to your organization.
Operational GIS
Organizational GIS typically has an operational component, which may entail most of the effort for at least some of the personnel involved. The operational component may not even be exclusively situated within the GIS function: various systems within the organization may support access to web-based geospatial technologies, maintenance of key operational data, licensing and technology access for desktop users, ongoing support for regular or repeated processes or business workflows.
The budget and resourcing for operational GIS tends to be relatively stable, with fluctuations in requirements being predictable. The specific budget or resource requirements of an operational GIS can vary substantially between organizations, but in general your own organization’s budget shouldn’t vary much from year to year.
While the priority given to operational GIS depends on the organization’s reliance on GIS and on the potential risk involved in disruption of that GIS, it’s often easier to understand than project GIS and more likely to be well-communicated and -documented. Some elements of operational GIS, such as publicly viewable web maps, might be considered critical infrastructure, with the highest priority given to minimizing disruption. Other elements of operational GIS, such as the maintenance of an infrequently used dataset, may be given lower priority. Delaying updates to that data may have little or no associated risk.
Scheduling for operational tasks is also related to the associated risk. Regularly scheduled updates to technology, the maintenance of data or the delivery of specific geospatial products or services may be associated with high risk (i.e., the time-sensitive decision on whether to proceed with high-priority initiatives with major implications might rely on key geospatial information/analysis/infrastructure). Lower-risk GIS tasks may come with considerably more flexible scheduling, where data received from a contractor can be processed and integrated into a dataset months or even years after the data is received, with few implications.
Maintaining or providing access to technology, whether through web-based technology, licensing or provisioning of software, is typically a higher priority, as the access to that technology is likely to determine whether a member of the organization can successfully complete tasks related to the technology. Thus, as GIS becomes more integrated into an organization, the risk of it becoming inaccessible increases.
Stability and predictability is a priority with operational GIS. Being able to ensure that adequate resources are allocated, key infrastructure is well supported, low-priority repetitive tasks continue to happen and that GIS is both a functional and reliable part of the organization is a key goal of operational GIS.
Project GIS
Project GIS relies on operational GIS and is often tasked with effecting changes to operational GIS. Projects can range from quick tasks accomplished for a stakeholder, such as the production or editing of a map or provision of a piece of analysis, to lengthier and more far-reaching tasks, such as upgrading an Enterprise stack or implementing governance. The relationship between project GIS and operational GIS can be complex and often blurry. The important thing to remember is that projects have a start and end date/time (which can be as short or long as needed).
It's difficult to effectively predict the necessary resources to support projects. Different organizations manage this in different ways. While there is no right way to manage this, each approach has its own costs and benefits. The two main approaches are to:
- outsource to effectively resource projects, and
- maintain sufficient capacity to support.
Budget/resourcing for project GIS can be difficult, as it may fluctuate throughout the course of the project, and, depending on how the project was scoped and is managed, can change rapidly. The scope, budget and schedule are typically managed by a project manager or a scrum master, depending on the nature of the project and the agreed-upon execution of it. The budget of a project should be defined, with processes in place to change it as needed, and should typically be related to the value of the project in some way. The lifecycle of a project is managed in different ways by different organizations, but generally some level of project control is expected (i.e. budget, schedule, deliverables, etc.). Some organizations like to outsource some or all of their project work, as they find it easier to manage from a resourcing perspective.
Projects are typically prioritized based on the value that they deliver back to the organization.
Scheduling for project-based GIS is typically controlled by a project manager, or at least using project management or agile principles. GIS projects can take hours or years, depending on the nature of the project. The timeliness of the project will need to be discussed with the project owners and stakeholders as part of the project initiation process.
Projects can require access to technical infrastructure and resources (who might also act as effective gatekeepers), careful consideration should be given to this aspect of technical projects, as the costs and timelines may have a substantial impact on the project’s overall success.
Projects are, by nature, intended to be executed over a scheduled period, and as such aren’t stable. However, they can contribute to the stability of your organization’s operations. One of the risks that a project team needs to manage is the stability of the factors that go into project execution. Projects can sometime produce solutions that will need to be migrated into the operational realm. The stability and lifecycle of those solutions should be considered during this migration.
In conclusion
Almost all the work we complete can be identified as either project or operational. Be sure to consider the distinction when evaluating your own interests. After all, every person has different talents and passions. Are you more of a project person? Or an operational person? Do you value stability over variety? Do you like to keep things on track, or find new ways to solve problems? No need to restrict yourself to one area or the other, but understanding your preference can help you focus your efforts and plan for training—or show you where you might need to direct your attention.
From an organizational perspective, does your organization have a clear distinction between project work and operational work? Are you expected to keep things operational off the side of your desk? Or execute project work alongside operational? Are projects well-managed and clearly prioritized? Or does your team work in a more agile, loosely defined way, defining priorities and delivering results in more of an iterative approach?
There’s no right answer, but it’s worth considering if this is a pain point for you or for your team—and that improved understanding might allow you to improve GIS delivery for everyone you work with.
If you’d like to hear more from Esri Canada’s Advantage Program advisors about GIS implementation at an organizational level, check out the Advantage Program stream here on the Esri Canada Resource Hub. Or, discover more about the Advantage Program if you’re interested in what I’m saying but aren’t sure how to proceed.