What? Why? How? Answering Essential Questions in Your Organization

Organizational documentation takes many forms: mission statements, vision statements, strategic plans, policies, procedures, process maps, project plans. How do these disparate documents relate to one another?

I find it fruitful to categorize documentation as answers to the basic questions of “what?”, “why?”, and “how?” when asked at a particular level of abstraction within the context of an organization. This article explores the relationship among that triad of questions and to the different types of organizational documentation.

A Recursive Hierarchy

Taken together on a particular topic of inquiry, the questions “what”, “why”, and “how” can be seen to have a hierarchical relationship to one another.

To see this relationship clearly, let’s take an example. Pick a topic of organizational concern, such as your work for today. We’ll call this concern the Current Topic of inquiry. It is the answer to the “what” question in this triad. (Q: “What is my current work?” A: “Rejigger the thingamajig.”)

When asked of the “what” of the current topic of inquiry, the answer to the question “why” (Q: “Why am I to rejigger the thingamajig?” A: “In order to get the whatchamacallit production line working.”) provides the contextually appropriate higher level motivating purpose or final cause of the “what”, whereas the answer to the question “how” (Q: “How am I to rejigger the thingamajig?” A: “Insert tab A into slot B.”) provides the contextually appropriate lower level causal sequence or efficient cause of the given “what”.

Taken as a unit, these triads of question and answer pairings also generate a recursive hierarchy. That is, we can move the Current Topic pointer to the “how” answer in our previous example (“Insert tab A into slot B”), making it the “what” of our current inquiry, and then ask the same questions. This time, the “why” for our new “what” will be the answer to our previous “what” (“To rejigger the thingamajig.”), and the new “how” will be an even more granular description of the work instructions (“Grasp tab A with your left hand. Grasp slot B with your right hand. Move your left hand toward your right carefully until tab A nestles into slot B.”) Likewise, we can move the Current Topic pointer to the “why” answer in our first example (“get the whatchamacallit production line working.”) to make it the “what” of a new inquiry and then ask the same questions again. The “how” of this third iteration will be our previous “what” (“Rejigger the thingamajig.”) and a new “why” will be generated (“To manufacture watchamacallits.”)

To put it alternately, in a teleological hierarchy (one of goals, purposes, objectives, targets, …), this triad of questions are generically answered as follows:

Question Answer
What am I to do? the current goal in the hierarchy
Why am I to do this? the parent, or next goal up, in the hierarchy,
How am I to do this? the children, or next goals down, in the hierarchy

This recursive analysis may in principle be repeated indefinitely. Within a given domain of inquiry, however, the analysis will at some point cease to be useful and reach a stop in both the upward and downward directions. In the organizational context, it will ground out at a base-level “how” describing work in physical actions that can be directly executed by employees and which carry the activity of the organization forward (and typically long before such specificity is documented). In the same organizational context on the ascending side, it will eventually stop at the “why” which references direct contribution toward the organization’s mission. From a process perspective, these two upper and lower terminals define the boundaries of the system that is the organization in question.

Three Levels of Organizational Documentation

While this recursive analysis may be applied at fine granularity, as in the previous example which analyzed part of a given process (“thingamajig rejiggering”), its procedural steps, and associated detailed work instructions, it may also be applied at a coarser resolution to gain clarity on how different types of typical organizational documentation related to one another. Viewed from the fixed perspective of an organization as a whole, we might categorize organizational documentation into three categories establishing organizational Identity, Strategy, and Execution, corresponding to the answers to Why, What, and How within a given organization.


In any given triad or recursive hierarchy of triads, the top level “why” has no "why" answer within the current context. As the initial example showed, to answer “why” for the current “why” requires another recursive application of the triad, moving the current inquiry pointer to the current top-level “why”, making it the new “what”.

At the boundary of an organization, the “why” answer lies outside the organization and comes from the purposes of the societal system in which the current goal hierarchy is contained. Organizational mission statements, which frequently reference contribution to fulfilling the needs of the society in which the organization is embedded, are an expression of that meta-level purpose within the current organizational context.


The organization’s “why”, expressed in its mission/purpose and vision, and constrained by its values and principles, are translated into a business model and broad objectives and associated key performance indicators at the “what” level to generate a strategy.


The strategic “what” becomes an executable “how” when each business model component and strategic objective is broken down into time-bounded initiatives (projects) and ongoing operations (processes). Each of these elements is susceptible to the same recursive analysis. For example, process descriptions may be taken as a “why” and decomposed into procedures specifying “what” work to do, which may in turn be decomposed into detailed work instructions that specify exactly “how” to do that work.


Why is this important? Because far too often, we neglect either the “why” or the “how”. In striving to accomplish the “what” of our work, these contextual considerations easily fall out of focus. When the “how” is neglected, we inevitably encounter avoidable error, costly rework, and missed deadlines resulting from poor process and inadequate planning. When the “why” is neglected, we find loss of motivation, poor morale, and petty politics deriving from the dearth of meaning in the mere accomplishment of the “what” of our work.

How do you keep the "why" and "how" aligned with the "what" of work in your organization? Leave your tips in the comments section below.

Documenting in Detail: Creating Context with a Table of Contents

Few organizations attain the level of organization afforded by defining a shared filing system. More typical is a haphazard collection of “buckets” of shared documents with little or no internal organization. If you’re committed to leveraging documentation to improve organizational effectiveness, however, you’ll want to go further and not only provide easy access to documents through a consistent filing system but also layer an index on top of that system to provide context for and guide stakeholders to the documentation you’ve created so they don’t have to browse or search or ask around to find relevant documentation. This article describes four options for organizing such a table of contents.


Annotated Index

Perhaps the simplest documentation guide is a table of contents, stored at the top level of the shared filing system which it indexes, containing hyperlinks to the other documents that you want to highlight for a particular group of stakeholders. Such an index could take the form of a spreadsheet or a table in a rich text document containing a series of document titles as hyperlinks, preferably accompanied by a brief description of the document’s content and relevance.

Example: Initech Internal Documentation
Document Description
Filing a TPS Report Step-by-step instructions for filling out a TPS report
TPS Report Cover Memo Specifications Sample cover sheet for TPS report
Stapler Requisition Process Approval process for ordering Swingline staplers
Troubleshooting “PC Load Letter” How to fix the paper cartridge message on an HP LaserJet


Perspectival Planner

Adding additional structure to a basic annotated index makes it more useful and faster to navigate. One approach is to group documentation links and descriptions according to their relevance to the different perspectives from which one may view an organization, such as:
  • People: Position descriptions & related human resources documentation.
  • Policy: Organizational values, principles, policies, rules, and controls constraining the operation of the organization.
  • Process: Procedures grouped by organizational process areas.
  • System: Setup & configuration documentation for systems supporting organizational processes.
  • Schedule: Planning calendar/tickler system identifying time-based triggers for executing documented procedures
Example: Dilbertesque Departmental Documentation


Document Description
Chief Inspiration Officer Position description for executive cheerleader.
Brand Warrior Position description for aggressive marketing maven.
... ...

(Group position descriptions into divisions and departments as appropriate.)


Document Description
Flair Standards Manager checklist for wait staff dress code compliance
Policy Policy Our self-documenting policy on writing policies.
... ...

(Group policies into organizational units and topics as appropriate.)


Document Description
Planning to plan Meta-process description for planning your planning.
Alphabetizing purchase orders A-Z guide to put order into POs

(Group procedures into process areas as appropriate.)


Document Description
LaserJet 2750p Printer setup & configuration documentation
HON H3000 Office workstation assembly instructions

(Group systems by organizational unit or type as appropriate.)


Document Description Recurrence Pattern
Casual Friday enforcement protocol HR checklist for employee dress code compliance Weekly on Friday
Company Picnic Setup instructions for annual potluck Annually, on 3rd Friday in June
... ... ...

(Group triggers into recurrence patterns as appropriate.)


Workflow Matrix

A more sophisticated presentation of these organizational perspectives may be obtained by creating an integrated workflow responsibility matrix, which shows the interrelationships among people, policies, processes, systems, and schedules. A spreadsheet works best for such a matrix, as it allows the user to shift perspective and find relevant documentation quickly by sorting and filtering according to his or her present interest.

Role Procedure Trigger Pos. A Pos. B Pos. C Supporting System(s)
Software Engineering Quality Prepare TPS report Weekly, on M & W R   A SAP-Y ERP
Purchasing Administration Alphabetize Purchase Orders PO received by Purchasing   R   -
... ... ... ... ... ... ...

A further advantage of this integrated approach is that when complete, it can facilitate the automatic generation and update of detailed position descriptions.


Strategic Operating Document

Each of the preceding examples added value to your documentation efforts both by making the documentation itself easier to find and also by giving it greater context so that its meaning in relation to other organizational priorities is clear to your coworkers. Another compelling and direct way to add such context and meaning is to use the table of contents as a way to reinforce your organizational mission and core principles so that employees understand the “why” not just the “what” and “how” of your business. This understanding reinforces the link between executing the “what” of everyday work (and doing so well according to the “how” of your procedures) as a fulfillment of the “why” of your mission.

Based on Sam Carpenter’s ideas in the book Work the System,serial entrepreneurs Dan Andrews and Ian Schoen have worked out a practical implementation way to link "what", "why", and "how" that they call a Strategic Operating Document, consisting of four sections:

  • Projects: A list of current active projects.
  • Procedures: Links to operational procedures (equivalent to the “Process” contents previously described).
  • Principles: A concise list of maxims to be invoked when making decisions in areas not covered by established procedures.
  • Mission: A statement of the organization’s core purpose and values.

Regardless of how simple or sophisticated you make it, providing some sort of index as easy entry point to your organizational documentation will help ensure it actually gets read and referenced by those for whom it’s been written.

How do you ease access to your important organizational documentation? Leave your tips in the comment section below.

Documenting in Detail: Patrolling Permissions

by Indygo, courtesy the Noun ProjectAssigning Access

An important but often overlooked aspect of distributing documentation electronically is assigning access permissions. In this article, we’ll discuss general considerations to bear in mind when sharing documents with others by assigning user and/or group access permissions.

Permission Levels

The exact permissions that can be assigned to a given document vary depending upon the file sharing service used. Most services allow at least three levels: a default no access level, a read-only View permission, and a read/write Edit permission. Google Drive adds in the useful Comment permission, which allows holders to attach comments to the document and make edits that show as highlighted suggestions which may be accepted or rejected by those holding the Edit permission.

Determining Permission Levels

The permissions applied to a given document will obviously vary depending upon the content of the document. For example, documents containing confidential or sensitive information should be restricted to only those who need access to that information to carry out their job responsibilities, with others granted no access whatsoever. Other documents with information applicable to all employees should be shared to employees with at least View (if not Edit) access. Yet other documents with content applicable to customers or other external stakeholders may be shared with public View access. Between these obvious extremes, however, there’s a grey area in the middle consisting of documents that contain no particularly privileged information such that they must be protected for clear reasons of confidentiality, but whose contents are only of direct relevance to a given stakeholder group, say a single department. How do you decide what permissions to assign to this majority of documents?

Decision Principles

The answer to that question will vary significantly from organization to organization. In practice, the unthinking acceptance of the default settings of file sharing system used to distribute the document typically provides the answer. But these defaults are typically designed by adherence to some general principle of permission. Such principles bear consideration in setting up your documentation distribution process.
Least Privilege
The majority of file sharing platforms default to disallow access to a document unless explicit access has been granted. This enables easy implementation of the principle of least privilege, which grants to a user only the minimum level of access necessary to only those resources which are essential to that user’s work.

The principle of least privilege has the advantage of enhancing both the security and integrity of information. It is the most conservative approach, especially suitable for organizations in regulated industries or those who deal with secret information.

The principle of least privilege has the downside of bogging down organizational processes, since the correspondence of security permissions to the actual “need to know” of employees is rarely perfect and may change frequently, requiring new authorizations for information access. Further, such restrictions likely hamper innovation by compartmentalizing information flow and restricting free access to organizational knowledge, which, if made available to the minds of more people, may spark novel connections leading to creative advance.
Open Access
On the other extreme is the information wants to be free model best exemplified by the wiki platform, which typically defaults to allow public Edit access. Wikipedia is the canonical example of such an open system, which maximizes information distribution potential as well as the opportunity for innovation by allowing anyone to edit. However, that latter capability opens up the potential for negative, degrading changes just as easily as useful, innovative ones. The wiki platform addresses this latter problem of information integrity by maintaining an extensive version history, which allows one to easily revert to a previous version when changes judged as unconstructive have been made. Automatic version histories are foundational to version control systems as well as other Internet publishing platforms, including Google Drive and Microsoft OneDrive.

Levels of Analysis

The question of assigning access should be analyzed at least at two levels, the organizational level and the document level. The answer at the organizational level provides the default settings for the permissions applied at the folder and document level, which may be overridden given the nature of the given document’s content.

At the organizational level, the primary consideration is the organization’s orientation to openness. The trade-offs are between security and innovation. The organization must decide where it stands on negotiating these trade-offs given its unique mission and environmental constraints. The relevant decision criterion is given by management scientist Stafford Beer, who developed a general systems principle relevant to any question involving trade-offs between allowing freedom and exercising control:
“[Freedom] … is in principle a computable function of the system’s purpose in relation to its environment.”

In this case, if your organization’s purpose involves safeguarding confidential information, your default organizational stance may be the principle of least privilege. A bank, for example, will certainly want to default to a least privilege stance to protect the security of its members’ holdings. If, on the other hand, your organization is committed to innovation and the dissemination of knowledge, perhaps the “information wants to be free” stance is a closer fit. Academic institutions, especially public universities, which have a commitment to the open advancement of knowledge, tend in this direction.

A similar analysis may be repeated at multiple levels within the organization, as appropriate given the disparate purposes that exist across functional departments. For example, even within a fairly open academic institution, the business office may have a different orientation toward information openness than a research department.

Regardless of any default orientation stemming from the organizational unit’s stance toward information openness, the analysis must be repeated at the individual document level, based on the content of the document. What is the purpose of the document? The answer to that question, in the context of the purpose and constraints of the organizational unit, will determine appropriate permissions.
Concern Permission to Restrict Trade-Off
Security View Innovation
Integrity Edit Agility

If your organization is especially concerned with security, then it may be worthwhile to codify a policy for information access which identifies classes of sensitive information and identifies the positions and organizational units which should have access to each class.

Capturing Permissions

When actually assigning sharing permissions, it’s useful to think in terms of the document stakeholders and their roles. An adapted responsibility matrix (which we introduced in a previous discussion as an element of a Documentation Policy) can clarify and capture appropriate permissions. In addition to columns capturing permissions for the standard RACI role codes, adding a more general Access code can capture the cases where a document may be shared with users or groups other than direct stakeholders.

Example: Employee Position Description

For example, appropriate sharing permissions on a given employee’s job description may be captured as follows. (Assume that Edit permissions imply View permissions.)
Position / Organizational Unit
HR Director
Associate HR Director
Position Supervisor
Current Employees

Example: Company Annual Report

Sharing permissions on a company’s annual report permission may be captured as:
Position / Organizational Unit
Communications Director

Permission Inheritance

While appropriate permissions can vary from document to document, it’s far more practical to assign them at the folder level when possible, as contained files and folders will inherit the permissions assigned on the containing folder, eliminating the need for file-by-file permission assignment. Thinking through the appropriate permissions for your organization’s filing schema can ease the administrative burden of assigning and maintaining sharing permissions. Thinking through the appropriate permissions for your organization’s filing schema can ease the administrative burden of assigning and maintaining sharing permissions.
Folder View Edit
  • Traditional Co., Inc.
Current Employees
  • Accounting
  • Processes
  • AR
CFO, Controller AR Clerk
  • AP
CFO, Controller AP Clerk
  • Projects
  • ...
  • Engineering

Thanks to reader Daniel Kegan for sparking these reflections on assigning access. How do you handle sharing permissions? Please let me know by leaving a comment below.

Documenting in Detail: Organizing for Access

FilesAndFolders.png by FrancoG <https://commons.wikimedia.org/wiki/User:FrancoGG>Regardless of which publishing platform you choose, you’ll need to organize your documentation in similar ways in order to facilitate access by those who need it (and prevent it by those who should not be privy, in the case of sensitive or confidential information). The options available for organizing and granting/restricting access will change depending on which publishing platform you’ve selected. However, the principles and general approach remain invariant regardless of your particular choice.

Essential Elements

While you could put all of your documents in one folder and grant access to everyone who needs them by assigning permissions on that top level directory, such a “one big heap” approach to file organization puts the burden of finding the relevant documentation on the user, requiring them to hunt around manually or search by keyword for the relevant document, decreasing the chances your documentation will actually be referenced. As a result, you will be well served to create a bit more structure. Here are the essential elements for effective organization:
  • Filing schema: A clear, consistent, shared filing structure in which to store documents.
  • Permissions: A set of role-based permissions controlling access to the filing structure.
  • Naming convention: A clear, consistent naming convention for the folders and documents in the filing structure.
  • Index: A table of contents and/or index to catalog the documents in the filing structure.
In this article, we'll concentrate on developing a framework for creating a filing schema, which will provide the basis for assigning permissions, filing documents, and creating an index, topics that will be covered in later installments.

Creating the Filing Schema

The purpose of a filing structure is to segment documents into logical categories which serve two functions: (1) Expediting locating documents; (2) Easing assignment of inherited permissions to control document access. To realize the benefit of those two objectives, it’s important to follow some consistent segmentation schema. The best choice depends on many factors, so will be determined by your organizational circumstances. Following are some of the most useful filing structure schema alternatives:
  • Organization: Folders mirror the corporate structure, recapitulating the organization chart from division to department to work-group.
  • Process: Folders mirror ongoing operational processes, independent of organizational structure.
  • Project: Folders mirror the defined projects in which the organization is actively engaged.
  • Category: Folders represent other categories relevant to the organization
  • Combination: A combination of the previous alternatives.
In my experience, a combination approach, thoughtfully & consistently applied, works well, as typically the single-perspective schemas become too cumbersome except in very simple use cases, since any organization has all of the perspectives more or less in play at all times.

Example: Functional Organization

For example, a traditional, functionally structured organization may create a shared filing system which follows the Organization structure down to the department level, then switch to Process and Project folders within department.
  • Traditional Co., Inc.
    • Line of Business
      • Marketing
        • Processes
        • Projects
      • Engineering
      • Manufacturing
      • Sales
      • ...
    • Support Services
      • Accounting
      • Finance
      • Human Resources
      • Maintenance
      • Information Technology
      • ...
    • Leadership
      • ...

Example: Project/Matrix Organization

A project-based or matrix organization may have a filing schema with both Organization and Project schemas at the top level, with function-oriented documentation organized by Department within the top Operations folder and cross-functional projects delineated within the top-level Projects folder.
  • McBain Consulting
    • Operations
      • Marketing
      • Accounting
      • Finance
      • Human Resources
      • Information Technology
      • ...
    • Projects
      • BigName Client A — Major Initiative
      • BigName Client B — Milking For Money
      • BigName Client C — Cleaning Up After Last Time
      • ...

Example: Network Organization

A flat or network organization may take a more systems-oriented view and opt for putting Process and Projects at the top level, breaking Process down into ongoing operational areas and Projects into time-limited initiatives.
  • NebuloCo
    • Processes
      • Mission, Identity & Vision Definition
      • Market Research & Strategy
      • Value Proposition Design & Development
      • Marketing & Sales
      • Customer Empathy & Success
      • Human Resource Cultivation
      • Financial Resource Stewardship
    • Projects
      • Boil the Ocean 2016
      • Disruptive Innovation #7
      • Ultimate Mobile, Social, Local, Crowdsource Platform v2.02
      • Next Killer App
      • ...

Naming Conventions

Once you have a filing structure in place based on your chosen schema, you can begin filing documents. In doing so, employing clear, descriptive folder and file names helps identify their contents easily. While full-text indexing and searching of documents has made descriptive naming seemingly less essential than it once was, the proliferation of electronic documents still makes the practice worthwhile since when a search produces many relevant documents, expressive naming will narrow the set faster. The following naming conventions are recommended:

Use Descriptive Names

Use names descriptive of the content of the folder or document. For example, an outline of a speech to be given to the Rotary Club is better titled 2016-05-12 Speech to Evanston Rotary Club.doc than Speech.doc.

Format Dates YYYY-MM-DD

Start the name with a date in YYYY-MM-DD (International Standards Organization 8601) date format when dates are included in names to allow for chronological sorting. For example, if saving meeting minutes by date, enter in 2016-02-03 not 2-3-2016, as the computer will not sort the latter by date properly.

Zero-Pad Numbers

Pad numbers with one or more leading zeroes to allow for sorting, both in dates and in other numeric sequences. For example, if numbering sequential documents, pad with zeroes "My Document 01", "My Document 02", ..., as the computer will sort "My Document 10" before "My Document 9" but after "My Document 09".

Prepend Non-alphabetic Characters to Force Sorting

If you prefer to control file and folder sort order for navigational clarity, consider starting names with non-alphabetic characters. Most non-alphanumeric keyboard characters sort before letters and numbers so, for example, starting a file or folder name with an underscore [ _ ] or exclamation point [ ! ] will typically put it at the top of the list when sorted in ascending order. Different file systems sort slightly differently however, so you may have to experiment.

Getting items to sort at the end of a list is trickier. Typically, you have to resort to using non-keyboard characters from the extended Unicode set. These characters must be entered by copying/pasting from another source, such as Windows Character Map or MacOS Character Viewer. Many of these extended characters still sort before letters, however. (My favorite extended character for forcing items to the top of a list is the bullet [ • ]). There are those extended characters that will sort to the end of the list, however. For this, Greek letters can be useful. Omega [ ω ] is a semantically appropriate character to use, though aesthetically I prefer Phi [ φ ].

When employing non-alphanumeric names, avoid restricted characters frequently used as filepath delimiters or search operators: \ / | ? : * " < >

With the basic filing structure in place and documents filed to share, you can begin assigning access permissions and creating an index to ease navigation. We'll cover these topics in future articles. In the meantime, please let me know what your favored filing system looks like using the comments section below.

Documenting in Detail: DIY Distribution

Now that you have identified your documentation priorities and started to generate some policies and procedures, how do you best disseminate them? Unless you’re creating documentation entirely for your own benefit, it’s likely that you’ll need to share it with others in your organization.

3-ring binder photo by Pavel Krok (used under the Creative Commons Attribution-Share Alike 2.5 Generic license)The obvious, tried-and-true solution is to simply print the documentation and hand it out to stakeholders, perhaps neatly organized into 3-ring policy and procedure binders. Or, if you prefer saving trees, disseminating documentation as e-mail attachments comes to mind as another straight-forward distribution avenue. These methods are generally simple and easy to execute but suffer from the same shortcomings. Since both rely on creating multiple copies of the documentation, they fail to provide a “single source of truth”. Every time you change your processes or guidelines, you need to re-distribute the documentation. If practices change quickly or you develop a lot of documentation, this churn leads to a lot of extra distribution work for you as well as burdensome filing work for your coworkers. It also opens up the potential for error in the quite likely circumstance that not all copies of old versions are replaced after an update, leading to an out-of-date version being relied upon as a reference.

Given these downsides, this article focuses on sharing documentation in ways that maintain a single source of truth. We’ll start by exploring “home grown” systems building on common file sharing services. In a future article, we'll also briefly explore more specialized documentation and workflow management systems.

Home Grown Systems


The simplest and lowest cost approach to distributing your documentation while maintaining a single source of truth is to grow your own system, preferably building on your existing method of sharing electronic files (assuming that’s not as e-mail attachments!). The proliferation of Internet file sharing services has made this DIY approach easier in the past decade than it had been previously, when it required significant IT expertise to set up file sharing servers, enable web publishing, and manage accounts and permissions. Now popular cloud services like Google Drive, Microsoft OneDrive, and Dropbox take care of all of the technical details, opening sharing up to anyone with moderate computer skills.


The following tables summarize leading alternatives for sharing documentation effectively. Most platforms are available in free versions with some usage limitations.
Attribute Description
Sharing Level Permission sets you can apply to shared documents.
Synchronization Client software (by operating system) enabling automatic document synchronization for up-to-date off-line access
Web Editors Web application(s) allowing direct editing of documents, if any.
Service Sharing Levels Synchronization Clients Web Editors
Google Drive View, Comment, Edit Google Drive for Windows, MacOS, iOS, Android Google Docs Suite
Google’s Web editors are not quite as full-featured as desktop OS office applications, but offer excellent collaborative authoring capabilities. Google Drive can store any file type, so you are not limited to sharing native Google document types.
Microsoft OneDrive View, Edit Microsoft OneDrive for Windows, MacOS, iOS, Android, Windows Phone Office Web Suite
While the Office Web editors may be more limited than Google’s equivalents, OneDrive offers seamless integration with the desktop and mobile OS versions of Microsoft Office, making it a good choice for Office-centric organizations.
Zoho Docs View, Edit Zoho Docs for Desktop on Windows, MacOS, iOS, Android Zoho Docs Suite
A lesser-known equivalent to Google Docs & Office Web, Zoho offers free and subscription productivity apps, as well as integrated specialty business apps for project management, customer relationship management, work orders, workflow, and more.
Dropbox View, Edit Dropbox for Windows, MacOS, iOS, Android, Windows Phone None
Many other cloud storage providers exist, including Amazon Cloud Drive, Apple iCloud, but DropBox leads the market in functionality and integrations.
Microsoft SharePoint Online View, Edit Microsoft OneDrive for Business on Windows, MacOS, iOS, Android, Windows Phone Office Web Suite + SharePoint Wiki & Rich Text Editors
Many other collaboration/intranet/content management systems options exist, but SharePoint Online serves as an exemplar. It integrates document repositories with web pages, wiki sites, discussion forums, and custom workflow capabilities.
Wikispaces View, Edit None Wikitext editor
If your needs are for highly collaborative editing with a web interface, but little need for advanced formatting, then a wiki may be a suitable choice. Wikispaces offers hosting, but there are many free wiki software options if you host yourself, notably MediaWiki, on which Wikipedia is built.
Github View, Edit Various Git clients on Windows, MacOS, iOS, Android Markdown
Git is a popular version control system. While used primarily for collaborating on software projects, it can handle storage and version maintenance of any file type, so if tracking and approval of document changes is important to you, version control software may be useful. You can host your own for free or use a hosted service, with Github being the most popular. Other providers, notably Bitbucket.org, also provide free and paid plans for hosting Git repositories.
Windows (SMB) File Server View, Edit Microsoft Windows Sync Center None
Once the de facto choice for sharing files, a traditional file server is now one of the least desirable, as it requires self-hosting and special setup for publishing over the Internet securely. On the file server front, a myriad of other protocol and platform choices exist (MacOS X [AFP], WebDAV, NFS, FTP), but all require far more setup and administration than the previously listed alternatives.

Regardless of which publishing platform you choose, you’ll need to organize your documentation in similar ways. The next Process Pragmatist article will explore the essentials of organizing for efficient electronic distribution, including methods of creating master indexes of shared documentation for easy navigation.

In the meantime, please let me know what documentation distribution system you're having success (or challenges) with in the comments section following this post or via reply e-mail.

Documenting in Detail: Procedure Procedures

In the previous installment of the Process Pragmatist "Documenting in Detail" series, I introduced a sample Policy on writing Policies (as well as other common types of organizational documentation). In this article, I descend to greater depth of detail on documenting by delivering sample procedures for writing procedures. As with a "policy" policy, a "procedure" procedure is self-describing, and its presentation provides an opportunity to illustrate ways to format procedures.

I offer two different procedures, one linear/sequential and one iterative. Both are written according to the guidelines in the previously presented Documentation Policy. The sequential procedure is the standard, step-by-step approach to procedure writing and makes sense to follow to maximize procedure production efficiency. However, unless you're a technical writer, trainer, or quality expert dedicated to writing organizational procedures, you may find it a bit daunting to tackle.

If you're creating procedures as a small part of larger job responsibilities, the incremental and iterative approach may make matters more manageable. This approach to capturing procedural documentation is a more organic method of documenting a given procedure over time. It’s especially suited to situations where you are the person currently executing the procedure to be documented and have competing demands on your time.

Create & Deploy Standard Operating Procedure


This procedure defines the steps to follow in creating standard operating procedures.


In defining standardized work for organizational processes, standard operating procedures (SOPs) provide the basis for continuous improvement efforts to increase organizational efficiency and effectiveness and enable the pursuit of high standards of quality by improving employee communication and coordination, increasing productivity through process improvement and reduction in organizational bottlenecks, and reducing productivity losses (as well as employee and customer frustration) due to avoidable error and associated rework. This procedure aims to ease the creation and adoption of SOPs by defining consistent, best-practices guidance for their generation.
  • Documentation Policy
  • Electronic Document Filing System Policy
  • Style Guide


All employees of {Organization Name}




  1. Identify key SOP parameters
    • What is the topic for the SOP?
    • Who is the audience for the SOP?
    • What is the criticality of the SOP?
    • What resource(s) are available to create the SOP?
    • What is the timeframe for deploying the SOP?
  2. Select an approach to creating the SOP
    • Review the 2 options for SOP creation outlined in the following sections
    • Compare the fit of the options against the previously identified parameters
    • Select an approach that fits best with the identified parameters
  3. Follow the selected approach to create & deploy the SOP
    • Reflect and renew
    • What went well in the process/should be preserved?
    • What should be improved for next time?
    • What steps should be taken now?
    • How will you celebrate this accomplishment?
Option 1: Sequential Steps
This linear approach is best suited to situations where:
  • Resources can be dedicated to the creation of the given SOP
  • The SOP is critical to company operations, safety, or compliance
  • The timeframe for producing the SOP is short
  • The audience needs polished and/or special/multi-media presentation
Step Explanation
Identify topic & scope What will the procedure cover? What’s not included? Capture this in a concise summary of the contents to serve as the procedure Description.
Identify purpose What’s driving the creation of the procedure? Review the Documentation Drivers. Capture the purpose in a concise statement of the motivation for executing the procedure to serve as the procedure Rationale. Keep the purpose in mind when selecting a presentation format and writing the procedure.
Identify audience For whom is the documentation written? Capture a list of the role(s) or position(s) responsible for executing the procedure to serve as the procedure Audience. Keep the audience in mind when selecting a presentation format and writing the procedure.
Choose presentation format Given the topic, scope, purpose, & audience, -elect a suitable format for the procedure (see Formats section of Documentation Policy):
  • Step-By-Step Outline,
  • Step-By-Step Table,
  • Checklist,
  • Slide deck,
  • Flowchart,
  • Screencast,
  • Video tutorial.
Review style guide Review the style guide from the Documentation Policy.
Compose first draft Keeping in mind the needs of the audience, the emphasis dictated by the purpose, and the best practices embodied in the style guide, write a first draft.
Edit the draft After a break, come back to the draft with fresh eyes. If possible, offer the draft to others familiar with the procedure and/or style guide to comment on. Edit the procedure to conform to the best practices in the style guide
Test the procedure If possible, test the procedure with someone with the relevant skills for identified role/position but who has not completed the procedure before. Observe them performing the procedure according to the documentation and note any areas of difficulty. Solicit feedback for additional improvements.
Repeat Edit/Test cycle until acceptable execution ensured Repeat steps 7-8 until acceptable execution reliably achieved.
4. Deploy
Formalize Complete all sections of the presentation format and route for approvals as necessary, as specified in the Documentation Policy.
Publish & distribute Publish the documentation and distribute to the audience with any necessary instructions to begin implementation.
Establish maintenance schedule Set the necessary reminder to review the procedure for updates or termination per the Documentation Policy.
Option 2: Incremental & Iterative
This organic method of capturing a given procedure over time is best suited to situations where:
  • The person documented has competing demands on time.
  • The timeframe for deployment is flexible.
  • The SOP’s criticality is low enough that initially incomplete or unclear instructions can be tolerated.
Step Explanation
Jump In
  • The most important thing is to just start!
  • Think about your audience, and a suitable presentation format, but don’t agonize over the choices.
Start Small
  • The next time you're doing the procedure, open up a new document and start capturing the first steps.
  • Give yourself permission to be sloppy and incomplete the first time.
Build Iteratively
  • When you perform the procedure the next time, fill in a few more steps.
  • The time after that, add in details.
  • The time after that, add in exceptions.
  • After that, edit for clarity.
Test & Refine
  • Hand the documentation off for testing to see if it makes sense to someone else.
  • Observe and refine.
  • Incorporate feedback.
Formalize & Deploy
  • Put the finishing touches on the SOP per the Documentation policy
  • Distribute & delegate.



Position / Organizational Unit

Date Revised Author(s) Date Approved Approver(s) Date Next Review

While they capture the essence of creating procedures, both options identified in this sample procedure are written at a fairly high level of abstraction to make them applicable to a variety of organizations and documentation media. An even more useful procedure would descend to the level of work instructions, providing detailed guidance on the concrete steps to create a given procedure for a given audience with the given institutions's tools of choice. For example, if your organization uses Google Docs extensively, then the procedure would describe how to create a new Google Doc from an existing procedure template, where to save it, who to share it with, etc. so that an individual with the appropriate work qualifications but no prior experience in your organization could execute the procedure.

In the next Process Pragmatist article, we'll start to explore some of those nitty-gritty particulars. I'll continue  "Documenting in Detail" with an exploration of practical ways to efficiently organize and distribute your policies and procedures.

In the meantime, please let me know how you would improve these "procedure" procedures using the comments section following this post or the contact form on the About page.

Documenting in Detail: A Policy Perspective

Image Credit: Writing Tools by Pete O'Shea, from Flickr <https://www.flickr.com/photos/peteoshea/5600161625>
So you're convinced. Maybe it was enduring the latest tirade of a customer or colleague burned by botched work because a coworker didn't know how to do a job properly. Maybe it was dealing with the fallout from an employee who transgressed a tacit company rule that they didn't even know existed because, well, it wasn't actually written down anywhere. Maybe it was hours spent troubleshooting a fault with a company system, half of which was wasted just figuring out how the system was configured in the first place because nobody bothered to document the initial setup. Maybe it was the realization that if you wrote down the steps to that job that only you seem to know how to do, you could stop being the bottleneck, delegate the work, and get on with more important things. Maybe it was just previously reading my pithy proverb, "If it's not documented, it's not done".

Whatever the reason, you've decided it's finally time to start doing things right and writing some documentation. But where to start? Documenting can feel like a tedious chore. Extra work. Maybe even overwhelming. Until it's done. Then it's liberating!

Just Start

The most important thing is to just start: Open up a new document and start writing the first steps to that onerous procedure the next time you're doing it. It can be sloppy and incomplete the first time. When you perform the procedure the next time, you can fill in a few more steps. The time after that, you can add in details. The time after that, you can add in exceptions. After that, edit for clarity. After several passes, you'll be able to hand the documentation off for testing to see if it makes sense to someone else. Then when you know it's understandable, you can easily delegate the whole process because it's clearly documented.

Documenting as you go may add a few minutes to each execution of the procedure, but that time can be returned many times over through delegation and eliminated rework. Who knows, you may find the process of documenting a procedure reveals hidden efficiencies to be exploited in eliminating or combining steps.

Having something written down and shared is the most important thing. Format, style, presentation, and everything else are secondary considerations. If you're like me, though, you want to have more of a plan in place, a clear end goal to strive for, even if it takes a while to get there. Granted, given the things that I am interested in writing about, it is unlikely that you are like me, but for the sake of the remainder of this article, let's assume that you're looking for a little more guidance than "just do it".

A Policy Policy

To that end, I've gathered best practices I've learned over the years and compiled them into the following example policy on, well, writing policies! Actually, the policy is a bit broader than that. Since so many of its guidelines apply equally to other types of organizational documentation, this sample policy covers writing policies, procedures, as well as system setup documentation. Just consider those additional inclusions free bonuses.

Why a policy? I chose this form because it's self-describing and self-illustrating, serving as an example of the guidelines it promulgates.

Next time, the Procedure Procedure!

Documentation Policy


This policy establishes the types of documentation that must be maintained and sets forth guidelines for the production of such documentation.



In promulgating consistent, best practices standards for the creation and distribution of organizational documentation, this policy aims to increase organizational efficiency and effectiveness and enable the pursuit of high standards of quality by improving employee communication and coordination, increasing productivity through process improvement and reduction in organizational bottlenecks, and reducing productivity losses (as well as employee and customer frustration) due to avoidable error and associated rework.


  • Electronic Document Filing System Policy
  • Style Guide


All employees of {Organization Name}




All (1) established policies, (2) important reoccurring processes & related procedures, (3) important system installation & configuration parameters, shall be documented and maintained by the respective organizational owner and promptly published to all relevant stakeholders under the terms outlined in this policy.

Documentation Types


Regardless of precise format, policies should contain the following:
  • Title: A concise, descriptive name ending with the word “Policy”.
  • Description: A concise summary of the contents.
  • Context: A section containing the following two subsections identifying the context answering the “why” for the policy.
    • Rationale: A concise statement of the motivation for adopting the policy.
    • Related: Links to documents containing related (1) statements of guiding values and principles, (2) parent or sibling policies.
  • Audience: The stakeholders to whom the policy applies.
  • Definitions: Definitions of important words or concepts used in the policy.
  • Policy: Statement of rules or guidelines to be followed, divided into sections as appropriate, outline numbered when appropriate.
  • Resources: Bullet list of links to useful related background material.
  • Control: See the Shared Document Control section.
Recommended format(s):
  • Policy template


Regardless of precise format, procedures should contain the following:
  • Title: A concise, present-tense action verb phrase naming the procedure.
    • Examples:
      • Onboard New Employee,
      • Conduct Employee Exit Interview.
  • Description: A concise summary of the contents.
  • Context: A section containing the following two subsections identifying the context answering the “why” for the procedure.
    • Rationale: A concise statement of the motivation for executing the procedure.
    • Related: Links to documents containing related
      • strategic objectives,
      • project charters,
      • Policies,
      • parent or sibling procedures.
  • Audience: A list of the role(s) or position(s) responsible for executing the procedure.
  • Definitions: Definitions of important words or concepts used in the procedure.
  • Procedure: Step-by-step instructions for completing the procedure, divided into sections as appropriate for ease, produced according to the constraints laid out in the Style Guide section if written.
  • Resources: Bullet list of links to related background material useful to executing the procedure, including internal documents or Internet sites.
  • Control: See the Document Control section.
Recommended format(s) should be appropriate to the procedure and audience, but may include:
  • Step-By-Step Outline,
  • Step-By-Step Table,
  • Checklist,
  • Slide deck,
  • Flowchart,
  • Screencast,
  • Video tutorial.

System Configurations

Regardless of precise format, system configurations should contain the following:
  • Title: Descriptive title for document including system name (Manufacturer/Publisher/Service Provider + Hardware Model/Software Title/Service Name) + specific setup steps described.
  • Description: A concise summary of the contents.
  • Context: A section containing the following two subsections identifying the context answering the “why” for the policy.
    • Rationale: A concise description of the purpose of the system, its primary users, the particular topic of the documentation, any major "gotchas".
    • Related: Links to documents containing related
      • configuration documentation,
      • policies,
      • procedures.
  • Audience: The role(s) or position(s) responsible for maintaining the system.
  • Definitions: Definitions of important words or concepts used in the procedure.
  • Configuration: Step-by-step instructions outlining the actions taken (setup) to install/configure the system.
  • Resources: Bullet list of links to related background material useful to the configuration information, including internal documents and manufacturer/publisher/provider information.
  • Control: See the Document Control section.
Recommended format should be selected as appropriate to the contents, but may include:
  • Manufacturer/Publisher/Provider manuals/materials,
  • Step-By-Step Outline,
  • Step-By-Step Table,
  • Slide deck,
  • Diagram,
  • Screen capture,
  • Setup video.

Document Control Section

All documentation should have a Control section with the following content.


A responsibility matrix recording responsibility for writing, reviewing, approving, and receiving the documentation serving as the basis for assigning access permissions and notifying stakeholders of changes, coded as follows:
  • (R)esponsible: The one position charged with creating and maintaining the documentation, which should typically be the position responsible for enforcing the policy, executing the procedure, or maintaining the system, as appropriate.
  • (A)pprove: Zero or more positions charged with approving changes to the documentation, which should be those immediately accountable for the policy, procedure, or system configuration, as appropriate.
  • (C)onsult: Zero or more positions from whom input must be solicited during drafting.
  • (I)nform: Zero or more positions who should have access to the documentation and be informed of all updates.


A table with the following contents documenting revisions to the documentation and, if required, approvals for those revisions.
  • Date Revised: The completion date of the current revision.
  • Author: Name(s) of those person(s) who wrote the current draft, in Last name, First order, separated by semicolons.
  • Description: Optional concise narrative of changes made in the current revision.
  • Approver(s): For documents requiring change approval, the name(s) of the person(s) approving the revision in Last name, First order. For non change-controlled documents, “Not Applicable”.
  • Date Approved: Date the draft was approved, if applicable, otherwise, “Not Applicable”.
  • Date Next Review: Date the document should be reviewed by the Responsible position for updates or sunset.

Document Distribution

The position responsible for the documentation must promptly distribute new, modified, or revoked policies to all stakeholders to whom the policy applies, as recorded in the Control section of the document structure. Documentation should be stored per the Shared Filing System Policy.

Documentation Style Guide

General Writing

  • Write for clarity & readability, employing accepted grammar & spelling.
  • Unless otherwise noted in this document, follow the { organizational style guide | Chicago Manual of Style | APA }
  • Dates: Use the ISO 8601 YYYY-MM-DD format when specifying dates in order to enable chronological document sorting and to avoid confusion between American and European date orders.
  • Time: Use 24-hour time notation with time zone reference when specifying times to enable chronological document sorting and avoid confusion.

Procedure Writing

  • Write procedures with enough context and specificity to allow an individual with the qualifications for the position but no prior experience with the procedure in question to be able to complete the procedure unaided.
  • Exclude all sensitive information such as passwords, substituting an appropriate descriptive placeholder and/or instructions for securely looking up the sensitive information.
  • Break long procedures down into logical sections, naming each section descriptively.
  • Outline indent as appropriate to visually show hierarchical relationship of substeps to steps, identifying sequential action steps using legal numbering.
  • Indent step explanations/clarifications to using bullets as appropriate.
  • Keep step descriptions concise to promote readability.
  • Describe each step on same outline level at the same logical level of activity.
  • Describe steps starting with a present-tense action verb phrase identifying the action to be performed, providing any useful context/explanation/clarifications in closing clauses or indented bullet points.
  • Embed screen shots, tables, diagrams, screen captures, and videos for added clarity.
  • Use ampersands to conserve space in step descriptions.

Typographic Conventions

  • Bold: Section headings
  • Italics: emphasis within a paragraph, especially when introducing new words.
Graphical User Interface (GUI) Formatting
When specifying components of graphic user interfaces in written descriptions, employ the following typographic conventions to promote clarity:
  • Button/Hyperlink: Boldface & underline pressable GUI element, such as a button or hyperlink.
  • Menu: Boldface the name of any pull-down or pop-up menu or menu item, separating items in hierarchical menu with the greater than (>) character.
  • Filename: Underline the (path) name of any file, folder, or URL.
  • “Prompt”: Place in double quotes any computer prompt, including dialog box or window text
  • User Input: Italicize any text the user should enter.
  • Other Element: Boldface and italicize the name of any other GUI element referenced, such as tab control, accordion, etc.




Position / Organizational Unit


Date Revised Author(s) Date Approved Approver(s) Date Next Review

A Procedure Procedure

If that policy statement seems too onerous or abstract to be helpful, fear not. In the next Process Pragmatist article, I'll continue the "Documenting in Detail" theme but take it down to a more practical level by presenting a procedure for writing procedures, which will also fill in some missing links in the Documentation Policy by furnishing a few documentation format templates.

In the meantime, please let me know how you would improve the sample documentation policy using the Comments section following this post or the contact form on the About page.