« July 2008 | Main | October 2009 »

April 18, 2009

PPQA Philosophy

One of the things I appreciate most about PPQA is its departure from widely held views of the quality assurance role.  Many professionals have been exposed only to a rather customary QA approach in which activities are designed only to provide senior management insight.  Often, this approach places QA people into something of a "tattletale" role, and not surprisingly, projects view them with suspicion.

PPQA is the DEV model's shortest PA (probably also in ACQ and SVC, but I haven't checked to be sure).  There isn't much material in its Specific Practices by Goal section.  Its Introductory Notes are relatively lengthy, though, and they're a rich source of information about PPQA's intent and even its philosophy.  Among other things, the Introductory Notes establish a distinct tone of respectful and helpful project support.

"Quality assurance should begin in the early phases
of a project to establish plans, processes, standards,
and procedures that will add value to the project and
satisfy the requirements of the project and the
organizational policies. Those performing quality
assurance participate in establishing the plans, processes,
standards, and procedures to ensure that they fit the
project's needs and that they will be useable for
performing quality assurance evaluations. In addition,
the specific processes and associated work products that
will be evaluated during the project are designated. This
designation may be based on sampling or on objective
criteria that are consistent with organizational policies
and project requirements and needs." [emphasis added]

The next paragraph reinforces this collaborative view:

"When noncompliance issues are identified, they are first
addressed within the project and resolved there if possible.
Any noncompliance issues that cannot be resolved within the
project are escalated to an appropriate level of management
for resolution." [emphasis added]

The image of asking a respected colleague to provide a "sanity check" comes to mind whenever I read this material.

Management oversight certainly is a part of PPQA, and an important one at that.  And management oversight is clearly evident in the escalation language quoted above and in SG 2.  I just feel that the collaborative project support aspects of the PA are essential, and should be factored into any CMMI-based process improvement implementation.  Collaborative is more likely to be overlooked, though, because it's outside many professionals' personal experience, and it's easy to miss in the scarce PPQA material.  [Unfortunately, many people don't seem to spend much time in any of the PAs' Introductory Notes sections.]

Posted by Chuck Myers at 03:35 PM | | Comments (0) | TrackBacks (0)

REQM and PA Categories

I find REQM to be rather mixed in relation to the PA categories.  In the DEV model it's been placed in Engineering.  In ACQ and SVC it's in Project Management.  I would guess (and that's all it is) that V 1.3 probably will place it in the latter category for all three models, as that would provide more consistency in the CMF.

I've long felt that one could argue for REQM's assignment to Project Management, Engineering, or Support because of the diversity among its SP's:

  - SP 1.1 (Develop an understanding with the requirements providers on the meaning of the requirements.) seems to be closely related to--and might even be included in--RD.  This SP argues for the Engineering placement.

  - SP 1.2 (Obtain commitment to the requirements from the project participants.) seems to lean more toward Project Management.

  - SP 1.3 (Manage changes to the requirements as they evolve during the project.) clearly ties to CM, particularly to SG 2.

  - SP 1.4 (Maintain bidirectional traceability among the requirements and work products.) has an obvious Engineering flavor to it, but it also smacks of the same sort of administrative work that's provided by the ML 2 Support PAs.

  - SP 1.5 (Identify inconsistencies between the project plans and work products and the requirements.) leans pretty clearly in the Project Management direction for me, as with SP 1.2.

All the practices relate to requirements in some way, so for me it makes sense to put them in close proximity within a single PA.  The criticality of requirements as the root cause of many ML 1 problems further argues for some explicit, special attention.

REQM interacts significantly with many of the Project Management, Engineering, and Support PAs.  Addressing all of those interactions would require far too much time and space for discussion here, but they constitute one of the model threads that's well worth taking the time to investigate further on one's own.

Awareness of REQM's interaction with the work described by so many PAs can be of great help when implementing CMMI-based process improvement.

Posted by Chuck Myers at 02:09 PM | | Comments (0) | TrackBacks (0)