Procedures Specify HOW to Do Something, Not WHAT to Do

A common problem I notice when reviewing an organization's processes and procedures is that the organization doesn't understand how to document a procedure. Rather than simply telling someone HOW to perform the process, the document states a set of requirements that must be met by the people performing the procedure, which then allows multiple ways of performing the procedure by any person attempting to use the document. There seems to be a general misunderstanding that commands or directives tell someone HOW to perform a process, when in actuality all that is being communicated is WHAT to do.

The CMMI Glossary defines process as activities that can be recognized as implementations of practices in a CMMI model. These activities can be mapped to one or more practices in CMMI process areas to allow a model to be useful for process improvement and process appraisal.

The Glossary also defines a process element as the fundamental unit of a process. A process can be defined in terms of sub-processes and/or process elements. A sub-process can be further decomposed into sub-processes and/or process elements; a process element cannot. Each process element covers a closely related set of activities (e.g. estimating element, peer review element). Process elements can be portrayed using templates to be completed, abstractions to be refined, or descriptions to be modified or used. A process element can be an activity or task.

Page 53 of the CMMI book provides the following description of Maturity Level 2:

At Maturity Level 2, the projects of the organization have ensured that processes are planned and executed in accordance with policy; the projects employ skilled people who have adequate resources to produce controlled outputs; involve relevant stakeholders; are monitored, controlled, and reviewed; and are evaluated for adherence to their process descriptions. The process discipline reflected by Maturity Level 2 helps to ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.

At Maturity Level 2, the status of work products and the delivery of services are visible to management at defined points (e.g., at major milestones and at the completion of major tasks). Commitments are established among relevant stakeholders and are revised as needed. Work products are appropriately controlled. The work products and services satisfy their specified process descriptions, standards, and procedures.

Page 54 of the CMMI book provides the following description of Maturity Level 3:

At Maturity Level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods. The organization’s set of standard processes, which is the basis for Maturity Level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization’s set of standard processes according to tailoring guidelines.

A critical distinction between Maturity Levels 2 and 3 is the scope of standards, process descriptions, and procedures. At Maturity Level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (e.g., on a particular project). At Maturity Level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit and therefore are more consistent, except for differences allowed by the tailoring guidelines.

Another critical distinction is that at Maturity Level 3, processes are typically described more rigorously than at Maturity Level 2. A defined process clearly states the purpose, inputs, entry criteria, activities, roles, measures, verification steps, outputs, and exit criteria. At Maturity Level 3, processes are managed more proactively using an understanding of the interrelationships of the process activities and detailed measures of the process, its work products, and its services.

Page 295 in Organizational Process Definition provides some Tips that relate to processes and process assets:

Organizational process assets support a fundamental change in behavior. Projects no longer create their processes from scratch but instead use the best practices of the organization, thus improving quality and saving time and money.

Standard processes define the key activities performed in an organization. Some examples of standard processes include requirements elicitation, design, and testing; planning, estimating, monitoring, and control; and product delivery and support.

The objective is to decompose and define the process so that it can be performed consistently across projects but will allow enough flexibility to meet the unique requirements of each project.

And from the book Interpreting the CMMI by Margaret Kulpa and Kent Johnson, second edition on page 198 there is a section on Defining Procedures that supports the CMMI material quoted above. In the context of the CMMI, procedures are equivalent to sub-processes and process elements.

Procedures are step-by-step instructions on how to perform a task. To be repeatable, the steps need to be broken down to a level that anyone who needs to perform the task, with a general understanding of the work to be done, can perform the work adequately by following the instructions. Procedures are a subset of processes. The process is what to do; the procedures are how to do the steps of the process.

Procedures are step-by-step instructions of how your processes are performed. They include:

• Sequence of activities
• Deliverables
• Controls
• Inspections and reviews
• Guidelines and standards used

In addition, in the CMMI book on pages 99 and 100, Bill Curtis, an author of the Software CMM, talks about policies, PPQA, and process improvement:

Polices that merely regurgitate goals from CMMI process areas represent a lost opportunity for executives to communicate their expectations for behavior in their organizations. Once policies are established, executives need visibility into compliance. Assurance groups have influence only to the extent that executives attend to their reports and address noncompliance. However, the greatest value of assurance groups, and this is subtle in Process and Product Quality Assurance (PPQA), is when they serve as mentors to project managers and technical staff on practices that support compliance. Consequently, assurance groups need to be staffed with competent developers and managers so that they are credible in transferring knowledge of best practices across the organization.

Process improvement must be conducted as a project. Executives must assign responsibility for managing the project, provide funding and resources, expect periodic status reports, and measure results. The person assigned to lead the improvement project must be a good role model for other project managers. Executives should ask frequent questions about project plans and the assumptions underlying them. The guidebooks, defined processes, measures, checklists, and other artifacts produced through process improvements are organizational assets. They should be treated as products, albeit for internal use, and be produced with the same discipline used in producing any other product.

Consequences and Summary
By not specifying how to perform the process steps it gives carte blanche to whoever is performing the process to do whatever they want to in order to satisfy the step. In addition, by not specifying how to perform the process steps, it makes it impossible to perform a PPQA process audit. The person performing the objective evaluation of the process (process audit) needs to know how the process is supposed to be performed in order to create a checklist so he or she can objectively evaluate whether or not the process is being followed the way it is supposed to be followed.

Essentially, by not supplying the information of how to perform a process, you do not have a repeatable process, which is at the core of Maturity Level 2. A repeatable process means that every time someone uses the same documented process description, he or she will perform it the same way. The only way that you can ensure this outcome is to document how the process is performed. At Maturity Level 2 it is permissible to have multiple documented processes for the same process. At Maturity Level 3 the organization is supposed to examine the multiple documented processes and look for exemplar practices to elevate to the organization level to become the standard process for the organization.

The challenge facing the process writers is to document the process such that it is neither too detailed nor too general to follow. If it is too detailed, then you have painted yourself into a corner and the process may be too detailed to correctly follow. If too general, then it basically allows you to do anything you want. Either way, there is no benefit to the organization.

This issue also points out a fundamental difference between ISO 9000 and the CMMI. At its core, ISO 9000 is a set of standards for a quality system. It requires the existence of processes good, bad, or indifferent. In contrast, the CMMI is a set of guidelines for process integration and product improvement. The whole focus of the CMMI is process improvement. And it becomes very difficult to do process improvement if you don’t spell out how a process is performed.

To illustrate the issue allow me to cite an example of incorrectly worded procedure step.

• The Project Manager derives estimates for the size of the software work products, or changes to the size of the software work products.

There is more than one way to estimate size if you don’t specify how to perform this step. By not specifying how, you cripple your ability to analyze the process and identify process improvements.

If I were to ask the Project Manager how he or she peforms this step, I might find out that they do this by using the project requirements and historical data (notes and reports from past projects and lessons learned) from similar past projects to determine size factors (SLOCs, number of files, database size, number of screens) and applying appropriate scaling factors using engineering judgment. The Project Manager then reviews the size estimates with the Team Leads for reasonableness. This is an excellent explanation and practice.

By providing this level of detail, now there is enough information for PPQA to perform a process audit and also enough information to perform process improvement and determine if an estimation model can be built to improve the accuracy of project estimates.

Requirements Development/Management Question

I was slightly confused after reading this statement in the Requirements Development (RD) Process Area (PA), Specific Practice (SP) 2.1 states "Establish and maintain product and product component requirements, which are based on the customer requirements"

The informative material goes on to say "The modification of requirements due to approved requirement changes is covered by the "maintain" function of this specific practice; whereas, the administration of requirement changes is covered by the Requirements Management process area."

I do not understand the difference between maintenance of requirements in RD and administration of requirement changes in REQM. How are they different?

The Requirements Management (REQM) Process Area (PA) is there to help an organization manage changes to an agreed to set of requirements (baseline). So, no one makes any changes to the requirements (add/modify/delete) without following the documented requirements change control process, which should include review and approval by the relevant stakeholders of the requirements.

And actually, REQM is a specific instance of Configuration Management (CM). But REQM is such an important and vital practice that it is its own Process Area. So it is entirely possible for an organization to have one Change Management process that it uses to manage changes to requirements, documents, plans, test scripts, code, etc.

In contrast the intent of Requirements Development (RD) is to actively elicit and further refine the requirements that are then agreed to and incorporated into the requirements baseline. Specific Practice 2.1 contains the phrase “establish and maintain,” which has a special meaning within the context of the CMMI. If you have taken the Introduction to CMMI class you would have learned what this phrase means. This phrase is also defined in the CMMI Glossary and it means formulate, document, and use. For SP 2.1, this means that the product and product component requirements are formulated (elicited, discussed, refined, reviewed, etc.), documented (written down in a requirements specification, requirements management tool, etc.), and used (develop the project plan, design, code, tests, etc.).

So the connection between REQM and RD is that proposed requirements changes are reviewed, analyzed, approved, and processed by REQM and the authorized and approved changes are propagated through the baselined requirements by RD.

I would not get too focused on trying to understand the separation between REQM and RD. You have identified one of the many areas in the CMMI where there is a tight coupling between PAs, if not overlap. What is important is that you

1. create a requirements baseline that does not change unless there is an approved change request,
2. investigate, impact, review, and disposition all proposed requirements changes with the relevant stakeholders (approved or rejected), and
3. only make approved changes to the baselined requirements and appropriately update the traceability

Applicability of the Informative Material

I have been told that if an organization has to go for CMMI ML 5 the organization has to address all of the sub-practices even though they are informative material and if the company is only going for ML 3, then they can apply appropriate sub-practices. Is this true?

Please allow me to try to explain the model. There are at least two ways to look at the CMMI: 1) implementing the model and 2) appraising the organization against the model.

In addition, there are three CMMI components: Required, Expected, and Informative. These components only have meaning when you are talking about appraisals. The Required components are the Specific and Generic Goals, the Expected components are the Specific and Generic Practices, and everything else is an Informative Component.

When you are implementing the model, you should not be concerned about differentiating between the different types of components. From Chapter Two of the CMMI-ACQ (and this statement applies to ALL CMMI constellations): “All model components are important because the informative material helps you to understand the expected and required material. It is best to take these model components as a whole. If you understand all three types of material, you can then understand all the pieces and how they fit together to form a framework that can benefit your organization.”

When the organization is being appraised against the CMMI in a formal SCAMPI A appraisal, the organization will only be appraised against the Required and Expected components, regardless of the Maturity Level. However, the appraisal team may be evaluating the evidence and perhaps asking questions in the interview sessions at the sub-practice level just to gain a better understanding of how the organization is addressing each of the Required and Expected components. The organization will not be penalized if it is not performing one or more sub-practices. The appraisal team will be identifying and documenting weaknesses with the organization’s implementation of the goals and practices.

Because there has been a misunderstanding of what High Maturity means (ML 4 and ML 5), the SEI has been emphasizing that the proper implementation of the goals and practices for OPP, QPM, OID, and CAR means reading, understanding, and implementing the types of activities described in the Informative material. So, for a ML 4 or ML 5 SCAMPI, the organization will not be evaluated against the OPP. QPM, OID, and CAR sub-practices, but weaknesses will be noted at the goal and practice level if the organization has not properly implemented these Process Areas to meet the intent, which is gained by understanding the Informative material.

Quantify Functionality - RD Process Area

Sub-practice 1 of Requirements Development SP 3.2 states " Analyze and quantify functionality required by end users". What does quantifying functionality mean? Does it refer to quality characteristics of functionality or does it refer to Function Point estimation?

What quantify means in this sub-practice is to spell out the required functionality requirements so everyone is in agreement, as well as state exactly how many functionality requirements there are. And since this is a sub-practice, this is an informative component of the model and it is supplied for clarification of the intent of the practice statement “Establish and maintain a definition of required functionality.” If you are implementing RD in your organization, you are not required to implement the sub-practices. You need to do what makes good business sense for your organization in order to determine the definition of the required functionality.

OSSP Question

What does "organization’s set of standard processes" mean?

As I have indicated in previous blog entries, the first place you should always check for definition questions is the CMMI Glossary. You will find a comprehensive definition of the OSSP there. If after reading the definition you still have questions, then read the Organization Process Definition (OPD) Process Area which will put the OSSP into context. And if you still have unanswererd questions, please post them to this blog.

Project Classification Part Two

This is a follow on discussion to http://ppqc.blogspot.com/2009/04/project-classification.html

I will try to make my point clear here. Let's assume for a moment that an organization has identified project types i.e development and testing. If such an organization has to go for CMMI ML 2, then what should be their approach to further segregate each project type for better process implementation? I would like to look at project duration (start date and end dates) , the SDLC (phases), number of people working on project or effort put on the project.

Is there any other technique or anything else I should look at to categorize each project type into small, medium and large? Because I do not find CMMI publishing any kind of guidelines for segregating projects into small, medium and large. So ideally as you said ..project size... Can we say that to look at project size we need to look at effort required to complete the project and duration of project? So I am looking for other parameters to give the organization better picture of the basis to arrive at small, medium and large projects.

Thank you so much for the clarification.

You seem to be making a distinction between project type and project classification. In my mind project type and project classification are two different terms that mean the same thing: category. As you have discovered, there isn’t any guidance for what is a project type or classification. This categorization is up to the organization to determine for its internal purposes. Project size could be a classification, but is probably not the best one to use. As I have suggested in other posts, application domain, platform, language, methodology, etc. are potentially better categories to use. And the primary reason for labeling projects with a category is to allow the organization to compare like against like. For example, there is not a whole lot of value in comparing a web development project to a mainframe project, or a web development project to a road construction project. You want to compare apples to apples and oranges to oranges, not a mixture.

But I think that the bigger issue here is defining what is a “project” for your organization. A project has a defined start and stop, budget, resources, tasks, schedule, identified deliverables, and typically operates according to a plan. And a project can be composed of other projects. Once you have decided on what a project is for your organization, then it becomes pretty obvious the project types or classifications that make sense for your organization.

Typically I do not find that organizations have separate projects for development and testing. Testing is part of the development lifecycle and typically not treated as a separate project. However, you may have a testing plan, testing resources, funds, and a testing schedule. So testing could be a sub-project of the main development project. Therefore, I would not normally expect that projects would be categorized as development or testing. However, I have seen projects categorized as development or maintenance projects. Once you have decided on the primary project categories for your organization, then it might make sense to look at size (small, medium, large) within a specific category to further refine your definitions and comparisons.

Requesting Processes and Assets

I have read your CMMI blog. Can I have some draft CMMI process documentation? I would like to learn and implement the process.

There is no such thing as a set of documented CMMI processes that can be provided for a company, though some unscrupulous consultants will try to sell you a set. Rather, there are industry accepted standards for documenting processes, such as ETVX. These process documentation standards are easily available by searching on the internet. The actual processes for REQM , PP, PMC, SAM, MA, PPQA, CM, etc. are a function of the organization’s business and its practices, though there is some commonality across companies and organizations. However, this commonality exists at the CMMI level. The CMMI is a set of guidelines for process improvement. The implementation of these guidelines will differ from organization to organization. The best advice that I can give you is to document all of your current business practices using an industry accepted process documentation standard, avoiding the temptation to improve the process. By simply documenting your existing processes, you will discover opportunities for improvement, but don’t make them at this point. Just document the process as it is currently practiced. Once you have all of your processes documented, then compare the results to the CMMI, add the missing practices, and address any improvement opportunities. Then you will have a set of processes that your employees will have ownership of and will also comply with the CMMI.

And, if you are interested in learning more about the CMMI, take the SEI-licensed Introduction to CMMI class from an SEI-authorized instructor.

Project Classification

I heard from a colleague that project classification needs to be done to be compliant to the Project planning processes. Which Project Planning Specific Practice (SP) refers to project classification?

I am not sure what you mean by project classification. Do you mean application domain? Or project size? Or something else entirely?

My best advice to you is not to listen to colleagues who may not be CMMI experts, but instead work with a CMMI consultant or SEI-certified Lead Appraiser. They will provide you with the best information and CMMI interpretations.

The CMMI does not state that you must classify projects for Project Planning (PP). That is why you are having difficulty determining the applicable Specific Practice.

Applicability of Requirements Development (RD)

Is Requirements Development (RD) applicable for maintenance projects?

If the CMMI-DEV is applicable to your maintenance projects, then the short answer is YES!

Excluding Supplier Agreement Management

Page 440 of CMMI-DEV 1.2 model clearly states that: "SAM process area does not directly address arrangements in which the supplier is integrated into the project team and uses the same processes and reports to the same management as the product developers (for example, integrated teams)."

This statement opens room for some Lead Appraisers to trigger the default button: "SAM is out." But the paragraph continues with the following statement: "Typically, these situations are handled by other processes or functions, possibly external to the project, though some of the specific practices of this process area may be useful in managing the formal agreement with such a supplier."

In my oppinion, not considering SAM may incur problems in the future because you may be postponing the elaboration of a mature way to handle suppliers and contracts and this will be necessary when the organization evolves to higher maturity levels. And, of course, it will be necessary to survive in a global IT world driven by strong and stronger supplier/acquirer relationships.

In my country, only 2 out of 16 organizations who published their Maturity Level 2 appraisals considered SAM in their scope. And, guess what? Many of these organizations use a high number of contractors in their development phases. So, what led them to exclude SAM?

It is important to understand the intent of SAM. If you are augmenting your staff by having a supplier provide people and these people then act, for all intents and purposes, as your employees, then SAM does not apply. Basically, they are following your processes and not managing any of the work on their own, you are managing the work. However, if you give the supplier a chunk of work that they can manage by themselves using their own processes, then SAM applies. So both the organization and the Lead Appraiser need to be aware that if the relationship changes with the supplier, then SAM may move from being N/A to in scope for an appraisal. And you raise a good point, whether or not the Lead Appraiser determines if SAM is in or out of scope, the organization should be aware of the necessary practices it should have in place to manage a supplier.

And if the organization wants to become more sophisticated in managing suppliers, they should be using the CMMI-ACQ.

PPM - Data Analysis

We are a CMMI ver 1.1 level 5 assessed software company and we are in the process of ver 1.2 assessment. As part of this, we are developing the Process Performance Models. We would like to get input on the following points.

1. What kind of statistical analysis are required on the data that is collected for the PPM development?.
2. Do we need to perform Gage R&R test on the data that is collected?. As mentioned, since we are a software company and not a manufacturing company, i am not too sure about the data collection that needs to happen at multiple instances by the same person on the same tool and different person on the same tool.

For example, to check for Repeatability, if I am considering Schedule Variance of various feature development as a measure, there might not be any difference in the schedule variance that will be measured by different people, if the operational definition is clear for the metric.
Now to check for Reproducibility, if competency of the resource for code development is considered as a measure, this could be changing from period to period, as unlike in manufacturing industry where the activities are of repetitive nature. So the reproducibility will be minimal in this scenario.
If its mandatory to perform Gage R&R analysis on the data, can you throw some ideas on the different areas where this can be applied and how the analysis can be performed. Please share your thoughts on this.

It sounds like the Process Performance Models (PPMs) were overlooked for your organization when it was appraised to CMMI v1.1 3 years ago. I would like to make several points regarding PPMs.

1. The CMMI does not specify any required statistical analysis technique for PPM development. Based on your data, your QPPOs, PPBs, the organization has to decide the proper analytic techniques to use. There is a wide variety available for use.
2. What is the reason you are considering Repeatability and Reproducibility? Are you led to these items by your Quality and Process-Performance Objectives (QPPOs)?
3. There is no CMMI requirement to use Gage R&R.
4. It sounds to me that it would be a good idea for you and your organization to have someone facilitate a Measurement and Analysis workshop for you to properly identify your measures, PPBs, and PPMs.
5. You are asking some questions that cannot be properly answered on this blog unless we are working directly with your organization and have some knowledge of your business.

PPQA Audits

Would you please distinguish the different types of audits 1) Projects, 2) Process and 3) products? Does PPQA audit the Project, Process, or Product? Or all the three? And from which area do we need to collect improvements, 1, 2, or 3? I'm confused, can you help?

You say that you are confused. I Let me try to provide an explanation for what I think you are asking about PPQA. The intent of PPQA is to act as the eyes and ears of senior management to ensure that the practitioners are following the documented processes to produce the work products. So PPQA performs two types of audits: process audits and work product audits. Now the processes being audited can be at the individual level, project level, or the organization level. And the processes being audited are not restricted to the CMMI Process Areas. The organization has to determine which processes to audit based on its business goals and objectives, so there may be processes audited in addition to the processes covered by the CMMI.

A process audit is conducted by first studying the documented process and then interviewing the practitioners to determine if they are following the process as documented.

Each process has one or more work products that are produced by following the process. These work products can be at the individual, project, or organizational level as well. The work products can be audited by sitting at a desk and reviewing the work product against the documented requirements for the work product. Is the work product produced correctly? Does it contain the proper level of information? Etc.

Both process and work product audits will identify non-compliances. By analyzing the non-compliance issues, PPQA should be able to identify the underlying causes for the issues and recommend one or more process improvement suggestions.

Estimation Rationale

I guess this seems little silly, but I needed more clarity on it. According to PP 1.2, attributes need to be estimated. Can anyone give me examples of attributes for project? I guess, when we say small, medium , large type projects they form the characteristics of project and not the attibutes. For sure, once we are clear with attributes we can surely ensure that our effort estimates (PP 1.4) are based on estimation rationale. How will project attibutes map up to estimation rationale?

What PP SP 1.2 is addressing is the Basis of Estimate for the project tasks, deliverables, etc. Basically this practice is looking for the sizing attributes that you use to ultimately determine your effort estimates. For a document, an attribute you might estimate is the number of pages for the document that have to be added, modified, or deleted. For hardware, it might be the number of drawings you have to maintain. For software, it might be the number of lines of code, function points, etc. Just using small, medium, or large doesn’t provide a Basis for Estimate. The Basis of Estimate is then your estimation model that is derived from the historical data from prior projects going through this same process. When you first begin to use the Basis of Estimate approach you may not have very good data, or no data at all. So the best you can do is make a guess as to the estimate (SWAG or engineering judgment). But over time as you collect the project data from each project, you will be able to refine this approach and have much better estimates. Then you take these sizing parameters or attributes and apply a productivity factor, again based on your historical data, to arrive at the effort and cost estimates in SP 1.4.

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.

Integrated SCAMPI

I am faced with a problem with determining which CMMI to use (CMMI-DEV, CMMI-SVC, or CMMI-ACQ) for an in-house IT Department that performs all three types of functions for the organization. I face the following questions:

1. Is there an integrated SCAMPI for all three models held together? Or is the scope is simply determined by adding different PAs from different models? In this case, against what model will the ratings be announced?
2. What about the cost paid to the SEI? Is it calculated differently for such a SCAMPI?
3. What about exclusions if all PAs from these three models that are not fully applicable? Is there a way other than pursuing Continuous Representation?
4. Can you recommend any research work done already on integrating the three model for designing and implementing the OSSP?

I will be greatful for your help and support...

As a first step you should hire an SEI-certified Lead Appraiser, preferably in all three constellations, to provide you the proper advice as to which constellation is appropriate for your organization.

I would only recommend that an organization use the CMMI-ACQ if their primary focus was acquiring products and services from vendors. The CMMI-DEV and CMMI-SVC both have the Supplier Agreement Management Process Area, so either constellation will work if acquisition is not the primary focus of the organization.

Here are my answers to your specific questions:

1. It is possible to conduct blended SCAMPI A appraisals that cover more than one constellation. But your Lead Appraiser will have to work with your organization and the SEI on how best to perform the blended appraisal and determine your Capability or Maturity Level ratings.
2. There are NO fees paid to the SEI by the organization for any appraisal. Any appraisal costs are negotiated between you and your Lead Appraiser.
3. The determination of the appraisal scope is performed jointly with your Lead Appraiser when planning the appraisal. The appraisal scope specifies the representation and the Process Areas being evaluated.
4. I am unaware of any reported results using blended constellations. Though Mike Phillips from the SEI has said that blended SCAMPIs are permissible. I suggest that you contact the SEI and ask for this kind of information, if it exists.

Definition of SOW

I would like to know what is the content of the Statement of Work and how does this document meet requirements of the CMMI?

As a best practice with definition questions, the first place to look is the CMMI Glossary. In this case there is a definition of Statement of Work (SOW) in the Glossary. “A description of contracted work required to complete a project.” In other words, the SOW contains the requirements for what you have to delivery to the customer. And there are varying levels of detail from SOW to SOW depending on the size, criticality, and nature of the work. For large government contracts, the SOW may also contain the Work Breakdown Structure (WBS) for the program/project as well. At a minimum, the SOW will contain the customer’s requirements that the organization will further develop. So the SOW supports RD and may also support PP.

CMMI-SVC and Emergence of Open Organizations

Emergence of Open Organization- when will it happen? LinkedIn + Google+Sourceforge+Newscale + Visa
I foresee Newscale/ Pinky/SEI coming up with a master service catalogue that could be integrated with Google where any Group member can have his own service catalog in his profile. The Group Service catalog could well be an Organization's service catalog. Probably any individual would say he has his office is in Yahoo!, Google etc and may add that he works for a particular social enterprise/many enterprises. I also feel that some governmental procedures or a global standard will evolve for the governance of Open companies. My question is does the CMMI-SVC address this?

What you are asking about is a virtual office environment and the tools to enable this environment. There are two practices in the CMMI that address work environments: OPD SP 1.6 Establish and maintain work environment standards and IPM SP 1.3 Establish and maintain the project’s work environment based on the organization’s work environment standards. Since both OPD and IPM are Core Process Areas (PAs), they are common to all CMMI constellations CMMI-DEV, CMMI-ACQ, and CMMI-SVC. So your virtual office concept can work with any of the three constellations.

Advice on a Gap Analysis

For the first assessment, does the gap analysis have to be performed against practices or against work products?

There are no specified standard requirements for a Gap Analysis. The Gap Analysis is intended to identify major differences between a model standard and actual practice. A Gap Analysis may involve just reviewing documents, just interviewing people, or a combination of both. I like to evaluate a combination of documents and people for a Gap Analysis. This approach yields the best results, because in many cases the process as practiced is different from the process as documented.

Definition of Work Product Terms

What is the meaning of the following work products: WBS task dictionary, documented requests for commitments, and documented commitments?

There are no unique definitions for these terms in the context of the CMMI. Otherwise these terms would be defined in the CMMI Glossary. These are standard Project Management terms.

The WBS Task Dictionary is the list of tasks, deliverables, and predecessor/successor relationships between the tasks. There is sufficient information provided so anyone using the WBS Task Dictionary will have enough information to create a WBS for a project.

Documented Requests for Commitments means exactly what the words say. A request for a commitment. It can be as simple as emailing a document to someone for their commitment and approval.

Documented Commitments again means exactly what the words say. Basically the commitments made by the various parties and stakeholders are written down somewhere.

KPA vs. PA

What is the difference between the terms KPA and PA?

KPA stands for Key Process Area and applied to the Capability Maturity Model (CMM) that was retired years ago. This term no longer has any meaning.

PA stands for a CMMI Process Area.

KPA and PA are basically the same, but KPA is only relevant for the obsolete CMM and PA is only relevant for the current CMMI.

The CMMI Glossary defines a Process Area as a cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making improvements in that area. All CMMI Process Areas are common to both the Continuous and Staged Representations.

Challenges with Implementing the CMMI in Small Settings

At the 2009 North American SEPG Conference in San Jose last week, I was the first presenter in the Small Settings track. This was a well attended presentation and I wanted to share it on my blog with those of you who were not able to attend this year. I also wrote a companion article published by ExecutiveBrief that you can read at Small Business and the CMMI: Sink or Swim.

Challenges with Implementing the CMMI in Small Settings

View more presentations from Henry Schneider.