Monday, September 22, 2008

Does anyone have an example of how everything flows together?

I'm looking for a work flow diagram or something of that nature that shows how all of the Level 2 and Level 3 Process areas and associated work products flow together. I'm talking about some sort of diagram or chart that shows a regular waterfall development lifecycle found in a software environment and where each Process area, and it's work products fit into that scenario.

Since the CMMI is a set of guidelines for process improvement, there is no single way of tying everything together. It is highly dependent on how you have implemented the model in your organization. Have you taken the SEI’s Intro to CMMI 3-day class? If so, then you have seen diagrams that sort of address your request. These diagrams also appear in Chapter 4 of the CMMI book. There is a whole series of these diagrams that illustrate how the Process Areas (PAs) are interconnected and the types of information that flow between the PAs. These figures only show possible interactions between the PAs and are not the only way to do things.

Interpreting OPF SP 1.2

While reading and then interpreting SP 1.2 of OPF "Appraise the Organization's Processes" it seems that it is a mini SCAMPI (correct me if I am wrong). Now in this context I have few questions and would like answered.

Organizational Process Focus (OPF) SP 1.2 states “Appraise the organization’s processes periodically and as needed to maintain an understanding of their strengths and weaknesses.”

1. These internal appraisals to satisfy this practice will be performed by the PEG (Process Engineering Group), how much rigor is required? Can we employ the SCAMPI Class C method to satisfy this practice?
SCAMPI A, B, and C appraisals all satisfy this practice as well as any other type of appraisals or assessments that provide an understanding of the organization’s process strengths and weaknesses. There is no level of rigor implied by this practice.

2. Should we check the evidences and/or satisfaction at processes' implementation at project level or its better to keep the scope of these appraisals at OU level only?
OPF is an organizational level process. And the practice states to appraise the organization’s processes. Some of them are performed at the project level and others at the organizational level. But the focus should be at the organizational level.

3. Should we formally present the findings as normally done in SCAMPI Class A appraisals by the LA or that much rigor is not required (as it required lot of stakeholders presence like CEO if he is the sponsor)?
The rigor of the Findings Presentation is up to you. However, you should determine the level of rigor when you are in the planning phase for these evaluations. As a Lead Appraiser, I create an appraisal plan for any appraisal I conduct and I specify in the plan how the practices, projects, organization, etc. will be scored and how the results will be presented.

4. If we are appraising the organizational processes, then should we appraise all the ML 2 and ML 3 process area or we can make selection?
Since this practice covers all process appraisals conducted on the organization’s processes, depending on the appraisal, you have a lot of flexibility on the scope and conduct. It all needs to be specified in the appraisal plan. Of course a SCAMPI A appraisal using the staged representation will dictate which PAs to include depending on the Maturity Level. Other than the SCAMPI A, you have the freedom to pick and choose what you want to appraise. But keep in mind, you do need to have an overall strategy and plan for these appraisals. As a Lead Appraiser appraising this practice, I expect to see a periodic plan for your appraisals, not just the SCAMPI A appraisals I conducted.

5. If we make a checklist for all process areas, then is it a good idea that we include the Subpractices as a questions (may be not all subpractices) in checklist for all ML 2 and ML 3 PAs?
Again, you can use whatever checklists you want for your internal appraisals. In fact, it might work to your advantage to be very rigorous in an internal appraisal. But remember, when it comes time for the SCAMPI A appraisal, you will not be evaluated against the sub-practices.

Who Owns the Process?

A company/organization entirely outsources its software development to another company. That's their business model. The developers working for the company whose name appears on their paycheck work for the client in every way except for who signs the paycheck (so to speak).

The entire development effort (client and developers) implements CMMI.

IF BOTH the leaders of the client company AND the developer company take part in the process efforts, e.g., GP2.1, GP2.7, GP2.8, GP2.10, GP3.2, et al. can the SCAMPI be done such that both OUs are delineated? Can BOTH organizations lay claim to a rating?

I think the key element comes down to the definition of the Organizational Unit. And you imply in your scenario that there are two OUs. One OU has outsourced the engineering work and the other OU is performing the engineering work. Given the OU definitions, I think that this scenario indicates the need for two SCAMPI appraisals. One for the client using the CMMI-ACQ since it has outsourced the development work and one for the development organization using the CMMI-DEV.

Hurricane Ike, Risks, and the CMMI

In a previous blog entry, http://ppqc.blogspot.com/2008/08/help-understanding-process-performance.html, I have used hurricanes to illustrate the differences between Process Performance Baselines and Process Performance Models. But there is a more practical problem with hurricanes that impact organizations, Lead Appraisers, and appraisals at any Maturity Level. This problem manifests itself in the areas of Risk Identification, Tracking, and Mitigation. After the devastation of hurricanes over the past several years, most notably Katrina and now Ike, I recommend to all of my clients along the Gulf Coast and the Atlantic Coast that they include hurricanes or severe weather as a credible risk for the process improvement efforts and appraisal planning, especially during hurricane season June 1 to November 30. Recognizing that hurricanes can cause severe damage and at at minimum, a disruption to work, risk mitigation plans need to be identified. Not only are businesses closed for days, electric power and other essential services are out, homes can be damaged, and people evacuate. Today it is 10 days since Ike came ashore and chewed a swathe through Galveston and Houston. Only about 60% of the power has been restored. Many people have lost everything and most of us are preoccupied with clean up and insurance claims. So even though businesses are back open today, many employees will not be able to return to work. And those that do return to work won't be productive for some time. They will be relating their Hurricane Ike stories.

So, when identifying a hurricane, severer weather, or other act of God or war as a risk, the mitigation plans need to address the worst case scenario and the potential loss of weeks of work, if not data. And from the Lead Appraiser's perspective, a disaster can wreak havoc with the calendar since appraisals tend to stack up at the end of the calendar year. If a disaster strikes in September, it may be a problem to reschedule an appraisal in the same calendar year.

Monday, September 8, 2008

CMMI Certifications & Career Development

I'm a graduate student and starting my degree in 2009. I have over 2 years experience (3 mini assessments) in Process Improvement, CMMI ML 3 and ML 5 evidence collection, and verification. I will be taking the Intro to CMMI class in December 2008.

As I am interested in researching the CMMI and Quality Assurance for my thesis and to shape up my career to be a CMMI consultant position; I contacted SEI. The SEI suggested that I seek the advice and guidance from a few registered Lead Appraisers in different parts of the world on how I should plan my future studies.

My questions are:

  1. In the professional world job market is there a value for such research?
  2. What other professional qualifications should I gather to be a CMMI consultant?
  3. From your experience do you think its worth it (career development wise) to conduct appraisals externally rather than waiting for your organization to provide them free for you?
  4. Any other advice you want to provide me in my career planning?

Your guidance in these questions are highly appreciated.

Here is my advice to you to help further your interests and your career.

  1. There is always room in the professional arena for research. Research results are regularly presented at professional symposia and conferences. I am sure that the SEI would encourage you to submit an abstract for consideration at an upcoming SEPG Conference. If your research is credible, and you gain visibility in the community, that can only strengthen your credentials as a consultant. It also demonstrates that you are staying current in the field of process improvement.
  2. To become a CMMI consultant, you would need practical experience, not necessarily additional professional qualifications. Take a look at the criteria for being on an appraisal team. That criteria also makes for a credible CMMI consultant. So I would recommend that you gain some experience in Project Management, as well as engineering experience, at least 3 to 5 years worth. If you were to start consulting immediately upon graduation, you may be looked upon as providing an academic approach to CMMI implementation.
  3. Since implementing the CMMI can take several years and the expenses for appraising an organization are fairly high, there will not be many internal opportunities for appraisals. Especially if you want to become a Lead Appraiser. You may be able to satisfy the minimum requirements to become a Lead Appraiser with internal appraisals, but most likely you won’t be able to conduct enough internal appraisals to maintain your credentials. Therefore, I recommend that you conduct external appraisals. If you were to work for a consulting company specializing in the CMMI, then the company would most likely pay your expenses. Otherwise, you will be faced with financing them yourself.

Sunday, September 7, 2008

Difference between measurement objectives and process performance objectives

CMMI uses following terms while talking about measurements:
  1. Identified information needs and objectives at organization level (MA)
  2. Measurement objectives derived from such information needs and objectives (MA/SP 1.1)
  3. Quality and Process Performance Objectives (OPP/SG1)
I want to investigate finer differences between the later two. Are they more or less the same? If not, what are the finer differences?

Your first two questions deal with Measurement and Analysis (MA) which is a Maturity Level 2 Process Area (PA). Your third question is about OPP which is a Maturity Level 4 PA.
MA is a support PA that applies to ALL PAs in the CMMI. Its focus is defining measures and indicators that help answer or address a specific information need. An information need can be articulated using the following format:

<someone> needs to know <what information> in order to make <what decision>.

For example, an issue facing the Project Manager may be that Project Plans are inaccurate causing project teams to routinely miss milestones and deliveries.
Therefore the information need would be: The Project Manager needs to evaluate the schedule, progress, and dependencies of key development activities and events in order to determine necessary corrective actions.
Then the measurement concept or strategy for addressing this information need would be: At the end of each week the Project Manager collects estimates to complete the work for each current task and enters the data into the schedule. The Project Manager and team review progress to determine the necessary corrective actions and modify the Project Plan as needed each Monday morning.
Now it becomes very easy to determine the base and derived measures that support the measurement concept.

So these concepts (information need, measurement concept, and measures) are interrelated concepts that help define what data to collect and analyze to help answer a question.

The Quality and Process Performance Objectives (QPPOs) are entirely different from the measurement concept. The QPPOs are objectives set by the organization based on the organization’s business objectives, past performance of projects, and are constrained by the inherent variability or natural bounds of the process. Now, in order to determine the measures that the organization will use to support the QPPOs, the organization should follow the MA process of articulating the information need, defining the measurement concept, and determining the measures.

Tuesday, September 2, 2008

Trying to Understand the Differences Between RD SP 2.1 and SP 2.2

I have difficulties understanding the difference between Product Requirements and Product Component Requirements. For me Product Requirements are when I have documented the customer needs and I have performed the next step, interpreting and writing the technical requirements in tree categories, functional, non functional, interface. But what happens with Product Component Requirements? In which category do they apply? When in the project lifecycle do I have to describe this kind of requirement? Is it in design while the developers are writing code and they discover that something is missing? And then in SP2.2 "Allocate product component requirements", I cannot figure out what kind of allocation the CMMI refers to.


The intent of Requirements Development (RD) Specific Goal 2 (SG 2) is to refine and further elaborate on the customer requirements. If you think of the customer requirements being at 50,000 feet, SG 2 is adding the information necessary to bring you down to 10,000 feet. Still pretty high level, but with some detail now.

As I always recommend to people who have model interpretation questions, the first place you should consult is the CMMI Glossary. If you look in the Glossary you will find definitions for product component and product component requirements.

Product Component – In the CMMI Product Suite, a work product that is a lower level component of the product. Product components are integrated to produce the product. There may be multiple levels of product components.


Product Component Requirements – A complete specification of a product component, including fit, form, function, performance, and any other requirement.

Here is an illustrative example to help you better understand the concept of a product component. Let’s consider a mechanical alarm clock. The clock consists of several parts or components: clock face and hands, gears and levers, alarm bell, setting levers/buttons, and a clock housing. There may be others, but these will do for now. Each of these parts is a separate clock component with associated detailed requirements.

So when you consider a software system at a high level, it breaks down into one or more components. And it is possible for each component to further break down into sub-components. This concept is easy to understand for new development. For the maintenance case, you may only be receiving requirements for one component. So it may not be immediately obvious what the difference is between a product and a product component requirement.

Product component requirements apply throughout the lifecycle. However, you are more likely to encounter them in the early phases.

Specific Practice 2.2 “Allocate the requirements for each product component.” If you have a copy of the CMMI book, there are some helpful hints in the margin that should clarify what is meant by this practice. The intent of this practice is to ensure that the requirements for each product component are correctly specified (allocated). At this point in the lifecycle you aren’t addressing implementation, that will be at the 5 foot level. So at the product component level, you may have a mixture of hardware requirements, software requirements, performance requirements, operational requirements, etc. The intent of SP 2.2 is to allocate these different requirements to the proper component so you don’t implement a hardware requirement in software or vice versa by mistake. And once again, in the sustaining maintenance environment, when you receive new requirements, they may have already been allocated for you. So the distinction is not immediately obvious.