Designing the Collaboration Process
Collaboration processes are about making it as easy as possible for people to Ask for Help and to Offer to Help. This is an extension of 'work visibility' where the request for help is a work item and offering to help is a work item (remember: work is work). 
Design Considerations
Some questions to consider when designing an Intelligent Swarming Collaboration process:
- What is the scope of the collaboration?
- All the knowledge workers from the old tiers of support (Levels 1/2/3)?
- Product engineering teams (software development, hardware development, DevOps)?
- Engineering can gain many benefits by early visibility to relevant work.
- Other parts of the company or organization: Sales, Marketing, Human Resources, others?
- External resources: partners, community members, customers?
- When a knowledge worker needs help, how do they find the most relevant people to collaborate?
- When someone is able to help, how do we enable them to offer help?
- How do we capture what we are learning?
- How do we ensure that we are using, improving, and if it doesn't exist, creating knowledge?
- How do we recognize those who are good at collaboration?
When designing the collaboration process, scenarios (or user stories) can help in designing the triggers, expectations, and engagement. Below, we describe seven basic scenarios that are helpful as a starting point. The team of knowledge workers designing the processes will almost always come up with variations on these, or their own scenarios, based on the nature of the work they do.
The process is best designed by the people who will be collaborating: the knowledge workers. And, we should expect that we will iterate on the process as we get some experience with it.
It is always a question as to whether we should design the ideal collaboration process (without regard to current platform functionality) or design the process based on our current platform functionality. The goal of the design session is to define just enough to get started with our current functionality. The experience we gain by trying it - even if much of it is manual - will give us an informed view of what the ideal process would be. For more on this, see the Tools and Integration section.
Seven Process Scenarios
The following seven process scenarios have proven to be helpful when designing the Intelligent Swarming collaboration process. Think through these processes with the people who will be collaborating: how can we currently build a collaboration process around these scenarios? It can be helpful to separate these into synchronous (I need help in real time) and asynchronous (later is okay) processes.
- I need help (and I have searched the knowledge base)
- On a live call
- With a specific question
- I know who could answer it
- I need help
- On a live call
- With a specific question
- I don't know who could answer it
- I need help
- On a live call
- I have no idea about how to pursue resolution
- I need help
- In research mode (offline)
- I don't know who could help
- I see a request for help
- How do I know someone is asking for help in an area relevant to me?
- How do I respond?
- I see an incident (that someone else has taken ownership for) that I know the answer to.
- How do I find the incident?
- How do I offer help?
- How do I find or see open/available requests that are relevant to me?
These do not represent all of the potential scenarios, but they offer a good place to start a conversation with a design team.
Timing and Exception Handling
As can be seen in the seven collaboration scenarios, collaboration does not have to be real-time. In today's world of everyone being connected all the time, we are conditioned to expect an immediate response. This thinking severely limits the ability to tap into a global network of people with skills and competencies to help. There are situations where real-time knowledge sharing and help are required, but these situations are probably less frequent than we assume. How much of our work being done is 'live' with a customer? When designing our processes and leveraging technology, it is important to think about asynchronous collaboration and knowledge transfer.
Along with the timing, we need to think through the exceptions that will be encountered.
- What happens with requests for help that go unanswered?
- What happens when we have 'panic button' situations?
- What are the other exceptions we'll encounter in our environment?
We need to design for these, along with any other scenarios outside of our normal operating procedures.
Learning, Capturing Knowledge, and Sharing
As we mentioned earlier, knowledge is an important consideration in each scenario. Having the team identify the points in the process where knowledge practices play a role must be part of the process maps. When should we be searching and reusing knowledge, updating existing knowledge, and if it doesn't exist, creating knowledge articles? A simple, and perhaps obvious, example is that the process map for a knowledge worker requesting help should include searching the knowledge base before the request is made. It is critical that we capture - in the moment - what we learn as we collaborate. There is seldom time or motivation to update the knowledge base after the fact.
The collaboration in the swarm ends with a resolution that solves the issue of the requestor. If the swarming organization has already adopted KCS, it is a natural step to update or create a knowledge article as part of this process. If KCS has not been adopted, using, improving, or capturing knowledge as part of the collaboration process will need some special attention.
For an exceptionally complex, critical, or pervasive issue, an after action review (AAR) might be appropriate. In Agile terms, this is called a retrospective. This evaluation is done shortly after the swarm has solved the issue and before the swarm will be disbanded. Often facilitated by someone outside the team, the retrospective will look at the process of collaboration and outcome. How did it go? What can we learn for the next or similar situations? Did we collaborate too late, too soon? Did we engage the best resources available at the time? Do we need to improve the collaboration process or tools? The retrospective is not meant to assign blame, but rather to learn and improve.
In summary, to design the collaboration process:
- Identify your collaboration scope
- Define your collaboration use cases
- Document corner cases and exception handling
- List outcomes / success criteria
- Incorporate continuous improvement