The 7 Key Attributes of a Workflow Automation Project
By Mike Raia Posted September 14, 2015
Alignment with organizational goals and policies
This is probably a given, but any workflow automation project should be born out of the goals of an organization and designed to follow the instituted policies. Often workflow automation is brought in because the organizational goal is to improve efficiency or internal customer service. The project should adhere to those goals and be consistently described in those terms. This goes a long way toward positive internal PR for the project and helps ensure executive and stakeholder buy-in.
Buy-in and involvement from all department stakeholders
Speaking of buy-in, here are the primary stakeholders to consider for a workflow project. The more buy-in you can generate in the early stages of the project, the less you will have to manage change at the end of the project.
- Workflow Administrators: Building and editing workflows, translating business requirements into a workflow solutions, creating reports, designing the end-user experience.
- End-Users: Initiating workflows, acting on tasks that are assigned to them from the workflow (indicating approval or rejection, entering data on a form, viewing and creating reports.
- Executives: Viewing reports generated from the workflow data to analyze status and trends
A documented walk-through of the current process and future state
Before you start looking at how your workflow will operate within your workflow software, walk-through the entire process with the people involved and document it as it is. Then discuss and document how you want it to be, where bottlenecks are, etc. This is the most critical step in the project. Having a well-defined future state will help drive the granular requirements needed to develop the solution.
A business and technical plan for integration with existing business systems
It's critical to understand both the "which" and the "how" of your integration plan. Which systems are currently housing data involved in the process and which systems need to be fed data? How will this data be retrieved and then pushed where it needs to go? In some cases the "system" housing the data is simply a shared spreadsheet and in other cases it's a massive ERP system. How will the workflow connect and retrieve this data? It's also a good time to consider what other systems might benefit from integration with the workflow that aren't currently involved. In larger organizations, it’s important to requesting permission (even if it’s read only) to these other systems as early as possible in the development life-cycle.
Documentation of what will be measured and how it will be reported (and to whom)
These should be aligned with the organization's goals and values of course. Some workflows will be mission critical and provide a majority of the overall value in terms of ROI and efficiency. Some workflows will be helpful and necessary but less valuable than others. Regardless, all workflows should be measured and the results communicated by role. For instance frontline managers should have access to all reporting metrics and should communicate them to their teams as they see fit. Meanwhile, executives should have access to top line metrics for ongoing business review.
Piloting early and often
One of the biggest mistakes we see is not getting feedback early in the development life-cycle. Even if the entire solution is not completed, attempt to engage your end-users early in the process so they can provide feedback. This will help you identify issues/requirements you may have missed and make you users feel like they are involved in the implementing the change. A rigorous testing plan is essential
Before anything is built in your workflow tool, walk-through several scenarios, including rare and unlikely scenarios that will result in exceptions. Most exceptions will be manageable but you should know them before you start building the logic and rules that will become the foundation for your workflow. Once the automation is built you'll obviously want to test it through the entire process, including those potential exceptions. Recruit testers you can count on to take the project seriously and will be responsive. You'll have to call in a few favors or offer a gift but it will be well worth it.
A thoughtful roll-out and training plan
People will fight the change you're implementing, that's just how we are. Be prepared to train and train again. Don't roll out everything all at once. Add workflows with a light touch and let people get used to the new way. The benefits may be obvious to you but most people will believe it when they see it. Too much change at once will distract people from their day-to-day and may cause resentment.