Workflow Design: Process, Example & Learnings
The purpose of workflow design is to make sure sequential tasks are mapped out in a way that the process and its associated activities move seamlessly.
Ironically, designing a workflow can have the opposite effect.
It’s more than knowing how to create a good flowchart, and it’s certainly more than plugging in data into a workflow platform. I've had a few big failures in workflow design, so in this article I outline what you should (and shouldn't) do.
What is Workflow Design?
Workflow design is part of workflow management, and it's the business process of mapping out your most frequent, important tasks and processes so they flow efficiently and effectively from one stage of a project to the next.
In my case study at the bottom of this article, I outline how I was hired on to a project team to smooth out the process of handing off projects from the design to the development team. This is one example of workflow design.
How To Design a Workflow
It's been reported that good workflow design can help improve operating efficiencies by more than 83%. Here's how to design a workflow, step-by-step:
- Define Objective and Scope: Identify the goal and outline your tasks.
- Analyze Current Processes: Review existing methods, identify inefficiencies, and determine your resources.
- Design the Workflow: Map out the new process with a workflow diagram, detailing steps and assigning roles.
- Develop and Test: Create a prototype, test it on a small scale, and refine based on feedback.
- Implement and Monitor: Roll out the workflow fully and continuously monitor for improvements, automation, or necessary changes.
Effective Workflow Design Practices
Before I share my tips and best practices, it's important to understand the three essential elements of good workflow design. These are:
| Input | the resources, data, or materials required to start a workflow. |
| Transformation | the actions applied to the inputs to change or convert them. |
| Output | the results or products that come out of the transformation. |
Here are some best practices with this in mind:
- Set Clear Objectives: Clearly define the goals and outcomes expected from the workflow. This ensures alignment and a clear direction.
- Simplify Processes: Strive for a simple workflow design. Break down complex tasks into manageable steps and eliminate unnecessary bits.
- Assign Clear Roles and Responsibilities: Clearly define who is responsible for each step. This clarity ensures accountability and smooth execution.
- Leverage Technology: Utilize appropriate tools and integrations for automation, communication, and tracking. This can significantly improve efficiency, accuracy, and ease of workflow management.
- Test and Refine: Implement the workflow on a small scale first to gather feedback. Use this to refine and improve before full-scale implementation.
Real-Life Lesson Learned in Workflow Design: A Case Study
Here’s my story about a failed attempt at implementing change.
First, you should know that I’m not an overly enthusiastic person. I’m an optimist and with experience I am becoming more of a realist. I’m a fan of “less is more”, I have a background in front-end development, love UX and strive to produce solutions that focus on simplicity.
I’m passionate about workflow efficiency, organization and helping facilitate others to find and maintain an optimal momentum in their work. I believe through personal discovery, a foundation of trust, and a willingness to modify one’s processes, every day can be more efficient, productive and rewarding.
Background
As I mentioned earlier, I was recently hired on to a project team to smooth out their process of handing off projects from design to the development team.
After observing their existing workflow, I noticed many functional requirements were being lost during the hand-off or never identified prior to it. Additionally, requirements were not logged anywhere and were not accessible to the team—requirement details were primarily being communicated verbally between the project managers and the team.
The Plan
My strategy was to increase the reliance on the project board, and Slack, for listing project requirements and maintaining a record of discussion.
I proposed a workflow design like this:
My strategy was to increase the reliance on the project board, and Slack, for listing project requirements and maintaining a record of discussion.
An added benefit would be the reduction in the number of interruptions between team members throughout the day.
The project board would serve as a highly visible, single source of truth for project requirements while Slack would serve as a ledger of discussion to support it.
Implementation and Challenges
Unfortunately, I was blind to the fact that the people affected by the changes, primarily the PMs, weren’t buying in. Sure, the executive team was on board and the developers were too but my fellow PMs were not.
In fact, I realized that I was punishing, not helping, my team.
As we moved ahead adding more information to the project board, and discussions to the Slack channels, it was clear the PM team was spending more time writing tickets and channel updates. Sure, interruptions were reduced, but was this a good thing?
As I analyzed this problem, it led me to wonder. What if they enjoyed handling the interruptions and engaging in impromptu meetings throughout the day?
Analysis of Failures
Negative Punishment
The definition of negative punishment is to remove a positive stimulus. I now realize this is exactly what the adjustment was doing: removing, or at least reducing, the requirement for PMs to verbally communicate with the team.
Positive Punishment
What if the team detested writing project tickets and hated Slack? That would mean this new process step was imposing on their sense of autonomy. The definition of positive punishment is the addition of a negative stimulus, and again this was the result of my imposed changes.
What I Learned
Regardless of improved efficiencies, these process adjustments were my idea and the team was not sufficiently consulted before implementation started.
I’m learning that strategy and best practices can not be immediately applied to workflow processes (which involve people) in the same way they can be applied to code or other static mediums.
A team culture is rich with personalities, perspectives and opinions—to maintain a healthy culture containing mutual respect among its members, everyone needs to be engaged, understood and considered.
Here is a short list of my takeaways before we dive in to my stories:
- Executive buy-in does not equal team buy-in
- Even positive process adjustments can feel like punishments
- Workflows should fit the team culture, not just standard best practices
- Don’t trust the feedback you get—dig deeper for red flags
Key Takeaways on Designing Workflows
In this attempt, I learned a little bit about how to design workflows, but I learned much more about how to design a process of change at work. How to get buy-in. How to uncover underlying risk and assumptions early, and how to incorporate them into a new workflow implementation.
Here’s a workflow diagram to sum up my recommendations for anyone who’s changing a process or implementing a new workflow in your organization:
On the takeaways from this experience, here are my thoughts on each one:
1. Executive buy-in does not equal team buy-in
It’s the team members whose work day was affected by the process adjustment. Team members need to be consulted and given an opportunity to question, challenge and provide feedback on any process changes.
A “lead by example” approach might work if the process is being introduced by the executive team, and buy-in is inferred, but if all team members truly have an equal voice then everyone should be given time to consider the proposed changes and an opportunity to provide input on them.
2. Even positive process adjustments can feel like punishments
A change in process infers an elimination of existing steps that others likely identify with or may enjoy.
Adjustments may be designed to increase efficiency but without adequate discussion and time for the team to challenge them, the benefits of such efficiencies may not be understood and the team may be left feeling like they’re being punished.
3. Workflows should fit the team culture, not just standard best practices
Inquire to learn the value of the existing workflow steps before judging and suggesting new ones. Ask yourself and the team members what attributes or historical factors you may be overlooking. Inquire to them on which ones they feel add value and why.
Perhaps only a fraction of the new “best practice” initiatives are a fit for the current culture, or perhaps none at all.
4. Don’t trust the feedback you get—dig deeper for red flags
I’ve learned that a verbal check-in or a voluntary acceptance check with the team is not sufficient. Everyone needs an opportunity to be consulted and provide feedback. The team must be given time to consider the proposed changes and arrive at their own conclusions, followed by time to review, question and challenge the new ideas for the workflow
What’s Your Experience Defining Processes?
What do you think is the best way to create workflows that really work? Do you have any workflow tools or techniques that worked well?
Share them with The Digital Project Manager community in the comments below. While you're here, check out our membership opportunities for more!