How to Build a RIM Playbook Part 3 - Gather and Review Documentation

Step 3 in the process to build a RIM playbook is to gather and review any existing documentation related to a given RIM-related activity. The existence of documentation strongly suggests that the activity documented is a play that should be included. Some of this documentation might be outdated; some processes may have very little in the way of actual documentation. We'll discuss how to address both of these issues in part 4. 

This gathering and reviewing exercise is arguably the core of, and the most valuable time spent on, building a playbook. Even if your playbook is just a simple spreadsheet, with links to the most current documentation for each of your processes listed in that one file, you'd still be significantly ahead of the game. 

This also means that this exercise is worthy of some time and effort. It's not just amassing the documentation and skimming through it - you need to review each document in depth to understand how they flow and interact. Process-related documentation in particular often makes references to other documentation that can be of value in building the playbook. 

There are three main types of documentation to gather and review.

Process documentation. These documents will drive the development of the plays themselves, including the title, description, purpose, and schedule/frequency. They may also help to identify the roles involved for a particular play. And they are the actual resources that are included, and used, to execute the individual plays.

Process documentation includes: 

• Existing procedures
• Flowcharts and process maps
• Checklists and guidelines
• Troubleshooting guides
• Templates
• "Cheat sheets"
• Quick start guides
• Training materials
• Lists of frequently asked questions 

The records retention schedule can also be valuable here, as many of the RIM-related tasks will generate records which are included in the retention schedule.

If you have a formalized help desk or support function for the records program, or even just for the recordkeeping system, it may be helpful to look through the trouble tickets as some of these may relate to plays. 

Roles & responsibilities. These documents will help to identify the roles involved for a particular play. Responsibilities are more than just “who does what” – I suggest using a RACI matrix or something similar to identify the roles that are:

• Responsible – the one(s) actually performing the task. This is often the person generating the metrics listed below. More than one role may have responsibility; the responsible role may also be the accountable role in some cases.
• Accountable – the one who ensures that the task is completed to standard. This is often also the initial audience for the metrics listed below. There should only be one role that is accountable.
• Consult – generally subject matter experts who provide specific advice. This is a two-way or multidirectional communication, and can be from the Responsible, Accountable, or other Consult roles.  More than one role may be Consulted for a particular task.
• Inform – anyone who needs to be kept up to date on the status of a process, progress, roadblocks, etc. This is a one-way communication, typically from the Accountable role. More than one role may be Informed about a particular task.

Relevant documents will include things like job descriptions, organizational charts, and other program documentation that identifies areas of responsibility, including those previously listed. In other words, it's not uncommon for a procedure to identify the roles involved. Similarly, a flowchart might include swim lanes to indicate responsibility for specific tasks. 

Reports, scorecards, and dashboards. Reports include metrics, and one or more recipients or audiences, which will help to determine both the RACI and the metrics for each play.

Reports would include things like weekly/monthly status reports; regular metrics; and dashboards, scorecards, and other aggregators of qualitative and quantitative data relevant to a particular task or activity. At a minimum, anyone receiving the reports should be considered an Inform role, and may be a Consult or even an Accountable one. 

Next up: Part 4 - confirming the final lists of plays based on the information gathered to this point. 

I teach a workshop on how to build playbooks. You can find more details about the course and approach at https://athroconsulting.com/?page_id=981. 

I also build RIM and IG playbooks for organizations - drop me a note at jesse.wilkins@athroconsulting.com and let's talk about what that could look like.