The purpose of workflow design is to make sure sequential tasks are mapped out in a way that the process and its associated activities and assets move seamlessly from step to step.
Ironically, designing a workflow can have the opposite effect.
The reason why I think workflow changes are hard is because changes can threaten people’s sense of autonomy and mastery over their work. Changing workflows successfully requires much more effort in the beginning to understand current tasks, roles, challenges and needs.
It’s more than knowing how to create a good flowchart, and it’s certainly more than plugging in data into a workflow platform. It requires an open, in-depth, and consistent dialogue with the people who will live the change day in and day out.
How do I know this?
From a few big failures in workflow design.
Below, I’ll tell you about my experience in defining processes and doing workflow analysis in my projects. There’s lots of great lessons that I learned the hard way—listen up!
Workflow Design Lessons Learned
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
How I Learned The Hard Way About Workflow Design
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”, a personal philosophy learned through years of playing music. 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 new day can be more efficient, productive and rewarding than the last.
First, The Plan
Recently, I was hired on to a project team to smooth out their process of handing off projects from the 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 rest of the team.
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.
Then, The Problems
However, 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?
What if they enjoyed handling the interruptions and engaging in short impromptu meetings throughout the day?
Negative Punishment
The definition of negative punishment is to remove a positive stimulus. I now realize this is exactly what the process adjustment was doing: removing, or at least reducing, the requirement for the 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.
Regardless of improved efficiencies, these process adjustments were solely my idea and the team was not sufficiently consulted before implementation started.
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:
Get buy-in, dig for red flags, give your team time to give feedback—these should be part of your workflow design process, shown in the workflow diagram above.
On pondering the takeaways from this experience, here are more 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.
Related Articles:
- Workflow Apps To Organize Your Projects & Teams
- Workflow Diagram Software To Help Chart People & Processes
- Project Workflow Software
- Mavenlink Competitors And Alternatives