Questions to Ask Before Hiring a Data Consultancy
- SaaS & Tech
- Finance, Fintech & Investment
TL;DR
Buying data consulting is hard because you cannot inspect the product before you receive it — you are signing a promise. Six questions make that promise verifiable. Who actually writes the code (names and allocation, not an org chart). Whether scope and date are fixed or the rate is open-ended. How they validate that migrated numbers are right — ask for the method and one concrete example. What you keep when they leave: repository, documentation, credentials, automated tests. What they have built for companies your size, in enough technical detail to judge. And how they charge, including an explicit list of what is not included. None of the answers has to be perfect; they have to be specific. Vagueness during the sale becomes change orders during delivery.
Key takeaway — You cannot inspect data consulting before you receive it, so you are signing a promise. These six questions make the promise verifiable: who does the work, whether scope and date are fixed, how they validate the numbers, what you keep when they leave, what they have built before, and what the price excludes. You are not looking for the right answer — you are looking for a specific one.
When you buy machinery, you can see it. When you hire an accounting firm, there is a professional license behind it and a regulator auditing the output. When you hire a data consultancy, there is neither: no certification that means anything, no licensing body, and the work happens inside systems you cannot evaluate while they are being built.
You are signing a promise. And most data projects that end badly do not fail on technical competence — they fail because the promise was ambiguous and nobody noticed until week eight.
Ambiguity is detectable before you sign, though, using questions any serious vendor answers without discomfort. Here are the six that yield the most information. Full disclosure: I run a consultancy, and some of these I answer well because that is how I built the practice — but the guide works anyway if you never hire me. If you take these to a different vendor and they answer well, you came out ahead.
1. Who is actually going to do the work?
Why it matters. The most common business model in professional services is that a senior partner sells and a leveraged team delivers. That is not wrong — it is how a firm scales. The problem arises when the buyer believes they are paying for the person who sold the engagement and are in fact paying for that person’s part-time supervision of others.
The difference does not show up in the proposal. It shows up in week five, when the person who understood your business is out selling the next engagement and the person answering your email joined the industry eight months ago.
What to ask, precisely. Do not ask “who will be working on this?” — you will get an org chart. Ask:
- Who writes the code? By name.
- What percentage of their time is on my project?
- How many other engagements do they run in parallel during mine?
- Can those names go in the proposal?
What a serious answer sounds like. Names, percentages, and a willingness to write them down. “I do the modeling and validation at 60% for six weeks; I bring in one data engineer for the initial loads, here is their background; I am not running another build in that window.”
What an evasive one sounds like. Profiles instead of people — “a senior architect and two analysts” — or “we staff based on availability.” Neither is a lie; both are ways of avoiding commitment. If a vendor cannot put names down, it is because they intend to be able to change them.
At Clarivant this is the whole model: the principal does the work, which caps how many engagements run at once. That is a real constraint rather than a slogan — and it is exactly the constraint worth probing at any vendor.
2. Is the scope and date fixed, or is the rate open-ended?
Why it matters. This is where you decide who carries the risk. On an open hourly rate, if the project turns out larger than anyone thought, the overage is yours. On fixed scope and date, it is the vendor’s. Neither model is dishonest — but only one lets you take a number to the board that you can defend line by line. Time and materials also carries an uncomfortable second-order effect: the vendor earns more when the project takes longer. You do not need to assume bad faith to notice the incentive exists.
What to ask, precisely. Is the price a ceiling or an estimate? What happens if the scope turns out to be 30% larger — who pays? What events trigger a change order, and who decides they have been triggered?
What a serious answer sounds like. Price and date committed in writing, with an explicit definition of what counts as new scope, preceded by a paid discovery phase: nobody honest commits a price without having seen your systems. A fixed price offered before anyone looks at anything is either a guess or a padded number you will pay whether or not the padding is used.
What an evasive one sounds like. “We work from a block of hours and prioritize with you as we go.” That can work for ongoing support. For a migration with a deadline it means scope is renegotiable every Tuesday and the date does not really exist.
3. How do you validate that the numbers are right?
Why it matters. This is the question almost nobody asks and the one that costs the most money. In a data migration, the worst outcome is not that the new system fails — it is that it works and produces numbers slightly different from the old system’s, with nobody able to say which is correct. That destroys trust in the new platform in a way that is very hard to recover. Every vendor uses the word “validate”; what varies is whether there is a method behind it or a meeting.
What to ask, precisely. What is the validation method, step by step? Do you reconcile record by record or only totals? What is the agreed tolerance threshold, and who signs off? And: tell me about a real discrepancy you found on another project and how you resolved it. That last one is the best question on this list, because it cannot be answered without having done the work.
What a serious answer sounds like. A concrete method: a frozen baseline from the legacy system, record-level reconciliation against the new one, every difference documented with its root cause, a threshold agreed before starting. Plus a specific story about a discrepancy that turned out to be a bug in the old system — because when you validate properly, that happens often.
What an evasive one sounds like. “We validate with the users during UAT.” Translation: validation is yours, and it will happen at the moment your team has the least time to do it well.
For calibration on how far the method reaches when it exists: on one revenue analytics rebuild, record-level reconciliation closed at 0.002% variance across $84M validated, surfacing 15 silent bugs that had been in production for years in the system being replaced. That is the evidence to ask any vendor for — not the certificate, the method and one example.
4. What happens when you leave?
Why it matters. A data project does not end on delivery day. It ends the first Tuesday something breaks and your team has to fix it alone. If, at that moment, the only person who understands the pipeline no longer works with you, you have converted an investment into a dependency. Some firms’ business model is that dependency: they ship something that works but that nobody else can maintain, and the support retainer becomes structural.
What to ask, precisely. What documentation do we receive, and can our team maintain it? Does the code live in our repository from day one or yours? Are cloud accounts and credentials in our name? Are there automated tests that fail on their own when data arrives wrong, or does someone have to notice? How long is the handover and what does it include?
What a serious answer sounds like. Handover appears in the proposal as a deliverable with acceptance criteria, not as a closing courtesy. Code in your repository, in your cloud, under your credentials. Documentation written for the people who will maintain it. Automated tests that run without supervision — that is the difference between a platform that watches itself and one that needs a guardian.
What an evasive one sounds like. “At close we do a two-hour handover session and provide documentation.” Two hours and a PDF is not a handover; it is a goodbye.
If the engagement includes AI on your data, this question has a sharper version: ask what prevents the model from answering from badly defined metrics once nobody from the vendor is watching. I wrote separately about guardrails that outlast the consultant.
5. What have you built for companies like mine?
Why it matters. A client logo on a slide tells you nothing about who did the work, when, or whether that person is still at the firm. And “like mine” rarely means the same industry — it usually means the same size, the same kind of mess, and the same class of constraint.
What to ask, precisely. What exactly did you build — which tools, how many objects, over what timeline? Who on your team did it, and are they still available? Can I talk to someone from that client? If the case is anonymized, can you give me enough technical detail to judge it?
What a serious answer sounds like. Numbers and mechanics: what was there before, what got built, how long it took, what went wrong along the way. A vendor who only tells clean victories is editing. An anonymized case can be perfectly credible if the technical detail is specific; what is not acceptable is “we work with leading companies in the sector.”
What an evasive one sounds like. Cases without numbers, or numbers without context — “we improved efficiency by 40%.” Of what, measured how, against which baseline?
To calibrate how concrete you can reasonably demand: the data platform for a 100+ location restaurant franchise is described with the full stack, the source system, and the operational outcome. Hold any vendor to that level of detail; the published case studies work as a measuring stick whether or not you ever hire us.
If you run a multi-location chain, we take that same build apart layer by layer in Building a Data Warehouse for a Restaurant Chain — it doubles as a template for what to ask whoever wants to build yours.
6. How do you charge — and what is not included?
Why it matters. The second half of that question is worth more than the first. Almost every budget surprise in a data project comes not from the agreed price but from what fell outside it without anyone saying so: tool licenses, warehouse consumption, your own team’s time, historical data migration, training, the stabilization month after go-live.
What to ask, precisely. What is explicitly not included in this price? What third-party costs will I pay directly, and what do you estimate them at? How many hours of my team’s time does your plan assume? What happens if my people cannot give you those hours on schedule?
What a serious answer sounds like. A list of exclusions volunteered without being asked, and an honest estimate of third-party costs even though the vendor does not bill them. Above all, a clear number for how much of your team’s time the project consumes — the cost that never appears in the proposal and always appears in the calendar.
What an evasive one sounds like. A proposal with no exclusions at all. It reads as generous and is the opposite: the boundary gets defined later, once you have signed and lost your negotiating position.
What a data consulting proposal should include
When the document arrives, check that all six are present:
- Scope written as a list of verifiable deliverables, not objectives.
- A committed date, with intermediate milestones you can inspect.
- Names of the people doing the work, with allocation.
- Acceptance criteria for each deliverable, including the validation method.
- What transfers to you at close: repository, documentation, credentials, tests.
- Price, payment terms, and the explicit exclusions list.
A missing item does not make the vendor bad. It means that item gets defined later, and “later” always means with less leverage than you have today.
The cheap way to test the answers
Questions can be answered well by people whose work is not, which is what makes consulting hard to buy. So the most useful advice here is not another question but a structure: start with a small, paid, dated commitment before the large one. A bounded diagnostic lets you watch how a vendor actually works — whether they document, whether they show up, whether the senior who sold the engagement is the one opening the console — at two or three weeks of risk instead of six months.
That is the logic behind the data stack diagnostic, the fixed-scope entry engagement we start nearly everything with: two to three weeks inside your real stack, ending with an inventory, a findings document, and a fixed-price, fixed-date quote. The principle holds with any vendor: buy one small paid deliverable first and evaluate the work instead of the pitch.
The service lines are published with their mechanics, and a strategy call is enough time to ask all six questions in this guide. You do not have to ask them of me — but ask them of someone before you sign.
Frequently asked questions
What should I ask a data consultancy before hiring?
Six questions cover most of the risk. Who actually writes the code — by name, with the percentage of their time on your project, not a staffing pyramid. Whether the scope and date are fixed or the hourly rate is open-ended, and who absorbs the cost if scope grows. How they validate that migrated numbers are correct, with a method and one real example from a past engagement. What you keep the day they leave: repository, documentation, credentials, automated tests. What they have built for companies your size, in enough technical detail to verify. And how they charge, including an explicit list of what the price does not include. Look for specific answers rather than perfect ones.
How do data consultancies charge?
Three models dominate, and the model matters more than the rate. Time and materials — an hourly or daily rate where you carry all the scope risk. Retainer or a block of hours — you buy capacity rather than an outcome, which suits ongoing support and suits a deadline-driven migration badly. And fixed-scope engagements with a committed price and date, where the consultancy carries the scope risk, which is why any honest version of it requires a paid discovery phase first. The same work can cost very differently across the three, and a low hourly rate against open scope routinely ends up costing more than a higher fixed quote. Compare models before you compare rates, and treat a fixed price offered before anyone has looked at your systems as either a guess or a padded number you are paying for.
What should a data consulting proposal include?
Six concrete things: scope written as a list of verifiable deliverables rather than objectives; a committed delivery date with intermediate milestones; the names of the people doing the work and their allocation; acceptance criteria for each deliverable, including the method used to validate that the numbers are right; what transfers to you at close — repository, documentation, credentials, automated tests; and the price with payment terms plus an explicit list of what is not included. That last list is the most informative item in the document. A proposal with no exclusions is not generous, it is ambiguous, and the ambiguity gets billed later as a change order.
How do I know whether seniors or juniors will do the work?
Ask directly and request three data points: the name of the person writing the code, their percentage allocation to your project, and how many engagements they run in parallel. Then ask that those names go into the proposal. A firm that plans to rotate staff cannot commit names in writing and will answer with profiles instead — 'a senior architect and two engineers.' A leveraged model is not automatically wrong; it changes the fair price, the pace, and how much oversight falls to you. What should never happen is discovering the team composition at the kickoff meeting.
How should a consultancy prove the numbers are right after a migration?
Ask for the method before you sign, not the certificate at the end. A serious method looks like this: a frozen baseline from the legacy system, record-level reconciliation against the new one rather than totals only, every difference documented with its root cause, and a tolerance threshold agreed before work starts. Also ask them to describe one real discrepancy they found on a past project and how they resolved it — that question cannot be answered without having lived it. The generic answer, 'we validate with the users during UAT,' is the warning sign: it means validation has been delegated to your team under a different name.
What happens to my data platform when the consultants leave?
That depends on what the contract made a deliverable. Ask whether code lives in your repository from day one or theirs, whether cloud accounts and credentials are in your name, what documentation you receive and whether your team can maintain it, and whether there are automated tests that fail on their own when bad data arrives — or whether someone has to notice. Handover should appear in the proposal as a deliverable with acceptance criteria, not as a closing courtesy. A two-hour session and a PDF is not a handover; a platform nobody but the vendor can maintain converts an investment into a dependency.