How to Build a Process Framework (Pt 1)

A while ago, I shared tips on how to build a staff process that people can actually follow. Because when you start getting overwhelmed with requests, a process is key to staying cool and organized.

We did the first step of clarifying how these requests play out in our orgs today. We’ve got notes on everything that matters: the types of requests we get, the needs of our requestors and our own team’s capacity. (If you haven’t read that first post, you’ll want to start here.)

Now that that’s done, we need to translate those points into a living, breathing process. That’s a big leap, especially when you’re not used to doing it!

But building a process is a process in and of itself. And you’ll see success by sussing out 3 specific things:
1. The framework for your process
2. Your intake & feedback mechanisms
3. Your accountability system

1. The framework for your process
2. Your intake & feedback mechanisms
3. Your accountability system

This post will be part of a series for the next few weeks on how to build effective processes for your staff. Be sure to subscribe to know when those other posts are out!

What’s your process framework?

Google the definition of framework and this is what you get: “a basic structure underlying a system, concept, or text.”

Structure is what we’re after. Before implementing anything, we need to understand (and document!) how this process will work behind-the-scenes. What are the buckets of tasks that need to get done, what are the time frames, and who are the major players?

Choose a request type to hone in on, and let’s start building a framework.

One quick thing before we begin…

There’s a method to this madness, and that’s sketching your ideas on paper – or whatever medium you choose. Ultimately the transfer should look like this: from brain, to doc, to real world.

Pen & paper is easiest. Spreadsheets are also great. But for the sake of readability, I’m going to use Google Drawings (another great + free tool from the Google Suite of Products) to illustrate my very simple example.

Step 1: Start at the end of your process.

Once you’ve picked a process to hone in on, jump to the end – the point where a request has been delivered and everything is done.

My staff have a habit of asking me for lists the day before they want to send an email. (I knooow gang. I know.) So for this example, we’re building a request process for email lists – something I may very well formalize in the near future!

Green dot for emphasis. We’re starting this baby at the end.

Step 2: List every task that needs to happen along the way. Include how long each step takes.

Try moving backwards as you do this, to make sure you’re considering each task. We tend to forget those last-minute things towards the end!

Include ranges for how long each item will take. You can factor in worst-case scenarios to be on the safe side, and name any specific people or teams responsible.

Hint: don’t forget to add those communication to-do’s in your plan too, ones you may have noted in the exercise from the last post. In my case, a list request isn’t complete until I’ve sent an email with the attachments and a summary of those list requirements. (Paper trails like this are important, especially when you work in tech.)

Whoa, where’d all these steps come from?!

Step 3: Throw in those variables that are beyond your control.

As the Systems Manager for my org, most list requests are within my power to deliver! But occasionally I’ll get an ask that goes beyond my querying abilities, and need to ask our data scientist for help.

Those situations are what you want to incorporate. Are there individuals or teams who can cause a bottleneck at any point in the process? Maybe you need IT’s help accessing your database, or need to wait on the Program team to give you their impact metrics. You noted some of these hold-ups in the last exercise, so now’s your chance to include them.

In many ways, this is what a process helps us overcome. So make sure you’re incorporating those curveballs, and adjust your timeframes accordingly.

The pink box is my wild card in our process. Because of it, I’ve added a few extra days to my timeline.

Step 4: Incorporate feedback loops with your requestors.

For some tasks, we may need staff input along the way. Identify those feedback points in your process diagram!

If no feedback loops are coming to mind, it’s most likely because they’re just not coming to mind – and not because you don’t have them! So, if you’re drawing a blank, here are some ideas of where you might need staff input:

  • The beginning of a process , when you need to confirm or document your deliverables
  • The end, when you confirm that what you’ve given them works
  • Any points where things tend to change unexpectedly
  • Any points where you’re bound to reach a fork, and need direction
  • For processes involving written work – each round of draft revisions
My team likes to confirm the number of recipients in a list before they commit to using it. So in my sketch, I’ve added a feedback loop for sending those stats and making any necessary changes as a result.

You now have a framework for your staff process!

It’s a simple exercise, but powerful – because you now have a framework that your process can sit on and be built further upon. Transfer that documentation into a format that your team can easily reference, and be proud! Because all this work is going to make this next part much easier.

p.s – This post is one in a 3-part series. Now that you’ve read part 1, move on to part 2!

Liked what you read? Spread the word!

Share your thoughts!