Is This a Valid Performance Model?

Is a reliability growth model considered to be a valid PPM in the CMMI?


Asking this question out of context with what you do in the organization does not have a lot of meaning.  The correct answer is both yes and no.  Please remember what High Maturity is all about.  You begin with setting your business goals and objectives and use them to derive your Quality and Process Performance Objectives (QPPOs).  These QPPOs in turn will lead you to the proper measures, process performance baselines (PPBs), and process performance models (PPMs) that your organization needs to quantitatively and statistically manage your work.So, if Reliability Growth is a critical process or sub-process and you have sufficient data to analyze to determine that you have a stable and capable process, then a reliability growth model might be considered a valid PPM.

But just selecting models without performing the analysis I just sketched out is incorrect and you will not be able to demonstrate that your organization is a High Maturity organization.

Thanks for the detail. I just happen to see in CMMI v1.3 High Maturity in which the "reliability model growth" which was given as example in OPP SP1.5 (CMMI v1.2) is deleted. Does it mean that reliability growth model will not be accepted in CMMI v1.3? Or the reliability growth model is not acceptable by the experts? Or is it only good if you use CMM v1.2  and not for CMMI v1.3?

As CMMI v1.3 is an improvement and the practices are carefully analyzed by the SEI and experts, is it advisible to use the reliability growth model given in CMMI v1.2? Or there is any chance that CMMI v1.3 will include the reliability growth model as an example?


Apparently there is some misunderstanding of my answer above.  Whether the CMMI contains the reliability growth model as an example or not is irrelevant to whether or not it is a good model.  Your organization has to mathematically analyze its data, business objectives, QPPOs, PPBs, and PPMs to determine if there is a need for using a reliability growth model.  Do the following analysis:

1. Describe the reliability growth model in probabilistic terms.
2. Define the critical sub-processes (those that must be consistently and correctly followed every time) that can be managed using the reliability growth model.
3. Define how a project manager uses the reliability growth model in the context of his or her projects to predict performance, "what-if" analysis, and predict QPPO achievement.
4. Provide an equation or show by other means how the stable sub-processes that you have identified in your processes contribute to the reliability growth model.
5. List the other models that are used in conjunction with reliability growth model and why it has statistical relevance.

Once you have performed this analysis you will have enough information to answer this question yourself.

MA and PPQA Questions

I have the following two basic queries about CMMI ML 2:

1. While writing a Metrics and measurement process, should we address the organization level metrics data consolidation and review. As ML 2 is project specific, is it proper to also document the organization level data consolidation? Also can anyone tell me, the right site for definition of metrics like requirement stability index, schedule variance, effort variance etc.?
   
2. Similarly while documenting PPQA process, is it proper to start with defining an organization level PPQA plan? I am looking for boundaries where to limit writing processes compliant to ML 2. I know that G.P 2.1 to G.P 2.10 must be in place to achieve CMMI ML 2, but the organization specific plans/areas must not be mentioned/documented at CMMI ML 2.

You sound like you are focusing on CMMI compliance rather than on your business goals and objectives. One of the basic tenets of the model is your business objectives. That is where your focus belongs. And if done properly, you will have the side benefit of being CMMI compliant. So, to address your questions:

1. When documenting your Measurement and Analysis process, you should focus on those measures that are important to you. Remember, the first MA practice SP 1.1 states “Establish and maintain measurement objectives that are derived from identified information needs and objectives.” So whatever you have identified as information needs and objectives, that should be your MA focus. At ML 2, for many organizations that are just doing this for the first time, I recommend the org take baby steps and begin with a project focus. But you don’t have to be restricted to the project, an ML 2 org may have also identified some org level measures as well. Go to the Practical Software and Systems Measurement web site for the specific measurement information you need www.psmsc.com
   
2. There are NO CMMI-imposed restrictions on the limits of PPQA. Your organization must define its own limits for the processes you are going to audit. Since GP 2.9 applies to all Process Areas, at a minimum for ML 2, PPQA applies to all of the ML 2 Process Areas you have implemented in your organization. But, if there are other processes that are critical and/or important to the success of your business, then it makes perfect sense to have PPQA audit them as well. Again, do what is right for your business.

GP 2.1 Establish an Organizational Policy

This Generic Practice is fairly simple and straightforward, but one that many organizations have difficulties implementing the first time around. The practice states "Establish and maintain an organizational policy for planning and performing the process." What I see many organizations do is write a high level process or procedure as the policy instead of providing the necessary organizational expectations for the process.

One of the underlying principles of the CMMI is the principle of setting goals and objectives. Senior/Executive Management should be setting and clearly communicating the organization's business goals and objectives. The policy required by GP 2.1 is then the place for aligning the quality system with the organization's business goals and objectives.

Another problem I have encountered is that organizations tend to write huge policies when in point of fact, all that is necessary to clearly communicate the organization's policy is a few sentences or a paragraph.

And in an extreme case, I have seen one organization declare that it is their policy for each organizational unit to achieve a specific Maturity Level. This odd policy is very similar to the blog I wrote the other day titled Setting Proper Goals and Objectives. The organization's core business is NOT to achieve a Maturity Level, implement a specific model, or comply with with a specific standard. The organization may need to achieve a specific Maturity Level or comply with a standard in order retain existing business or win new business, but that is not why the organization is in business. The organizational policy writer(s) need to dig a bit deeper and write the policies to be aligned with the organization's actual business goals.

For example, if one of the organization's core business goals and objectives is to deliver high quality products and services to their customers, then each organizational policy should have that focus. Keeping this focus in mind, then an example Requirements Management Policy might look like this:

Organization XYZ is committed to delivering high quality products to its customers by establishing a common understanding between the customer and the project of the customer’s requirements. This policy applies to all XYZ projects that meet one or more of the following criteria:
1. [Project effort is expected to exceed 1000 hours]; OR
2. [Project budget is expected to exceed $250,000]; OR
3. [Project schedule is expected to exceed 6 months].

All projects that satisfy these criteria must follow the Requirements Management Process and ensure that:
1. The requirements are documented.
2. The requirements are reviewed by the managers, and other affected groups.
3. The plans, work products, and activities are changed to be consistent with changes to the requirements.

Senior Management is responsible for:
1. Establishing and ensuring conformance to this policy.
2. Establishing responsibility for analyzing the system requirements and allocating them to hardware, software, and other system components.
3. Providing adequate resources and funding for managing the allocated requirements.
4. Reviewing the activities for managing the allocated requirements on a periodic basis.