NTEN’s 2024 Nonprofit Digital Investments Report has some grim stats about the sector’s ability to get value from new technology. Of the organizations surveyed, 54% think their organization doesn’t have the time to learn new tech, 47% say they don’t have the budget, and 43% believe they don’t have the culture to effectively implement it.
What if we rethink what “new” technology should look like?
The number one problem with technology projects is that they simply don’t achieve the desired results.
By some accounts, nonprofit technology projects fail 50% of the time, or that 17% of major IT projects go so poorly they put the existence of the organization at risk. Regardless of how we feel about the precise numbers, technology projects are riskier than we’d like them to be. There are many contributing factors, but the key pitfalls are interconnected and human-centric.
The first problem is the process itself. Projects are typically defined by the three constraints of time, cost, and scope. You can choose to view scope as the #1 serial killer of projects, but an end date can create problems that are equally pernicious (and impact scope). Having a fixed duration create pressure in two competing directions:
A second problem is that we often aren’t sure exactly what’s needed or the best way to get there at the start of a project. There are simply too many variables. This can make it difficult to collectively agree on deliverables when they are defined at the start of a project. We miss something important early on that becomes a must-have: scope expands. Or we realize an item we thought was critical and already built doesn’t actually matter: a waste of resources. The more time and energy between discovery and launch, the more space there is for getting scope wrong.
Even if we nail it and build just the right thing, we still need to learn how to use it properly. The NTEN report cited at the beginning of this article also revealed that, on average, training accounts for only 1% of nonprofit technology budgets. New tech isn’t just a new system that magically works “better”—it almost always requires a change in behavior as well. We might get exactly what we need but are still only using a portion of the full potential.
When technology improvements are treated as a series of projects, it’s no wonder that time, money, and cultural readiness are all barriers to success.
Let’s start by reframing an organization’s technology systems as a product that serves the needs of its users (primarily staff, but also constituents, partners, etc).
The product is used by a variety of people, each of whom have a different set of needs and pain points. It’s not working perfectly for everyone right now, different departments (and staff within the departments) have competing priorities, and nobody’s sure yet what the tech implications are for the new strategic plan. In short: there’s a lot of uncertainty.
Flipping from “Project” to “Product” mentality means that we stop trying to define constraints early and look forward to a “done” date where everything is fixed. Instead, we shift to an ongoing flow of work and focus on prioritizing the right things and delivering ongoing value. This change creates a slew of benefits.
To be clear: a product approach doesn’t mean we need to abandon projects entirely. There’s still a time and a place for a concerted effort within scope/time/budget constraints. But the project goals flip from trying to get it all done to doing as little as necessary on top of our ongoing product improvements.
So how do we go about moving from a project to product mindset?
The first step is recognizing that improving technology is an ongoing process. Unlike traditional IT expenses, however, investing in a technology product will create ongoing value for the organization. Over time the systems improve and will create efficiencies and insight.
Work requires a different type of management. A Project Manager’s role is about making sure the scope everyone agreed to at the beginning is delivered on time and on budget. By contrast, a Product Manager is responsible for making sure the product meets the needs of its users, is aligned with a longterm vision, and creates value. This means a focus on feedback, prioritization, collaboration, and iteration.
A technology roadmap is another important ingredient. Unlike a project plan, the roadmap is expected to evolve and change. It’s reviewed regularly and updated to reflect current priorities, goals, and dependencies by cross-department leadership. Items further in the future are more likely to change (in scope or timeline), while elements in progress should be more accurate and less likely to change. When necessary, standalone projects (defined as an additional allocation of resources) are included in addition to the ongoing stream of work.
There isn’t one switch to flip—the change can be messy and will take time and energy. But we believe it’s a fundamentally better approach than trying to manage your big Projects into better outcomes.