Author: Lisa Montague | Category: Technology Governance for Nonprofits

Two innovation teams launched in the same nonprofit within months of each other. Both were tasked with building new products. Both had momentum, budget, and executive support.

A year later, both had stalled.

Why? They stalled because nobody asked the right questions before they started building.

The Setup: Two Teams, Two Products, One Assumption

Team One built a loan product. It was new, it filled a gap in the nonprofit's service line, and the leadership team was excited about it.

Team Two built a banking portal. Different product group, different customer base, different use case. Equally important.

Both teams operated independently. Both had their own budgets. Both reported up to different leaders. And neither talked to the existing product department that had been running the nonprofit's core offerings for years.

Here's what happened next.

The Loan Launch: When Integration Planning Didn't Happen

The loan team launched their product and started a paid ad campaign to drive customers to the onboarding site.

They sent users to a page. The page was supposed to recognize: This person came from the loan funnel, not from our regular counseling product.

But it didn't. The onboarding site had no way to know where users were coming from. So every loan customer got entered into the system as a regular counseling client. No tracking. No differentiation. No way to understand which customers belonged to which product.

Meanwhile, the ad campaign wasn't generating the expected traffic.

Why? Because the page they were sending users to wasn't indexed by Google.

Years earlier, someone had made a decision: Don't index this subdomain. It was the right call at the time. But that decision had never been revisited. No one from the loan team even knew about it, and no one from the existing product team mentioned it because they weren’t consulted. By the time anyone figured out the indexing problem, the campaign had already failed, and the launch was delayed by months.

Technical oversights, decisions made in isolation, one failed launch.

The Banking Portal: When Platform Mismatch Met Silence

Team Two built a banking portal pilot for their banking customers. The pilot performed well: user testing showed pilot users could complete their required tasks with the product. The users could log in, fill out forms, change passwords, everything the job required.

Then came the “release to production”: connecting it to Salesforce, the system of record for customer data.

The platform they'd chosen to build the portal didn't have a built-in Salesforce integration. So they tried to build a custom one.

It failed.

Meanwhile, in the existing product department down the hall, that team had already built Salesforce integrations. Not one way, but two different ways. They'd solved this problem using the Force REST API and Salesforce Orchestration API.

But Team Two didn't know. They didn't ask. Either they assumed the existing team's resources weren't available to them, or they didn't know how to ask in the first place.

So they kept trying to build a custom integration that couldn't work. Months passed. The portal sat in pilot mode. The launch slipped, and finally the product was canceled.

The Real Problem: It Wasn't About the Technology

Here's what's important: Both teams had real problems. Both needed solutions.

But the problems didn't stall the projects.

The silence stalled the projects.

The loan team didn't know about the indexing decision because no one had mapped the customer journey across teams. The banking portal team didn't know about the Salesforce integrations because there was no structure for sharing technical knowledge between departments.

The Pattern You'll Recognize

If you work at a nonprofit with multiple departments, multiple products, or multiple innovation initiatives, you've probably seen this pattern:

  • Teams launch in parallel without aligning on the customer journey
  • Knowledge lives with individuals, not teams (so when someone leaves, it disappears)
  • Decisions made in one department cascade into problems in another
  • Budget is allocated by silo, so teams don't know they can share resources
  • Questions like "Can we integrate with Salesforce?" or "Is this page indexed?" get answered too late, after the launch is already planned
  • By the time problems surface, the project is already behind schedule and over budget

This is what stalling looks like.

It's not always dramatic. It's just... slow. Delayed. Frustrating. Teams saying "We didn't know" when the launch slips.

How Governance Stops This Pattern

Here's what changes when you add governance:

Before launch:

  • What systems does this integrate with?
  • Who in the organization already knows this?
  • What decisions were made before that we need to revisit?

The conversation happens before the project starts, not after it stalls

During the project:

  • Teams share updates across departments (not silos)
  • Technical knowledge gets documented and accessible (not locked in someone's head)
  • If a blocker emerges, you know who to ask because the structure is already there

At launch:

  • You've already caught the integration problem, the indexing issue, the missing data tracking
  • You launch knowing the customer journey is complete, not fragmented

The Eight Predictable Failure Modes (And How Governance Fixes Them)

We've identified the eight predictable failure modes that cause tech projects to stall.

Each one has a governance fix.

Each one is avoidable.

See the eight failure modes and the governance fix for each one