Lock It Down Before You Order: Heading Off Project Blowups Through Requirements and Estimates [Vendor Control, Part 1]

About this series

Software projects that turn into trouble tend to follow the same pattern. The buyer says "we'll leave the rest to you," hands everything off, then looks at what comes back and says, "this isn't what I had in mind." That is the storyline.

Vendor control is not about managing the other side and cracking the whip. It means the buyer taking ownership and helping steer, so the project never loses its way. In this series, we lay out how to do that across three parts.

• Part 1 (this article): Preparation before ordering — locking down requirements and the estimate
• Part 2: Managing the work in progress — the daily habits that keep a project moving
• Part 3: Avoiding trouble and wrapping up — quality, estimates, and closing

Half of all blowups are, in fact, decided before the order is placed. So we start with what you should do before you sign a contract.

Pause before deciding to build at all

Building a new system from scratch is the most expensive and time-consuming option on the table. Before you even consider placing an order, take one step back and ask whether a lighter approach could achieve the same goal.

For each feature, ask yourself three questions: "How many minutes per month does this task take today?" "How much will we invest to cut that?" "Will it actually pay off?" First carve out the parts you can avoid building, then think about how to build what's left.

For example, if you're systematizing an ordering process that currently runs on Excel, you might split it like this.

• Routine orders (80% of the volume) → Can existing tools or off-the-shelf packages handle this with standard features?
• Your own inventory allocation rules (your edge) → This is the part worth building from scratch
• Forms that differ by customer → Absorb whatever the standard can handle, and build custom only for what truly requires it

Just by separating "don't build / lock down with off-the-shelf / build from scratch," you keep both cost and timeline well below what a fully custom build would require.

Confirm "will the frontline actually use this"

Before you finalize requirements, take the time to hear from the people who will actually use the system. A system decided by leadership alone, that doesn't fit how the frontline actually works and ends up unused, is a textbook failure.

• Ask a frontline representative (a key person) about today's workflow and pain points
• Check whether you can state, in a single sentence, "what does this feature make easier for the frontline?"
• Before building, walk through the workflow once on paper or in Excel

How will the features listed in your purchase order fit into the frontline's daily routine? If you can picture that, the precision of your requirements goes up dramatically.

Lock down the definition of done: turn vagueness into numbers

What you need to decide before kicking off is "what does it take to call this complete?" Writing requirements one line at a time, in the format below, cuts down on omissions.

[Who] does [what] to [what] [under which condition]

Example: When the inventory count drops below the reorder point, the system automatically creates a purchase order for the affected product.

The biggest enemy is vague phrasing. "Easy to use," "fast," "flexible" mean different things to different people. The buyer should convert these into numbers up front.

Inspect requirements "one line at a time"

Every time you write a line of requirements, check the following six points. It cuts down on omissions.

• Subject: Who (which user type, or the system) performs the action or processing
• Verb: Is it clear what the system does (generate, send, detect)?
• Object: What is being acted on (the purchase order, the inventory data, the email)
• Condition: When and under what circumstances it runs (when inventory drops below the reorder point, after approval)
• No vague phrasing: As in the conversion table above, if any remains, turn it into a number
• Check in the negative: Picture "the state where this can't happen," and confirm whether that becomes a problem

Alongside this, lay out data access permissions (who can create, read, update, and delete) and state transitions (draft → awaiting approval → approved → sent...) in a table and lock them down. Making "can read but cannot write" items explicit prevents disputes over permissions later.

Non-functional requirements are the buyer's job too

Beyond "what it can do" (functional requirements), the buyer should also put "to what level of quality it runs" (non-functional requirements) into words. Leave this blank and you'll end up arguing later over "it's slow," "it crashes," and "the access controls are too loose." At a minimum, confirm these six.

• Performance: Response time, and the cap on concurrent access
• Availability: Uptime, the target hours, and the recovery goal in the event of an incident
• Security: The access control scheme, how long operation logs are retained, and encryption
• Maintainability: Who changes settings and by what procedure (can an administrator fix it through the GUI alone?)
• Scalability: Future feature additions, growth in data volume, and the cap on the number of users
• Migration: Importing existing data, and running in parallel during the cutover period

Nail down failure handling and exceptions first

The kindling for a blowup hides in "when things don't go to plan." Before you order, work through failure scenarios like these together.

• What happens when an integration partner (another system, a mail server) doesn't respond
• When an approver doesn't act within the deadline, is there a reminder or a delegated-approval path
• What is the behavior when input is invalid or a required field is missing
• How do you stop someone without permission from attempting an operation

It also helps to decide "until when can the operation be performed, and how are exceptions handled after the deadline?" That heads off the disputes that crop up around approval flows, which tend to grow complex relative to the number of screens.

"By when, for how much" is part of the requirements too

It's not just features and quality. The constraints on deadline and budget are "requirements" that should be shared from the start.

• State the budget ceiling, tax included
• Communicate your preferred go-live timing, along with the reason ("before the fiscal close," for instance)
• Communicate the existing systems you need to integrate with, and any constraints on usable technology

If you hide your constraints and take a proposal anyway, you'll later hear, "I wish you'd told me that from the start." Constraints are the preconditions that draw out a good proposal.

Don't accept a "lump-sum" estimate

When an estimate is rolled up into a single line like "operations support features, all-in, ¥X million," you can't see where the money is going, which means you can't compare or trim. Know the patterns vendors tend to fall into that leave the buyer worse off, and inspect every estimate you receive from these angles.

• Rolled into a lump sum → Ask for an itemized breakdown by feature and phase (requirements definition / authentication / master data / each screen...)
• Infrastructure bundled together → Break it into cloud, server, licenses, and monitoring, leaving room for things like annual-contract discounts
• Only one proposal → Ask for several proposals at different configurations (good, better, best) so you can compare
• Only the "best" tier is lavish while the lower tiers are thin → A "decoy designed to push you toward the top tier" gets seen through and erodes trust
• Unclear what's required vs. optional → Ask for each line item to be marked "required / optional"

For example, if you're handed "Web-based ordering, all-in, ¥24 million," break it into line items and get to a state where you can split it as "the ordering screen this term, inventory lookup next term." Itemizing isn't about haggling — it's about reclaiming the material you need to make decisions. Compare costs not just on the initial outlay, but on roughly five years of total cost (TCO), maintenance and modifications included.

Is it worth the investment? Decide with ROI

When you're torn over whether to include a feature, come back to this formula.

Value of the feature = reduction in operational hours + increase in revenue (or reduction in errors/inventory)

Estimate "how many hours per month this feature saves," and weigh it against development and operating costs. As a rule of thumb, if the investment pays back within 12 months, lean in; if it takes more than 24 months, pause and reconsider — and your decisions won't waver.

Standardize your RFP (request for proposal) with a template

To get multiple vendors proposing on the same terms, prepare a single-page request for proposal (RFP). Choose on price alone and you'll hit quality or staffing problems later, so set your evaluation criteria up front as well. Use the items below directly as a template.

• Background and purpose: The current pain points, and what you want to achieve with the implementation
• Scope: What you're building / what you're not building
• Functional requirements: Prioritize each feature as "Must / Should / Could"
• Non-functional requirements: Performance, availability, security, maintenance, scalability, migration
• Constraints: Budget ceiling, deadline, systems to integrate with, technology to use
• Evaluation criteria: Score each vendor using the point allocation in the table below
• Deliverables: What you want delivered as finished work (this one tends to get missed)

Feel free to use this RFP template as a handy reference. Just fill in your own items, and you'll be able to compare every vendor's proposal on a level playing field.

Don't let deliverables be just "the spec document"

The most frequently overlooked part of an RFP is the "definition of deliverables." Beyond the spec document and the source code, spelling out the following as deliverables makes later maintenance and verification dramatically easier.

• Table design document (DB design): What tables exist, and what fields they hold
• Per-table operation list (CRUD matrix): Once you have the design document, ask for a list of "which table, which operation, at which timing, performs create / read / update / delete." With this in hand, the flow of data never becomes a black box
• API test results: The test cases and results for each API (both normal and abnormal paths). Ask for evidence that it was tested, not just "it should work"

Deciding on deliverables up front also makes the pass/fail criteria for acceptance testing (covered in Part 3) clear. Lock down "what gets delivered for this to count as complete" at the RFP stage.

Scope: write down "what you're not building" too

When you finalize requirements, document not just "what you're building" but also "what you're not building this time (out of scope)."

• Write the features included in this scope separately from those not included
• Keep "might do someday, but not this time" items on the list as out of scope
• Writing down what's out of scope prevents the "surely this is included too, right?" arguments mid-development

Drawing the line on scope heads off the majority of disputes before they happen. "Deciding what not to do" is a perfectly legitimate part of requirements definition.

Confirm the approval and budget flow

To move an order along smoothly, get a handle on your organization's decision-making flow at the very start.

• Who gives final approval on the budget (who is the decision-maker)
• What materials are needed to get the request approved
• How long the approval takes

With an itemized estimate and configuration options you can trim, the decision-maker has an easier time deciding. Placing an order is a "negotiation with the vendor" and, at the same time, a matter of "lining up internal approvals."

Part 1 checklist

• Did you check whether an existing tool or spreadsheet could get the job done in the first place?
• Did you write out "what it takes to be complete" concretely, in the requirements format?
• Did you turn vague language into numbers?
• Did you lock down the non-functional requirements (performance, availability, security, maintenance, scalability, migration)?
• Did you decide failure and exception behavior up front?
• Is the estimate broken into line items and in a form you can compare across multiple proposals?

Related learning material: For how to approach requirements definition and business-flow design, you can study it systematically in the freely available IT Consulting Guidebook (courses on requirements definition and business flows for on-site implementation).

Wrap-up and what's next

Preparation before ordering is the single biggest lever for preventing a blowup. Lock down the definition of done, turn vagueness into numbers, work through the non-functional requirements and the failure scenarios, and receive the estimate as itemized line items. Only once you've done all this does placing an order become a matter of "design" rather than a "gamble."

Next time (Part 2), we cover progress management after the contract — meeting structures, reporting, risk handling, and the other daily habits that keep a project moving.

And when handling all this pre-order groundwork in-house alone feels daunting, a PMO with a development-firm background can stand on the buyer's side and provide hands-on support. After all, that first round of locking things down is what most heavily decides whether a project succeeds or fails.