Josh DargieInfrastructure · Cloud · Software

Blog / consulting

Scoping a technology project before calling vendors

How to scope a technology project before calling vendors: describe the problem, be honest about budget, and define success so quotes compare.

Most technology projects go wrong before anyone writes a line of code or pulls a metre of cable. They go wrong at the phone call, when a business rings three vendors and describes a solution instead of a problem.

I spend a lot of time reviewing quotes, and the pattern behind most bad ones is not vendor dishonesty. It is that the vendor was handed a vague request and filled the gaps with assumptions, which are always the assumptions that favour the vendor. The fix is a page of writing done before any vendor hears from you. Here is what goes on that page.

Write the problem, not the solution

The most common scoping mistake is calling vendors with a prescription: "we need a new server," "we want to move to the cloud," "quote us Wi-Fi 7."

The trouble is that your prescription becomes the ceiling of every conversation. Ask three vendors for a new server and you get three server quotes, even if your actual problem, say, that month-end reporting takes four hours, would be better solved with software changes, or hosting, or nothing.

So write the problem in operational terms. What is slow, failing, risky, or impossible today? Who does it affect and how often? What triggered this project now rather than last year? A vendor reading that paragraph can propose a solution and defend it. A vendor reading "quote us a server" can only quote a server.

I make my living partly on this gap. When I recommend keeping what you have, as I argued in an earlier piece, it is almost always because the stated solution and the actual problem turned out to be different things.

Be honest about budget

Businesses hide their budget from vendors on the theory that revealing it invites a quote for exactly that amount. The fear is not irrational. But the alternative is worse: with no number at all, vendors guess, and you get one quote scoped at $8,000 and another at $80,000 for what is nominally the same project. Those quotes teach you nothing because they are answers to different questions.

You do not have to name a figure. Name a range, or a ceiling: "we expect this is a $20,000 to $40,000 problem; tell us if you disagree and why." That last clause matters. A good vendor who thinks your range is wrong will say so and explain, and that explanation is free education. A vendor who silently scopes to your ceiling has told you something too.

Honesty runs both directions. If the realistic quotes come back at triple your range, the project is mis-scoped or mistimed, and it is far cheaper to learn that now.

Define what success looks like

Before any vendor visit, finish this sentence: "This project is done when..."

Done when the backup restores in under an hour, verified by a test restore. Done when the warehouse has usable Wi-Fi at every picking station. Done when a new employee can be set up in a morning without calling anyone. Concrete, checkable, boring.

Success criteria do two jobs. During quoting, they force completeness: a vendor who must meet "verified by a test restore" has to include the testing they might otherwise omit. After delivery, they end arguments, because "done" was defined in writing while everyone was still friendly.

If you cannot write the success sentence, you are not ready to call vendors. That is not a failure; it just means the project needs definition before it needs pricing.

Why this makes quotes comparable

Here is the payoff. Send the same one-page scope, problem, constraints, budget range, success criteria, to three vendors, and the quotes that come back are finally answers to the same question. Differences in price now mean something: they reflect approach and margin, not divergent guesses about what you wanted.

It also transforms what a review can catch. When I do a second opinion on a quote, the first thing I ask for is the scope the vendor was given. With a written scope, missing items are provable omissions. Without one, everything is a misunderstanding, and misunderstandings always bill at your expense.

One page. A few hours of thought. It is the highest-return work in the entire project, and it happens before anyone sells you anything. If you would like help getting that page right, or want the scope pressure-tested before it goes out, that is precisely what my project planning engagements are for.

← All posts

Start with a conversation

Thirty minutes, no charge, no pitch.

Tell me the problem. I'll tell you whether I'm the right person for it, and if not, who is.