This week, I am posting five lessons I've learned while designing and consulting on content-related workflows. The third of these five: "If you're mapping workflows, start by clearly identifying the functions involved (what are often referred to as 'swim lanes')."
Almost every workflow improvement project relies on some sort of visual documentation. Often, these process maps are created to capture every step in a content workflow. That's admirable, but it can sidestep three important considerations.
The first is, "Who is doing the work, and what happens when they are done?" As noted yesterday, workflows with multiple handoffs challenge both quality and speed.
The second thing to ask is, "Does work ever come back?" Documenting parts of the process that identify and address re-work is the first step toward reclaiming workflow capacity.
The final consideration is, "When does this work occur?" Without including a timeline, process steps all look more or less the same. But changes late in a project have a much bigger impact, often at a point that leaves little time for response.
To help answer these questions, I lay out a timeline on the x-axis (moving from left to right) and identify process 'actors', typically departments or individuals, on the y-axis (moving from top to bottom). There's no magic to using those axes; they just work well for me.
Between each of the departments or individuals named on the left, I extend dotted lines from left to right – the 'swim lanes' – and use those as boundaries for handoffs between actors. This approach helps make the the impact of rework explicit.
Typically, a lot more happens on the far right, toward the end of a workflow, than at the far left. To help understand the viability of a documented process, it's important to maintain at least a rough sense of scale in creating process maps.
If that's not possible, I sometimes use a second map focused on a small portion of the overall timeline. The scale changes, but the breakout map allows detail that might otherwise be sacrificed.
Sometimes, developing a comprehensive picture of prevailing workflow becomes a big project. An effective process map should do at least two things: inform all functions about their roles as part of a whole; and give those involved a tool to plan changes that meet business objectives.
Business objectives vary, but it always helps to look at an existing process and ask "Why do we do this?" An alternate version of the question might be "How does this activity add value or help us meet our goals?" Keep in mind that process maps are a tool, not the explanation.
Tomorrow, I'll post about the value of changing processes to take advantage of software design, more than the opposite.
