Ceptara

Summary

• Managing complex system development projects can be difficult, especially when there are both committed and shared resources.
• A SIPOC diagram is an effective tool for identifying all elements required for a process, but does not provide a useful tool to manage the process execution.
• By breaking a SIPOC into project phases, the SIPOC can be an effective project management tool.

What’s the problem?

Developers of complex systems sometimes require up to 18 months for releasing a new version of their product containing many features.  Using a phased approach developers can release product enhancements with fewer features every 6 months or so. Managing critical shared resources along with committed resources for each release can become a challenge. Consider the following example.

A product requires a computer platform from a 3rd party supplier, which will be integrated with application software developed in house.  The product development organization might look like the following:

In this example, the Customer, Program Manager, Third Party Supplier, Third Party Supplier Manager, and Product Manager can all be considered multi-tasked resources; in other words they are involved in each product release.  Contrast this with the committed resources for each product release, which includes dedicated Release Managers, Development Teams, Integration Teams, and Final Test Teams.

A SIPOC diagram can be used to define the high level process for the requirements definition phase of product development as follows:

In this very simplistic example, the Customer “supplies” the release requirements as the “Input”.  A standard “Process” is used to develop a system design resulting in platform requirements and application requirements as “outputs” to the third party supplier and development team “Customers”.

In this very simplistic example, the Customer “supplies” the release requirements as the “Input”.  A standard “Process” is used to develop a system design resulting in platform requirements and application requirements as “outputs” to the third party supplier and development team “Customers”.

In my experience SIPOC diagrams typically show all customer, inputs, processes, outputs and customers into a single chart.  This is fine to show the 30,000’ view, but how can this tool be used to help manage a project?  At Motorola we documented a process for managing 3rd party suppliers using SIPOC diagrams.  The innovation was to break the process down by product development phase.

Consider the following expanded SIPOC diagram that defines the process for the entire release.

Here the committed resources are identified by the orange shaded blocks, and the multi-tasked resources are identified by the blue blocks. The Release Manager “owns” the SIPOC for the entire release and uses it to manage the entire release.  The SIPOC is an excel spreadsheet containing hyperlinks to appropriate artifacts.  For example, the processes are standard and documented in a process database.  The inputs and outputs are the work products and also contained in a database.  The suppliers and customers may also contain relevant artifacts, such as the team organization, etc.

During a program review all projects can be effectively conducted by referring to the contents of each of the SIPOCS.  The example below shows how Release N test phase, Release N+1 development phase, and Release N+2 requirements phase.

SIPOC diagrams are an effective way to identify all of the key elements of a process, but do not provide a useful tool to manage projects.  Phased SIPOCs is a way to use this tool to manage complex projects.