How to Build a RIM Playbook Part 6 - Drafting the Individual Plays

Now it's time to use the tool(s) we identified to start drafting the individual plays. As you get started, you'll need to make some decisions regarding the granularity of your plays. For example, do you have separate plays for sending boxes to offsite storage and retrieving them, or do you have one single play for "manage records stored offsite"? My recommendation is to err on the side of more granularity - two separate plays in this instance - because the different "sub-plays" may have different cadences and be executed by different roles. 

Each play should contain the following elements. Most of these elements will come directly from the resources and references for each play; if not, check with the people you think are involved in a particular play, especially the ones you think would be responsible or accountable. 

I find that the average play, including all of the listed elements and using the high-level description + links to references approach, is one to two pages long. 

Title. This is the name of the play, and should be phrased as a task, e.g., "Review and update the retention schedule" or "Send boxes to offsite storage." 

Purpose. Why are you executing this play? What is the benefit to the program (and ultimately to the organization)?  

Description. Depending on which tool(s) you're using, this could be either a high-level description, with links to the actual procedure, flowcharts, etc., or it could be the procedure itself. I generally recommend the former approach to my clients since most of them use Microsoft Word for their playbooks, but a LMS, knowledge base, or intranet platform could conceivably support the latter. 

Roles & responsibilities. I use a RACI (responsible, accountable, consult, inform) chart to list the key players at a glance. Details about the roles involved with a particular play and their responsibilities are included in the Description narrative. 

Cadence. This should address frequency - and schedule where applicable. Some plays are monthly, others are annual, and each might take place at a certain time during the month or year to leverage, or avoid, other things going on in the organization. For example, while reviewing and updating the records retention schedule is important, it's probably better to schedule it when it won't conflict with month, quarter, or year-end, or tax season. 

Plays that are run on an as-needed basis, such as placing or lifting a legal hold, can be listed as just that, "as-needed" or "upon request". 

As a reminder, if a task or activity is only conducted every few years - for example, defining business requirements for a replacement recordkeeping solution - I'd argue that's not a play, it's a project. It's still important to document somewhere, but the playbook should focus on the plays that are routinely executed. 

Resources and references. These should include all of the things required to complete a particular play, including but not limited to policies; flowcharts; procedures; job aids; glossaries; lists of acronyms or abbreviations; templates; style guides; and more. Resources should be hyperlinks, and should include a version, date, or both. 

Throughout this series I've tried to make the case that one of the most valuable outcomes from developing a playbook is consolidating all the references into a single location or access point; the more time spent on this aspect of each play, the more useful the playbook will be. 

At the same time, we noted in Part 4 that some of these references may be out of date. The question then becomes, is it better to list them, knowing that they are out of date, or not, leaving gaps in the documentation? There's a third way, which is to quickly capture what *is* being done at present, and include that in the list of resources and references. Once you have the chance to flesh out the new procedure, reference, etc. and get it approved and published, you can update the playbook to reflect that. It might also be helpful to make a reference to the outdated resource and the status of the draft replacement, perhaps as a footnote. 

Metrics. You can't manage what you don't measure. At the same time, just because something is measurable and measured doesn't mean that that's a good metric to track. It's important to ensure that the metrics tell a story that aligns to the overall goals of the program. 

Metrics can also indicate that a particular play has been executed and indicate volumes, times, etc. 

Contact information. For most playbooks, the contact information for a given play will be the same person, role, or service account, e.g., recordsmgmt@somecompany.com. But there may be some plays that have a different primary point of contact; this is especially true for playbooks with a broader scope. 

Here's an example of an actual play. 

In the next installment, we'll talk about the process for reviewing the draft plays, particularly with those roles responsible and accountable for their execution. 

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.