It Proposal Writing

IT Proposal Writing

Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.

Required Inputs

Capability and permission contract

Default to read-only analysis and drafting. Do not publish, send, price, promise, alter customer records, commit budget, or modify production artefacts without explicit authority and a named approver. Minimise confidential data, preserve provenance, and keep reversible copies.

Degraded mode

If evidence, stakeholder decisions, specialist tooling, or authoritative commercial data are unavailable, deliver a labelled draft, checklist, or decision memo. State what was not verified and do not claim approval, publication, financial accuracy, or customer acceptance.

Decision rules

Domain Anti-Patterns

• Inventing customer evidence, prices, benchmarks, or approvals. Fix: cite the source or mark the gap.
• Publishing or sending a draft without authority. Fix: retain draft status and name the approver.
• Hiding assumptions inside polished prose. Fix: expose them beside each affected decision.
• Polishing presentation while the decision remains unclear. Fix: resolve audience, owner, and acceptance criteria.
• Treating unavailable tooling as passed validation. Fix: record the unassessed check.

Use When

• Framework for writing persuasive IT project proposals that win work. Covers Basis of Decision (BOD), Unique Selling Points (USP), proposal strategy, document structure, persuasive prose techniques, the 5-level destruction model, grammar rules...

Workflow

• For premium software or website proposals, load premium-software-product-execution and show how value, proof, risk reduction, delivery process, controls, content/SEO, UX, and support justify the fee.

Evidence Produced

References

• Use the links and companion skills already referenced in this file when deeper context is needed.
• Use premium-software-product-execution when proposing premium software, websites, SaaS, ERP/POS, dashboards, or agency delivery.

Based on Coombs, P. (2005). IT Project Proposals: Writing to Win. Cambridge University Press.

When to Use

• Responding to a client Request for Proposal (RFP) or tender
• Writing an unsolicited proposal for a prospect
• Preparing an internal business case for a technology project
• Reviewing a proposal before submission

The core truth about proposals: Your proposal is your shop window. A proposal full of accurate facts, buried in jargon and poor structure, will lose to a clearly written proposal from a weaker competitor. Good communication is what makes or breaks the deal.

1. The Proposal Lifecycle

Every winning proposal follows this sequence. Do not skip steps.

1. Establish the Strategy  →  BOD + USP + Reader + Approach
       ↓
2. Choose the Content      →  What the reader needs to see (not what you want to say)
       ↓
3. Determine the Structure →  Document plan, sections, headings
       ↓
4. Write the Proposal      →  Persuasive, specific, plain-language prose
       ↓
5. Review and Rate         →  Internal review using the Proposal Evaluation Questionnaire
       ↓
6. Submit                  →  Final check: compliance, presentation, contact details

The lifecycle is iterative. Content choices may force you to revise the structure. A review finding may require rewriting a section. Allow time for iteration.

2. Establishing the Strategy

Basis of Decision (BOD)

The BOD is the set of criteria — stated or unstated — that the reader will use to evaluate your proposal. Understanding it is the most important step in proposal strategy.

Sources of the BOD:

• The RFP itself (stated evaluation criteria)
• Knowledge of the client's organisation, budget pressures, and political context
• Prior conversations with the client
• The problem statement the client has articulated

If you do not know the BOD, you cannot write a targeted proposal. You will write a generic document that answers questions nobody asked.

Questions to determine the BOD:

1. What is the client's primary problem, stated in their own words?
2. What does success look like to the key decision-maker?
3. What are the unstated concerns (risk aversion, budget justification, internal politics)?
4. Who else is the client likely to receive proposals from?
5. What would make the client choose a competitor over you?

Unique Selling Points (USP)

Your USP is the answer to: "Why should this client choose us over every other option?"

A USP must be:

• Specific: "We have delivered 3 school management systems in Uganda with a combined user base of 40,000 students" — not "we have extensive education sector experience."
• Relevant to this client: Connect your strength to their specific need.
• Credible: Backed by evidence (case study, reference, data).
• Differentiated: Something the competition cannot honestly say.
• Value-defending: Makes the invisible parts of software quality visible: discovery, controls, architecture, UX, content, SEO, security, testing, support, onboarding, reporting, and change control.

If your USP is "we are experienced, professional, and client-focused," you have no USP. Every proposal says this. None of it persuades.

Knowing the Reader

Write for the decision-maker, not for yourself.

• Who will read this proposal? (Procurement officer? CTO? Board member? All three?)
• What is their technical level? Do not write for your own level of expertise.
• What are they worried about? Address their risk explicitly — do not wait for them to ask.
• How long will they spend reading it? Assume less time than you expect. Every word competes for attention.

3. The 5 Levels of Proposal Failure

Coombs identifies 5 progressive ways a writer's message is destroyed before it reaches the reader.

Level 5 errors make the client doubt Level 1. If you cannot proofread a document, the client doubts whether you can manage a project.

4. Choosing Content

The Golden Rule of Content

Include only what advances your argument that you are the best solution to the client's problem. Every sentence should satisfy one of these tests:

• It demonstrates that you understand the client's problem.
• It shows that your solution is credible and complete.
• It provides evidence that you can deliver (past projects, methodology, team expertise).
• It addresses a specific risk or concern the client has stated or implied.

Nothing else belongs in the proposal. No company history unless it directly supports a claim. No technical deep dives unless the reader is technical and the detail is evaluatively relevant.

Typical Proposal Sections

5. Structuring the Document

The Inverted Pyramid

Put the most important information first. Decision-makers read executive summaries and skim the rest. If your key differentiator is on page 8, it will not be read by everyone.

Structure of the Executive Summary (mandatory):

1. Statement of the client's problem (in their language — not yours)
2. Your proposed solution in 2–3 sentences
3. The key reason to choose you (top USP, evidence-backed)
4. Total investment (price) and timeline

Section Headings That Work

Headings must stand on their own. A reader scanning headings should understand the proposal arc.

6. Writing Persuasive Prose

Spin the Words: Benefit-First Writing

Every technical claim must be translated into a reader benefit.

Before: "The system uses a microservices architecture." After: "The system's modular design means you can add the HR module in Phase 3 without rebuilding any existing functionality — saving an estimated 200 hours of rework."

Avoid Abstraction

Abstract claims lose readers. Concrete specifics persuade.

Plain Language Rules

• Use active voice: "The system generates the report" not "The report is generated by the system."
• Sentences under 25 words. Split anything longer.
• One idea per paragraph.
• Avoid jargon unless the reader is technical and the term is precise.
• Define every acronym on first use.

Remove Boilerplate

Boilerplate is the text that appears in every proposal regardless of client: company history paragraphs, mission statements, generic team introductions. Every paragraph of boilerplate is a paragraph the client skips — and a paragraph that crowds out your real argument.

Test: If this paragraph could appear word-for-word in a proposal to a different client, delete it.

7. Grammar Rules That Matter in Proposals

Apostrophes

• Possessive singular: The client's requirements (one client).
• Possessive plural: The clients' accounts (multiple clients).
• It's = it is. Its = belonging to it. Never use "it's" as a possessive.
• Misplaced apostrophe on a front page signals carelessness to every professional reader.

Bullet Lists

• Lead-in sentence ending with a colon: bullet items continue the sentence — no full stop at the end of each item unless the items are grammatically complete sentences.
• All items in a list must be parallel: all noun phrases, or all sentences, not a mixture.
• Maximum 7 items per list. Beyond 7, the reader stops absorbing and starts skimming.

Capitalisation

• Choose one style (title case or sentence case for headings) and hold it throughout.
• Do not capitalise for emphasis. Bold serves that function.
• Product and company names are capitalised; roles generally are not ("the project manager").

8. The Proposal Evaluation Questionnaire

Use this checklist to score a draft proposal before submission. Score 1–5 on each dimension.

Scoring:

• 45–50: Submit. Strong proposal.
• 35–44: Revise targeted sections, then submit.
• < 35: Major rewrite required. Do not submit in current state.

9. Anti-Patterns

Sources

• Coombs, P. (2005). IT Project Proposals: Writing to Win. Cambridge University Press.

Cross-References

• Upstream: software-business-models (services model depends on winning proposals), software-pricing-strategy (pricing section in proposals)
• Downstream: sdlc-planning (winning the proposal triggers SDLC planning), project-requirements (requirements gathering follows after project award)
• Related: technology-grant-writing (grants are specialised proposals with different evaluation criteria)

Quality Standards

Every scored requirement must have a locatable response and evidence; commercial assumptions, exclusions, dependencies, and approval status must remain visible.

Outputs