Tag Archives: Writing well

Effective, less risky procedure documents

Far too often policy manuals, standard operating procedures, work method statements sit on the shelf and are hardly ever used. They are read by quality system auditors every few years, but they are hardly ever used by people in the business.

This is a problem for two reasons:

  1. Developing these documents is costly in both direct writing costs and the time lost by people diverted from their normal work to provide the content. Manuals are an expensive asset – it is important to get a return on investment.
  2. There is often a mismatch between what is written and what is done. Over time small changes are made to processes that are not reflected in the manual. Whether by laziness or an over cumbersome approval system, the end result is a mismatch between what managers think and what workers do – a very risky situation for any organisation.

There is no magic bullet to solve the problem. However, one thing that can help is to change the way documents are written and formatted.

Make sure policy and procedure documents are useful.

Manuals must provide relevant information to those who will use them. They must contain information that is important for doing the job without lots of extra fluff.

Make sure policy and procedure documents are usable.

People must be able to find the information they need quickly. And once they find it, they must be able to extract meaning quickly. So, a few things that can help;

  • avoid pages of document control information at the start – the user is not interested
  • keep line lengths short to make them more readable
  • use consistent styles so that users easily recognize information types
  • use photos instead of always relying on text descriptions
  • try starting all action steps with a verb

Make policy and procedure documents attractive

Entice people to use manuals by making them pleasing to the eye. There is no reason why work documents should be ugly. Form and function should come together.

Action

Find out which documents are being used and which just sit on the shelf.

Find out who is using them and how they are being used.

Check the written practice against the actual practice.

To be persuaded, the reader must see and must care

hearts-and-mindsWhether you are writing marketing copy, a business proposal or a new procedure you expect people to follow, you need to touch both your reader’s heart and their mind in some way. Impersonally presented facts or reasons, no matter how clearly they are presented, are not strong enough to move people away from their existing way of thinking or behaving.

How many facts that you have already seen or heard today? If you’ve browsed a news website or walked past some billboards, you will have seen multiple facts. Most of those will have washed over you – you see them but you don’t care. You only become interested in stories when they connect with your interests or something you are passionate about. Similarly, just presenting bland facts to your readers is useless if they don’t care.

Well reasoned writing is not sufficient. Our minds are stuffed with facts, and most of them we need to ignore in order to function sanely. If facts are connected in some way to our vital interests or sympathies, then we’ll pat attention. So, find out what is important to your readers, and relate your facts and your arguments to that.

On the other hand, merely stirring the emotions is very unwise if there is no solid reasoning to back up your position. Stirred emotions can arouse suspicion about a proposal or persuasive document, and tell our reason to investigate further. Emotions can create discomfort and paralyse action if they are out of step with our reason.

Emotional writing is not sufficient. It is folly to stir emotions that cannot be justified by rational facts and argument.

(built on ideas from Don Pfarrer; Guerrilla Persuasion)

Audit vs evaluation – the importance of asking the right questions

audit vs evaluationAudit’ answers ‘Did we do what we said we would do?’ For example, did we publish the document?, did it go out on time?, did it reach all our clients?

Evaluation’ answers ‘Did we achieve the outcome?’ For example, do our clients now understand our services?, are our procedures efficient?, how well did we predict that outcome?

Both types of questions are important and have a role in managing an organisation well. But often matters that should be evaluated are audited instead.

For example, suppose you recognise a communication need – you want your clients to better understand what you can do for them, or you want the public to take advantage of a new policy or initiative. The usual course of events goes something like this:

  1. Decide you need an information product (people usually think a document or website is the best way to deliver information)
  2. Get a project team together
  3. Develop a project timeline and determine a budget.
  4. Set tasks and assign responsibility
  5. Get the resources you think you will need
  6. Do the work – develop the product
  7. Deliver

How do we usually measure a project? Usually against the project plan. If the product is on time and on budget it is usually considered a job well done. We assume that if the document has been written and published then the job has been done.

But that’s audit, not evaluation. Only rarely are projects measured against purpose.

Evaluation questions are like: Did people see and read the document? Did they understand it, and understand the importance of the information? Have they changed their thinking or behaviour as a result of reading?

Financial disclosure – being clear, concise and effective

financial disclosureThe law says that financial disclosure documents must be worded and presented in a clear, concise and effective manner. This is a requirement of the Corporations Act 2001:

  • Financial Services Guides – Sect 942A (6a)
  • Product Disclosure Statements – Sect 1013C (3)
  • Statements of Advice – Sect 947C (6)

My observation is that many disclosure documents do not meet the standard of ‘clear, concise and effective’. Writers seem to focus on complying with other aspects of the law – having  the correct content. They assume that being complete and accurate is enough. That’s a very risky position to take, and it may break the law.

These standards of ‘clear, concise and effective’ are tough to meet because they can only be judged with reference to the reader, or user, of the document.

An effective document is one that achieves purpose. The general purpose of disclosure documents, as described in the law, is to help people make a decision about whether to buy financial services or products, or follow advice. To be effective, disclosure documents must work to achieve that purpose. That means you must know something about your readers and their decision making process, and use that knowledge to inform your writing. It may mean including additional content not required by the law, but that is helpful for your readers.

Being concise means not including unnecessary material, not saying the same thing multiple times (removing redundancy) and not using more words than is needed to express an idea. It means you should not blindly use a boiler-plate template that includes material that is irrelevant to some readers.

Being clear is a matter of

  1. organising content in a way that makes sense to your readers
  2. using words, sentence structure and a style that can be understood easily.

In short, all financial disclosure documents must be written using the principles of plain language, with a deliberate focus on the needs of users.

Reckless writing

reckless

Reckless writing is when writers just float a document ‘out there’ without any serious thought about their readers. Like reckless driving, it’s just doing what you think is OK without properly considering the consequences.

Even if your document is complete and accurate, not considering your readers is reckless. Not considering how they will understand and what they will do as a result of reading is both arrogant and careless. Not taking the time to structure your document in a way that makes sense, and not writing plainly in language readers can understand, is irresponsible.

It is never enough just to write what you think is good enough – the reader is the sole judge of effective communication.

Unfortunately, reckless writing is common. It’s unusual for authors to carefully articulate the purpose of the document and the needs of their users before they start writing. Proper user (reader) testing is rare. And document reviews don’t always fix the problem – they can end up being group recklessness.

But reckless writing is very risky behaviour for government agencies and businesses. It’s especially risky if you write documents that people use when making decisions.

Sometimes the risk is that the document is ignored. In that case, all that has been lost is

  • research effort in defining the content
  • writing effort, as authors struggle to find words to convey ideas
  • design effort when graphic elements are sourced to supplement the words
  • review effort as the document passes through various levels of approval
  • publishing cost, perhaps printing or placing it online
  • archival and governance effort to keep proper records of the document
  • the opportunity – the document was intended to achieve some outcome but didn’t.

Other times the risk is that users (readers) misunderstand the document and take an action that they shouldn’t, or that they would not have if they had understood it properly. When that happens, the cost to you and to them can be huge and may potentially involve legal action.

Consider your users when you write and what they need to do with the information. Test to make sure you are communicating effectively.

Outline of an effective business case – IT example

This example outline uses the familiar Situation, Complication, Question, Answer structure for business proposals.

The context is a large company in the finance industry implementing cloud technology for software development (referred to as virtual environments).

Note the power of ‘talking headings‘ – you’ll get the gist of the proposal just by reading these headings.

Executive summary

‘Virtual Environments’ open new opportunities

A transformational change plus tangible benefits

1 Situation: Solid technology underpins the business

1.1 Supporting a business with purposeful intent

1.2 Robust technology base

1.3 Sound controlled change methodology

2 Complication: Changing our technology is cumbersome

2.1 Shared and limited number of traditional environments

Development must be completed within a fixed window

Delays in one release impact future releases

Changes to one project impacts all other projects in the release

Production support is disrupted every release

Drives inflexible training schedules

2.2 Limited test data

Limited capability to back-up and restore test data

Old and unrealistic data compromises test confidence

2.3 Dependence on legacy platforms

Manual configuration results in delayed changes and increased variance

High costs of environments

3 Focusing question: How can we have rapid, yet robust, change?

3.1 How can we introduce change rapidly without losing control?

3.2 How can we provide data so that changes can be tested quickly and confidently?

3.3 Is there a way to allow projects to work at different rates?

3.4 How can we transform so that rapid change becomes ‘business as usual’?

4 Proposal: Modernise our IT environments and processes

4.1 Extend virtualised environments

Extend the application coverage to cover all organisational requirements

Decommission all traditional environments

Provide dedicated VEs for minor releases and production support

Provide dedicated VEs for training

4.2 Provide better test data management

Provide capability to backup and restore test data in non-production environments

Provide masked production type data

5 Cost/benefit: IRR of xx% and a payback period of yy years

5.1 Some benefits realised immediately, others gradually ramp up

5.2 If we ignore this opportunity, we’ll lose momentum

5.3 Strategically aligned to corporate objectives

6 Costs

6.1 Costs that can be estimated well

Data solution and extension of VEs across the organisation

6.2 Costs that cannot be estimated well

Extend VEs to include partner organisations

Impacts on the change delivery teams

7 Benefits

7.1 Benefits that cannot be estimated well

Improved business flexibility

Improved project quality and efficiency

Reduced reputation risk

Foundational build to support future delivery

Strategic capabilities for test data management

Reduced hardware spend

7.2 Benefits that can be estimated well

Avoiding the cost of provisioning new traditional environments

Avoiding the cost of new traditional environments to support large scale programs

Eliminating lost productivity and migration effort resulting from de-scoping

Decommission traditional environments

Eliminating minor release environment migration and lost productivity

Reduced retrofitting effort

8 What might raise costs or limit benefits?

8.1 Sensitivity analyses

Changes in cost estimates

Slow project progress

Limited project funding

Variable test data solution costs

8.2 Dependencies

Benefits are only realised if test data solution provided

Full realisation of benefits requires changing the way we work

8.3 Constraints

Satisfaction with current performance

8.4 Project risks

No change in mindset, so no organisational transformation

Partial implementation will reduce benefits and lead to ‘slip back’

Applications may require re-architecture

Additional non-functional re-architecture may be required

Hardware or software is procured unnecessarily by teams external to project

9 Appendices

9.1 Alternative solutions considered

9.2 How the project will be organised

9.3 How we gathered information

Bottom-up

Top-down

9.4 Industry trends

The curse of knowledge

curse of knowledgeSometimes poor writing is not the result of laziness or a desire to be obscure, it’s just because we know the content too well.

When you know something really well it is extremely difficult to imagine not knowing it. That makes it hard to share knowledge with others because you can’t easily put yourself in your readers’ shoes. It’s like trying to un-see or un-hear something.

The first principle of writing clearly is to understand your users or readers; to understand their needs, wants, interests and mind set. But that is really hard to do if you are an expert trying to communicate with non-experts.

Experts immerse themselves in the subject for years. They end up speaking and writing using abstract terms to summarise all the concrete data in their heads. They describe ‘replacing the bolt’ as ‘taking corrective measures’, or ‘wind and rain’ as ‘unfavourable weather’, or ‘stopping pollution’ as ’emissions reduction’. But novices don’t get it. They only hear vague phrases.

Experts forget how difficult it has been to acquire knowledge. They now see much of their knowledge as ‘obvious’ or ‘common sense’.

Elizabeth Newton illustrated the curse of knowledge in a simple game. A “tapper” was asked to tap out the rhythm of a well-known song, such as “Happy Birthday”. The listener’s job was to guess the song. Newton asked the tappers to predict the probability that listeners would guess correctly. They predicted 50%, but listeners actual success rate was 2.5%. The reason for such a difference? The tapper can’t avoid hearing the tune in their head playing with the taps, but all the listener can hear is a kind of Morse code.

Deliberately working to put yourself in the users’ shoes is a start, but doesn’t really solve the problem. The only solution is to test what you have written. Ask your user, or a surrogate user, what they understand from your writing.

(inspired by reading Steven Pinker’s book, The Sense of Style)

Think before you consult when writing policies

Top view of co-workers planning a strategy Free Photo
Business photograph designed by Pressfoto – Freepik.com

Employee consultation has become a ‘sacred cow’ when writing policies and procedures. There’s a tendency for organisations to involve all possible stakeholders so that everyone can have their say when defining how things work in an organisation. It’s promoted as a way to create an engaged and empowered workforce; an antidote to a command and control culture.

But consultation takes time and can be counter productive. Countless hours can be lost in document reviews and meetings, sometimes with little benefit.

Yet consultation communicates that you and your organisation value people and respect their point of view, knowledge and experience.

So, think before you run every policy through the same consultation process. Discern which documents will benefit from consultation, and who should be involved.

Consider policies in three broad groups:

1. Policies where consultation is pointless

If you are developing policies or procedure to implement a non-negotiable directive from the board, or a piece of legislation, consultation may not be helpful. Just write the document and get on with it. Consultation in this situation may even be harmful – it can raise the expectation of negotiation and input when there is none. You could lose credibility.

2. Policies where input from others is essential

Sometimes subject matter expertise resides in a number of people. You’ll need to consult to find out what is happening, or the best way of doing something. Find the right people and involve them in every stage of drafting and review. You’ll end up with a richer outcome by listening to appropriate stakeholders.

3. Policies where people just want to have their say

There are some policies in an organisation that stir the passions – like the ‘car policy’. People want to be heard but full consultation is not mission critical. When developing policies like this, I often invite comment but don’t run a full consultation process. Of course, if you invite comment you need to consider it – revise the policy or provide other feedback.

(this blog inspired by a conversation with Adam Leonard, General Manager Human Resources, Anglicare)

Writing a compelling business case – the MARCH approach

MARCH business caseWhen writing a business case, put yourself in the shoes of your reader (as you should do with all documents). Think through the decisions they will make as they consider your business case.

Remember the acronym MARCH to make sure you’ve included important content.
(This will help you march forward with your business case – daggy but memorable.)

The way a business thinks when considering a significant investment is similar to the way we all, as individuals, do. So I’ll use the example of buying a new kitchen for your home to illustrate the ideas.

M – must have or might be nice

Make sure you explain why the business should invest in what you are proposing.

Must have

Your solution might address a genuine business need or problem; current or emerging. That is, without it, the business will experience some amount of pain.

If my kitchen is broken – appliances not working, shelving falling down, etc – a new kitchen is a need.

Might be nice

It might be possible for the business to continue functioning without your solution, but your solution will make things ‘nicer’ in some way. It may be an opportunity to save money, reduce complexity, prepare for the future.

If my kitchen is not broken – it can still be used to prepare meals – but it is looking tired and worn; more efficient appliances will save money; a better design will make working in it easier; a modern appearance will please me and impress my friends.

A – affordable

The business must be able to afford the solution.

There are some absolutes around affordability, but also some perceptions. The cost must be perceived to be commensurate with the problem being solved or the opportunity provided.

If cost is likely to be an issue, you may need to explain how the business could afford your proposal. (Car dealers often express new car prices as ‘only $12.87 per week’.)

If a new kitchen will cost $500,000, I absolutely cannot afford it no matter how good it is or what benefits it will deliver. If it will cost $50,000, I can likely afford it, but with pain. If it’s only $5,000, I’m very interested.

R – right

Is the solution you are proposing the right way to solve the problem or deliver the opportunity? Is it the best option available?

Consider different products, but also consider fundamental changes to the way things are now.

Best = value, and value is measured by comparing the cost against the benefit. Examine the cost/benefit ratio of different options. There are different ways of doing this – return on investment, payback period, discounted cash flows and the like. Your organisation will have a preferred method.

There are a number of different kitchen suppliers. We’ve considered many of them, and XYZ offers the most suitable solution at the best price. We also considered converting the kitchen into a games room and eating out at every meal, but rejected this option due to health concerns.

C – choice, is this the best direction

Is this the best thing to invest in now?

Your proposal may be competing against a number of other unrelated ideas. There are always a number of things a business could invest in – is your idea the best thing to do now?

Yes, a new kitchen would be great, and the one from XYZ is the best one available. But the roof is leaking. We need to fix that before buying a kitchen.

H – how will it work

How will the solution be implemented?

What are proposing? When will it happen? What will be the impact on the business? What are the risks and how will they be managed? Who will be involved?

Provide clear answers to give the reader confidence you can deliver what you say you can.

The plans for the new kitchen are attached. We can start next month and you won’t have a kitchen for a week. We have three suppliers of ovens to manage supply problems. We’ve engaged expert trades people that have a track record of excellence.

All the MARCH framework items must be in your business case, although you can change the order in which they are presented to best meet your readers’ needs.

Removing the Indian accent when writing for Australian readers

oz india flagsOver the past few years I’ve worked with people from India on some IT projects within the finance industry in Sydney. Some have been in Australia on special work visas, others have migrated here.

For the most part, the people from India I have worked with are clever and have a good work ethic. In the IT space they bring valuable skills and experience. Some are plain brilliant. Businesses benefit from a diverse workforce and the synergy of different ways of thinking.

But sometimes communication is difficult – and it’s just because we grew up in different parts of the world. Our cultures are different, the way we use words is different and the way we sound out words is different. In face to face conversations and meetings people often have to repeat themselves multiple times to get a shared understanding. Speaking a little slower than normal helps, but doesn’t solve the problem entirely.

Moving to the written word should make things easier, but sometimes it doesn’t. It is not poor grammar or incorrect sentence construction.  Many Indian professionals have studied English for years at school and university.  But the Indian idiom and way of speaking often doesn’t gel with Australian readers.

Here’s three problems I’ve noticed. And to be fair, these are not exclusively Indian problems.

  1. Writing in an ‘official’ or bureaucratic way; using big or obscure words when simple words will do. Adopting this style can stop you from getting your ideas across and can sometimes result in readers laughing at you. It’s best to just say what you mean clearly and simply.

Sure Greg, I am updating the text for all the funds on UAT right now. Will intimate you once the activity is completed. – the writer didn’t really want to become intimate with me, they were just going to tell me when the job was done.

Please revert back at the earliest opportunity. – the writer didn’t want me to quickly return to my former state, they were asking for a reply.

  1. Using more words than needed. More words makes your document longer, but it doesn’t make your argument or your content stronger or more convincing. Australians prefer to be convinced by the quality and clarity of a proposal or idea, rather than the weight of words expressing it. Even when writing simple text, use as few words as you can to get the idea across.

Chris can be reached in case of any queries pertaining to consolidated monthly invoice figures. – it would be better, and shorter, to write Ask Chris if you have any questions about invoices.

  1. Excessive ‘cut & paste’. Sometimes content is taken from one document and pasted into another without serious thought about whether it is entirely appropriate. It’s fast but not always good. This is a more troublesome problem because it reveals a lack of robust consideration about the topic. Good writing can only come from good thinking.