The proposal is the first document that builds trust between consultant and client. A poor proposal — focused on hours, vague about deliverables, and open-ended without limits — is the main cause of projects that end in frustration. A good proposal aligns both sides before the work begins.
Illustrative diagram — anatomy of an unambiguous proposal.
🧾 Anatomy of a proposal that sells results
Most proposals start with “I’ll do X hours of Y.” The proposal that closes the deal starts with "your problem is Z, the expected outcome is W, here's how to get there". Clients buy results, not hours.
📐 Structure of an effective proposal
- 1.Context — the client’s problem in one sentence. It shows you understood.
- 2.Expected result — what changes in the operation or the numbers. Concrete and measurable.
- 3.Approach — how you’ll get there. Phases, deliverables, methodology.
- 4.What’s included — fixed scope, named deliverables.
- 5.What’s not included — explicit out-of-scope items.
- 6.Price and terms — per project, per phase, or on retainer. Never hourly only.
💡 Practical tip
Start the proposal with the outcome: "By the end of this project, you'll have [concrete result]." If you can’t complete this sentence before you start writing, you don’t understand the problem well enough yet.
shows that you listened
the why behind everything
the structured how
scope + out of scope
🎯 Scope, deliverables, and out of scope
Scope creep isn’t an event—it’s a gradual process. It starts with a small request ("can you include this?") and keeps growing until the project becomes unfeasible. The antidote is in the proposal: writing down what’s out of scope is just as important as writing down what’s in scope.
✓ Well-defined scope
- ✓Named deliverables with acceptance criteria
- ✓Out of scope listed explicitly
- ✓Documented change request process
- ✓Both parties sign off on the understanding
✗ Vague scope
- ✗"Help with AI" without specifying what
- ✗Without out-of-scope items = anything can be requested
- ✗Changes accepted verbally without being documented
- ✗A project with no defined end
📊 The out-of-scope rule
Whenever the client asks for something that isn’t in the proposal, you have two options: include it for free (and create the expectation that they can ask for anything) or treat it as a change request with separate pricing. The second option seems harder—but it’s what keeps the relationship healthy.
🗓️ Phases and milestones — assessment, plan, execution
Dividing the engagement into phases works for both sides: the client has checkpoints to assess whether to continue; you have natural opportunities to renew and expand. A phase completed successfully is the best way to sell the next phase.
🔍 Phase 1 — Assessment / diagnosis
~2 to 4 weeks · product: prioritization report
Maps the current state, identifies opportunities, and prioritizes use cases. Small scope and affordable pricing reduce the client's perceived risk of hiring someone new.
🗺️ Phase 2 — Plan / roadmap
~2 to 3 weeks · product: roadmap + business case
Turns the opportunities into an execution plan with phases, estimated ROI, and risks. Gives the client what they need to get internal budget approval.
⚙️ Phase 3 — Execution
~1 to 6 months · product: deployed and adopted solution
Implements the prioritized use cases, tracking adoption and value metrics. The biggest project, made possible only because trust was built in the earlier phases.
💡 Why the ladder works
The client who completed the assessment with you has already paid to see you work. They have evidence of your method, not just a promise. Selling phase 2 to someone who approved phase 1 is infinitely easier than selling from scratch to a stranger.
🤝 Expectations: what the client also needs to do
The consultant delivers better when the client does their part. Projects don’t fail because the consultant is incompetent—they often fail because the client wasn’t available: took too long to validate, didn’t provide access, stakeholders didn’t attend critical meetings.
What to ask the client for in the proposal
- •Access to data and systems — without this, the assessment is based on assumptions.
- •Stakeholder availability — at least 2h per week from someone with decision-making authority.
- •On-time validations — a delay in the review delays delivery. That’s on you too.
- •Sponsor designated — someone with authority who advocates for the project internally.
⚠️ Warning sign
If the client doesn’t want to name a sponsor or can’t guarantee 2h of availability per week, the project will stall. This needs to be resolved before signing, not after the first month.
📐 SOW and acceptance criteria
The Statement of Work (SOW) turns the proposal into an operational agreement. The acceptance criterion answers a simple question: how do both of you know the deliverable is ready? Without an objective answer to this question, the project never ends.
Examples of objective acceptance criteria
- ✓ Clear: "Report delivered and approved at a review meeting attended by the sponsor."
- ✓ Clear: "Model with ≥ 85% accuracy on the test set provided by the client."
- ✓ Clear: "Dashboard published with access for 5 users designated by the client."
- ✗ Vague: "Client satisfied with the result."
- ✗ Vague: "Solution working as expected."
measurable or verifiable
yes or no, not "more or less"
the client signs before work begins
there is a defined "done"
🚩 Signs of a project or client to turn down
Turning down a project feels counterintuitive—it seems like losing money. In practice, the wrong projects cost more than they bring in: they drain energy, take up capacity that could go to good projects, and, if they end badly, send the market the wrong signal. Knowing how to say no is part of positioning.
🚩 Red flags before signing
- ✗Impossible scope — the promised outcome cannot be achieved with the available resources.
- ✗No sponsor — no one internally has the authority or interest to lead the project.
- ✗Data unavailable or inaccessible — the project depends on data the client doesn’t have or can’t provide.
- ✗Client wants results without getting involved — “get everything ready for me” without making time or decisions.
- ✗Price below the minimum — what the client is willing to pay doesn’t cover the cost of the relationship.
- ✗Misalignment of values — you wouldn't be able to recommend the outcome the client wants to achieve.
💡 How to decline without damaging the relationship
Be specific about why: "To deliver the result you expect, I’d need X—and you don’t currently have that available. It wouldn’t make sense to sign now." This keeps the door open for when the situation changes—and positions you as honest, not as someone who lost interest.
🎒 Module summary
Next module:
5.2 — Engagement pricing: pricing models, offer ladder, and how to charge for the assessment