Process mapping with SIPOC in Jira

Implementing a new computer system

Whenever you’re implementing a new computer system or having an old one updated, your goal is finding how to best support your processes. For example, a document management system facilitates the process of authoring and approving documents while a service desk application streamlines the process of receiving and handling support requests.

Before embarking on any project that involves implementing a new computer system or updating an existing one, it’s important to have a clear model of the process it will support. This is why process mapping exercises are critical. It gives you the opportunity to gather input from all stakeholders and align everyone around a common goal.

Introducing Jira SIPOC

The end result of the process mapping exercise is a written description of one or more processes, and today we’re going to introduce you to just such a process: the SIPOC. The SIPOC (Supplier, Input, Process, Output, Customer) is a Six Sigma tool and a common method for describing processes.

Putting Jira SIPOC in practise

1. Each process step can be mapped to a Jira status, such as In Progress and In Review, the statuses at which the Jira issues changes hands and undergoes review.
2. The “change of hands” expressed by supplier/customer is basically the handover of process between various assignees.
3.  The data expressed in input/output are the custom fields we need to have in a Jira issue: also highlighting any points where data is “required” as opposed to optional.
4. Decision points represent fork and variations in the process.

Let’s give an example of how SIPOC could be implemented into the process of signing off on a Jira issue. The Jira issue is an assignment to create a new article: “How Advances in Toothbrush Handles Improve Oral Health.” The assignee tasked with project completion is the author, doing the creative work of drafting the article. Once they’re done with their first draft on their toothbrush article, the issue changes status from In Progress to In Review. Now the issue is placed in the hands of a reviewer. The reviewer examines the document through. They provide feedback and send it back to the author, who quickly revises the article and sends it back. Satisfied, the reviewer sends it down the chain, either to the next reviewer or to the quality assurance team member. If all reviewers are satisfied with the article, its status is changed to Done and can be published.

Some key ideas for successful SIPOC modelling and Jira configurations

1. Structure vs. rigidity. It’s all about balance. Do not be too prescriptive -> use the changing of actors as a hint as to how to break the process into steps/statuses. Always try to start with rough lines and try to get more granular only if needed.
2. In Jira there is always a single assignee: that is a principle of accountability. However in the modelling of the process refer to “teams” – that will give you the idea about which project roles you need to have and how to set up permissions. For example, during “QA Review” only persons in the QA role can be assigned. 
3. Terminology. Use generic terminology that can be used across business processes. “In Review” is better then “In Article Review.”

Hopefully this article can provide some guidance on how the SIPOC process can help smooth your creation process and help you catch mistakes. It’s worth taking the extra time to establish a quality assurance process with multiple overseers.