General Information

Quick Overview

This chapter is not intended to be a comprehensive manual of MATLAB®. Our sole aim is to provide sufficient information to give you a good start. If you are familiar with another computer language, and we assume that you are, it is not difficult to pick up the rest as you go.

MATLAB is a high-level computer language for scientific computing and data visualization built around an interactive programming environment. It is becoming the premiere platform for scientific computing at educational institutions and research establishments. The great advantage of an interactive system is that programs can be tested and debugged quickly, allowing the user to concentrate more on the principles behind the program and less on programming itself. Since there is no need to compile, link and execute after each correction, MATLAB programs can be developed in much shorter time than equivalent FORTRAN or C programs. On the negative side, MATLAB does not produce stand-alone applications—the programs can be run only on computers that have MATLAB installed.

MATLAB has other advantages over mainstream languages that contribute to rapid program development:

• MATLAB contains a large number of functions that access proven numerical libraries, such as LINPACK and EISPACK. This means that many common tasks (e.g., solution of simultaneous equations) can be accomplished with a single function call.

• There is extensive graphics support that allows the results of computations to be plotted with a few statements.

• All numerical objects are treated as double-precision arrays. Thus there is no need to declare data types and carry out type conversions.

CONTENT AND STRUCTURE

Content is not the same as structure. We need to decide what we are going to say – the arguments that will win our case. And then we need to decide how that content should be presented, so the arguments appear in an ordered and persuasive sequence. As Figure 3.1 shows, the content is made up of a number of different pieces that are interlocked into the structure most suitable for a specific proposal.

It must be that way around: content then structure. We cannot start with a predefined plan and then try to force everything we want to say into that. This may seem self-evident, but many organisations mandate a fixed structure for all proposals. The authors feel they must adhere to this template, so some sections end up as “not applicable”, or get filled with irrelevant blather. This is not writing that wins.

I am not going to suggest that there is some perfect combination of content and structure that will guarantee success for every proposal you submit. Instead, I will list some typical sections that a proposal may contain and describe the factors that need to be considered when creating each of these. You must decide which sections are applicable to your proposal and determine the specific content of each one. Having selected the most appropriate sections, you can then examine the plans in the next chapter in order to pick the structure that will best present the chosen content.

THE PURPOSE OF PUNCTUATION

The subject of punctuation can raise considerable debate. One camp maintains that it helps the reader in the same way as musical notation helps an instrumentalist to interpret the notes as the composer intended. The other camp maintains that a fussy succession of little marks interrupts the flow of information to the brain, and that punctuation is only needed when there is a possibility of ambiguity. But there is a difference between those who mis-punctuate through ignorance and those who carefully choose when to omit unnecessary marks. When I read reports and proposals, I often sense that writers are scared to use anything more than the minimum of punctuation in case they get it wrong. And then they do get it wrong. The effect is to devalue the points being made because the text is so hard to unravel, as the following example illustrates:

You can go too far in the other direction, littering your text with so many marks that reading it becomes a series of fits and starts.

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.

SPIN THE WORDS

I now want to turn to the ways in which we can use the power of language to persuade our readers of the truth and beauty of our message. I quoted this example earlier:

What is wrong with this? The facts are all there; there's nothing wrong with the grammar, spelling or punctuation; and I'm sure we all understand what is being proposed. But it's so dull that before you get halfway through your eyes seem to have wandered off in search of something more interesting. It could be that the solution being presented is so novel and revolutionary that it demolishes any competing approaches, but that is not how it comes across.

Look at the example again. The writer has devised a strategy that needs to be explained and ‘sold’ to the reader. But the words chosen are repetitive, neutral and uninspiring.

Table 10.1 shows the twelve rules for creating a winning proposal. Regrettably, I cannot guarantee that applying these rules will win that big contract, or that your pet project will be approved. Maybe the technical solution is inappropriate or too expensive – no amount of word-spinning can disguise that. But I can promise that if you follow these rules then your proposal will be as persuasive as can be achieved in the time available. No one can ask for more than that.

DOCUMENT STRUCTURE

Why have a plan?

Few fields of human activity are not the better for a plan. However, most people do not start on a proposal with any particular structure in mind; they hope one will emerge at some point during the creation process. Too often, it doesn't, and the result is a hotchpotch of ideas with no theme or conclusions. We can't just throw down everything we know, with every alternative that we have dreamed up, in the hope that some of it will strike a chord with the reader. Examine this next example. The writer has some revolutionary, exciting, even rather crazy ideas. But he is trying to appeal to his managers, the people who will change the direction of the whole company to embrace those ideas. What will they make of this?

DOES GRAMMAR MATTER?

My knuckles still feel a ghostly pain whenever I break the writing rules beaten into me at what, significantly, was called a “grammar” school. In those days, grammar did matter. Perfect prose carried more weight because it instantly indicated that the writer was “one of us” – someone who understood the rules and hence was to be trusted. Some remnants of that attitude persist. There are still some people who, should they encounter a split infinitive or some other manifestation of incorrect grammar, immediately bin the offending text. Others may decide that the writer is only semi-literate, but will soldier on, being convinced more by the arguments than by a failure to obey some arcane rule. But, whoever the readers may be, we don't want to interrupt their understanding of our world-beating technical solution with something that makes them pause, wondering if they have read it right.

Unfortunately, when you ask most people if they know any rules of grammar, they will come up with something trivial. In fact, most of the rules you think you know are wrong: you can split an infinitive, end a sentence with a preposition or start one with a conjunction. In this chapter, I will show why. But those rules don't matter; the situations where they arise are rare, and the resulting English is not so bad anyway.

Why have a standard?

You may have disagreed with some of the rules defined in this book. Matters such as the punctuation of bulleted lists, the use of commas and the acceptability of Latin abbreviations are not universally standardised, and the conventions for punctuation and spelling vary in the different English-speaking countries. You may also have noticed that some of the text in this book does not adhere to the rules I have defined. This is because the Cambridge University Press has its own guidelines, which override my personal preferences. What matters is consistency. Books issued by the Cambridge University Press must be produced to high, uniform standards, which supplant the individual conventions used by each author and outweigh any arguments about whose convention is ‘right’.

Every organisation – not just publishers like the Cambridge University Press – needs a standard that defines a ‘house style’ for the appearance and conventions of the documents it issues. Such a standard is often called a “Style Guide”. I dislike this term. Firstly, it is not a “guide”; it is a mandatory standard – no exceptions. Secondly, it is not about “style”, which to me is more about the way words are used than about conventions for terminology, punctuation and so on. So I call it a “Document Standard”, which makes its function clear.

Usually, there will be a different standard for each type of document that your organisation may produce: letters, technical documentation, user manuals and so on.

VALIDATING COMPLIANCE

You must do what the customer asks. If you are responding to an Invitation to Tender, Request for Proposal, or similar document, you must check that you have complied with all its requirements. These fall into two groups:

• The physical requirements, which may include the expected format of the proposal, a list of sections to be included, how prices are to be presented, how many copies are needed and so on.

• The technical requirements defining the system for which you are bidding.

The best method is to draw up a Compliance Matrix. On the left-hand side this lists the requirements from the customer, sentence by sentence, in the form of a cross-reference, the text itself, or both. The right-hand side shows how your proposal addresses each requirement. The result will be something like Table 8.1.

As you complete the matrix, you should be asking yourself if your response to each requirement is adequate, and presented in the manner asked for. You must provide a response to all the requirements in the Invitation to Tender, no matter how repetitive or pointless they may seem. So don't just respond with “As before”, “See the attached” or “Compliant” – give a full answer to each question asked.

You may choose to include the Compliance Matrix as an appendix to your proposal, either because the customer has asked for one, or because you would like to help them with their evaluation process.