Most failed data projects were mis-scoped before a line of code was written. Not mis-built — mis-scoped. The requirements were vague, the success criteria were unstated, the ownership was ambiguous, and the vendor and the client were quietly imagining two different projects. By the time that becomes visible, the budget is spent and the dashboard nobody uses is already live.
If you lead a nonprofit or foundation and you’re evaluating a data-infrastructure proposal, you don’t need to become a data engineer to protect yourself. You need to ask a handful of specific questions and require specific answers. The patterns that predict trouble are consistent, and they show up in the scoping conversation long before they show up in the invoice.
Start with the decision, not the dashboard
The first question is not “what do we want to build” but “what decision will this help us make that we can’t make today.” Good data work is defined by the decisions it enables — reroute resources to an underperforming site, catch a stockout before it costs lives, answer a funder’s question in an afternoon instead of a month. If a proposal leads with technology (a lake, a warehouse, a model, a dashboard) rather than with a decision, that’s the first warning sign. The technology is a means. If nobody can name the decision, the project has no destination.
Require this in writing: what will someone be able to do after this project that they can’t do now, and how will we know it’s working? If the answer is a list of features rather than a change in what your team can do, push back until it isn’t.
The questions that separate serious proposals from sales pitches
Where will the data live, and who controls it? This is the sovereignty question, and it comes first. The data should stay in your environment, under your control, portable if you ever leave. If the answer is “in our platform,” understand that you are renting access to your own data and price in the lock-in.
What happens when you leave? Ask directly what you’re left holding when the engagement ends. The right answer is: documented pipelines, a model you own, trained staff, and everything running in your own environment. The wrong answer is a shrug and a support contract. A project you can’t operate without the vendor wasn’t a build; it was a lease.
Who on our side will run this? Every sustainable data project has an answer to who maintains it after handover. If the plan assumes the vendor stays forever, the real cost is not the build price — it’s the indefinite dependency. Insist that capacity-building and documentation are in scope, not extras.
What’s the smallest version that delivers value? Be deeply skeptical of the proposal that requires building everything before anything works. The right shape is a first slice that produces a real, usable result quickly — one city, one program, one report that someone actually needs — with the architecture designed to grow from there. A proposal that needs six months and the full budget before you see anything is a proposal that hides its risk until it’s too late to act on.
How will data quality be handled? If the answer is silence or “we’ll validate at the end,” expect problems. Trustworthy data comes from layered checks — at entry, in processing, at the point of consolidation — not a single pass before launch. Quality should be part of the design, described up front.
The patterns that signal trouble
A few recurring tells, each of which should slow you down:
- Technology-first framing. The proposal names tools before it names the problem.
- All-or-nothing delivery. Nothing usable exists until everything is done.
- Vague success criteria. “A modern data platform” is not a success criterion. “Program leads can see site-level coverage weekly” is.
- Ownership left implicit. Nobody has said, in writing, that you own the data, the code, and the models at the end.
- No handover plan. Training and documentation are absent, or quietly billed as a future phase you’ll need whether you planned for it or not.
- A price with no phases. A single large number with no milestones tied to deliverables gives you no way to stop if it goes wrong.
None of these are automatically disqualifying. Each is a prompt to ask another question until you’re satisfied.
What good scoping looks like
A well-scoped project reads almost boringly. It names the decisions it will improve. It defines success in terms someone non-technical can verify. It stages delivery so value arrives early and risk is visible. It states plainly that you own the outputs and that your team will be able to run them. It treats data quality and handover as part of the work, not as upsells. And it is priced in phases you can halt.
You don’t need to know how the pipeline is built to require all of that. Scoping is not a technical skill; it’s a discipline of insisting on clarity before money changes hands. The projects that go well are the ones where both sides were imagining the same thing on the day they signed — and that agreement is something you can demand, in plain language, before a single line of code is written.
This is a field note from our practice. If you’re weighing a proposal and want a second read on whether it’s scoped to serve you, start a conversation.