Summary: Business Process documents give business and technical users an objective snapshot of how a system works. Use these guidelines to improve how you analyze, document, and review As-Is and To-Be processes.
Ask how it works. In other words, you can’t write about something until you know how it works. The key to writing process design documents is to understand every facet of the design process so you can ask informed questions, write useful material, and educate the reader.
Of course to get there, you have to figure out how it works.
3 Pre-writing Tasks
If you’re new to technical writing, or if you’ve just been asked to write up a series of process maps, you have several options when it comes to documenting process flows.
Let’s say you’re doing the workflow for a new banking system.
Where do you start?
- Install the software, learn how it works, and then map out the main activities. That’s fine to a point.
- Examine the functional requirements, see if it contains any workflow diagrams, cross check them against the new system, and update the new diagrams.
- Talk to the developers. This the step most people leave to last. It’s easy to understand why as developers tend to shy away from interviews – they just want to code and rightly so as that’s what they’re hired for – but as they built the system, they can provide a lot of information that you may not be aware of.
20 Business Process Writing Tips
So, where to start? When I interview developers, I try to work as follows:
- Go to their desk, introduce yourself, and ask if it’s ok to get some time with them later in the week. Not then, later. When it suits them.
- Send them a sample of what you’re trying to write. Show them the best example you have. But, just send one document. Don’t overdo it.
- Create an agenda. Outline what you’d like to cover in the meeting. This helps you both. They can prepare mentally in advance. You can use it to keep the session on track.
- Have everything ready in the meeting room. Pens help. Get a white board.
- Start with the big picture first. Don’t assume anything. For ten minutes just talk about the high level stuff. This helps you both relax, find your space, and warm up. But don’t try and get too buddy-buddy too fast. Light but professional.
- Share a printout of the agenda.
- Start with the first process.
- Diagram how you understand it using the white board. Ask for clarification. Walk them through the diagram, asking if each step is correct. Keep probing gently.
- Don’t assume anything. If you’re not clear about something, ask for help. Say, ‘Can you help me understand this…’ and then describe where you’re confused. Most people are obliging.
- Ask about exceptions, parallel activities, pre-conditions. These are the things they assume you know, or may have overlooked. So, keep probing away.
- One problem, one process. Don’t mix two process flows together. Split them instead. Later, you can merge them into a composite process diagram but, for now, you want to capture how it works at the lowest possible level.
- End the meeting on time, say thanks, head back to your desk.
- Write up everything immediately. Trust me, do. Tomorrow it will be all gone. Ok, not all but more than you’d like.
- Open MS Word (or Google Docs) and create a simple table. Add the step number in the first column, and a description in the next column. This helps you may to the diagram.
- Use a simple 1, 2, 3.1, 3.2 etc numbering convention. Avoid using the automatic numbering in Word, instead type them in by hand.
- Open Visio (or PowerPoint), create a few rows, and map the tasks accordingly.
- Paste the diagram back into the Word doc and sent to the developer.
- Number the doc as follows: company_productname_version_draft.
- Turn on Track Changes and encourage them to review each step. Don’t try to be smart and deliberately add mistakes, i.e. to check they read the doc.
- Create a final draft, update the version to 1, and the draft to Final, and publish.
Next week, we will look how to design the actual process flow and mistakes to make when connecting different activities.