Previous chapters covered workflow, projects, personal tasks, checklists, and repositories. These are the building blocks of your workflow. They can be mixed and matched to fit your needs and structure your team’s work.
At times, however, workflows or projects in a structure may require an additional workflow or, essentially, have a workflow(s) within a workflow.
We call this the Hub and Spoke Model. One or more boards serve as the hub and additional boards serve as spokes connected to the hub.
Each spoke of the hub can represent a related (or completely separate) process that tasks need to flow through. You can have as many spokes as you need to fully build out your workflow.
The unique aspect of the Hub & Spoke Model is that tasks never leave the hub. In Rindle, Mirrors paired with Automations make the Hub and Spoke Model possible. A task can live on many different boards in many different workflows at the same time, using Mirrors. This allows for parallel workflows. While the task sits in a step within the “hub” board, it can also be on another board moving through a completely separate workflow.
Using this model provides endless flexibility when it comes to more complex processes and workflows.
Let’s take a look at some examples.
Delegating Work to Teams
Let’s say you typically have 20 active projects at a given time, and you have three different teams helping you complete these projects:
- Implementation Team
- Creative Team
- Quality-Control Team
In a traditional environment, the people on those teams have to jump between 20 different projects to try and understand which work applies to them individually. The same goes for the manager of those teams. They have to jump around all over the place to see the workload of each team and team member.
The Hub & Spoke Model solves this by allowing you to delegate work to the teams so each team can see their entire workload across all 20 projects in one place. So instead of just 20 project boards, you would have a board for each team.
In this case, the projects are the hub, and the team boards are the spokes. The tasks can now live in two different workflows, like this:
Now, the implementation team can manage all of their team’s tasks in their own workflow without any duplicate data entry or copy and pasting. All of the data inside the task stays in sync with the hub, in real time. This allows the project manager to see any updates that the implementation team makes to the task without leaving the project board and vise versa.
Within your workflow, you may have a step that has enough steps of its own to justify a sub workflow. The Hub & Spoke Model can be used to create streamlined sub workflows.
Let’s take the screen printing process of an apparel manufacturer as an example:
However, imagine that the ‘Approve Artwork’ step has the following sub workflow:
In this example, the Print Production board is the hub and the Artwork Approval board is the spoke.
When the job gets to the Approve Artwork step, the task is then moved or mirrored to the Artwork Approval board in the Creative Director Approval list, and the Creative Director is notified.
Once the task completes the Artwork Approval workflow, it will then continue to the next step in the Print Production workflow.
As you can imagine, if your workflows had many sub workflows like in the above example, you could simply add more spokes from the hub.
In our recommended Baseline Workflow, we have a step called “Blocked.” When a task that you’re working on is blocked and cannot proceed forward, you move it to the Blocked list and add a comment with the details of why it’s blocked. This lets everyone on the board see any tasks that are not moving forward as planned.
This works great on a board-by-board basis. But if you have a team of managers that help resolve blocked issues, you may want the blocked tasks to flow through a separate workflow.
The Hub & Spoke Model solves this by allowing managers to field all blocked escalations from every board and organize them through a custom workflow. So, in addition to the team boards/spokes, you may have a board/spoke like the following:
- Blocked Tasks
For this use case, the projects would be the hub, and the Blocked Tasks board would be an additional spoke. The task can now live in two different workflows like this:
Now the management team can manage all of the blocked tasks in their own workflow without any duplicate data entry or copy and pasting. All of the data inside the task stays in real-time sync with the hub. This allows the project manager to see any updates that the management team makes to the task without leaving the project board and vise versa.