Review Activity for a Short Term Project

Our organization will be going through CMMI Maturity Level 2 Appraisal in a couple of months. I have a PPQA question. As per the PPQA Process Area (PA), we require a review of the work products (content/template) and procedures required at Maturity Level2 during the project life cycle. We have one project that is 3 months long. There are many work products that will be produced during the project development life cycle.

• Requirement documents such as SRS, Use cases, Bidirectionally traceability matrix document, change log, etc;
• Plans for all the PAs, e.g. requirements management plan, project plan, configuration plan, etc;
• Development artifacts, such as ERD, Code, UML diagrams, etc;
• QC artifacts, such as test cases, test reports, etc.
• Monitoring/controlling artifacts, such as Issue list, MoMs, Risks, etc.

How is it possible to review the work products for a 3 month project when we don't have a separate QA department and the stakeholders involved in development do the work product reviews one way or the other.

This same question holds true for reviewing procedures.

Of course, we review high priority documents, such as Project Plan, Use Cases, ERD, Application; but not all of them.

Can you help me understand what should be done for a short duration project, such that the PPQA PA requirements are met and we don't have to hire separate people just to fulfill the requirement?

The first thing that I would do is postpone your ML 2 SCAMPI A appraisal as apparently you have a major risk to achieving ML 2 since PPQA does not appear to be in place in your organization. And even if you could put PPQA in place for a 3 month project between now and your appraisals, that may still not be enough time to demonstrate institutionalization, meaning that you have a repeatable process. Essentially you will have one project using PPQA, which is one data point. And it is not possible to determine institutionalization from one data point. Your organization will be at serious risk of not achieving ML 2.

Industry average shows that PPQA is 3 – 5% of your organization. You haven’t told me how large your organization is. But if your organization is 25 people, than 1 person should be assigned to perform the PPQA practices.

I think that you are misunderstanding the differences between reviewing a work product and objectively evaluating a work product. It sounds like your project teams are already reviewing the work products. The role of PPQA is not to review the work products, but to audit the work products and processes to ensure that the work products follow the specific standards and are products according to your documented processes.

I highly recommend that you, or someone you select in your organization, take a training class on how to perform PPQA. I cannot adequately explain how to perform PPQA and answer your specific questions in this blog. The person you select for the training needs to be taught how to conduct a work product audit, how to conduct a process audit, how to plan PPQA audits, how to communicate audit results, and how to track audit non-compliances to resolution. If you don’t already have this capability in house, it will take some time to develop it internally. And I strongly advise against using an external consultant to provide this service. PPQA is for the benefit of your organization and management. It is essentially the eyes and ears of your senior management. And an external consultant may be motivated by other considerations than your best business interests if asked to provide PPQA services.

Reviewing Process Status with Senior Management

When a manager reviews the work products of a process, is it not effectively the same as reviewing the process? The model can't expect status reports to senior management to have a list of 18 or 22 process areas to be reviewed with senior management on a regular basis. Project managers I work with could see no possible value in this and their managers/supervisors won't listen to it. And it's not because they don't want to support process improvement.

It sounds like you are having difficulty understanding the intent of GP 2.10 “Review the activities, status, and results of the process with higher level management and resolve issues.”

First off, I need to ask you why is a manager reviewing the process work products? The model doesn’t require that managers review process work products. However, it sounds like your processes may have this requirement.

GP 2.9 “Objectively evaluate adherence of the process against its process description, standards, and procedures, and address noncompliance” does call for objectively evaluating selected work products, but this is a PPQA responsibility. And the intent is to determine if the work product meets the requirements of your documented processes and applicable standards.
There is a huge difference between reviewing a process work product and reviewing the process. Just because a work product exists does not mean that the documented process was followed for producing the work product. For example, your design process states that you document the customer requirements first, then you derive the functional requirements from the customer requirements and create a functional requirements spec. Then you create a design based on the functional requirements and write a design specification. So you would expect to find these three documents in the project folder at the end of the project.

Scenario 1) The project follows the documented procedures and produces the documents in the order described and per the procedures.
Scenario 2) The project doesn’t follow the documented procedures and launches immediately into design and when preparing to close out the project, they rapidly create these three documents .

The work products exist for both scenarios, but they have value in Scenario 1 and no added no value in Scenario 2 and could be viewed as a waste of time to create. In addition for Scenario 2, the product documentation was written per the design, when in fact the product was supposed to be designed per the written documentation.

So, simply reviewing a document will NOT be the same as reviewing the process.

Now to get back to GP 2.10, the intent of this GP is to provide higher management with appropriate visibility into the process. The reviews called for by GP 2.10 are for managers who provide the policy and overall guidance for the process, not for those who perform the direct day-to-day monitoring and controlling of the process (which is the intent of GP 2.8). The intent of GP 2.10 is review the process results, which is typically an aggregate of the results across projects, not the detailed process results on each project. And yes, the expectation is that higher management reviews the process results for ALL Process Areas (PAs) in scope; 7 PAs for Maturity Level 2, 18 PAs for Maturity Level 3, 20 PAs for Maturity Level 4, and 22 PAs for Maturity Level 5. Why else would this be a Generic Practice? But keep in mind how you have implemented these PAs. Most likely your implementation has combined some PAs into a single process and you may also have multiple processes for a single PA. The intent of GP 2.10 is to review your processes. When you prepare for an appraisal you simply have to demonstrate that you have covered each PA with your process reviews.

From a practical standpoint, it is tedious to review the complete set of PAs in scope at a single setting. Especially those processes that do not occur often and there may be nothing new to review. It also depends on the frequency of your process reviews. The model does not specify a frequency, it has to be set by the organization. You can also have these reviews be event-driven. One approach that I have seen work in several clients is to hold quarterly process review meetings with senior management and only review a subset of the PAs at each review. There is an overall plan for reviewing the PAs, for example it may take a year to complete the PA set, but each quarterly review only examines ¼ of the PAs. That eases the burden on everyone. Then if a process issue arises and that PA is not due to be reviewed for 9 months, a special event-driven review for that PA is held.