Most stakeholders don't understand the complex diagrams preferred by many traditional modelers, nor do they want to take the time to learn them. The secret is to adopt inclusive models[2] which use simple tools and simple techniques that stakeholders can easily learn and therefore use to help capture and analyze requirements for your policies and procedures. We'll go through a number of these modeling techniques here.

The narrative outline

The narrative outline is probably the most ubiquitous form of process and procedure communication. A simple narrative outline is shown below where we've separated short sections of information and identified them with numbers and letters (or an alphanumeric combination).

Narratives are ever-present because they are very easy to follow and provide quick identification of logical groupings and the relative importance of the information being presented.

The narrative playscript or RACI chart

A slightly different concept of a narrative is called a playscript. And if you are wondering, yes, a play as in "theater." No, you don't have to dress up in tights and quote Shakespeare (if you do, send me the video, I need a laugh). Like a narrative it uses the indented, alphanumerically identifiable outline of short action items that need to be performed. And it adds an extra touch by listing the name or title of the person who is supposed to take the action.

While a true RACI chart displays who is Responsible, Accountable, Consulted with, and Informed, the playscript will usually focus on only those responsible, consulted with, and informed.

The biggest benefit of a playscript narrative over a simple narrative is that the reader immediately knows who is supposed to be performing the activities being described. There is no question and the "who should be doing this" part of the narrative can't be accidentally missed.

Frequently Asked Questions (FAQ)

The FAQ is a question and answer format that is popular with helpdesks and support sites. It is primarily used to simulate a conversation where one person asks questions and the second responds with a great answer. These can work well if the questions posted are commonly asked (hence the "frequently" part of frequently asked questions). The best way to use FAQs is to create a question and answer bank to fend off staff who are going to be opposed to new policies and procedures. By thinking through what the skeptics might say, and then posting FAQs that correspond to new policies and procedures, you can address concerns before they actually arise. A sample short FAQ follows.

Index cards

Index cards are great, simple, and cheap by the dozens. One great use for index cards is when documenting the various sub items that your controls are calling for. When we document controls, we use index cards to write the name and ID of the control along the top of the card. Below that, we list each of the major aspects, steps, or processes that the control calls for.

Simple index card method

By using something as simple as an index card, you can quickly and easily document your controls and then pass the cards around to the members of the team for their input as well. You can later transfer these cards over to some other type of documentation - but initially using the cards will ensure that your team doesn't get caught up in the formalities of writing instead of the process of analysis and understanding.

Troubleshooting tables

Troubleshooting tables are best used for documenting troubleshooting processes as they are neither a narrative nor an FAQ, and users are guaranteed to not read the whole document. Why won't they read it? Because if troubleshooting tables are written properly, the most likely causes will be listed first and the least likely causes will be written last. Therefore, as the reader progresses through the table, once they find and fix the problem they will cease to read the rest of the table.

Sample troubleshooting table

Troubleshooting tables are fine for easy solutions to common problems. However, with complex problems that require certain decisions to lead down one path and others to lead down another path, you have to move to flowcharts.

Flowcharts

Flowcharts are a modeling technique introduced in the 1940/50s. There are three basic symbols on this flowchart:  squares which represent activities or tasks, diamonds which represent decision points, and arrows which represent flow of control. Flowcharts support other types of symbols, such as off page connectors (for when your diagrams get too big) and input/output symbols to represent printed reports and data storage options.

Basic flowchart symbols

In order to create a flowchart, you simply need to work through the logic of the process one step at a time. The best place to start is at the top left of the diagram and then map down and to the right.

Each time a decision is made, the diagram calls for a diamond shape. Each arrowhead leaving a decision should be labeled with the appropriate condition.

The best way to stay agile when working with flow charts is to keep things simple.  Sketch them on whiteboards with your stakeholders to discuss important business logic, take a digital photo if you want to save it, or simply erase it once you're through.  The value often isn't in the models that you create, but instead, it is in the act of modeling because it helps you to think things through.

Sample flowchart

Data flow diagrams

Data flow diagrams are used to document the logical flow of data through the process. On one hand, they are very much like flow charts. On the other, their symbols and process flowers differ greatly.

Main objects in a data flow diagram

The data flow diagram of documenting the configuration of a system would be represented by something akin to the diagram that follows.

Sample data flow diagram

Universal Modeling Language (UML) activity diagrams

UML is a general-purpose modeling language that includes a standardized graphical notation that may be used to create an abstract model of a system, sometimes referred to as the UML model. UML may be considered as an extensible modeling language since it offers a profile mechanism to customize the language. UML diagrams have supplanted flowcharts as the tool for organizational process modeling. In many ways, UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development. There are several more symbol types in a UML activity diagram than there are in a basic flowchart.

The UML version of the flowchart that we displayed in the previous discussion would look something like this:

UML of website analysis and documentation

A more complete set of shapes for use with Microsoft Visio can be found online at http://www.phruby.com/stencildownload.html#How.