Recurring Activity Matrix: Write Down what your Team Actually Does

Scott Adams, the creator Dilbert, has written about how systems are much more valuable than goals.  This concept is incredibly powerful, and there are great, large, complex frameworks for defining and enhancing systems that people and organizations use and manage.  Frameworks like ITIL and CMMI do a great job of helping organizations think through all the various aspects of defining process architecture and governance.

However, they’ve often big, intimidating frameworks for a small team looking to become more mature.  Something I’ve found a lot of success with is starting with creating a Recurring Activity Matrix (RAM) for teams to write down all the stuff they do more than once, so they can publish a body of knowledge, which helps them be more efficient, collaborate with each more easily, and bring new people onto the team quicker.

I start small with teams, building a simple table with these columns in a wiki platform (e.g. Atlassian Confluence):

  • Team – specify the team (if this group has more than 1 team) that does this work
  • Owner (Role) – specify the role (not the person’s name) who performs this work
  • Recurring Activity – name the actual activity performed (e.g. “Check that the Website is Still Working”)
  • Frequency – e.g. Weekly on Fridays at 3pm
  • Link to Procedure/Checklist – provide a link to another wiki page with the details of what is actually performed (this can start pretty small, but eventually the goal should be that someone with little to no experience in this area could use this list to perform the activity)

Teams usually populate this data initially with a very small list, with early versions having the owner as someone’s job title. But as team’s mature, they start to identify a lot of items that go in this table, and start to break up roles more, so they’re not directly tied to job titles (Holacracy has a great concept related to this called Role vs. Soul).

As teams advance in this, I like to keep building on this — ideas like:

  • Automate the reminding and tracking of these actions, such as using recurring calendar reminders, or emails from SendRecurring.com to the person to reminder them, or (if you really want to show off) an email from SendRecurring.com to a Jira Service Desk instance to create a Jira ticket and assign it to the right person to do the work (and track if they completed it)
  • Use daily standup meetings or other sync-up meetings to identify tasks that are occurring that aren’t tracked in the RAM (or when someone takes a vacation and no one can figure out how to do something)
  • Separate Process Owner, Process Manager, and Practitioner roles (see ITIL process roles)

Eventually organizations as they scale will want more complex process management, looking at things like an ITIL Service Catalog or CMMI Organizational Process Definition; but early on the real value is just writing something down and incrementally improving it.

This is great, short article about how 1-800-GOT-JUNK wrote down their key processes, published it in a binder, and used it to rapidly scale a huge franchise business across the country.

One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s