| 22 February 2007:The proposal - not just getting the business |
In this issue
Featured article The proposal - not just getting the businessLast month I talked about the request for proposal and the process of gathering all the information you need to create a proposal. This month I want to talk about the proposal itself. A proposal has to do two things:
I am not going to be able to help you much with number 1. You already have a style that works for you and who am I to tell you how to do it better? However you may not be totally up to speed on number 2 where technology projects are involved. In the technology world, not losing your shirt on a project is a big issue. Hi-tech developments can go many times over budget if you are not careful, and companies have gone bust because of one bad project. A project may turn into a problem project because:
But 90% of the time the cause is something called 'Scope Creep'. When I worked for a large software house I was sent to the Middle East to look after a project which, it transpired, had been carelessly proposed. A colleague at the time told me that if you want to do business with a fool in the Middle East you had better take him in with you. He was right. It rapidly became obvious that the client was going to exploit the holes in the proposal to extend the requirement in all sorts of ways we didn't expect. When I got home I told my boss that "we had better try and get out of this one", but my manager at the time told me not to be so negative. Six months later we settled out of court for a sum of money well in excess of the contract value. That taught me a lesson I will never forget. The key is to make sure you are very precise about what you are going to deliver. Most sales people just want to say yes to everything; make very general statements and tick every box. This can lead to conflict and for that matter out of court settlements, so most software houses have learned that proposals have to have the sign-off of the developers. What do we have to cover in the proposal? 1. Compliance statementA compliance statement lists the requirements in the brief and against each one states whether you are proposing to comply with that requirement or not. This only works of course if you have a detailed brief, and it works better in some cases than others. In the right place and done properly a compliance statement looks very professional and gives a warm glow to the prospect. Of course you will be ticking all the boxes - right? On a complex brief we may not be able to tick all the boxes, or at least not tick the boxes and keep the budget within bounds. Ideally you will give an alternative approach that will meet the business requirement. However this is not always possible and you have to put your hand up and say that you don't plan to meet this or that requirement. That sounds bad, but take it from me if is nothing like as bad as facing a law suit because you haven't delivered. If a requirement you can't meet is a show-stopper, better to back out now. Most of the time it's OK and the prospect will accept that you have met 99% of the requirement and will live without the 1%. Obviously you would discuss this issue with them before going to print. 2. Assumptions about requirementsIf the brief is less than perfect, you may have to make assumptions about what is required. If you are making assumptions, then list them, and give the reasons why you are making those assumptions. Even if you have agreed an assumption with the prospect at some stage, list it here. He or she may conveniently forget when the chips are down. 3. Phasing and timingThe prospect of course wants the web site next Tuesday, often after delaying the decision for three months. It is important that you come reasonably clean about delivery times. There is no real reason not to be an optimist about this unless the client has somehow made time 'of the essence'. Whatever timescales you quote however are going to depend on the client doing something, such as delivering content, or making decisions. Make those assumptions explicit as they could be your let-out if the project is late. 4. Terms and conditionsI could devote a whole newsletter to terms and conditions, but it is pretty boring so I won't inflict that on you. But some of the more important Ts and Cs: - The proposal is a complete statement of what we plan to deliver and (this is important) supersedes all previous written or verbal communications. Other requirements (even if such matters have been previously discussed) do not form part of the requirement to be delivered. - any changes to the requirement must be agreed in writing. The control of change orders is something I will talk about next month. Some software houses make much more money out of change orders than the original project - its called 'stiffing' and we don't indulge in it. However change control is the key to limiting scope creep. But you had better get the businessAll of this is irrelevant if you don't get the business of course, and the primary job of the proposal is to support your sales effort and help you get the business. However the business bit has to work.
|