Comparable proposals start with a clear project description: 12 details worth providing

The current UK Sourcing Playbook states that a clear specification should provide bidders with enough information to make an informed decision about whether they want to bid. It also notes that without a shared understanding of requirements, it is difficult to relate proposed prices to the buyer's understanding of costs and intended outcomes. [1]

The Government Commercial Function puts the point even more directly: a good specification should contain enough information for suppliers to cost goods or services accurately so that the buyer can compare bids on a like-for-like basis. [2]

At the same time, the UK Digital, Data and Technology Playbook warns against over-specifying the solution. It recommends focusing on the user, the problem and the intended outcome while leaving suppliers room to propose an effective way of delivering it. [3]

The conclusion is not "describe everything in as much detail as possible." A better rule is:

describe precisely what must be common across all proposals, not what a capable specialist can reasonably design themselves.

Two professional proposals will never be identical, and that should not be the goal.

Comparability means that specialists are responding to the same problem under broadly similar assumptions.

They should therefore have roughly the same understanding of:

• the objective,
• the scope,
• the starting point,
• the expected outcome,
• important constraints,
• the timeline,
• client responsibilities,
• how price should be presented,
• the criteria by which the proposal will be assessed.

They may still differ in areas such as:

• proposed approach,
• sequence of activities,
• method,
• team composition,
• tools,
• division into stages,
• approach to reducing risk.

Those differences are often valuable and should remain visible.

Start with the problem, not a feature list.

Instead of:

"I need an application with a dashboard, notifications and reports."

try:

"Five people currently manage the process through spreadsheets and email. It is difficult to see the current status of a case, who owns it and what should happen next. We want to reduce manual tracking and have one place showing the current state."

The second description does not yet decide what application should be built.

It does help the specialist understand why the project exists in the first place.

The Federal Acquisition Regulation for performance-based services recommends describing work primarily in terms of required results rather than how the work is to be performed or the number of hours to be provided. Its minimum statement of objectives includes elements such as purpose, scope, background, required results and operating constraints. [4]

So describe what should be possible when the work is complete.

For example:

• a user can complete a defined process independently,
• the team can see the current status of every case,
• the client receives an analysis with priorities,
• the system is moved to a new environment and operates against agreed criteria,
• the prepared material is ready for publication in a specified channel.

The outcome should be concrete enough for both sides to understand the direction of the work.

It does not have to mean guaranteeing a business result that depends on the market, user behaviour or other factors outside the provider's control.

The same end need can require very different effort depending on where you start.

It is useful to state:

• what already exists,
• what works and should be preserved,
• what does not work,
• whether source files exist,
• whether documentation exists,
• whether data must be migrated,
• whether the specialist must work on an existing system,
• which materials are already available.

"A new website" could mean a build from scratch or a redesign of an existing site while preserving content, URLs, analytics, integrations and data.

Those are different jobs even if the final visual result might look similar.

The scope should not force specialists to guess which parts of the problem they are expected to price.

For example:

In scope:

• analysis of the current solution,
• design of new views,
• implementation,
• migration of a defined subset of data.

Out of scope:

• creating new content,
• purchasing licences,
• maintenance after the first month,
• rebuilding the payment system.

The World Bank's sample Terms of Reference emphasises that the requirements and expectations for consulting services should be clearly articulated and adapted to the specific project. [5]

Boundaries are especially important when two tasks are naturally related and it would be easy to assume that one includes the other.

If you expect specific materials or outputs, name them.

These might include:

• a working solution,
• source files,
• a report,
• documentation,
• a visual design,
• a set of materials,
• environment configuration,
• training,
• a recording,
• transfer of code and access.

Words such as "design", "analysis" or "implementation" can be interpreted differently.

A shared list of major deliverables helps avoid a situation in which one proposal contains far more than another, but the difference is hidden behind a similar service label.

Not every constraint is a technical detail.

Relevant constraints might include:

• a required system or environment,
• mandatory integration with a specified service,
• accessibility requirements,
• industry regulation,
• restrictions on data storage,
• a requirement to preserve existing infrastructure,
• specific devices or browsers,
• work within defined hours,
• restrictions on access to data.

The FAR explicitly includes operating constraints in a statement of objectives, while the UK Digital, Data and Technology Playbook also shows why a solution should not be prescribed where a real constraint does not exist. [4] [3]

A useful rule is:

state what the specialist cannot change, but do not invent a constraint simply because you are used to one particular solution.

The specialist should know what level of cooperation they can base their proposal on.

State whether you will provide:

• a decision-maker,
• system access,
• existing materials,
• data,
• test accounts,
• information from the team,
• access to users,
• content,
• regular meetings,
• responses within a defined time.

If you do not yet know what you can provide, it is still useful to say so.

Lack of access to data, materials or people can change the method, cost and timeline. This is not a minor administrative detail. It is part of the conditions on which the proposal is built.

Not every date has the same meaning.

Distinguish between:

• preferred start date,
• hard deadline,
• a date tied to an external event,
• indicative date,
• stages that must happen in a particular sequence.

If a deadline genuinely cannot move, explain why.

If it is flexible, say that too.

This gives the specialist room to propose a different scope, sequence or staged delivery rather than assuming every date is an absolute requirement.

There is no single rule saying a client must always disclose the full budget.

Depending on the situation, you can provide:

• a maximum budget,
• a budget range,
• a budget for the first stage,
• a note that you want a scope proposal first and pricing afterwards,
• the expected structure of the price breakdown.

For comparison, the most important thing is that specialists present cost in a similar structure.

For example:

"Show the price separately for analysis, design, implementation and monthly maintenance. Also identify third-party costs that are not included."

That format is far easier to compare than four different totals where each total covers something different.

Uncertainty does not disappear just because it is not written down.

If you do not know:

• how much data must be migrated,
• whether an external interface supports the required operation,
• whether all content will be ready,
• whether the current code can reasonably be extended,
• whether a required approval will arrive on time,

say so.

GAO's guide to reliable cost estimating highlights the importance of explicit assumptions and risk and uncertainty analysis. [6]

A good specialist can then:

• include a contingency,
• propose a discovery stage,
• price alternatives,
• identify a condition that would change the price,
• refuse to pretend to a level of precision that cannot honestly be achieved yet.

An explicit unknown is better than a hidden assumption.

If you already know what will matter in the decision, say so before proposals are prepared.

You might assess:

• relevance of the proposed approach,
• experience with similar problems,
• quality of evidence from previous work,
• realism of the timeline,
• availability,
• approach to risk management,
• skills of the people who will actually work on the project,
• price,
• maintenance cost,
• quality of communication.

The World Bank's current guidance on Rated Criteria notes that non-price criteria can include the quality of methodology and work plan, risk management, performance and capacity, and key personnel. Criteria are tailored to the procurement and weighted according to their relative importance. [7]

That does not mean a small project needs formal scoring.

It is enough to answer this question before you send the request:

"What, apart from price, would make one proposal better for me than another?"

If you genuinely want to compare proposals, ask everyone to answer the same basic set of questions.

For example:

1. How do you understand the problem and expected outcome?
2. What approach do you propose?
3. What exactly does your proposal include?
4. What is excluded?
5. What assumptions are you making?
6. What is the timeline?
7. What do you need from the client?
8. What are the main risks?
9. What is the price and exactly what does it include?
10. What similar experience or work evidence is relevant to this project?

In public procurement, standardising responses, criteria and pricing formats is used precisely so that proposals can be assessed on a common basis. The Government Commercial Function stresses the need to provide enough information for accurate costing and like-for-like comparison. [2]

A common format should not erase differences between specialists. It should simply make those differences visible in the same places.

It depends on the purpose of the request.

Sharing the budget can help when:

• the scope can be adjusted to available funds,
• you want a recommendation for the best option within a defined ceiling,
• you want to rule out proposals that do not fit the project's financial reality quickly.

Not sharing the full budget can make sense when:

• you first want an independent view of the appropriate scope,
• you do not yet know the realistic cost,
• you are comparing different solution models,
• the process requires a different way of collecting prices.

The worst situation is not necessarily the absence of a budget. It is the absence of information about what kind of pricing response you expect.

The specialist should know whether to provide one total, a range, alternatives, stage-based pricing or assumptions needed for a more precise estimate.

A good project description does not need to answer every question.

It can honestly say:

• "We do not yet know whether the current system can be extended safely.",
• "We do not know the exact number of records that will require migration.",
• "We have not yet decided whether the second language version belongs in the first stage.",
• "We need help choosing the best option."

That is useful information.

Uncertainty should affect how the proposal is prepared, not disappear from the document.

In some situations, the best first service is not full delivery but a short discovery stage that ends with a decision, a more precise scope or a more reliable estimate.

1. Giving each specialist a different set of information.

2. Listing features without explaining the problem and objective.

3. Failing to describe what already exists.

4. Hiding constraints that later change the delivery method.

5. Asking for one final price without stating what it should include.

6. Judging proposals using criteria you had not defined for yourself in advance.

7. Confusing a detailed description of the problem with a detailed prescription of the solution.

1. Have I clearly described the problem, not only the solution I imagined?
2. Is the outcome I want to achieve clear?
3. Does the specialist understand the current state?
4. Is it clear what must be preserved?
5. Are the boundaries of the first scope clear?
6. Have I named the most important deliverables?
7. Have I stated the real constraints?
8. Is it clear what I will provide on my side?
9. Is the timeline described together with its flexibility?
10. Will the pricing format allow proposals to be compared?
11. Have I openly described the most important unknowns?
12. Do I know what I will assess apart from price?
13. Will all specialists answer a similar set of questions?
14. Have I left room for a better solution than the one I imagined?

A good project description has two apparently competing goals.

It should be specific enough for several specialists to price the same problem.

At the same time, it should be open enough for each of them to propose their own, potentially better approach.

A useful order is:

problem -> outcome -> current state -> scope -> deliverables -> constraints -> client responsibilities -> timeline -> pricing format -> unknowns and risks -> selection criteria -> common response format.

If, after receiving proposals, you discover that one person priced the full project, another only the analysis and a third assumed additional integrations, the problem may not be in the quotes.

They may each have received a different assignment even though everyone was sent the same text.

[1] UK Government - The Sourcing Playbook
Open source

[2] Government Commercial Function - How to write a procurement specification
Open source

[3] UK Government - The Digital, Data and Technology Playbook
Open source

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Open source

[5] World Bank - Sample Consultants Terms of Reference
Open source

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Open source

[7] World Bank - Rated Criteria
Open source

Methodology note: the sources come mainly from public procurement and cost-management contexts. They are not presented as direct rules for a private specialist marketplace. The article uses only principles they actually support: clarity of requirements, focus on outcomes, explicit assumptions and risk, comparable pricing information and quality evaluation using criteria beyond price alone.