Today’s businesses run on processes and the software applications that support or automate them. But look in the average software user guide and you’ll find very few process flows to contextualize the application functionality. The focus of the material is on task-competence exemplified through screenshots and step-by-step instructions.

This approach is grounded in the factory assembly line paradigm in which it is not necessary for a task-worker to know or care much about the task that precedes or follows their task. A century or so later, in the so-called “knowledge economy” manned by “knowledge workers”, this task-centric approach needs supplementing with contextual views of the process that help participants to better understand their role and that of other participants to encourage everyone to think from a process rather than just a task perspective to help drive best practice improvements.

One way to get this contextual process perspective is through formal “models” of all or part of the process in the form of visual diagrams such as use-cases or process flows (e.g. swimlanes). Another way is through the use of textual process narratives that describe the process and the process steps. There are issues with both these perspectives. Some people do not respond well to visual models, especially if they do not fully understand the visual notation used to convey important information such as relationships or the type of entity diagrammed. Others find a textual description intimidating or just plain boring and won’t take the time to read it.

My aim here is to propose a different approach to writing process narratives by applying the principles of screenwriting and indeed using screenwriting software to write a process narrative I term a processplay. A spin-off benefit of this approach is that the process narrative could eventually be filmed as a movie to provide another highly accessible way of understanding a process from end to end.< /span>

Screenplays vs. Processplays

A screenplay envisions a movie. A processplay envisions a process execution. The former recounts a story, the latter a process execution flow. The processplay is intended to be:

· Explanatory - describing how something happens

· Instructional – describing how something is done

· Situational – describing what might actually be said

Conventionally, a screenplay documents a linear narrative that represents a series of story events usually with a causal link between them. These events are represented in the screenplay by individual scenes, each comprising a series of story beats and each scene usually involves one or more characters speaking dialog or doing something in a particular setting or locale. A scene may end with an explicit transition instruction (e.g. CUT TO) that suggests a visual transition between scenes.

Even with this brief introduction to a screenplay it’s obvious that there is significant synergy between a screenplay and a process.

• A screenplay narrative has a beginning and an end just like a process.

• A screenplay is populated with characters just as a process has “actors” representing a specific process “persona” or “role”.

• A screenplay has scenes that are “set” somewhere, while a process has places where steps takes place or systems in which process tasks are managed.

• A screenplay has dialog – an interchange between characters – just as a process has interchanges between roles and/or tasks.

• A screenplay has scene settings like a process has location-specific dynamics.

• A screenplay has scene action like a process has events that take place within or around the process boundaries.

• A screenplay has transitions and a process has handoffs.

A (good) screenplay is also written in a highly visual way so that it is easy for the audience – and initially the screenplay reader – to envision and see what the screenplay describes. This is important because it is indicative of how utilizing a screenplay mode for writing process narratives bridges both visual process diagrams and textual process descriptions. A screenplay literally helps the reader to “see” the process in their minds-eye. A processplay leverages this aspect of screenwriting to provide another way to communicate a process to an observer/participant.

How to Write a Processplay – A Process Narrative Screenplay

It is easy to write a processplay in any standard screenwriting package. A starting assumption is that the world of the processplay is the process of focus, the places and systems where the process “plays out”, and the participants in the process. It is up to you to decide whether these participant characters represent roles, persona or named individuals within your organization.

Use a screenwriting software package to define all your characters (i.e. roles) and then outline all your scenes (i.e. process steps) as placeholder headings in the processplay. In a conventional screenplay a scene heading or slugline looks something like this:

INT/EXT – DESCRIPTION OF LOCATION – DAY/NIGHT

In a processplay the scene heading may simply be a title for the process step or could be something like this:

<STEP ID> - <NAME OF STEP> - <SYSTEM MODULE>

1 - LOOKUP ORDER – ORDER INQUIRY SCREEN

Or whatever makes sense for the process narrative you are envisioning. Now that you have a cast of characters (roles) and a series of scenes (steps) you can begin to “fill in” the processplay scenes (steps) to document step dialog, description and action.

Process Step Dialog, Description and Action

A scene usually starts with some scene description to describe the locale. This is no different for a process step: Where is the role or what system/module/screen are they in and what are they about to do, for example:

1 - LOOKUP ORDER – ORDER INQUIRY SCREEN

In the order processing office the ORDER ENTRY CLERK receives a phone call from a CUSTOMER inquiring about the status of a recent ORDER.

In a screenplay the scene is usually elaborated by specific roles speaking dialog or doing something. In a processplay this could be translated into a role describing what they say or do and then some description to clarify what happens as a result of what the role does, for example:

1 - LOOKUP ORDER – ORDER INQUIRY SCREEN

In the order processing office the ORDER ENTRY CLERK receives a phone call from a CUSTOMER inquiring about the status of a recent ORDER.

CLERK

Do you have the order number?

The Clerk keys the order number provided into the search box and clicks SEARCH. A list of orders is displayed but not the one the customer asked for.

In this case the scene is elaborated by handling a sequence of dialog/actions by the clerk or to manage issues such as exception events:

1 - LOOKUP ORDER – ORDER ENTRY SYSTEM

In the order processing office the ORDER ENTRY CLERK receives a phone call from a CUSTOMER inquiring about the status of a recent ORDER. While saying hello, the clerk switches to the ORDER INQUIRY screen.

CLERK

Do you have the order number?

CUSTOMER

No.

So order number can’t be used to search for the order.

CLERK

Do you know your customer ID?

CUSTOMER

No.

So customer number can’t be used to search for the order.

CLERK

OK. What is your company name?

CUSTOMER

XYZ Limited.

The Clerk keys the customer name into the SEARCH box and clicks the GO button. A list of customers like the name entered into the search box is displayed. The Clerk double clicks the name he thinks is the correct customer.

A list of OPEN ORDERS for the selected customer is displayed, one line per order. Each order line displays the order NUMBER, DATE, DUE DATE, VALUE and STATUS.

It’s already clear that each scene could become quite elaborate, which is why it is important to define the scope and focus of the processplay upfront. For example, a good use of a processplay is to reflect a best-practice or ideal “to-be” scenario that does not include exceptions or alternative ways of doing things, as below:

1 - LOOKUP ORDER – ORDER ENTRY SYSTEM

In the order processing office the ORDER ENTRY CLERK receives a phone call from a CUSTOMER inquiring about the status of a recent ORDER. While saying hello, the clerk switches to the ORDER INQUIRY screen.

CLERK

Do you have the order number?

CUSTOMER

12345.

The Clerk keys the order number into the SEARCH box and clicks the GO button. A copy of the order displays on screen. One item is out-of-stock and highlighted in yellow. The status of the order is clearly shown in red, top right: PENDING - AWAITING STOCK.

CLERK

Item XYZ is currently out of stock.

Shall we ship the order now and

put this item on backorder?

CUSTOMER

Yes please.

The Clerk clicks the SHIP NOW button that changes the status of the order so that it’s ready for picking and sends an email confirmation to the customer.

CLERK

That’s done.

An email confirmation is on its way.

Is there anything else I can help you with?

In this way the processplay not only documents best practice but also literally provides a “script” for the role participant to work from as a guide. This will help new employees get quickly up to speed in their respective process roles.

Ideally the process narrative is made into a movie. Especially if the processplay documents a mission-critical process and a best practice execution is being advocated as a change to the way the process is being done currently. But even if the processplay is not filmed, this approach offers an interesting alternative or addition to conventional process documentation that should make the whole process easier to assimilate and envision for all participants – both “old hands” and newbies.