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?
