A while ago, I shared tips on how to build a staff process that people can actually follow. When you start getting overwhelmed with requests, a process is key to staying cool and organized.
In that first post, we did a lot of pre-work on figuring out the types of requests we get, who are our requestors, and our team’s capacity. (If you haven’t read that one yet, 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:
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. What needs to get done, what are the timeframes, and who are the major players?
Choose a request to hone in on and let’s start building a framework. I tend to get all our list requests whenever my org needs to a send an email, so that will be my example.
One quick thing before we begin
The real method to this madness is writing out your ideas. Pen & paper is easiest. Spreadsheets are also great.
For the sake of this post, I’m going to use Google Drawings (another great + free tool from the Google Suite of Products) to illustrate my 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.
Since my staff have a bad habit of asking for lists the day before they want to send an email (I knooow gang. I know), we’re going to create a list request process.
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 all the pieces.
Include estimates for how long each thing takes. You can factor in worst-case scenarios to be on the safe side, and name any specific people or teams responsible.
*Tip*: Don’t forget to incorporate communication to-dos in your plan! For example, I don’t consider a list request complete until I’ve sent my requestor an email with the list/s & recap of the criteria. (Paper trails like this are important, especially when you work in tech.)
Step 3: Add in those variables that are beyond your control.
In my role, 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 plan for. 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 impact metrics.
In many ways, this is what a process helps us overcome. So make sure you’re incorporating those curveballs, and adjust your timeframes accordingly.
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.
If you’re drawing a blank on what those feedback loops might be, here are some ideas of when you may 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
You now have a framework for your staff process!
It may seem simple, but you now have a framework for a staff process that you can build on! 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!