GIS Projects: Triaging Considerations Series - Part 6

Just to review from my previous post, 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 the Application & the Project. 

Understanding Applications & Projects

Understanding Applications and Projects

Welcome to the last part of my series on project triage considerations. This blog post focuses on considerations from an overall project perspective. It also looks at an example deliverable – a web application. Through our exploration of some of these considerations, hopefully you’ll see how this can apply to other projects like migrations, upgrades, rip and replaces, etc.

Understanding our User stories, Use-Cases and Workflows

Understanding the User Stories

For larger projects involving multiple stakeholders or complex workflows, understanding user stories is crucial. A project proposal that thoroughly comprehends these stories is more likely to succeed due to a comprehensive phase of gathering both technical and non-technical requirements.

However, it's impossible to map every possible scenario and workflow. This is why an agile and iterative approach to development is encouraged. It allows for flexibility in design while staying focused on achieving the main functionality.

On the other hand, project proposals that lack user insights are less likely to succeed. If actual users are not engaged in the process, the project will reflect a non-user’s perspective, which often fails to capture the true needs of the users. Consequently, the adoption of the deliverable will face resistance.

Understanding Re-useability

Understanding Re-useability

When evaluating a project, it's important to consider whether the project will result in technology components or skills that can be repurposed, recycled or reused in other parts of the organization. Fortunately, most projects do result in deliverables that can be reused. However, we should be cautious with projects that require significant effort with specialized skills and technology for one-off tasks. For example, if a project necessitates the temporary hiring of specialized consultants for integrating an application without an API, it can be considered higher risk because much of the knowledge and intellectual property may be 'hidden' during knowledge transfer.

To mitigate these risks, we should prioritize the use of solution templates and out-of-the-box configurations as much as possible. This approach allows for minor customization and aligns with a common DevOps framework, enabling the codebase to be shared more effectively.

Understanding the Project and App Development Approach

Understanding Project and App development Approach

Agile and DevOps methodologies are particularly beneficial for GIS projects, including cloud-first implementations, GIS mapping application upgrades and new front-facing mapping apps. Agile's iterative approach allows for continuous reassessment and adaptation, which is crucial for handling the complex and evolving requirements of GIS projects. For instance, in a cloud-first implementation, Agile enables the team to incrementally deploy and test components, ensuring that each part works correctly before moving on to the next. This reduces the risk of large-scale failures and allows for quick adjustments based on user feedback.

DevOps further enhances Agile by integrating development and operations, ensuring seamless collaboration and efficient workflows. Version control systems like Git are essential for tracking changes and managing multiple developers working on the same project, which is common in GIS mapping application upgrades. Together, Agile and DevOps provide a robust framework that enhances flexibility, reduces risks and ensures high-quality outcomes for GIS projects.

In contrast, the Waterfall approach is riskier because it follows a linear, sequential process where each phase must be completed before moving on to the next. This can lead to significant issues being discovered late in the project, making them more costly and time-consuming to fix.

Understanding Lifecyle Management and Hygiene Responsibility (The RACI)

Understanding Lifecyle Management and Hygiene Responsibility (The RACI)

While these topics deserve their own detailed discussion, this one is particularly important. In most software development lifecycle (SDLC) frameworks, it is crucial to have clear roles and responsibilities for the project team, sustainment, owners and end users. Establishing this clarity early in the project proposal phase prevents confusion and ensures all team members understand their roles. This awareness facilitates effective communication within teams and with external stakeholders, ensuring the right people are involved in decision-making at the right time.

By clearly defining team roles, we can assign accountability and allocate resources efficiently, thereby reducing project risks. Implementing a RACI matrix early in a proposed project sets a strong foundation for project management and helps in budgeting for necessary resources.

A RACI Matrix is a table that defines the decision-making rights of the teams involved in the project. It stands for Responsibility, Accountability, Consulted and Informed. My colleague Matt Lewin describes the use of RACI in the governance implementation process. Although this is discussed at the macro (organizational) level, we can adapt RACI to the micro (project) level. Implementing a geospatial strategy with a well-defined corporate governance structure fosters an environment where these frameworks can be applied at the project level.

For example, the following RACI matrix outlines the roles for a project that migrates ArcGIS Enterprise from an on-premise deployment to the Azure Cloud environment:

Understanding RACI

At each phase of this migration project, we have clarity on each team's role and responsibility. This information helps the project assessment team decide on budgeting and resource allocation timelines.

Understanding Lifecycle Resourcing

Understanding Lifecyle Resourcing

As an adjunct to understanding the RACI, we should have some idea of level of effort (resources and time) that will be required for each phase. This is likely where I would ask a lot of questions related to identifying the core team members for each phase.

Understanding the Time-to-Live Requirement

Understanding Time-to-Live Requirement

Projects with a clearly set go-live time are beneficial. However, if these timelines are compressed without adequate resources and budgeting, they can become challenging. Projects with a well-defined timeline and a fully resourced budget tend to be lower risk compared to those required "yesterday." These urgent projects often arise from immediate unforeseen operational needs or external pressures.

For example, if a region experiences sudden and extreme wildfires, the organization may lack the "muscle memory" to meet the need for public information dissemination. Such projects, which involve life-and-death information, can be highly risky as they require on-the-fly application development. This scenario can be likened to building a plane while flying it. However, this risk can be mitigated through agile or iterative project frameworks, starting with a minimum viable product (MVP) and adding functionality in sprints. ArcGIS solution templates and app builders are uniquely situated for this process and I have assisted many customers, in their time of emergency, in building public-facing applications so they can make critical and timely decisions.

Projects with a "mañana" timeline are medium risk because they are typically not yet business-critical and often do not receive the attention they deserve until it's too late. For instance, a project to upgrade ArcGIS Enterprise to the latest version may be repeatedly postponed for various reasons until a vulnerability attack occurs, compromising the organization's GIS. It is always good practice to keep enterprise spatial systems updated and patched to prevent vulnerabilities.

Understanding Accessibility Requirements

Understanding Accessibility

In many organizations, especially within government, there's a recognized need to improve the implementation of enabling technology to meet accessibility mandates. Applications and projects that follow WCAG AA guidelines align with these goals. However, projects that deviate from WCAG AA, such as those only meeting WCAG A, aiming for WCAG AAA or worse, being non-compliant, pose significant risks.

Reasons for Increased Risk:

Legal and Regulatory Compliance: Not meeting WCAG AA standards can lead to legal issues, as many accessibility laws reference these guidelines. Failure to comply can result in lawsuits, fines and other legal actions.

User Accessibility and Experience: WCAG AA ensures that web content is accessible to a wide range of users, including those with disabilities. Projects that only meet WCAG A may not address critical accessibility barriers, making the content difficult or impossible for some users to navigate. While aiming for WCAG AAA is ideal, it can be challenging to achieve across an entire site and may not be necessary for all content.

Reputation and Trust: Organizations that fail to meet accessibility standards risk damaging their reputation. Users expect accessible and inclusive digital experiences and non-compliance can lead to negative public perception and loss of trust.

Financial Implications: Fixing accessibility issues after a project is completed can be costly. It's more efficient and cost-effective to integrate WCAG AA compliance from the beginning rather than retrofitting solutions later.

Inclusivity and Social Responsibility: Adhering to WCAG AA shows a commitment to inclusivity and social responsibility. It ensures that digital content is accessible to all users, regardless of their abilities, promoting equality and diversity.

Esri incorporates inclusive design principles throughout the creation of core software, website and design systems. The ongoing mission is reflected in the usability of products and solutions. Esri’s commitment to accessibility is found here and includes access to conformance audits and reporting.

Understanding the Volume of Users and How Often

Understanding the Volume of Users and How Often 

Understandably, projects or applications with a wide user base are generally considered lower risk from a business value perspective, though they may be high risk in other areas. For example, the need for high-service availability for an enterprise GIS makes it high risk in terms of reliability and uptime. However, from a broader project level, an application used by many within the organization can significantly support the organization’s mission of being employee centric. By providing comprehensive technology, it empowers staff to perform their duties efficiently and effectively, making it an overall low-risk opportunity to deliver business value.

On the other hand, a one-off project that serves only a few users can be considered higher risk, especially if it requires significant resources to implement and sustain. These projects may not provide the same level of return on investment and can divert resources from more impactful initiatives.

For example, consider a project proposal to custom-develop an application that automates the annual PSAB reporting obligation – tangible capital assets reporting. If the proposal considered all the potential risks involved, such as time and resourcing, no integration, etc., there might be an opportunity to look at commercial off-the-shelf (COTS) solutions like Cityworks that users can use to generate reports themselves. If there are many requests for point-solutions and custom applications, it may be worth reevaluating these asks in a broader context to see if there is a viable project to implement a geospatial asset management system for the wider organization that addresses the challenges these point solutions are trying to solve.

Understanding the Modality of Access

Understanding the Modality of Access

Web browser-based applications are generally lower risk because they can be accessed from any device with a web browser. This makes them very accessible and compatible, reducing the chance of compatibility issues and reaching a wider audience. Plus, updates are easy since they happen centrally, so everyone gets the latest version without any hassle. They also tend to be cheaper to develop because there's no need to create different versions for each operating system.

Mobile-only web applications have a bit more risk. They need to consider screen size and bandwidth and mobile browsers might struggle with complex tasks. However, using tools like ArcGIS templates can help manage these challenges.

Mobile-only native applications depend on specific operating systems like iOS and Android, which can limit their user base and require separate development for each platform. They also face unique security challenges and need to be optimized for different devices, making development and testing more complicated.

Applications downloaded from app stores come with their own risks. Even though app stores have strict policies, there's still a chance of malicious apps getting through. Users also need to manually update these apps, which can delay important security fixes. Plus, app stores control the distribution, which can limit how developers manage updates.

On-premises installed applications are the highest risk. They need specific libraries, hardware and manual installations. These applications need to be certified safe for users' machines and designing a good user interface can be resource-intensive. Scaling these applications can also be challenging and costly.

Understanding the Project Communication Strategy

Understanding the Project Communication Strategy

As a GIS Project Coordinator, you might not always focus on how a project or application will be communicated to others. This responsibility might fall to someone else in the RACI chart. However, it's important to know who will be seeing the application or project.

This is especially true for projects that use an iterative or agile approach. Managing the expectations of clients and users throughout the project can help reduce the risk of not meeting requirements.

I consider communication strategies for public-facing applications to be the highest risk. The messaging needs to align with the corporate mission, the overall GIS strategy, public expectations and the technical and non-technical requirements of the project. Once communication is out, it's difficult to retract if there are errors. So, when evaluating a project proposal, we should consider who will receive the communication and when it will be sent out.

Additionally, projects that require more evangelism are higher risk. These projects often need extensive promotion and advocacy to gain user adoption and support. This can be challenging because it involves convincing stakeholders of the project's value and ensuring consistent messaging across different channels. If the evangelism efforts are not successful, the project may fail to achieve its intended impact, leading to wasted resources and potential reputational damage. Therefore, it's crucial to carefully plan and execute communication strategies for these projects to mitigate risks and ensure their success.

And Here We Are, At the End

A well-defined geospatial strategy is essential for effectively triaging projects. It establishes a framework to evaluate potential projects, ensuring they deliver meaningful and sustained business value through location intelligence. This strategy guides project assessment at both operational and tactical levels. Even if your organization lacks a formal geospatial vision, it's important to ensure that proposed projects align with the overall IT strategy and corporate vision.

Understanding Alignment

Thank you for following along with my series on the 6-pillar framework for triaging project requests! Many of you have asked how to choose which projects to take on while managing daily duties. Although I haven't covered every scenario, I hope these posts have provided valuable insights.

If you found these articles helpful, I'd love to hear from you. Feel free to connect with me on LinkedIn. If you’d like to hear more about how a geospatial strategy can help your organization succeed with locational intelligence, I can help you get connected.

As a bonus, I have included a one-page checklist that summarizes the 6 pillars we have discussed. This checklist, along with the series, should help you prioritize your projects effectively.

 

Project Triage Checklist V1.0