Holistic Methodologies: Odd bed partners (Six Sigma and PMLC/SDLC), but Harmonious Relatives
Projects all have one thing in common: They all have customers or stakeholders that use some product of the project. It could be a report, feature, or an indirect enhancement to the primary business process they are actors within. Regardless of their role, the product has some impact on these customers or suppliers. It is important to note that some of these customers may also be suppliers. Customers and suppliers can also be external to the team or company.
Those of you who came up through old-school System Analysis and Design will be familiar with the use of IPO charts. In that case, much of this topic will be familiar to you, but with a new twist. Do you remember having to create IPO charts to map the data usage needed in your program to produce a given output? This tool just adds a human element and raises it up to the macro level of a project vs. an individual computer program when dealing with data attributes.
So what do SIPOC and COPIS stand for, and why are they different?
|S||Supplier||Who will supply the requirement / data or input content?||Name of person or team|
|I||Input||What is the input required to the process?||List of data or specifics of inputs required to enhance the Product / Process / Functional requirement / Test case prerequisites|
|P||Process/Product||What will be done with the input by the process / functional requirement||List of steps / functional requirements / test cases|
|O||Output||What will be the resulting output of the process / functional requirement||Report / Data / Functional requirement / Test case|
|C||Customer||Who will consume the output of the process / functional requirement||Name of person or team|
The fundamental difference between SIPOC and COPIS is order and perspective. Are you looking at the tool from a Customer or Supplier standpoint? If you have not already guessed, COPIS is just SIPOC in reverse, thus putting the Customer first.
Usage in Six Sigma DMAIC/DMADV
In Six Sigma SIPOC/COPIS is typically used in the Measure phase, and includes some additional considerations:
- Start and stop boundaries of the process
- Units of work, or process(es) the product interfaces with
- Opportunity, or characteristics you want to analyze or test (which could be cycle time or defects you are trying to resolve) along with the target for the improvement
- Defect /Error — Exceptions that result in not meeting the end result
These additional components may not be relevant to usage within the SDLC.
So why is SIPOC (or COPIS) needed?
When managing legacy systems some reports/outputs are created because of a request that may have been made many years ago. Often, no one has questioned who gets this output or if it is even used anymore. Features or functional requirements may be created based upon a need that may be either discrete (a one-off) or common to a group of customers, or that could impact customers in up- or downstream systems.
SIPOC/COPIS (for simplicity, we'll use just SIPOC from here on) gives you a framework to map all the Customers to their Outputs, which are created by the Process/Product and consequently mapped to the Inputs needed to make the Process/Product function, and finally identifying the Suppliers of those Inputs.
You can also think of a SIPOC as a hybrid between a Data Flow, Use Case diagrams, and a validation of who will consume the process/product output along with who will supply the needed input to make it work. When filled out, a SIPOC will provide a good cross check of the completeness of your requirements, data, and resources as well as the outputs.
A SIPOC is helpful to identify all the suppliers and customers when the functional/business requirements are coming from multiple sources or the impact of the product is broad reaching.
Anatomy of a SIPOC/COPIS
High Level example — you can also use this tool to get down to a field level if some of those contents come from separate suppliers.
If you start off with what the customer wants (COPIS), you can work back from what success looks like to the customer to identify the contents of the "black box" that will get you there. A SIPOC provides a functional decomposition of the components that go into writing a good business requirement or design specs and an appropriate test harness.
Another aspect of a SIPOC is to show interdependencies between requirements, since they may be mapped to a common set of inputs or outputs that come from different suppliers/customers. For example, when a given application interfaces with other upstream or downstream applications that are outside of the project team's control, who are the SMEs and what is being done with that data to transform it into something your customer needs?
From a project management standpoint, a SIPOC is also very helpful when used in conjunction with a Bull's Eye chart and Force Field analysis (topic of a future article) to make sure you have all your stakeholders and customers identified and categorized appropriately to assist in building your project or operational RACI (roles and responsibilities matrix). This will make sure you have the right people/resources lined up throughout your project and beyond.
Using a SIPOC within the SDLC
SIPOC can be used across all phases of the SDLC:
A SIPOC table will help identify who will be needed and what their role will be (Supplier or Customer of the output), as well as what will be needed from them to justify their requested involvement. Fill out the Supplier, Input, Output and Customer columns at a high level and then drill down through individual meetings if necessary to gain commitment.
In conjunction with your current requirements gathering, estimation, risk and issues management lifecycles, a SIPOC table can be used to validate the completeness of your requirements. It will also help identify SMEs who will assist with questions pertaining to the Input/Process-Product and Output.
There may also be new processes that have to be designed to operationalize the delivered product or process. SIPOC will also help with designing those supporting processes and may need to be part of the estimation/risk and issues management.
During execution, revisit your SIPOC analysis to make sure the customer is getting what they need. If there are requirements changes, SIPOC will also provide an enhanced view into their impact on the data flow.
Add the SIPOC table to the Operational documentation for the project. It can also be used as the basis for setting up Operational- or Service-Level Agreements at a Supplier and Customer level; for example, in order for the product to work the supplier has to provide given input by a specific date/time, or the resources that conduct the processing or operate the product have to provide a given output by a specific date/time to each customer.
Download a SIPOC template for running this analysis with your project team. (19kb .XLSX)