Process Improvement Essentials: CMMI, Six SIGMA, and ISO 9001

3.7. Developing Process Program Components

This step represents the bulk of the work you'll undertake in creating your quality program. As its name suggests, this cycle is an iterative process. But it begins with a period of extended observation, questioning, and knowledge acquisition. The objective here is to learn the business. You and your team will be working to build standards, processes, and procedures to improve the business, but this can't be undertaken in a vacuum. You need to first learn how activities are being conducted, delve as deeply as you can into the rationale behind the activities, and then evaluate them for improvement opportunities.

3.7.1. Engage Relevant Work Groups

I find that a SWOT analysis is usually helpful here. SWOT stands for Strengths, Weaknesses, Opportunities, and Threats. Just about any business strategy, situation, or activity can benefit from a SWOT analysis. In this case, you and your team look for what strengths lay in the current processesthat is, what is working well in terms of management, accountability, and control. Next you identify what appears to be working less well: what might be only partially fulfilling its purpose, what might be lacking structure, what might be missing altogether. Then you can analyze these strengths and weaknesses. You look and determine where you see potential opportunities for improvement. This may become clear with weaknesses, but bear in mind that you can make improvements to strengths, too. It's helpful to list these opportunities, and even prioritize them a number of ways: perhaps by difficulty or effort, perhaps by business criticality, maybe by organizational impact.

Once you have identified opportunities for improvement, you can then assign threats. You can think of a threat as a potential cost to the organization should the opportunity not be addressed. There can be all kinds of threats: internal and external. Some inside threats might be impaired communications, risk of data loss, misalignment, increased costs, or extended correction time. External threats might be regulatory fines, potential loss of market share, or reduced customer satisfaction.

By thoroughly analyzing targeted business practices with SWOT, your team and the partner groups will acquire a common understanding of the current structure of the organization, which is a good foundation for moving on to improvements. You can now work with the groups to identify areas to work on. You'll probably have plenty to choose from, so you'll need to facilitate this step carefully. It's generally a good idea to select processes that will strengthen the groups that helped you uncover them. At the same time, you need to weigh the overall needs of the organization. Once you've selected processes to work on, your team can begin design activities.

This is not yet the time to formulate the entire solution. Here is where the cycle begins to turn. In your first design effort, keep the solution at a somewhat high level. Then take this back to your partner groups for review, feedback, and maybe even a tryout. Then take their input and drive the solution to a deeper level. Depending on the business activity and the process you are defining, this cycle might go through several iterations. The key, however, is to develop it in manageable steps, ensuring that you, your team, and the partner groups remain in sync, with a common understanding, each step of the way. The resulting solution should be one that you are comfortable with, one that addresses a specific business need, and one that can exist in harmony with other related business activities.

Follow the observation-design cycle until you have created acceptable trial processes for each of the targeted business activities.

3.7.2. Build from the Inside

A "collaborative design" approach works best for creating a process program within an organization. This approach is particularly effective when an organization is already following loose or undocumented processes, or has a fixed business path already set into place. The collaborative nature of the approach requires two teams working in tandem along a six-step axis of activity.

The first team is made up of selected organizational stakeholders. These stakeholders are those people within the organization that possess depth of knowledge concerning business activities, contracts, clients, applications, and other elements that may be impacted by process management. Often these people are called SMEs: subject matter experts. They should be selected as design contacts based on three criteria:

• They need to have the business knowledge required to direct and shape processes designed along effective and proper lines.

• They need to be available to the process team during the design process. If they can only dedicate a limited amount of attention to the effort, or they are susceptible to being pulled away at any given time, it might be best to select someone else.

• Finally, they need to have some appreciation of process. Ideally, they will embrace the idea of process and want to work to establish it within their teams.

Carefully consider the stakeholders you select to participate in the design process. They will have considerable impact on the success of this effort.

The second team is made up of process design consultants: usually the members of your process team. This team consists of process professionals who have deep familiarity with the structure, requirements, and recommendations embedded in your process model. These members will work with the appointed stakeholders to design, document, and validate the process and artifact components of the new program. Together, these people will work to design the program components using a collaborative approach.

The six-step collaborative design approach includes the following:

Identification

The process team consultants (PTCs) work with the subject matter experts (SMEs) to identify the inventory of elements needed to be pulled, formalized, created, or adapted in order to realize a fully compliant business process program. This is accomplished through formal and informal discussions and work sessions. The baseline for these discussions is the focus of your process program. Using this framework (perhaps based on ISO 9001, CMMI, or Six Sigma), you begin to target those processes, procedures, and artifacts that the complete program will need.

Elicitation

PTCs then work with the SMEs to design and develop the templates, processes, forms, and artifacts required to support the program. The emphasis at this step is on tracing the current flow of business activity, examining and reusing existing business support materials, and reviewing descriptions of activities already in place in the organization. These elicitation activities seek first to use what exists, incorporating things into the program that give it familiarity. Once the value of existing materials has been identified, the two teams can work to identify missing elements that will need to be jointly created to fill the model.

Documentation

The PTCs and SMEs will work together to document the processes and artifacts that represent the process program, establish a central repository to house and control these elements, and then prepare the components for organizational review. This activity probably represents the bulk of observation-design work. It is very much a shared activity, and very much iterative in nature. It is typically carried out as a series of short work cycles: gathering and understanding business flows, mapping to framework needs, analyzing procedures, documenting, reviewing, and revising for wider release. With several of these teams working at once, you'll soon begin to amass a set of process documentation that will begin to fit together into a cohesive, comprehensive program. As this material begins to appear and take more and more solid form, you'll want to begin presenting it for broad organizational review and potential refinement.

Review/revision

To the extent deemed appropriate by the organization, the key stakeholders review and analyze the documented program components and share them with other relevant stakeholders. This step serves as a socializing verification and validation step. Here, components can be adjusted and tailored to reflect specific needs of the various project teams, and to accommodate differing degrees of focus among similar teams.

(Trial)

This is an optional step the organization may elect to use for certain program components. This is actually an activity that mini-pilots the program components on a trial application or for a trial project. This step is an extension of the review/revision step and serves as proof-of-concept and real-world test opportunities for the program components and for use by project teams. This trial method can be valuable if you're dealing with complex processes or if you're building components that need to be verified by multiple working groups.

Publication

In this final step, the program is judged ready for adoption by the organization and is instituted as a managed tool set. A central repository is established, and the program components are published into the repository.