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.