Thursday , 27 April 2017
Home » How not to write a proposal – Part 1

How not to write a proposal – Part 1

I’ve been writing a lot of anti-patterns and “not to do” code. I’ve kind of exhausted out my “Code You Should Not Be Writing” series because I’ve completed this project and moved on to another project. So this will be another new series of some interesting quirks I’ve encountered reading proposals, reports, requirements specification documents, etc. I don’t know how this will take off or if I have enough content to even make a series out of it, but let’s just try it out.

First up! Objective statements! Here’s one objective statement I’ve often read in various proposals that should not be followed.

To build an application that is intuitive and user-friendly.

How many of you who have read proposals ever seen these things in objectives? This is not the first time I’ve read something objectives that are similar to that effect.

So how do you write a proper objective then? Let’s first understand what an objective is, and the purpose of writing an objective statement.

An objective is your goal in this project or proposal. It can be to solve a current problem, or to create a tool to increase productivity or reduce cost, or anything along those lines. From Merriam Webster,

an objective is something toward which effort is directed : an aim, goal, or end of action.

So an objective statement is a statement about the end result. Some might argue that the statement mentioned above is a valid end result, building an application that is intuitive and user-friendly. If you can elaborate what kind of application it is, and what concrete measurement of intuitive and user-friendliness that will make your application a success, then that will be a better objective statement.

The purpose of the objective statement is to give you a summary of your problem, your success criteria and additional details that might support your claims. This becomes the “What” of your proposal. Here are some questions you might ask yourself while thinking of what you’re to write for your objective statement.

  • What is your problem?
  • What is your proposed solution?
  • What is the aim of this solution?
  • What are your success criteria?

A lot of your answers to these questions will overlap with each other, and hopefully you’ll start realizing that this is exactly your objective statement.

Here’s what an example of a better (not the best) objective statement.

To build a solution that will at the very least half the time taken to process the business accounting of the company.

Notice that there are several detailed points you can gather from this initial objective statement, which can be elaborated further in sections below the proposal. For example, now I know this project is about a business accounting problem. I also know that the measurement for success is time. Furthermore, I now understand what you’re trying to achieve and I can come up with a rough idea that can solve your problem specifically. Now, with this short statement I know more about this proposal than just the initial statement.

What do you think? Have you read any interesting proposals, or reports lately that is so ambiguous?

About Justin Lee

Check Also

Samsung Galaxy Note7 – “Eye-ing” the Next Evolution in the Galaxy Note Series

The next generation Samsung Galaxy Note7 combines both style and innovative features and top of …

3 comments

  1. The hallmark of a proposal is that it becomes verifiable. When it comes to intuition and user friendliness everybody is an expert (same as everybody is an expert when is comes to food – try let the “expert” cook instead of eat).
    What might be user-friendly or intuitive for one group might be out of the world for another. Nice sample: If you are a professional accountant all you want is the ability to enter accounts using your numerical keypad only. You know your numbers and you want to be fast. For the small business owners accounts numbers are the last thing she wants to remember. Here something like a menu with “I sold stuff, I bought stuff, I did some service” would be user friendly and intuitive – and drive a professional accountant mad.
    When you look at “Usability” there is actually a very clear cut definition (It is even an ISO): Can the software do its task, is it efficient, are the users pleased.

    Back to the proposal:
    Since your potential customer has that requirement in the RFP, you have to address this. So you get specific:
    – allows the sales professional to get sales leads entered with few clicks (problem: don’t bog yourself down with a specific number, since you might need just one more) – or fewer clicks than now.
    – Has been tested for Usability by [name group of users of customers] in x sessions
    – Allows professional users to work faster than entry level users using shortcut keys

    Stuff like that. Ideally you create the sign-off checklist directly with the proposal, so you can agree on it when everybody is in high spirit.
    🙂 stw
    .-= Stephan H. Wissel´s last blog ..Netgear support hell reloaded =-.

    • Well said. Unfortunately, the proposal writing isn’t done by myself or anyone from my side. It is a proposal to me from the other party, which I have difficulty understanding their purpose. So my potential customer is telling me what they wish to achieve in a “feelings” manner without telling me the actual situation or solution they want to implement. Which boils down to me being a fortune teller and reading their minds.

      On another side note, it’s been a long time Stephan. Remember me?

Leave a Reply