Summary


The Process Areas for Maturity Level 5: Optimizing

Organizational Innovation and Deployment

The purpose of Organizational Innovation and Deployment (OID) is to select and deploy incremental and innovative improvements that measurably improve the organization's processes and technologies. The improvements support the organization's quality and process performance objectives as derived from the organization's business objectives. Specific Goals and Practices for this process area include:

  • SG1: Select improvements

    • SP1.1: Collect and analyze improvement proposals

    • SP1.2: Identify and analyze innovations

    • SP1.3: Pilot improvements

    • SP1.4: Select improvements for deployment

  • SG2: Deploy improvements

    • SP2.1: Plan the deployment

    • SP2.2: Manage the deployment

    • SP2.3: Measure improvement effects

Process improvement proposals to improve the process of process improvement are included in this process area. Technology improvement proposals are also included. If readers review the Organizational Process Focus process area, they find that process improvement proposals are used there as well. What is the difference? In this PA, the proposals are subjected to quantitative analysis of proposed improvements. Metrics residing in the historical database, as well as defects and where they were introduced, are reviewed as well, in order to determine where, when, and how to make improvements. Costs and benefits of the proposed versus actual improvements are also studied.

Some people have interpreted this process area as including both process and product improvements. This opens up a can of worms for assessment teams . What was expected in the CMM for Software was process improvements and improvements in technology to support the processes. Technologies, such as a new requirements traceability tool or a new unit test tool, were included. Technologies that were to be part of a product, such as a new database management system or a new algorithm, were not included. With CMMI, these concepts become an even bigger issue. The systems that we may be building can include a lot of technologies. The question then becomes: how far should an assessment team go? Is the organization expected to have a defined process to select technologies? When selecting the type of phones for staff members , is that covered by OID? When selecting which type of interface to put on the new phone system, is that covered by OID? Or is that covered in Technical Solution at Level 3?

The steps in this process are as follows :

  1. Submitting improvement proposals

  2. Reviewing and analyzing the proposals (including a cost-benefit review)

  3. Piloting the proposed improvement

  4. Measuring the improvement to see whether it has been effective in the pilot

  5. Planning the deployment of the improvement

  6. Deploying the improvement

  7. Measuring the effectiveness of the improvement across the organization or project

For example, a Level 1 organization will simply mandate that a certain change control tool is now to be used. There is no piloting of the tool, no requirements study to see which tools out there fit the organization, and no training is given. This introduction of the new tool causes chaos. A Level 5 organization will follow the steps above, and should the pilot prove effective, will probably deploy the tool one or a few projects at a time (not en masse) into the entire organization. A "go/no-go" decision will be made at each step.

Do not wait until Level 5 to introduce these concepts into your organization. The difference in introducing this approach at Level 1 or 2, versus Level 5, is that at Level 5 you absolutely know your organization's processes and you can be more proactive about predicting the level of uncertainty that the tool (in the example used) will create. You can plan its introduction better, and pinpoint areas that will need more attention such as training and, perhaps, contracts.

Organizational Innovation and Deployment involves coordinating process improvement proposals submitted from the staff at various levels (improvement proposals may be related to innovative technology improvements); piloting selected improvements; planning and implementing the deployment of improvements throughout the organization; and measuring the effects of the improvements implemented.

Causal Analysis and Resolution

The purpose of Causal Analysis and Resolution is to identify causes of defects and other problems, and take action to prevent them from occurring in the future. Specific Goals and Practices for this Process Area include:

  • SG1: Determine causes of defects

    • SP1.1: Select defect data for analysis

    • SP1.2: Analyze causes

  • SG2: Address causes of defects

    • SP2.1: Implement the action proposals

    • SP2.2: Evaluate the effect of changes

    • SP2.3: Record data

Proposals and plans to improve defects in the processes used to produce products are included here. Defect Prevention in the previous CMM for Software included integrating project work with kickoff meetings. This activity is no longer included here. We recommend this activity be performed as a best practice, as found in other organizations.

This process area looks at defects and determines their root cause. The most simple definition of a root cause is simply the one, most basic reason why the defect occurred (or the source of the defect); and if that cause is removed, the defect vanishes. This process area identifies the root cause(s) and addresses the cause using a structured approach. The steps in this approach are:

  1. Look at the defects and problems in the organization

  2. Select data to analyze

  3. Analyze causes

  4. Prepare proposals to address the problems

  5. Implement the proposals

  6. Evaluate the effects of the changes

You should already be analyzing defects and problems during Project Planning and Project Monitoring and Control at Level 2. Training to perform the more sophisticated studies required for Level 5 should be considered .

We recommend that users of the CMMI for process improvement also review the CMM for Software for more advice or suggestions on other activities, and including them to satisfactorily complete this process area. Kickoffs, sharing among projects, roles in the organization, rolling up project data/causes/problems into organizational-level data, and integrating changes into the processes are described somewhat in the previous model, and may benefit the reader in understanding this process area.

Causal Analysis and Resolution includes identifying defects and where in the process they were introduced; determining the causes of defects and their resolution; and defining methods and procedures to avoid introducing defects into the processes in the future.




Interpreting the CMMI(c) A Process Improvement Approach
Interpreting the CMMI (R): A Process Improvement Approach, Second Edition
ISBN: 142006052X
EAN: 2147483647
Year: 2005
Pages: 205

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net