Blank Sheet Syndrome and How to Beat It – Key Questions
Key questions for getting started on that new Manual or Procedure, or breathing fresh life into tired company documentation
It’s a common scenario. You have been tasked with writing (or rewriting) the “xyz” Handbook / Manual / Procedure (for “xyz” substitute whatever you like – Quality, Health and Safety, overall company policy, etc).
It may be right up your street and an essential part of your role.
But often you are one of the “great unvolunteered.” You may be a respected line manager, competent operator or even the office secretary. But you have 100 other things to do, and setting out documented policies and procedures might not be in your Job Description, or in your personal comfort zone.
So how do you get started on that “blank sheet of paper?”
“Working from first principles”
There is no magic wand, or master template, to guarantee the perfect document that everyone will take to and immediately put into practice. But thinking about a few fundamentals may help to frame your ideas – and save the time, frustration and wasted trees of many later redrafts.
1. What is it for?
Why do you need this document, and what do you want to achieve with it?
This will inform every other consideration – including style, content and even whether you need it (or parts of it) at all.
Is it a day-to-day operational procedure for the shopfloor? Is it a top-level company policy? A training manual?
Do you need the documentation to comply with external standards or certifications? Does it need co-ordinate with anything else (e.g. parent Group policies)?
2. Who is it for?
Who is intended to read or use this documentation? Employees? Directors? What should they be getting from it?
Are there other (indirect) stakeholders who may need to see it – customers, suppliers, tender prospects, regulators or auditors?
Think about the right audience for the right reasons: a Management System, for example, should be written with the users in mind. Don’t be bullied into using “ISO” jargon or terminology just for the auditor – there’s no requirement for this in any ISO Standard, and it will simply make your documentation incomprehensible to those people who should be using it.
3. What to include?
This flows from the purpose you identified in Step 1, and works on two levels:
a) The scope to be covered:
Does the proposed documentation cover the entire organisation, or just certain departments / operations / processes / sites? Does it apply to all employees / contractors / visitors etc?
b) The level of detail:
Are you outlining a broad-brush statement of principle, or do you need minute instructions or diagrams defining every step of an operation? Are specific details needed to comply with legal or other obligations?
For some things, detailed technical instructions and meticulous stage sign-offs are clearly an essential part of the process. You don’t want your nuclear submarines being built from the back of a fag packet.
For others – broader process outlines, guidelines or other forms of presentation may be better suited.
What’s the purpose? Whose interests must be satisfied, and how much detail do they need?
Consider also what not to include – in particular anything already covered by other documentation or information sources. Remember the “single point of reference” principle: whenever you have the same information in more than one place, sooner or later they will get out of sync. Decide where the information lives, and whenever possible cross-reference from anywhere else.
4. What should it look like?
a) Structure or outline:
What’s the best way of organising or grouping the subject matter within your scope? Is there a logical hierarchy or sequence?
Does everything belong in a single document, or should there be a suite of (smaller) documents – maybe linked by an overarching diagram or index?
What is the best structure to help your users find their way around?
b) Format and style:
Whose language does your document need to speak? A workshop checklist reads differently to a boardroom statement of corporate values. Do you need to clarify terms and definitions, to ensure that everyone is reading the same words with the same meaning?
What tools does your organisation already use – hard copy files or electronic formats? Word, Excel, PowerPoint, Visio? Are your colleagues bullet point gluttons, or will “shopping list” procedures lead to some items being missed? What about using diagrams, flow charts, mind maps, pictograms, scale models?
A colleague once told me how he set up an ISO 9001-certified Quality Management System using diagrams and cartoons for a company whose workers couldn’t read or write. It can be done.
What is the best format to get your purpose across?
5. Who “owns” it?
Your process might insist that the MD (or the Quality Manager) “sign off” all documentation, but who is really going to give it the heart and meaning to make it “stick?” Who will make sure it fits both the policy framework and the practical needs of those working to it?
Whose inputs do you need, and how do you get them?
Who will champion and communicate the resulting documentation to ensure everyone is signed up to it?
And who will keep their finger on the pulse after that – checking your procedures or your policy statements actually work, keeping them up to date, making sure today’s finely-crafted essential reading doesn’t become tomorrow’s chip paper?
If you can answer most of these points before you dive into the detail – then you have already unblocked that “blank sheet of paper” you started with (or empty list of new ideas) and are more than halfway towards producing useful, meaningful documentation.
If you can’t, don’t have the time or still feel the task is overwhelming you – why not call us today and share your concerns? After all, not everyone can do what you are expert at. Your time may be better spent doing what is in your Job Description, and letting us do what is in ours.