IT Strategy & Leadership
Budgeting for IT in a Nonprofit: Run, Grow and Protect
A simple framework that makes a nonprofit technology budget easier to explain, defend and improve.
Most organizations have an IT roadmap. Far fewer have one that’s actually being followed. The usual story is familiar: a planning effort produces a polished document, priorities shift within a quarter, and the roadmap quietly becomes a record of what someone once hoped would happen.
Roadmaps fail for predictable reasons, and the fixes are just as predictable. Here’s how to build one that leadership will fund and teams will execute.
A roadmap that opens with “upgrade the network” or “move to the cloud” is asking leadership to care about technology. Start instead with what the organization is trying to achieve over the next two to three years, such as growth, new services, better member or patient experience, lower risk or a merger, and work backward to the technology that makes it possible. Every initiative should trace to an outcome a non-technical executive would recognize.
A useful roadmap is built on a clear-eyed assessment: which systems are aging out, where security gaps are, what’s costing more than it should, and where teams are working around technology instead of with it. Include the unglamorous items too. Technical debt that never makes the roadmap tends to make the headlines instead.
A roadmap with thirty priorities has none. Score each initiative on business value, risk reduction, cost and effort, and dependencies. Then make hard choices. A short list of initiatives that get finished is worth more than a long list that all stall halfway.
Group the work into three horizons:
Roadmaps die when they aren’t connected to budgets and people. Each initiative needs an estimated cost range, an executive sponsor, a delivery owner and a realistic timeline that accounts for the work teams are already doing. If the organization can’t resource it, it doesn’t belong in the “Now” column.
Leadership should be able to understand the roadmap on a single page: what’s happening, why it matters, what it costs and what’s needed from them. Keep the detail in supporting documents. The one-page view is what gets discussed, funded and remembered.
The business will change, and the roadmap should change with it. Review progress monthly with delivery teams and quarterly with leadership. Re-score priorities when circumstances shift, retire initiatives that no longer make sense, and celebrate what’s been delivered. A roadmap that’s updated is a roadmap that’s used.
Define success for each initiative in business terms, such as hours saved, risk reduced, uptime improved or a capability launched, and report on it. When leadership can see results, the next round of investment is easier to secure.
A roadmap is only valuable if it changes what happens next. Anchor it in outcomes, prioritize hard, attach owners and budgets, and revisit it often. That’s how a planning document becomes a plan.
Need a technology roadmap your leadership will back? Talk with our strategic advisory team.