Technical proposals can be long, daunting, and nit-picky. Worst of all, most times, there just isn’t enough time to write them. You are encouraged, by default, to jump straight in and start writing; how else would you finish it on time? But before you do so, here is some advice and plenty of warning.
1. Avoid writing as much as possible
This sounds counter-intuitive. However, the last thing you want to do is writing content that either already exists in your knowledge library or in an existing proposal. Trying to explain how a specific function works? Just copy and paste an introduction from your user manual. Or extract a graph from an old presentation and use it to explain your company profile. With technical proposals, as long as it is accurate and proprietary, it’s fine to re-use existing content.
2. Plan your reviews ahead of time
With most of the writing out of the way, the next challenging step is to get the right person to review and approve your draft. That person is often not fully involved in the proposal process, and may have other priorities. The last thing those reviewers want is to recieve 100 pages in one go. Concurrently, the last thing you want is to recieve 100 pages of revisions with only a few days left before the deadline. Instead, split the proposal into manageable parts, and share them over the course of the entire process.
3. Maintain strict version control
Drafts often fly back and forth between teams and colleagues and it is easy to lose track of which file has the most up-to-date content. Sharing the link to files, which you can do for most Microsoft and Google products, can allow different users to edit a single document, as well as keep version history. Otherwise, maintaining versions of your files (typically seen with v0.1, v0.2, etc.) is the easiest way to avoid losing content control.
4. Play the game, know the rules
Many technical proposals today are writing in response to a request for proposal (RFP) or an invitation to tender (ITT). These can include complicated terms and conditions, but some of them lay out how they will score bids, what percentage they would give to the commercial and the technical parts. A few might even give weighting for project experience. At the end of the day, it’s a points game. So find out how they count the points.
5. Check off the requirements list
Many RFPs and ITTs have a checklist of requirements, which your solution must meet in order to win the bid. The key is to clearly state whether you meet the requirements. The simplests way is to build a table in your proposal and go through each requirement, one by one.
| No. | Requirement description | Comply | Remarks |
| 1. | Build a website for a small knowledge management consulting company | Yes | See section 7.1.1 |
| 2. | Generate posts that highlight the experience of the company | Yes | See section 7.1.2 |
| 3. | Share templates that help users kickstart their technical writing career | Yes | See section 7.2.1 |
| 4. | Provide live training for business analysts on how to build better content. | N/A | Unavailable in pahase 1 |
Some RFPs and ITTs include a similar table in their documents already, and will request you to fill them in. But even if they don’t request such a table, creating one does help to clearly and exactly explain how your solution meets their requirements.
6. Updating your templates
After completing a proposal, you’d most likely want to relax and release some of the pent-up stress. There is no better way to do so than updating your technical proposal templates. Forgetting to do so would mean your templates would not reflect the best work you’ve done, and future bids would suffer for it.
Speaking of which, check out our proposal templates and see what features your templates might be missing.
Leave a comment