Most association leaders believe their tech projects fail because they picked the wrong vendor or chose the wrong software. They’re wrong.

After analyzing 100+ failed implementations and rescuing dozens of tech transformations from the brink, a clear pattern emerged: Tech projects don’t fail because of technology. They fail because of how we define value, lead the change, and execute the solution.

This isn’t theory. This is what Ashish Malik (CEO, 108 ideaspace), Rana Chreyh (Practice Leader, Stratford), and Asiya Shams (Director, Stratford) walked through in Tech That Delivers: From Overruns and Overwhelm to Outcomes That Matter — a live webinar that tackled the root causes of tech implementation failures and shared a battle-tested framework to prevent them.

Here’s what you need to know. 

The Reality Check: Why Tech Projects Actually Fail

Let’s start with a tough truth: your last tech project didn’t fail because of the tool. It failed because of the decisions you made before you ever talked to a vendor.

The Symptom vs. The Root Problem

Imagine you have a headache. You pop an Advil. It works—for a while. But the real problem might be dehydration or eye strain, not a pain that needs immediate medication.

This is exactly what organizations do with tech projects.

A client comes to you saying: “Our CRM is dysfunctional. We need a new one.” So you buy a new CRM. But dig deeper, and you discover the real problems aren’t the software—they’re the messy data, inconsistent workflows, weak governance, over-customization, and lack of training.

You implement the new tool and guess what happens? The old problems migrate straight into the new system.

The lesson: Before you buy anything, ask why. Then ask why again. Don’t solve the symptom; solve the root problem.

Fuzzy Goals and Success Metrics

When Ashish asked organizations “Why do you want to do this project?”, he heard things like:

• “We want to improve engagement”
• “We want to modernize our tech stack”
• “We want to improve data quality”

None of these are measurable. And here’s the problem: What gets measured gets managed. What doesn’t get measured cannot get managed.

Compare this to clear, measurable goals:

• “Increase repeat logins to member portal by 30% within 12 months” instead of “improve engagement”
• “Reduce manual data entry by 50%” instead of “modernize systems”
• “Reduce duplicate records to under 2%” instead of “improve data quality”

Without measurable outcomes, you’re building a solution for a problem you don’t fully understand. And you’ll fail to prove ROI when it matters most—at the board meeting.

The Shiny Object Syndrome

Many organizations buy technology without clarity on what they’re solving for. It’s like buying a gym membership and expecting fitness to happen automatically. It doesn’t.

You pick a vendor because they have flashy features, a great demo, or your peer organization recommended them. Then, three months into implementation, you realize they don’t actually understand your association structure, your workflow, or your real challenges.

By then, you’re committed. Budget is spent. Momentum is invested. And changing course costs even more.

The Leadership Crisis: Why Change Management Often Fails

Here’s what separates the top 10% of successful tech projects from everyone else: Leadership sponsorship.

Rana shared a real story that illustrates this perfectly.

A digital customer experience transformation project at a major organization was failing. A million dollars already spent. Large teams. Multiple project managers. Consultants coming in and out. And yet—after a full year—nobody could explain what the project was even about.

The CEO called the CIO. The CIO called Rana. And she asked the first critical question: “What is this project really about?”

No one had a clear answer.

The Framework: Clarity, Communication, and Concrete Action

Rana identified four critical areas of leadership action:

1. Clarity on the Why
The CEO and leadership team didn’t understand the purpose of the project. Rana went back to the executive table and laid down the foundations for clarity. She got a deep nod. That changed everything.

Without clarity on why you’re doing something, your team can’t stay motivated, stakeholders can’t support you, and your board will question every dollar spent.

2. Clear Roles and Accountability
In the struggling project, 30 people showed up to meetings. Nobody knew what they were doing there, what their responsibilities were, or who had decision rights.

Rana created a tight, powerful core team. She distinguished between people doing the work and people who were stakeholders. She made it clear: if you’re not doing work on the project, you’re not on the core team.

She also dealt with a dysfunction many leaders face: people with loud voices who have no skin in the game. These are the people who can tank a project by sending everyone in different directions—but if the project fails, it’s not on them.

3. Change Communication From Leadership
Once clarity was in place, communication became crystal clear. People understood not just the what, but the why. And they heard it from leadership—repeatedly.

Here’s why this matters: Change management cannot be outsourced. You can have change managers help, but the leader must sponsor the change. The leader must keep communicating. The leader must show resolve.

4. Leadership Action to Remove Barriers
As projects move forward, complex obstacles emerge. The leader’s role isn’t to make decisions in the weeds—it’s to remove barriers and create space for the team to innovate.

In this project, procurement said it would take six months to procure the first solution. Rana’s response: We need to deliver something concrete and useful in one year. If we keep dragging on, people lose faith. She removed the barrier.

The result: The project went live with key customer experience systems within a year. It was a massive strategic win. They didn’t just implement the system—they innovated using large language models and AI to deliver insights that far exceeded what was originally imagined.

The Battle-Tested Framework: Three Phases to Deliver Tech with Measurable Impact

This is where the rubber meets the road. Asiya walked through the exact framework that turns tech projects from overruns and overwhelm into outcomes that matter.

It’s three phases. Each builds on the previous one. And each is critical.

Phase 1: Define Value Early

Before you pick a vendor, before you buy any tool, you need to define what value actually means.

Imagine a renovation team showing up at your house with all their tools but no blueprint. Would you let them start working? Of course not.

Yet in tech projects, organizations rush into action. They buy the tool. They start configuring. They move quickly and feel like they’re making progress. Then six months later, they realize the tool doesn’t solve their actual problem.

The three steps:

1. Business Process Analysis — Understand what actually happens in your organization (not what you think happens). You can’t digitize chaos, so get clarity on what you’re really trying to improve.
2. Define the Problem Clearly — When you know your why, what becomes obvious. A client said: “We need a new CRM.” Digging deeper revealed: “We need a 360-view of our members. We need to understand the full member journey. We want to improve member experience.” The right solution became obvious once the problem was clear.
3. Translate Goals into Measurable Outcomes — Don’t just say “reduce manual renewals.” Say “increase automatic renewals by 25%.” Don’t just say “improve member experience.” Define exactly what that looks like: response time, satisfaction score, retention rate.

The critical insight from Asiya: “Being in motion does not necessarily mean you are in the right direction.”

Everyone is busy. Everyone is working hard. But without defining value first, all that activity is motion—not progress.

Phase 2: Measure Twice, Cut Once

Once you know what value looks like, the next phase is validating your approach before you build it.

This is where cross-functional ownership becomes critical. Your team isn’t just IT. It’s marketing, membership, finance, operations—everyone who will be affected by or will use the new system.

You map your current state processes. You design your future state. And crucially, you validate requirements from a future-state perspective: “How will this improve our members’ experience?”

You also prioritize ruthlessly. Every organization has a wishlist. But you focus on the few capabilities that solve the right problem—not the most requested ones.

Establish sign-off checkpoints. Manage expectations. Start change management now—not at launch. Early buy-in prevents late resistance.

Phase 3: Execute with Evidence

This is where you actually build and implement. But here’s the key difference from how most organizations do it:

It’s a shared build, not a handoff.

The vendor doesn’t build in isolation and hand you the solution. You’re collaborating constantly. You’re monitoring for scope creep. Small changes don’t stay small—they compound. Before you approve a “quick addition,” you reassess complexity, effort, impact, and budget implications.

Client-owned tasks (like data export and cleanup) are treated as project-critical deliverables, not afterthoughts.

Throughout execution, you’re tracking metrics. You’re sharing wins with staff. You’re measuring adoption, user satisfaction, and business impact continuously.

The truth Asiya emphasized: “Perfection isn’t the goal. Alignment is.”

You’re not trying to build the perfect system. You’re trying to build a system that everyone is aligned on, that delivers measurable outcomes, and that the team can actually adopt.

Smart Vendor Selection: Beyond the Beauty Contest

Here’s a hard truth: Most organizations select vendors like they’re picking a prom date—based on a good-looking demo and the way the salesperson makes them feel.

This is a $200K mistake waiting to happen.

When you get to vendor selection (and only after you’ve done Phases 1-2), here’s what actually matters:

1. Fit — Does this vendor understand organizations like yours? Can their solution work with your structure, your workflow, your real world?
2. Flexibility — When requirements change (they always do), can this vendor adapt? Or are you locked into a rigid, expensive customization process?
3. Partnership Mindset — Are they invested in your success? Or are they just another vendor transaction?

The approach that worked: structured vendor evaluation based on your defined requirements, not a beauty contest based on features.

One organization came to Stratford and 108 ideaspace saying: “We need to replace our AMS.” After the framework work, their actual need was crystal clear. The vendor selection process became obvious. They chose the right fit—not the biggest name or the most features—and saved $200K in implementation costs and months of wasted time.

Leadership Without a Tech Background: How to Ask the Right Questions

Here’s something that stops many association leaders cold: “I’m not technical. How am I supposed to lead a tech transformation?”

The answer: You don’t need to know code. You need to know how to lead.

Three core questions to ask (even if you don’t understand the technical answers):

1. “What problem does this solve?” — Make them articulate the business problem, not the technical solution.
2. “How will we measure success?” — Push for measurable outcomes. Not “improve efficiency.” “Reduce manual steps by 50%.”
3. “Who is accountable?” — Make sure roles and responsibilities are crystal clear.

Your job as a leader isn’t to understand the code. Your job is to demand clarity.

Leadership in tech transformation means:

• Setting the why and repeating it constantly
• Building alignment across departments
• Removing barriers so your team can execute
• Holding people accountable to measurable outcomes
• Keeping your board informed about trade-offs and progress

What Happens When You Get It Right

The organizations that follow this framework don’t just succeed—they transform.

They deliver projects on time, on budget, with measurable impact. They keep their best people because there’s clarity and direction, not chaos and constant firefighting. They actually prove ROI to their boards because they defined what success looks like from day one.

And more than that—they create space for innovation. When everyone is aligned on the framework, teams stop just managing projects and start imagining what’s possible.

The Full Picture (And Why You Should Watch the Webinar)

This article captures the key frameworks and insights from Tech That Delivers. But there’s a depth and nuance to the full webinar that you won’t get here.

You’ll hear real stories from leaders who’ve lived through implementation disasters and come out the other side.

You’ll see concrete examples of how organizations applied this framework and the specific results they achieved.

You’ll understand the difference between what looks like progress (being in motion) and what actually is progress (moving in the right direction).

Most importantly, you’ll get a playbook you can take back to your organization—a framework that works for associations and nonprofits of all sizes, in all sectors.

The next time your board asks about a tech project, you won’t be making excuses. You’ll be presenting a framework. A clear timeline. Measurable outcomes. And a leadership approach that ensures success.

Ready to transform how your organization approaches technology?

Video Available Soon.