Documentation

PROPOSAL

Purpose :

A document which serves the dual purpose of concisely defining your offer to a prospective client, and taking the opportunity to sell it.

Objective :

Io pave the way for a sale.

Key features :

It needs to be succinct, fairly short, use concrete language and contain minimal abstraction.

Pointers :

	There must be no surprises! It should set out no more, and no less than has already been agreed in the selling process.
	Know your audience. Try to eliminate all clichés, buzzwords, acronyms and industry jargon unless you are certain that the entire intended readership unambiguously understands them.
	Don't assume the audience is longing to read it immediately. They aren't.
	Don't cite benefits that the decision-maker has not already agreed are real benefits.
	Always contain a one-page summary of investment .
	Always include a one-page Executive summary.

TENDER RESPONSE

Purpose :

A special type of proposal, where the document format and the specific issues have been defined in advance by the buyer, in order to standardise responses.

Objective :

Issuer : To establish a transparent and auditable framework for the comparison and evaluation of all vendors on an equal footing.

Respondent : To make the proposal score as highly as possible in the tender terms of reference, while remaining honest and ethical.

Key features :

It has to convincingly argue a case and provide supporting evidence, while fitting within the form and content specified by the issuer.

Pointers:

	Before starting, try to evaluate the levelness of the tendering playing field. Is the real purpose of the tender to camouflage for a decision that has already been made? Or, do the terms of reference of the tender appear to be written to favour one respondent above others? This can happen unintentionally - for example if the author is unwittingly influenced by special experience of one vendor's products and services. Your thoughts may influence the overall approach taken, and the amount of resources that can be justified.
	It should set out no more, and no less than is necessary to address the tender terms of reference and address all of the questions.
	Any and all instructions regarding the form and presentation of material should be followed to the letter.
	Try to resist the temptation to expand on benefits and features not specifically addressed by the tender document. If you are convinced there is a need to include them, first double-check that they are relevant. Will they deliver real, demonstrable benefits to the issuer.? If so, either add them as appendices, or, if you can keep it short, work them into the responses.
	Tenders are often evaluated using a weighted matrix of scores applied to the responses. This means that it is vital to answer all questions. Observe and respect the fine line that exists between the need to answer "Yes" to questions, and the need to be scrupulously honest. If a yes answer is given with qualification, then be especially careful to evaluate the implications of that qualification from the perspective of the issuer.
	Always include a one-page Executive summary.
	Try to include a short investment summary, even if it has to be an appendix, or worked into the executive summary.

SUBMISSION

Purpose :

A presentation document which lays out a structured case for something to be done, or something to be awarded.

Objective :

To obtain a favourable outcome for the organisation in an area of major strategic concern

Key features :

It needs advanced presentation techniques, usually sophisticated graphic design, and persuasive writing. It has to convincingly argue a case, visually and textually, and sometimes aurally as well.

Pointers:

	It should set out no more, and no less than is necessary to convincingly and comprehensively establish the case, and provide all the relevant facts and information to support it.
	Define the audience before you start. It is important to define the whole tone and style of the document with the readership in mind. What are they looking for? How do they think? The wider and more varied the audience, the simpler the expression of ideas should be.
	Try especially hard to eliminate clichés, buzzwords, acronyms and industry jargon unless you are certain that the entire intended readership unambiguously understands it in the same terms as you do,
	Observe and respect the fine line that exists between persuasively arguing a case, and spin and propaganda.
	Pay special attention to editing. Spelling, grammar and punctuation errors are fatally damaging in this type of document.
	Always include a one-page executive summary.

PROCESS MAP

Purpose :

One of the most important documents in any modern organisation. The range of form and content is broad .

Objective :

To formalise the who, what, where, why and when of a business process. Why?

usually to ensure standards and quality are transparent, and to ensure business continuity. In larger organisations , there is a need, in the context of governance, to prove that business processes operate in strict accordance with the organisation charter or product and service descriptions.

Key features :

It combines diagrams of process flow with enough narrative to meet the objectives.

Increasingly, business process mappings are tied in to the actual business applications themselves. This is a key feature of SOA (Service Oriented Architecture). For a good, concise introduction to this concept, read this article entitled "SOA WHAT"

Pointers:

	It is important to fully explore who, what, where, when, why and how. If possible also include with what?
	To be effective, process maps need a mechanism to "drill down" into sub process or related processes. A good way to do this is to deploy them on a diagram-driven intranet site. When the reader clicks on any object in a map, a narrative should appear, and a link to subprocess should appear.

BUSINESS REQUIREMENTS

Purpose :

To accurately describe and structure requirements for new or changed business processes and systems as part of a change program.

Also, many organisations now reverse-engineer business requirements from existing, older applications. This can be an effective way of discovering and documenting what it is that they are supposed to do.

Objective :

To ensure that systems and processes reflects exactly what the business requires.

Key features :

The Business Requirements Document (BRD) must be expressed in clear, concise, concrete language.

Requirements need to be structured into numbered and sub-numbered headings so that all specific requirements are allocated a reference number. The reference number needs to be included in a traceability matrix, which traces the origin of each requirement, and the design attribute in the functional specification that implements the requirement.

The document needs to differentiate between functional and non-functional requirements.

It also needs to assign an indication of relative importance to each requirement.

A good BRD should identify and categorise all risks involved with interpretation and implementation of the requirements.

Pointers:

	Make sure the project is accurately scoped before collecting requirements. Any requirement presented that cannot be defined as either in-scope or not provides a warning the scope of the project may not be clearly defined.
	Workshops are a very efficient way to collect business requirements . It is important to have one or more scribes, so that the facilitator does not have to do her own note-taking.
	A major trap to be on guard against is the inclusion of non-business requirements. Non-business requirement are not the same as non-functional requirements, which are genuine business requirements that are abstracted. "The system must be easy to use" is a non-functional business requirement. "The system must have a strip-menu on the top of each screen" is not a business requirement , but a design issue.
	Do not assume that what stakeholders say they require are what the business really requires. Make sure that where possible, requirements are cross-checked with multiple stakeholders, and where possible are checked against business mandates, public product and service descriptions, etc. A section on constraints helps to identify these.
	Add a glossary, which defines ANY term that the authors are not certain is understood by the entire readership.

AUTOMATED LETTERS

Purpose :

To generate letters or emails in bulk, such that each one can contain many different variations on its messages and wording, depending on the recipient's circumstances.

Objective :

To automate the production of written messages, so that targeted communication can be effectively done for little cost.

Key features :

Documents are produced from a database from which relevant data about the recipient can be extracted.

Typically, letters are compiled by applying business rules to the data to derive the wording, and embedding variable data, such as purchase history or amount owed.

Pointers:

	The message can use many forms of media, not just letters or emails. You can even generate varying content on your web site to target certain customer profiles.
	Simple letters, for administrative purposes like accounts collections, are usually produced using a "mail merge" process available in most word processors. A simple file is extracted from a database, and merged against named field markers in a "form letter".
	When it comes to marketing communications, more sophisticated means are often used. Typically, the letter itself is entirely built up from many different wording options which can be related to everything known about the customer. For example, we can generate totally personalised letters to all our customers and prospects that recommend new products which we know the customer may be interested in, based on past sales history.
	Automated , targeted letters can be a highly effective marketing strategy where large volumes of letters can be generated at a very low unit cost