5 Steps to Document a Process


There are many times where we need to document a process, either for our own management purposes or as part of the project strategy for clients or end users. This is easier said than done, particularly when you need to rely on subject matter experts to help understand the process itself! The following article provides 5 steps to help make sure you are documenting effectively.

Default settings are all around us – in our phones, computer monitors, and computer applications – and are the automatically assigned values that don’t require any user intervention. In essence, a default setting idiot-proofs an application or device so that if we go too far off the beaten path, we can always reset it and just start over again. Even though it’s never pleasant losing work, it’s better than reaching that dreaded point of no return. There is security in knowing everything will be just fine as soon as we go back to the Default setting.

Did you know that the project manager sometimes serves as the project’s default setting? You’re the person that everyone goes to when things get out of control, or when a process is broken or needs to be developed. People seek you out whenever things aren’t moving fast enough, there’s not enough feedback, or critical tasks and initiatives are dropped.

What happens is that everyone tries to do their own thing, realizes that it’s tedious and complicated, and calls you in as a project manager to unravel the pieces, document the process, look for improvements, finalize and implement the new way of doing things.

A great example of this process is when a project manager has to coordinate an Implementation Guide for a piece of software. Here’s the scenario: A new software product is being rolled out to the user community. It requires some client input and customization in order to make it work the way the client needs it to work. The problem is that there’s nothing between the software and the client that details what needs to be done…a problem that just came to your attention.

To further complicate things, there’s nobody around that can fill the critical role and produce that kind of information. Developers don’t think of things in client-facing terms. Your marketing department doesn’t have enough technical background to fill in the gaps. Your training department is offsite for the rest of the month on another project, and your technical writer is on vacation for the next two weeks.

The reset button has just been pushed and it defaults to you as the project manager. The following are some guidelines you can follow if you find you need to document a process:

  1. Start with an Outline – The first thing you’ll want to do is start with a high-level outline, a free-form, living and breathing document that you literally throw together in 10-15 minutes. Think about the process (in this case, using the software) you are trying document, and what the most logical progression to get from Point A to Point B is…Point B being the final goal you want to achieve.Once you have your initial thoughts down on paper, take a step back and look through the outline. Does it flow? Is it logical? Are there any large gaps that need to be filled? Put yourself in the shoes of a reader who is looking at this document for the first time and ask yourself what you would want to know. Move topics around and then start to fill in sub-topics under the main topics to add more color and depth. The outline will serve as a guide for you to follow when documenting the process and ultimately will become the Table of Contents.
  2. Put a Frame Around the Final Document – Next, spend time on a rough draft of what you think the final document will look like. You’ll end up with plenty of substance as you document the process itself, but right now it’s important to give it a sense of design and form. That will make the final document easy to read and follow.There are a lot of great templates online (for example, in Microsoft Office) that can serve as the starting point. There’s no need to start from scratch. Knowing what the final document will look like will make you aware of details you need to ask about while interviewing the experts. For example, you may end up with a sidebar that includes a section on Additional Resources, or you could have Definitions incorporated throughout the document as special callouts.
  3. Set Up Your Process Documentation Spreadsheet – Now that you have the final document set up, put that to the side. Your working document will now be a spreadsheet with these columns:
    1. Step Number – This is the step number of the process. You’ll be able to use this as the main way to sort and order the process you are defining.
    2. Category – There will most likely be various phases of the process that you’ll need to document. Break these down into five or six major areas. For example, the initial phase may be Data Collection. Then the second phase moves into Setup, third phase into Data Input, and so on. Categorizing keeps similar activities together and helps to explain the process at a high level.
    3. Description – The next column will be a description of the step. For example: Find Logos that are 300 x 150 pixels, or Upload document to Server.
    4. Notes – Include any notes that will help the user do their job better. This includes any recommendations or guidelines by the creator of the software and/or document, and best practices.
    5. Questions – Finally, you’ll want to have a column for any unanswered or open questions that need further clarification. Ideally, you’ll have everything answered the first time through, but this will serve as a repository of questions that may need further research.
  4. Meet with the Subject Matter Expert(s) – You are now in a position to get to work. Find the subject matter expert or experts and set up an initial three to four-hour session to interview them about the process. Explain that you will want to go through every painstaking detail for the purpose of documenting it from beginning to end. Set that expectation up front, because if you don’t, they will either become very aggravated and ill-tempered with you or they may just skim over the information superficially.Here’s a caveat… Don’t let them skim over the surface. Make them show you every detail, upload every file, push every button, and generate every report. People sometimes have a tendency to gloss over things that are not fully ‘baked’ yet, or will say that usability is still forthcoming. Don’t believe it. You need to act as the actual end customer that paid money for whatever it is that they are showing you, and to expect – no, demand – that it work. If you don’t, your customer will, and they won’t be quite as understanding.Record the process step-by-step, filling in the columns on the documentation spreadsheet (step #3) as you go, and then repeat your information-gathering with follow-up interviews. You won’t get everything you need from just the first session, so set up a regular schedule for doing it again – and again and again – until the entire process has been documented.
  5. Convert the Spreadsheet into Your Document – You now have the raw material you need to put together your final document. Review the outline again and make any adjustments necessary now that you understand things thoroughly. Go through each step, and also review additional information to plug in as resources or terminology, and certainly any descriptive screenshots. Have a second pair of eyes proofread your sentence structure and grammar.

That’s it! Now, it’s not exactly a simple or quick project to document a process. It does take an extraordinary amount of discipline and focus. Process works best when everyone can access and review it easily. Store your process documents online in your project management software, ideally in folders connected to the project. Uploading it to one location ensures that everyone has the latest version and literally keeps everyone on the same page.