How to Document a Process


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.

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

The Flow of Collaboration

  • Everything starts with an idea, need for documentation, standard, process, procedure, etc.
  • A seed is planted by creating a container document for the content that will be created and placing it in the most appropriate location for all who will be involved.
    • The location can be inside of an application such as a PSA, SharePoint, Wiki page, or a network drive.
    • The container document 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. I.e. Word docs will usually be converted to PDF for release to clients.
  • Everyone involved who needs access should be granted permissions and given a link to the container document and location.
    • The actual container document should never be attached and distributed. It creates problems with version control and lost data. Use links to content.
  • 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, and issues (bugs).
  • Once everyone has had a chance to review the content and there are no more 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 MPI 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: November 27, 2018  

November 21, 2018   1374   Catheryn Felipe    Agile Service Delivery Run Guide  
Total 0 Votes:

Tell us how can we improve this post?

+ = Verify Human or Spambot ?

Log In is required for submitting new question.

Submit a Comment

Log In is required for submitting new question.