Developing Questions for the CMMI Specific and Generic Goals Would Lead to Implementing Alternative Practices

I would be very CAUTIOUS about taking this approach to implementing the CMMI. The CMMI authors did not go to the lengths they did with defining the Expected components (Specific and Generic Practices) if all they really wanted an organization to do was start at the Goals and identify the supporting practices. In my experience as a Lead Appraiser, it is only on the rare occasion that I have identified and documented an alternative practice in a SCAMPI. 99.999% of the time, the organization’s practices are aligned with the Expected components. And I assert that the only time an alternative practice comes up is with legacy projects that are years in duration using practices that are no longer state of the art and there is no business value in changing them. For example one of the underlying assumptions of REQM is that an organization is using tools to help manage and control the project’s requirements. But if the original requirements were established before the advent of requirements tools and the organization’s documented process for reviewing and managing requirements was to manually review, trace, and track requirements through meetings and discussions re-deriving the traceability each time and the process works, it is an alternative practice. There is no requirements database, just a requirements document. There is no requirements traceability matrix or requirements tracking system, just the documented requirements and the expertise of the requirements analysts who are highly trained in how to procedurally review, maintain, manage, and control requirements. So it is difficult to evaluate SP 1.1 – 1.5 as FI, but REQM SG 1 is clearly FI.

How Can I Manage Both Legacy and Maintenance Projects?

The nature of the work does not preclude the organization from having to follow processes. The organization simply has to define the processes correctly for the different types of work and domains. For a Maturity Level 2 (ML 2) organization, this approach comes down to how the organization defines a project. In my experience, clients who are managing legacy and/or maintenance projects initially define individual changes as a project and it kills them because of everything required by Project Planning (PP) and Project Monitoring and Control (PMC). So the organization then has to think about how they manage work. At what level do they create a project schedule? Is it for each change? Or is it for a group of changes? Or is it on an annual basis? Basically the changes for maintenance work tend to be treated as a “job jar” and the organization pulls different jobs out of the jar to work on. So my clients in this situation, then consider work being managed annually, meaning that there is an annual project plan covering staffing levels, training, etc. That is, most of the PP Specific Practices (SPs). Then when they work on a specific job or task, they have a mini-schedule that is reviewed and compared to the annual plan to ensure that everything is compatible and they work to the mini-schedule using the annual project plan.

For legacy projects, the project plan, if it exists, was created well before the organization heard of or considered implementing a process improvement model like the CMMI. Consequently whatever exists was not developed per the current PP processes and there is no business value to go back and attempt to retrofit the old plan to the current process. What does make sense is for all project re-planning and re-baselining activities from this point forward to follow the new PP processes.

What is the Difference Between a Physical Configuration Audit and a Functional Configuration Audit?

A Physical Configuration Audit (PCA) is a Configuration Management (CM) audit that verifies that whatever you have built conforms to the technical documentation that defines the build. What that means is that CM must compare the configuration of the as-built product to the design documentation of the product. For example, CM looks at the list of all the configuration items (versions, etc.) in the as-built product and compares that list to the list of what is supposed to be in the product.

A Functional Configuration Audit (FCA) is a CM audit that verifies that the functions of the as-built product match the baselined functional requirements and that the operational and support documentation is complete and satisfactory.

Challenges With SEPG Staffing

Amir Shahzad Khan posted these two fairly realistic scenarios to the CMMI discussion group.

Scenario 1
We have resources that are on the bench waiting to start a new project and/or new billable work. We have decided to draw on this pool of idle resources to staff the SEPG and the ML 3 process teams. Each person has accepted these new responsibilities and they are working their assigned SEPG tasks. Suddenly, there is new billable work or a new project starts. Now management reassigns these resources that were on the bench to the new work leaving their assigned SEPG tasks incomplete, severely impacting the SEPG schedule. How to do tackle this kind of situation?

Scenario 2
People are selected from the organization to staff the SEPG. They are assigned to Process Areas that match their area of expertise. However, most people are reluctant to work on their assigned SEPG tasks and they either don’t deliver or deliver much less than expected, which impacts the SEPG schedule. The primary reason of their reluctance to deliver is that they don’t consider their assigned SEPG tasks as their core area of responsibility. Since the SEPG support will not affect their performance appraisal they don’t take it seriously. They only receive verbal appreciation. What kind of reward or penalty can be introduced in this regard so that people deliver what they have committed?

What is described in both scenarios is a serious lack of Management Commitment to process improvement, the SEPG, and the CMMI. Lack of Management Commitment is your worst enemy and will effectively kill all of your efforts, despite your best intentions. What is necessary is for management at ALL levels in the organization to actively support these initiatives, not just pay lip service.

Scenario One
First off it is a bad idea to assign people on the bench some SEPG “busy work” just to keep them occupied until a billing opportunity comes along. You should have recognized this problem as one of your major risks in the Process Improvement Plan and defined a Risk Mitigation strategy to use when people are reassigned and removed from their SEPG duties. The SEPG should report these issues to the Management Steering Group (MSG), who should be held accountable for allowing key SEPG resources to be reassigned. If these resources are also key people for billable work, they should have never been assigned to the SEPG. Instead they could be considered as Subject Matter Experts that can be called upon from time to time to consult with the SEPG. There should be a core set of dedicated people on the SEPG. Others who have “signed up” to work on the SEPG should be allowed by management to support the meetings, even if they have been reassigned. Look at the IPPD practices in OPD and IPM for guidance on establishing these types of management mechanisms.

Scenario Two
This scenario sounds like management has not given clear direction as to the importance of the SEPG to its members and the organization as a whole. If management doesn’t clearly think that the SEPG is important, then why should anyone else? The Process Improvement Plan should have identified this problem as a major risk as well. If someone has been assigned to the SEPG, their SEPG role should be part of their job and they should be held accountable for their performance of their assigned duties. The SEPG is effectively the project team and the MSG the project manager. The MSG should be taking a major role in reviewing the progress to the plan and resolving issues in both scenarios.

Process Improvement - A Twelve Step Process

1. We admitted we were powerless over quality/on-time delivery/estimates/project management/etc. – that our projects had become unmanageable.
2. We came to believe that a model greater than ourselves (the CMMI) could restore us to sanity.
3. We made a decision to turn our processes and procedures over to the care of Software Engineering Institute.
4. We conducted a searching and fearless gap analysis of our organization.
5. We admitted to our Lead Appraiser, to ourselves, and to our executive management the exact nature of our process weaknesses and gaps.
6. We were entirely ready to have our Lead Appraiser help us address these weaknesses and gaps.
7. We humbly asked our Lead Appraiser to help us remove our weaknesses.
8. We made a list of all projects that had suffered because of our bad practices, and became willing to take corrective actions to address the issues, as applicable.
9. We made direct modifications to our processes wherever possible, except when to do so would jeopardize the success a project.
10. We continued to appraise the organization, and when we had weaknesses we promptly admitted them.
11. We sought through the Engineering Process Group (EPG) and the Management Steering Group (MSG), to improve our direct contact with our Lead Appraiser and the SEI, asking only for their knowledge and expertise to guide us on our process improvement journey.
12. We have recognized the benefits of process improvement as the result of these twelve steps; we have tried to carry this message to other internal groups and external organizations and to practice these principles in all our affairs.

CMMI-ACQ - Agreement Management

Agreement Management (AM) is a Maturity Level 2 (ML 2) Process Area (PA) in the CMMI-ACQ. Basically this PA is a more robust treatment of the CMMI-DEV PA Supplier Agreement Management (SAM) Specific Goal 2 (SG 2), Satisfy Supplier Agreements. The Specific Goal and most of the Specific Practices have the same titles between the two PAs. However, the details are quite different.

AM only has one Specific Goal - The terms of the supplier agreement are met by both the acquirer and the supplier. SAM uses the term project instead of acquirer. This difference means that AM is applied in a broader sense than SAM. SAM focusses on the project's needs for acquiring a product or service from a supplier. AM focusses on the acquirer, which may be
· Procurement
· Purchasing
· Outsourcing
· Supply chain
· Buyer
· Contracting
· Logistics
· Supply sourcing
etc.
Mike Phillips/SEI said in the CMMI-ACQ class that he has a list of 17 different terms for acquirer.

How do I handle negative responses to process improvement or the CMMI?

Some people will always object. There is a saying, “you can take a horse to water, but you can’t make him drink”, which is so apropos to negative reactions to any process improvement initiative. What you have to keep in mind is that people generally fall into one of five populations when it comes to making changes: Innovators, Early Adopters, Early Majority, Late Majority, and Laggards. Innovators, Early Adopters, and the Early Majority are usually those people who are open minded, see the value of models and standards, and are willing to make a change. The Late Majority and Laggards resist change and do not see the value of any model or standard process. I have heard of these type of people referred to as CAVE (Citizens Against Virtually Everything). You may want to look at my presentation on Managing Cultural Change in the Slideshow sidebar on the right of this blog.

I ran into this problem years ago when I was the ISO 9000 Management Representative in a small software company. It was a constant struggle to get people to document and follow their procedures. I even had one developer who said “I just want to be left alone in my office with the door shut so I can write code.” I just had to maintain a positive attitude and continue working towards the end goal despite all the negativity and stupid comments like “OK, what is the documented procedure for making coffee now?”

I had another experience a few years back trying to teach the Software CMM class at a client site. Most of the students didn’t want to be in the class, but were forced to by management. In fact, there was one particular student who just sat in class, did not participate, and had a smug smile on his face the whole time. Half way through the second day the client decided, based on feedback from the students after hours on Day 1, to cancel the remainder of the class because they felt they didn’t need the training, it didn’t teach them anything they didn’t already know, and therefore it was of no value to them.

There isn’t a whole lot you can do with this attitude. You basically are a lone voice crying in the wilderness. They won’t listen to you no matter what you tell them. I characterize these types of people and organizations as being in the first step of the Twelve Step Process, they are in denial. They are a disaster waiting to happen and nothing is going to budge them to look at things differently until after something bad happens. About all you can do is “plant the seed” about the CMMI and process improvement and walk away. When things take a turn for the worse, they may remember what you told them and they may come back to you for help.

Help! I am Totally Lost When Interpreting the QPM Specific Practices

QPM SP 1.1 states “Establish and maintain the project’s quality and process-performance objectives.” When you are starting to implement the Maturity Level 4 PAs you won’t have a Process Capability Baseline, that is ultimately the goal of being at ML 4 so the organization can then move to ML 5. One of the main thrusts of ML 4 is to analyze the process data looking for Special Causes of Variation. Once those have been analyzed, then it is possible to determine the process capability. For SP 1.1 the project’s quality and process-performance objectives (QPPOs) are set by management and are based, in part, on the organization’s objectives (OPP SP 1.3). The Process Performance Models (PPMs) are then used to determine if the QPPOs can be met. If not, the QPPOs should be appropriately adjusted.

QPM SP 1.2 states "Select the sub-processes that compose the project's defined process based on historical stability and capability datat." One of the key words in this practice statement is "historical". Sources of historical stability and capability data include the organization’s process performance baselines (PPBs) and PPMs (OPP SP 1.4 and SP 1.5). And the intent of this practice is to tailor the organization’s standard processes (OSSP) so the project’s processes will support the project’s QPPOs defined in SP 1.1.

QPM SP 1.3 states “Select the sub-processes of the project’s defined process that will be statistically managed.” The model does not say that these sub-processes MUST be statistically managed, but these WILL be statistically managed. And this practice focuses more on than just selecting sub-processes. It also focuses on identifying the attributes of each sub-process that will be used to statistically manage the sub-process.

People appear to get confused with Maturity Level 4 (ML 4) sounds when trying to understand QPM independently from the rest of the model. You cannot do that. You have to consider OPP and QPM together when looking at ML 4. OPP provides the analysis of the historical data to build the PPBs and PPMs which are then used by the projects to help them appropriately tailor the OSSP to what will meet the project’s QPPOs. QPM SP 1.2 uses the word "compose", which may contribute to some of the confusion. Since compose is not in the CMMI Glossary, then the dictionary definition is applicable. The Webster definition of compose is “To form by putting together two or more things or parts; to put together; to make up; to fashion.” So for this practice, compose means going to the OSSP and selecting the processes and sub-processes that will meet the QPPOs and then applying the necessary tailoring criteria. What this practice implies is that the OSSP may have several different processes for each Process Area (PA) so the project manager can choose the most appropriate one when composing the project's defined process.

Another ML 4 concept that may be the cause of confusion is the notion of Quantitative Management vs. Statistical Management. QPM SG 1 is all about quantitatively managing the project, which means the Project Manager must be periodically reviewing progress, performance, and risks using the PPMs to determine/predict if the project will meet its QPPOs. If not, then appropriate correctives actions must be taken to address the deficiencies in achieving the project’s QPPOs (QPM SP 1.4) Statistical Management is covered by QPM SG 2. The intent is for the project to statistically manage those sub-processes that are critical to achieving the project’s QPPOs. There are only a small set of sub-processes that are critical to achieving the project’s QPPOs. If the organization were to statistically manage all processes, that would be insane. This approach would mean that the organization would need PPBs and PPMs for EVERY process, regardless of their importance to the QPPOs. And then the shear overhead of collecting, analyzing, and reporting data on every process would most likely bring the organization to its knees. Work would come to a standstill because it was taking far too much time to statistically manage each process and taking corrective actions that may not be necessary. Unless you have an infinite budget and dedicated staff to perform these analyses, that is why the model states to statistically manage SELECTED sub-processes.

CMMI for Acquisition Process Areas

There are 6 CMMI for Acquisition (CMMI-ACQ) Process Areas (PAs) unique to this new constellation: Agreement Management (AM), Acquisition Requirements Development (ARD), Acquisition Technical Management (ATM), Acquisition Validation (AVAL), Acquisition Verification (AVER), and Solicitation and Supplier Agreement Development (SSAD). AM, ARD, and SSAD are Maturity Level 2 PAs and ATM, AVAL, and AVER are Maturity Level 3 PAs.

In addition to these six new PAs, there are other changes at the Specific Practice level in Project Planning (PP), Project Monitoring and Control (PMC), Integrated Project Management (IPM), and Organizational Process Definition (OPD).

PP SP 1.1 - Establish and maintain the acquisition strategy

PP SP 2.7 - Plan transition to operations and support (the addition of this SP makes the old SP 2.7 now SP 2.8)

PMC SP 1.8 - Monitor transition to operations and support

OPD SP 1.7 - Establsh and maintain organizational rules and guidelines for the structure, formation, and operation of integrated teams

IPM SP 1.6 - Establish and maintain integrated teams

The difficult concept to understand if your background is in the CMMI for Development (CMMI-DEV)is that every core PA is interpreted in the context of the acquirer's processes.

When looking at the Continuous Representation for CMMI-ACQ the category Acqusition replaces the category Engineering from the CMMI-DEV constellation. And the other change is that Requirements Management (REQM) is now included in the Project Management category.

And on a final note, it is possible to perform a blended appraisal CMMI-DEV and CMMI-ACQ.

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.

Process Improvement in Small Organizations

On the final day of the 2008 SEPG Conference in Tampa this year there was a very interesting practitioner discussion by two small companies on their experiences in implementing CMMI Maturity Level 2. Their biggest challenge was funding the effort. Fortunately for them, they had three funding streams to draw on:
1. Internal funding
2. Contract funds
3. Funding from their mentor/protege partner
What was significant for these two companies was their levels of senior management commitment. The President of one of the companies was actively engaged with their efforts. He sat in the same office with the team and reviewed the documentation. He had a very hands-on approach that led to rapid implementation. This type of approach won't always work. Senior management has to have the proper attitude towards process improvement and be very supportive.

Other steps these companies took to rapidly improve were to establish a Management Steering Group (MSG) and Engineering Process Group (EPG) very early on as well as provide detailed training on a Process Area (PA) by PA basis, about every two weeks. They had discovered that the Introduction to CMMI class was a great introduction, as indicated by the course title, but the information did not sink in at first. They needed more in-depth discussions, which then led the teams to become more proficient in their PA roles. They also engaged with their mentor/protege (in other words, their CMMI consultant) early on as well who provided guidance and how to implement the model and avoid known pitfalls.

It was interesting to note that the lessons learned by these two small companies are the same lessons learned by much larger organizations and align with what we CMMI consultants and Lead Appraisers always tell our clients. But these lessons are much harder to "sell" to small companies that are seriously resource constrained.

Setting Proper Goals and Objectives

On choosing a transition partner for process improvment... : Green & White
One of the underlying issues in the "doomsday scenario" discussed in this article is management commitment and the proper setting of Business Goals and Objectives, Process Goals and Objectives, Quality Goals and Objectives, Project Management Goals and Objectives, etc. Achieving a certification like ISO 9000 or a CMMI Maturity Level is NOT, and should NEVER be, one of these Goals and Objectives. Unfortunately, setting the achievement of ISO or a CMMI Matuity Level is often what I see as a Business Goal and Objective when I teach the CMMI class or pay the initial visit to a new client. When the organization has this view of why it is in business, then they display ALL of the dysfunctional behaviors you noted above.

In my experience, most managers do not know how to perform proper goal setting without some coaching and mentoring. Either the goals are too lofty (motherhood and apple pie) or they have nothing to do with their core business (achieve ISO 9000 etc.).

And if their customers are demanding ISO 9000 or CMMI in order for the company to win new business, then it is extremely difficult to get management's attention to set proper goals and objectives.

CMMI for Acquisition

PPQC Adds Delivery of CMMI-ACQ Training and Appraisals to Its Offerings

I am pleased to announce that PPQC is now authorized by the Software Engineering Institute as a partner provider for the CMMI-ACQ, both as a provider of the CMMI-ACQ training class and also SCAMPI A, B, and C appraisals to the CMMI-ACQ. Visit these links for more information PPQC Services and PPQC Training.

The CMMI-ACQ version 1.2 was released in November 2007 and it provides guidance for the application of CMMI best practices by the acquirer. Best practices in the model focus on activities for initiating and managing the acquisition of products and services that meet the needs of the customer. Although suppliers may provide artifacts useful to the processes addressed in CMMI-ACQ, the focus of the model is on the processes of the acquirer. CMMI-ACQ integrates bodies of knowledge that are essential for an acquirer.

By integrating these bodies of knowledge, CMMI-ACQ provides a comprehensive set of best practices for acquiring products and services. CMMI-DEV may be treated as a reference for supplier-executed activities for systems engineering, software development, and hardware design work in an acquisition initiative. In those cases where the acquirer also has a role as a product or service developer (e.g., taking responsibility for the first few layers of product development and integration), CMMI-DEV (in particular the Requirements Development, Technical Solution, and Product Integration Process Areas) should also be used to improve the acquirer's product or service development processes.

Changes to Intro to CMMI Training and Appraisals for CMMI-ACQ

When taking the CMMI-ACQ upgrade training class from the SEI on March 21, there were a number of important changes that will impact CMMI Instructors, Lead Appraisers, and organizations that I think should be made available. No doubt over the next few months more information will be communicated by the SEI.

The FERPA form has been a pain for instructors because you have to be sure to collect them from each student and submit them to the SEI. In the past the SEI has stated that the FERPA forms were required by Carnegie Melon. In addition, the FERPA form is required so the results can be input to SAS and then made available to the Lead Appraiser when planning an appraisal.

The SEI made some small incremental additions to the core 16 Process Areas to accommodate ACQ. These changes are to the informative material. The CMMI Constellation architecture allows the SEI the freedom to tailor the core PAs at the sub-practice level. The sub-practice changes are posted on the web.

There is no difference in SCAMPI appraisals for the CMMI-ACQ. The SAS is almost ready to use for CMMI-ACQ.

On-line training for CMMI-ACQ is being developed with blended learning and will be available in May at about the same cost. The intent is that students can take the class online and then the instructor will schedule an online meeting with the class to discuss the material.

The CMMI-ACQ contains a new feature in the Process Areas. Typical Supplier Deliverables. This new feature ≠ deliverable artifacts. The Typical Supplier Deliverables are there to remind the acquirer of typical work products the acquirer might produce

The core Process Areas have some differences and this is intentional. To quote Rusty Young “Informative NOT Ignorative!” so the changes are important to note.

The CMMI-ACQ class will be a one-day add on training class. The current plan is to deliver the three-day class ( a generalist course) followed by a single day supplemental class in either DEV, ACQ, or SVC. The three-day CMMI class is for most people and the one-day supplemental is intended for Appraisal Team Members. This new structure will be available in about a year from now, March 2009.

When conducting a SCAMPI for a combined DEV and ACQ appraisal use the Continuous Representation if the overlap of the two constellations becomes a strength. You should be able to enter CMMI-DEV plus some ACQ PAs that best fit in the OTHER category in SAS.

The SEI relabled the categories in the Continuous Representation for CMMI-ACQ. REQM is included in Project Management.

And, finally, comparisons of the CMMI-ACQ to CMMI-DEV are provided at http://www.sei.cmu.edu/cmmi/models/ACQ-v12-comparetoDEV.html . Go to the bottom of the page for chapter-by-chapter detailed comparisons and to download PDF copies.
There may be a CMMI v1.2a update released after all the CMMI constellations have been released, perhaps by the end of 2009. And it may be called v1.3 instead.

Establishing the Verification Environment

VER SP 1.2 is “Establish and maintain the environment to support verification.” Companion practices are 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.”

So what this all means is that you have to define at the organization level what the standards are for verification environments, in IPM define the project’s verification environment(s) in the project plan, and in VER define what the various verification environments are. When you consider VER, there are at least two and possibly more verification environments depending on the system you are developing. At a minimum you have a peer review environment and a product testing environment. Both of these environments have requirements, resources, equipment, and tools which you will have to define yourself. In the case of peer reviews and inspections the environment is many times just the conference room with a whiteboard, LAN connection, computer, and a projector, plus other requirements. The testing environment may be a specific room and equipment set aside as a testing lab, etc. So, to implement VER SP 1.2 you have to define the requirements for each verification environment that you have defined for the project, along with the resources, equipment, and tools, and then the acquisition of these items to actually construct and maintain the environment(s), which also include upgrades over time.

And keep in mind the CMMI definition of the phrase “establish and maintain”, which means formulate, document, and use. Therefore you need to design the environment, document the environment, and use the environment for verification.