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.
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.
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.
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
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!