How to Build the Framework for a New Staff Process

A framework is the backbone for any request process. Here’s how to build one.

When you start getting overwhelmed by staff requests in your org, that’s a clue that it’s time for a new process.

A while ago, I shared tips on how to wrap your mind around creating a new process. We did some pre-work to understand the different types of requests we get, our requestors, and our own capacity.

But now it’s time to translate those notes into a living, breathing workflow. The first step? Coming up with a defining framework.

What’s your process framework?

According to Google, a framework is “a basic structure underlying a system, concept, or text.” The structure piece is what we’re after.

So let’s document how this process will work. What are all the things that need to happen? How long does each thing take? And who are the key players?

As a database admin, I’m frequently asked to export email lists. So that will be the example I use throughout the rest of this post.

Let’s sketch out our framework!

1. Start at the very 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.

Since my staff have a habit of asking for lists the day before they want to send an email 🙃 we’re going to build a comprehensive list request process. Starting at the very end.

Green dot for emphasis. Let’s start at the end, when the list is complete.

2. List each task that needs to happen along the way

Try moving backwards as you do this, to make sure you’re considering all the pieces. Include who’s responsible for each task and estimates for how long they take.

Also – be sure to add buffer to your time estimates. Just to be on the safe side.

I’ve started to add the key steps to my process framework.

Tip: Include communication tasks in your framework too. For example, a list request isn’t officially “complete” until I’ve sent my requestor an email with the link.

3. Add in those extraneous variables

In my role, most list requests are within my power to deliver! But if an ask goes beyond what I can query, I’ll ask our SQL expert for help – which prolongs the timeframe.

Think about all the plausible scenarios that can cause delays or bottlenecks to your process. Pay extra attention those steps that rely on other teams to deliver.

The pink box is the wild card in my process. So I’ve added an extra 5-14 days to my timeline.

4. Incorporate feedback loops

Some asks aren’t cut and dry from the start. For tasks where you need staff input at various points, include those points in your process.

If you’re drawing a blank on what those feedback loops might be, some ideas of where to look:

  • 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 & need direction
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 communication step (yellow) for sending those stats and making any necessary changes as a result.

You now have a process framework.

It may seem simple, but now you’ve got a framework you can build on! All that 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!

Share your thoughts!