Proposals are not written to be compared
A software proposal is a sales document that has to double as the basis of a contract, and those two jobs pull in opposite directions. The sales half wants to sound confident and complete. The contract half wants to limit what was promised. The result is a document where the confident language lives in the front and the limiting language lives in the back, and where the number on the summary page is a function of choices buried thirty pages behind it. Three vendors bidding the same work will produce three documents with different section orders, different units, different assumptions about who supplies the data, and different definitions of the word "delivered." That is not usually deception. It is what happens when three firms each describe an ambiguous job in their own house style. Your job as the buyer is to convert them into comparable objects, and nothing in the documents helps you do it.
The good news is that the information you need is usually present. It is simply not in the part of the document designed to be read. This piece is written from the seller's side of the table, which means it names the places where our own trade hides its risk.
You are probably here because
- Two bids for the same work differ by a factor of three and you cannot tell why
- The last project came in at nearly double the proposal and every increase was arguably legitimate
- You are being asked to sign something forty pages long that your team cannot technically assess
- A proposal reads well and you have a feeling that it says less than it appears to
The reading order below surfaces the risk first. In our experience the four pages that decide the outcome are assumptions, exclusions, acceptance and change control — and all four sit behind the part most people read.
Read it in the wrong order on purpose
Almost everyone reads a proposal front to back: summary, understanding of the problem, approach, team, timeline, price. That order is optimized for persuasion. Read it in this order instead, and read the first four sections of every bid before you read the approach section of any of them.
1. Assumptions and dependencies. This is where the price comes from. Every assumption is a risk the vendor has handed back to you.
2. Exclusions, or "out of scope." The scope is defined by this list far more precisely than by the description of the work.
3. Acceptance criteria. How anyone will know the thing is finished. If this is vague, the schedule is fiction.
4. Change control. What a change costs and who decides it is a change. This is the price of everything not in the document.
5. Team and named people. Who does the work and how much of them you get.
6. Price structure and payment schedule. Who carries which risk, and when your money leaves.
7. Approach and timeline. Read last. It is the most enjoyable section and the least binding.
The reason for the inversion is simple: the front of a proposal describes the world in which everything goes well, and the back describes what happens otherwise. Projects are decided by the second world.
The assumptions page is the real price
Every fixed number in a proposal rests on a stack of assumptions, and a well-run vendor writes them down because they are the boundary of the commitment. Read each one and ask a single question: what happens to the schedule and the price if this turns out to be false?
Some assumptions are harmless. "Client will provide branding assets" is a Tuesday afternoon. Others are the whole project wearing a small sentence. Watch for these four in particular.
"Client will provide access to systems and data within five business days of kickoff." This is the most common schedule bomb in the industry. Data access in a mid-size company routinely takes three to eight weeks once security review, a data-sharing agreement, a vendor security questionnaire and one unavailable database owner are involved. If the plan assumes five days and reality is six weeks, the vendor is idle and billing, or the team is disbanded and re-formed later at a cost. Before signing anything, find out who actually grants that access and ask them how long it takes.
"Existing documentation is accurate and current." It is not. It never is. This assumption converts an unknown quantity of archaeology into a change order.
"Data is in a usable, structured form." On data and AI work this single line can be half the effort. Ask the vendor what they will do if it is not, and whether they have looked at the data yet. If they have not looked, no number in the proposal is an estimate. It is a guess with a decimal point.
"Third-party APIs will behave as documented." Sometimes true. When it is false it is expensive, and the vendor has told you in advance who pays.
That inversion is worth sitting with, because it drives bad selections. A vendor who has thought hard about a project produces more assumptions, more exclusions and a higher number. A vendor who has thought about it less produces a clean, confident, cheaper document. The second one is more pleasant to read and is where the overruns come from. When a bid is materially lower than the others, the correct first hypothesis is not that they are more efficient. It is that they are pricing a smaller job.
Scope is defined by the exclusions
The description of work tells you what the vendor imagines building. The exclusions tell you what you will be paying someone else to do. Go through the list and mark each item with who does it: them, you, or nobody yet. The third category is where projects die.
Items commonly excluded, each of which is real work somebody has to do: data cleanup and migration of historical records, user acceptance testing and the coordination of testers, training and internal change management, third-party licenses and cloud costs, security review and any compliance evidence, production support after go-live, and integration with systems the vendor cannot access. If four of those land in the "nobody yet" column, the proposal in front of you covers perhaps sixty percent of the project.
Ask for the exclusions list explicitly if there is not one. A vendor who declines to write down what they are not doing has not scoped the work, and you will discover the boundary during the argument rather than before it.
Acceptance criteria, or how anyone knows it is done
This is the section that determines whether the last twenty percent of the project takes two weeks or five months. A deliverable described as "a reporting dashboard" has no finish line. A deliverable described as "a dashboard presenting the six metrics listed in Appendix B, refreshed nightly, matching the finance team's month-end figures for the three months of test data, loading in under four seconds on the reference dataset" has one, and both sides can see it.
On machine learning and AI work this matters more than anywhere else, because accuracy language is easy to write and almost meaningless without a protocol. "95% accuracy" is not an acceptance criterion. The criterion is the whole procedure: which held-out set, drawn from what population, labeled by whom, sealed before work starts, measured how many times, and what happens if it lands at 91%. Without those, the number can be met by choosing a friendly test set after the fact, and there is no dishonesty required for that to happen — it is simply what people do when the measurement is defined at the end.
| Price structure | Who carries scope risk | What it is good for | What to watch |
|---|---|---|---|
| Fixed price | The vendor, in theory | Well-specified work with a stable scope | The change-order rate. Fixed price with loose scope moves the money into changes |
| Time and materials | You, entirely | Discovery, ambiguity, research | No ceiling and no incentive to finish. Cap it and stage it |
| T&M not to exceed | Shared, tilted to the vendor | Most real engagements | The cap is only meaningful if the scope under it is written down |
| Milestone / deliverable | Shared at each boundary | Multi-phase builds with checkpoints | Whether each milestone has an acceptance test or just a date |
| Retainer / monthly | You, softly | Ongoing work and support | What you are entitled to per month, in writing, and how unused capacity is treated |
A fixed-price bid is not automatically safer than time and materials. Fixed price with a loosely defined scope simply relocates the negotiation to the change-order process, where you have less leverage because the vendor already holds the work. Read the change-order rate next to the base rate: if the base is $180 and changes are billed at $250, the pricing is telling you where the vendor expects to make its margin.
What actually predicts a good outcome — our weighting
Weights sum to 100. Our judgment about which proposal features correlate with projects that finish, not a measurement. Price matters and it is not the top of the list.
The team section: names or nouns
There are two ways to describe a team. "A senior engineer, a data engineer and a technical lead" is a description of roles. "Two engineers, named, at sixty percent and one hundred percent for fourteen weeks, with their prior work listed" is a commitment. The difference is the entire value of the section.
Where names are given, check three things. Are these the same people who came to the meetings? What percentage of their time is committed, in writing? And what happens if one becomes unavailable — is there a substitution clause requiring your approval, or can the vendor swap anyone for anyone at their discretion? A substitution clause requiring written consent for key personnel is standard, cheap to ask for, and rarely offered unprompted.
Where only roles are given, that is not automatically bad. It is honest for a large firm that genuinely staffs from a pool. But it means you are buying the firm's average rather than a team, and you should price that accordingly and stop treating the pitch team as evidence.
The schedule, and what a week means
Timelines in proposals are usually correct about sequence and optimistic about duration. Two questions clarify most of it.
Does the schedule contain your own work? A plan showing twelve weeks of vendor activity and nothing from your side is not a plan. Somewhere in there you owe them data access, subject-matter expert time, decisions, test participants and a production environment. If those are not on the chart with owners and dates, the chart is measuring one of the two parties in the project.
Is there any slack, and is it labeled? Mature estimates carry contingency and say so. An estimate with no contingency is either padded invisibly, in which case you cannot tell how much, or genuinely unpadded, in which case it is wrong. Ask the question directly. A vendor who says "there is about fifteen percent contingency in the integration phase because we have not seen the third-party API" is telling you exactly what you need to know.
Ask each bidder what they would remove to cut the price by a third
This question does more work than any other. A vendor who understands the project will name specific scope, explain what you lose, and tell you what they would keep. A vendor who offers the same scope for less has been overpricing, and a vendor who says nothing can be removed has not decomposed the work. It also converts three fixed bids into three menus, which is a far more useful thing to compare.
Normalizing three bids that are not comparable
Build one table yourself. Do not accept the vendors' structures. Six columns: the deliverable in your words, whether each bidder includes it, the assumption each attaches to it, the hours or price each assigns, who on your side is required, and what happens if it goes wrong. It takes an afternoon and it usually reveals that the three bids differ on inclusion rather than on efficiency.
Then add the lines nobody bid, because they belong in the comparison whether or not anyone priced them: data cleanup, security review, licenses and cloud spend, training, and the first year of support. Price them roughly and identically across all three. It is common for the ranking to change once those are on the page, and it is common for a bid to move from cheapest to most expensive because its low price was purchased by narrow scope.
One more normalization: put every bid on the same time basis. A fixed-price bid and a T&M bid are not comparable until you assume a duration for the second. Use the vendor's own estimate plus a contingency you choose, and apply the same contingency to everyone.
Send us the proposals and we will tell you what they are actually pricing.
Email the bids, with names redacted if you prefer, to contact@precisionfederal.com along with a paragraph on what you are trying to build. You will get back a written read on where the scopes differ, which assumptions carry the schedule risk, and the questions to send back to each bidder. One business day. No charge, no meeting.
contact@precisionfederal.comWhat a strong proposal contains that a weak one omits
Over enough documents the pattern is consistent. Strong proposals share features that have nothing to do with polish.
They state what they do not know. A section listing open questions and how the vendor intends to resolve them is a sign of a team that has actually thought about your problem rather than pattern-matched it to their last one.
They describe a first deliverable early. Something real inside four to six weeks, with a test. This limits your exposure and demonstrates that the work has been decomposed.
They price the boring parts. Documentation, handover, testing, deployment and support appear as line items rather than as adjectives. Work that is not priced is work that will be cut.
They say who owns what. Source code, trained models, derived data, and the accounts everything lives in. If the proposal is silent on ownership, the default is often less favorable to you than you assume, and it is far cheaper to fix now than after delivery.
They contain at least one disagreement with you. Somewhere in a good proposal is a sentence saying the approach you asked for is not the one they recommend, and why. That sentence is worth more than the rest of the document, because it is evidence that someone applied judgment rather than transcription.
The mistakes buyers make reading proposals
- Reading front to back, so the persuasive sections set the frame before the limiting ones are seen
- Comparing totals across bids that include different work
- Treating the low bid as efficiency rather than as a smaller scope
- Skipping the assumptions page, which is where the price is actually determined
- Accepting "95% accuracy" with no test set, no protocol and no consequence defined
- Letting the schedule show only the vendor's work and none of yours
- Ignoring the change-order rate, which is the real price of everything not written down
- Never asking what they would cut, and so comparing three fixed points instead of three menus
A two-week evaluation
Proposal Evaluation
Step six is the one that changes outcomes. Acceptance criteria written by the buyer are specific about the thing the buyer cares about, and a vendor who will sign them has understood the job. A vendor who negotiates them is doing you a favor by surfacing the disagreement now. A vendor who signs them without reading is the one to worry about.
Before you sign
- Every assumption has a written answer to "what if this is false"
- The exclusions list exists and every excluded item has an owner
- Acceptance criteria are testable by you, without the vendor present
- The delivery team is named with committed percentages and a substitution clause
- The schedule shows your obligations with owners and dates
- Change control states a price, a process and who approves
- Ownership of code, models, data and accounts is stated explicitly
- Documentation, handover and support are line items, not adjectives
- There is a real deliverable inside six weeks that you could stop after
- You have priced the unbid lines identically across all bidders
Bottom line
The front of a proposal is written to be read and the back is written to be enforced. Read the back first. The assumptions determine the price, the exclusions determine the scope, the acceptance criteria determine when you stop paying, and the change-order terms determine the cost of everything nobody thought of. Those four sections take an hour across three bids and they are the hour that decides the project.
And when one bid is much cheaper, resist the pleasant explanation. Find the paragraph where it is smaller. It is always there, it is usually short, and it is usually the part of the job you were least equipped to do yourselves.
Frequently asked questions
A smaller scope, almost always. Compare the exclusions lists and the assumptions pages side by side rather than the totals. Common places the difference hides: data cleanup, testing, deployment, documentation, and post-launch support. If the scopes genuinely match, the next likely explanations are junior staffing or a deliberately low entry price expected to be recovered through change orders.
Only when the scope is genuinely well-defined. Fixed price on a loose scope moves the negotiation into change orders, where you have less leverage because the work is already underway. For ambiguous work, a capped time-and-materials arrangement broken into short stages with real deliverables usually produces better outcomes than a fixed price that both sides know is a guess.
A complete measurement protocol rather than a number. Name the held-out dataset and where it comes from, who labels it and when, that it is sealed before work begins, the metric and the threshold, how many attempts are permitted, and what happens if the threshold is missed. A number without that protocol can be satisfied by choosing a favorable test set after the fact, which is the most common way an accuracy commitment becomes meaningless.
No. It usually indicates the vendor has thought about the project seriously, and it makes the risks visible while you can still act on them. What should worry you is a proposal with no assumptions at all, because those risks still exist and have simply not been written down. Read each assumption and decide whether you can make it true; that is the useful exercise.
"What would you remove to cut this by a third, and what would we lose?" It reveals whether they have decomposed the work, forces them to rank the components by value, and turns a fixed bid into a menu you can actually compare. A close second is asking what part of your plan they would push back on.