Comments on: How not to write a proposal – Part 1 http://justinlee.sg/2010/01/28/how-not-to-write-a-proposal-part-1/ Taking over the world with every line of code Fri, 10 Feb 2012 00:37:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Aaron Seet http://justinlee.sg/2010/01/28/how-not-to-write-a-proposal-part-1/#comment-222 Aaron Seet Fri, 05 Feb 2010 03:29:00 +0000 http://www.justinlee.sg/?p=7389#comment-222 It all boils down to this <a href="http://www.amazon.com/Software-Requirements-Techniques-Throughout-Development/dp/0735618798/ref=sr_1_1?ie=UTF8&s=books&qid=1265340469&sr=8-1" rel="nofollow">Software Requirements 2E</a> It all boils down to this

Software Requirements 2E

]]> By: Justin Lee http://justinlee.sg/2010/01/28/how-not-to-write-a-proposal-part-1/#comment-221 Justin Lee Tue, 02 Feb 2010 02:17:47 +0000 http://www.justinlee.sg/?p=7389#comment-221 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? 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?

]]> By: Stephan H. Wissel http://justinlee.sg/2010/01/28/how-not-to-write-a-proposal-part-1/#comment-220 Stephan H. Wissel Sun, 31 Jan 2010 15:41:13 +0000 http://www.justinlee.sg/?p=7389#comment-220 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 ..<a href="http://feedproxy.google.com/~r/Wisselnet/~3/VBj0Q66FALE/SHWL-828E4B" rel="nofollow">Netgear support hell reloaded</a> =-. 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 =-.

]]>