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.