GIS Projects: Triaging Considerations Series - Part 3

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 the more human aspects of successful project implementation.

Understanding Capacity

Understanding Capacity

Before discussing technology requirements, let's focus on the true indicator of success – people. We've already seen how committed sponsors, champions and technical leaders contribute to project success. Now, let's explore how understanding our end users, implementation team and sustainment team can guide our project's progress. We will look at this from a capacity to use, build and to sustain the project deliverable or application.

Understanding our End User

Understanding Our End User

Understanding the risk level of a proposed project is crucial for several reasons, especially from the end user's perspective:

• User Experience: Low-risk projects typically result in intuitive UI/UX, making it easier for users to adopt and use the application without frustration. This leads to higher satisfaction and productivity.
• Learning Curve: Moderate-risk projects may require users to engage in self-guided learning. While this is manageable for some, it can be challenging for others, potentially leading to slower adoption rates and increased support needs.

• Training Requirements: High-risk projects often necessitate specific guided training or extensive learning. This can be burdensome for users, causing resistance to change and impacting overall project success.

By evaluating the risk level, we can better plan for user support, training and adoption strategies, ensuring a smoother transition and higher likelihood of project success.

Understanding our Implementation Team

Understanding Our Implementation Team

When triaging potential project requests, evaluating and understanding the implementation team is crucial for several reasons, especially from a training and capability perspective:

• Resource Efficiency: Projects that require minimal full-time employee (FTE) involvement and training are more ideal. They allow your organization to allocate resources efficiently, ensuring that staff can focus on primary responsibilities without significant disruption.

• Training Requirements: Projects that need minimal training are easier to implement and sustain. They reduce the time and cost associated with onboarding and upskilling team members, leading to quicker project deployment and smoother transitions. Understanding the existing capabilities of the implementation team helps in matching the project's requirements with the team's skills. Projects that align well with existing capabilities are more likely to succeed with minimal additional training or resource allocation.

• Deprioritization Risks: Projects that require extensive training, research and development (R&D) are more likely to be deprioritized. They demand significant investment in time and resources, which can strain the organization and delay other initiatives.

By evaluating the implementation team, we can prioritize projects that are more feasible, cost-effective and aligned with current capabilities, ensuring successful and timely delivery.

Understanding our Business Application Management Team

Understanding Our Business Applications Management Team

Similar to evaluating the implementation team, it's crucial to understand our business application management team for effective staff resourcing needed to sustain and manage the deliverable. If our project outcome requires a vendor or third party to sustain or manage, consider the following:

• Vendor or Contractor Dependency: The highest risk arises when a project requires a vendor or contractor for ongoing management. This dependency can lead to increased costs, potential delays and challenges in maintaining consistent quality and support.

Here are some risks to consider when evaluating a project that requires third-party maintenance:

• Operational Risk: Using a vendor or contractor can introduce operational risk if their internal processes, people or systems fail, significantly impacting your operations. This includes the ability to maintain quality control standards, which can adversely affect product or service delivery.

• Business Continuity: Will the vendor have a defensible business continuity plan for uncontrollable events such as natural disasters or cyberattacks?

• Dependency Risk: Over-dependence on a provider may create a bottleneck and likely does not align with an organization’s goal of developing capacity in its own staff. There have been instances where a legacy application, critical to the business, is no longer maintained because the ‘expert’ from the vendor is no longer available.

Depending on vendors or contractors can bring risks like operational hiccups, business continuity issues and dependency problems. But with a solid strategy and backup plans, you can handle these risks better. Building your own team's skills and keeping control over key applications can help avoid disruptions and keep you on track.

In this post we touched on people and training as an indicator of a project’s potential to succeed. Stay tuned when we explore together, the technology indicators we can use to triage projects requests.