IT Project Proposals: Writing to Win / Edition 1

by Paul Coombs

Overview

Whether responding to a potential client's request or pitching a new IT project to the Board, a well-written proposal can be the difference between success and failure. This volume can help create high-quality, persuasive proposals. Paul Coombs explains how to influence the reader's decision by developing the writer's unique selling points. He discusses the structuring of documents, the secrets behind persuasive writing, and the basic grammar and punctuation rules that will prevent writers from destroying a good argument through bad presentation. The volume is written for IT managers, consultants and anyone producing internal or commercial proposals.

Product Details

ISBN-13:	9780521612579
Publisher:	Cambridge University Press
Publication date:	07/28/2005
Edition description:	New Edition
Pages:	158
Product dimensions:	6.85(w) x 9.72(h) x 0.35(d)

About the Author

Paul Coombs is an expert in bidding, costing and proposal-writing for IT projects following twenty-five years of experience with the international systems house Logica CMG and the media organisation Reuters. He has worked on mission-critical developments for EMI, London Underground, IBM, the BBC, British Airways, and a large number of major financial institutions. He has developed winning proposal strategies for large fixed-price projects in industry sectors as diverse as finance, defence, government, media and communications. He currently works as an independent consultant, running courses in estimation, project-writing and the bid process as well as undertaking cost/benefit analyses and proposals for specific projects. He is the author of IT Project Estimation: A Practical Guide to the Costing of Software.

Read an Excerpt

Cambridge University Press
0521612578 - IT Project Proposals - Writing to Win - by Paul Coombs
Excerpt

CHAPTER 1

Introduction

DOES GOOD WRITING MATTER?

All writing aims to achieve results. Whether the aim is to communicate information, to influence a decision or to stimulate the imagination, the language needs to be marshalled and controlled. There are many ways in which the desired aim can be achieved - and many more ways of getting it wrong.

The aim of this piece of writing is to improve the effectiveness of your proposals by making better use of language. By a "proposal", I mean any sort of document that is making a pitch: to your customers, to your manager, to your lover or to anyone whom you want to convince to take some action. We all receive many proposals, large and small, every day. But too often, although the information is accurate and the answers to our problems are in there, the way in which it is all presented is unconvincing and error-ridden. And so we don't buy; we don't take the action the writer wants us to. Maybe nothing could have been done - the ideas were rotten anyway - but possibly, if the writer could just have found the right words, we would have been convinced.

The purpose of this book is to help you find those "right words" for the proposals you produce, specifically those that seek to win or to initiate major IT projects. This is not to say that it is inapplicable to other kinds of proposals. If you work in another field then I'm sure you will find a great deal of useful advice - but most of the examples come from the world of IT. The book is not about sales techniques or specific technologies. I am going to assume that you have completed all the preparatory work and that you know what you want to say. What I am concerned about is that you express your brilliant solution or your revolutionary concepts in a way that is effective and persuasive.

You may believe that communication is all that matters and that your readers will forgive your inept English so long as your ideas are expressed somehow. I disagree, for two reasons. Firstly, you will probably not have too much of your readers' time or attention. Every word must count, so your proposal must be organised and spun to achieve the maximum effect. Secondly, your readers may well be judging your errors in spelling and grammar as a reflection on the content of the text. If every document seen by your customers or by your managers has a few silly mistakes, what confidence will they have that you will fix every bug or that you can be trusted to work with a new client? If you can't be bothered to run a document through a spelling checker then will you take the trouble to create a solid and usable technical design?

A while ago, I was asked to review a proposal just about to be sent to an important potential customer. I turned to the first page and read the following:

Management Summary

Assuming the MSP Database and Infrastructure are in Place. The following deals with all Desktop and API's products which are currently available within MegaCorp Ltd. and try to find a suitable solution to enable these products Access and source their data from MSP. A migration period will be needed. Thus, how this migration will be reflected on current products and their impact on MegaCorps' customers, Identification of issues and the remedy for each of them Finally a plan reflecting a migration strategy will be proposed.

That management summary was never issued. But I suspect that many proposals just as incomprehensible have reached important customers, and that many reports have left their readers wondering about the competency of the individual or the organisation from which they were requested. A lot of effort wasted, just because the final presentation was not convincing or in a form that could be easily understood.

Usually a great deal of time and money is invested in the development of the technical solution to a customer's problem. Skilled, experienced people from many disciplines work together to design a complex, user-friendly system that meets all the requirements. And then what? Do we employ skilled, experienced people to communicate that solution? No, it is the technical experts who do that - and a right mess they usually make of it.

A proposal is your shop window - do you want to fill it with low-quality rubbish, or sparkling, attractive products? To win work through promoting your company's advantages, and to get decision-makers to undertake the actions you recommend, you must argue your case well and not undermine it with simple errors. Good communication is what will make or break the deal, so we need to dedicate as much time and as much skill to that as we devote to the technology. By using the language effectively, we can communicate better - and the better we communicate our ideas the more likely they are to be accepted.

Image not available in HTML version

Figure 1.1. Destruction of a writer's message

WHERE DOES IT ALL GO WRONG?

Figure 1.1 shows the five levels through which a writer's message becomes progressively destroyed. Each will be discussed in turn.

Inappropriate content

I have a problem: your task is to describe your solution to it. What do I want to see? That you understand the problem and that your solution is credible. I have a set of rules, either expressed or subconscious, that I am using to judge whether your proposal addresses my problem.

What is your aim? To make sure that I understand what makes your solution special, so I will choose you to solve my problem rather than any of your competitors. Thus, your proposal must satisfy my set of judging rules and express the reasons why your solution is the best.

What else should it contain? Nothing. There is no point in filling up your document with fascinating facts, however true they may be, unless they satisfy one of my judging rules or are relevant to your solution. So why is it that every proposal I read is full of blather, blarney, waffle, boilerplate, padding - call it what you will? I don't always want to be told about the history of my company - or yours. I don't want a chronicle of recent technical advances, I already know about recent trends in my sector, and I'm quite prepared to believe that you have a competent and experienced team without seeing a six-page résumé of each member. But - just to be annoying - sometimes I do demand these things. Your job is to find out what I want to see, what my evaluation rules are and what my problem really is. You must target every word you write specifically at these subjects; otherwise, you are wasting the time of both of us. Techniques for determining what should and should not be included in a proposal are discussed later in this book.

Confusing structure

The best way to wreck the effectiveness of a proposal is to pay no attention to its structure. Writers tend to throw down everything they know, in the order in which it occurs to them, without developing an argument or presenting a consistent case. This is particularly true of documents written by more than one person, where incompatible lumps of text are roughly stitched together, regardless of structure, repetition or sense.

There have been many times when I have reached some point in a proposal or technical document and realise that I no longer understand what I am reading or how it is connected to what has gone before. It is the same feeling that I get when watching a costume drama with a multiplicity of characters and wondering, "Which one is she?" Sometimes this is due to my own inattention, but more often the writer has failed to construct an argument sufficiently well, or has not given sufficient context to the point in the text where my comprehension has finally lapsed.

No matter how brilliant the solution that is being presented, you must ensure that the reader is led through it in a structured, logical order. The templates described in this book can act as the basis for proposals of all types and sizes.

Unconvincing prose

Dull, unpersuasive arguments are constructed through over-abstraction, evasion, repetition, lack of flow and overuse of clichés. Have a look at this example:

At present Management Information data is stored in a wide variety of different databases and the maintenance processes to collect and maintain the data are duplicated and inefficient. Several databases use outdated technology and consequently the applications to derive the data are also outdated. The aim of the new MIS Strategy is to unify together all these outdated databases into one central database. This will use up-to-date RDBMS technology which is maintained using a single data maintenance application.

If you can't see anything wrong with that, you definitely need to read on; this text is analysed and transformed later in this book. I will explain how to give your prose more sparkle and how to spin the words to maximise the effect you are trying to produce.

Poor grammar

Yes, our language is evolving. But it is not up to you to invent new grammar and punctuation rules. There's no need to be over-pedantic, but writing within the rules makes your arguments more persuasive, and avoids distracting the reader with puzzling or incorrect constructions. For example, I recently received an expensively produced glossy brochure from a software house, enticing me to use their products and services. A great deal of time and money had been devoted to its production, and I have no doubt that a team of creative masterminds had laboured for hours over the front-page slogan:

Hackitout Software - professionalism at it's best!

A single misplaced apostrophe and all that work was in vain. So learn the rules set out in this book, and don't let bad grammar expose you to ridicule or diminish the power of your prose.

Typos and spelling mistakes

Use of a word processor provides little excuse for spelling mistakes. But your document is not necessarily suitable for release just because the automated check shows no errors. This book provides some tips on how to review your work, and advice on how to eliminate the simple slips that devalue your message.

THE PROPOSAL LIFECYCLE

In a commercial context, writing the proposal is only a small part of the overall sales cycle. We also need to maintain contact with the customer, derive an appropriate solution, determine a price, analyse the risks, obtain approval, follow up the sale and

Image not available in HTML version

Figure 1.2. The proposal lifecycle

so on. But this book concentrates on the proposal itself. Figure 1.2 shows the process that will obtain a persuasive, effective result.

We will be returning to this diagram several times, but at this point you should notice that the process is iterative. We may need to revise the content and structure of the proposal as we write more of the text, and we will almost certainly need to rewrite some sections following internal or external reviews. And, during these reviews, we will be ensuring the proposal is tightly focussed with respect to the original strategy. The next chapter describes the first stage: how to determine that strategy.

---

CHAPTER 2

Establishing the strategy

THE ART OF PERSUASION

There are several methods to get decision-makers to do what we want. Coercion, blackmail, lies and flattery are some possibilities, although not necessarily the best ways to obtain the go-ahead for an IT project. Usually, we need to employ the most difficult method: persuasion. The decision-makers are not necessarily against what we are proposing, but there are other options open to them. So we must manipulate their thinking in such a way that they reach the conclusion that our proposal is the only way to go.

Arguments are rarely won purely by logic. Anybody, including your rivals, can analyse the problem and produce a solution. To persuade the decision-makers, you must present creative new ideas that are based on that underlying logic. Then you need to show an emotional commitment - maybe some excitement as to what can be achieved or a reassurance that your organisation is reliable and reputable. Because, once that emotional commitment has been communicated, you stand more chance of achieving empathy - the state where the decision-makers believe that you understand the problem, and can be depended upon to resolve it. And so you finally get to the point at which the decision is made. Something connects in the customer's mind, and persuasion is achieved. We cannot guarantee that will happen because there are too many variables, most of which are outside our control. But, unless we have built the foundations well, our proposal will never get to be the top choice.

There are several stages to the mental journey that the decision-makers must take before this happens - these are shown in Figure 2.1.

The first stage is to establish the common ground - to make sure that we have the same world-view and the same appreciation of the problem to be solved. As the Roman orator and statesman, Cicero, put it:

Image not available in HTML version

Figure 2.1. The process of persuasion

If you want to persuade me, you must think my thoughts, feel my feelings and speak my words.

It could be the technical aspects of the proposal that are of most interest to you because they provide a chance to use exciting new techniques that will look good on your CV. But such aspects may be of little interest to the decision-makers, who are more likely concerned with keeping costs down and sales up. You must see the world through their eyes and express your proposal as being the solution to a problem that they have. To do this, you must use their language - in particular, the exact words that they chose to express their problem - when discussing your solution.

The second stage is to present the evidence. This may include confirmation that there is a problem, proof that this problem is serious enough to require action, evidence that previous initiatives have failed, support from other sources and so on. The overall effect is to prove that the current situation is unsustainable - that "do nothing" is not an option.

The third stage involves creating some sort of stress. The decision-makers are now holding two conflicting beliefs: their current world-view and the evidence you have presented. For example:

· Your IT manager believes that the customer database is operating well, but you have just presented convincing proof that it is obsolete.

· Your customers thought the previous proposal that they read was the best possible response to their Invitation to Tender, but your solution seems better and cheaper.

· Your clients think their current IT consultants are doing a good job, but you have suggested some new ideas that those consultants would never have conceived.

It is uncomfortable to be hosting a mental battle between two different beliefs, so something has to give. The decision-makers may use your evidence to reinforce their existing views, they may reject your evidence or they may accept that their views need to change.

If they are now open to persuasion then we can build on this during the fourth stage by evoking fear, uncertainty and doubt: the FUD Factor. So we may assert that within the next few months the database will fill up, response times will deteriorate, hardware will need to be upgraded, the market will demand better products, new legislation will need to be addressed, costs will rise, the sky will fall - anything that will make ignoring our proposal seem a very bad idea. We want to evoke a slight feeling of panic - it is nearly too late, something must be done now.

And so the ground is laid for the fifth stage, where we present our solution and show the way forward. Our solution is so convincing and so appropriate that it restores the decision-maker's mental stability and leaves them feeling that we have the medicine to soothe their pains. Now the battle is nearly won - we have turned "no" into "yes".

When we review the persuasion process, we can see that emotions are important elements. Our proposal cannot be bland and neutral. It needs to show our emotional commitment and to invoke emotions in the reader - emotions like inspiration, encouragement, comfort, shock, stimulation and worry. To induce such emotions we must press the right buttons - the emotional triggers that will convince our readers that we are sincere, that we understand their problems and that we can be trusted to implement the correct solutions. To do this, we must ascertain two things: the conditions that will generate the desired emotions in our readers, and the particular elements of our proposal that will establish those conditions. The first of these is called the Basis of Decision and the second is termed our Unique Selling Point.

DETERMINING THE BOD AND USP

If you're experienced in selling, you're probably used to these terms. The Basis of Decision (BOD) is the set of rules the customer will use to decide which of a number of competing proposals is the best. The Unique Selling Point (USP) is the set of elements that we think makes our solution more appealing than anything our rivals can dream up. Ideally, the USP will successfully address each element of the BOD and our proposal will win.

Identification of the BOD and the USP is essential to the production of every type of proposal. Before you write anything at all, you must ask yourself:

· What criteria will my readers be using to decide whether my proposal is persuasive or not?

· What is going to be special about my proposal, such that it will have the best chance of achieving the desired effect?

Write these things down first, constantly turn back to them as the document is being written, and review the result with these elements in mind. The foundation of effective proposal writing is to make sure that every word appeals to the reader's Basis of Decision while stressing your Unique Selling Point. All other words are redundant. So how long should your proposal be? Exactly long enough to address the BOD, explain your USP and no more. Let's look at some examples:

1. A technical report recommending a new hardware architecture

Here, the BOD would embrace the following factors:

• Does the writer understand the current situation?

• Do I understand what is being proposed?

• Does it make sense?

• Is it realistic?

• Have the alternatives been considered?

• Has everything I wanted to know been covered?

• Are the costs reasonable?

The USP may include:

• Providing a context to the report.

• Demonstrating technical competence.

• Using the right terms (those actually employed by the reader).

• Using diagrams, prose and layout to describe the proposed new architecture.

• Providing facts - volumes, reliability statistics, prices etc.

• Listing who was consulted, so the reader can see where omissions may have arisen or where particular ideas may have come from.

• Describing alternatives and why they were rejected.

• Stressing the benefits alongside the costs.

---

© Cambridge University Press

Table of Contents

1. Introduction; 2. Establishing the strategy; 3. Choosing the content; 4. Structuring the proposal; 5. Tightening up the text; 6. Obeying the grammar rules; 7. Obeying the punctuation rules; 8. Finishing off; 9. Reviewing the result; 10. Summary; Appendix A. The document standard; Appendix B. References and resources; Appendix C. Case studies.

Editorial Reviews

"All proposal writers should read this superb book. In fact, all technical communicators should have it at their desks. It is easy to read, is designed well in its use of white space and typography, and offers many useful concepts. Even if its overall size might lead you to believe that it doesn't have much to say, this small book is packed with loads of information."
Jackie Damrau for Technical Communication

From the Publisher