Skip to main content

How to Document a Process

General

All content requires collaboration in one form or another at one time or another. Most of the content created by this company will be created through collaboration over time. We must have a set flow for how we intend to collaborate and how we will ensure the completion of everything we start.

 

How to Document a Process
Process Components with Feedback

 

Properly Documented Process Components

  • Complete Flow Chart describing how this thing or idea works.
  • Quality Narrative for each cell of the Flow Chart
  • Forms for Input
  • Reports for Output
  • Email Templates for Communications
  • Checklists for Progress Measurement
  • A method for reviewing/revising/updating the process (Feedback loop)

The Flow of Collaboration

  • Everything starts with an idea, need for documentation, standard, process, procedure, etc.
  • A seed is planted by creating a folder for the content that will be created ( standard, process, procedure, etc.).
    • The location for these folders is (Chris Workman to finish this sentence).
    • The documents created should be the most appropriate for the content. E.g. Word, Excel, HTML Wiki, Visio, Etc.
    • This does not dictate or restrict the distributed / distributable form of the document once complete.
      • A Knowledge Base article would be created for release internally.
      • I.e. Word docs will usually be converted to PDF for release to clients
  • Everyone involved who needs access to the master files should be granted permissions and given a link to the container document and location.
    • The actual documents or folder should never be attached and distributed. It creates problems with version control and lost data. Use links to content instea.
  • As content is created or updates all those involved (collaborators) should be updated or informed.
  • There should be frequent stand up meetings to discuss additions, revisions, deprecations (stopped using), and issues (bugs) with the standard, process, procedure as tehy are developed or revised.
  • Once everyone has had a chance to review the content and there are no more significant changes, there should be a call to release the content as official or accepted.
    • We call this “Released to the wild”.
  • There should be frequent releases of usable content versus waiting for things to be 100% complete.
    The rule of thumb should be; that if the content is released, will our process, work product, or client value be better off for having this content available without causing a slow down due to missing elements?

    • Can the missing content be explained well enough and are there directions on how to proceed without the missing elements?
    • Can the content be labeled or otherwise designated as Seco South eyes only? I.e. Internal use only, not ready for release to clients.
    • Can the content be labeled or otherwise designated as Beta or Work in Progress – Not to be relied upon yet?

Last Update: August 20, 2019  

August 20, 2019   16   Manuel    General  
Total 0 Votes:
0

Tell us how can we improve this post?

+ = Verify Human or Spambot ?

Log In is required for submitting new question.

Leave a Reply

Your email address will not be published. Required fields are marked *

Click here to set sidebar widgets.

Twitter
Visit Us
Follow Me
Tweet
Pinterest
Pinterest
Pinterest

Log In is required for submitting new question.