REQM SP 1.2 Question

Can you please help me?

I am developing a study based on CMMI-DEV and I am having some difficulty with the interpretation of Specific Practice 1.2. My concern is how to apply SP 1.2 in practice. Who are the members of the project that must be committed to the requirements (business analysts, systems analysts, test analysts, developers, systems architects, project manager, and project leader)?

How should their commitment be documented? For example, for each new or changed requirement the members must sign a document that means that they are aware of the requirement and are committed to it.

Do you have a copy of the Addison Wesley published CMMI-DEV version 1.2? If so, there are some very helpful tips in the margins for REQM SP 1.2.

When you have a set of requirements for a project team, everyone on the team impacted by the requirements needs to share a common understanding of the requirements. In addition, since you typically do not have the full set of requirements available at project start, the project team needs to continually evaluate and reevaluate their ability to meet the requirements as the requirements evolve over the life of the project. One way of evaluating requirements is an impact assessment on the existing requirements, design, documents, test cases, current and downstream tasks and activities, cost, schedule, etc. for a new or changed requirement. By going through an impact analysis, that will provide a way for the project participants to communicate their ability to meet the requirements and associated commitments. The resulting impact analysis report can be one way of documenting the commitment. Other methods for documenting commitments include meeting minutes, document signatures, or email. However, just signing a document indicating that the participants are aware of a requirement really does not indicate that they are committed to the requirements and you might run into difficulties later on in the lifecycle.

Please keep in mind that commitments include both the resources involved (people, tools, and facilities) and the schedule for completion.

Definition of Work Product Terms

What is the meaning of the following work products: WBS task dictionary, documented requests for commitments, and documented commitments?

There are no unique definitions for these terms in the context of the CMMI. Otherwise these terms would be defined in the CMMI Glossary. These are standard Project Management terms.

The WBS Task Dictionary is the list of tasks, deliverables, and predecessor/successor relationships between the tasks. There is sufficient information provided so anyone using the WBS Task Dictionary will have enough information to create a WBS for a project.

Documented Requests for Commitments means exactly what the words say. A request for a commitment. It can be as simple as emailing a document to someone for their commitment and approval.

Documented Commitments again means exactly what the words say. Basically the commitments made by the various parties and stakeholders are written down somewhere.

Confusion regarding Project Montoring and Control

I have some confusion regarding Project Monitoring and Control (PMC) Specific Practice (SP) 1.2 Monitor Commitments and SP 1.5 Monitor Stakeholder Involvement. In my mind the intent of both practices are logically the same and the type of evidence produces should also be the same (eg. schedule, minutes of meeting/action file, and status reports). I think these are two duplicate practice. Kindly let me know your view regarding this issue.

This is an excellent question. There could be some overlap between Project Monitoring and Control (PMC) Specific Practice (SP) 1.2 “Monitor commitments against those identified in the project plan” and SP 1.5 “Monitor stakeholder involvement against the project plan.” The primary difference concerns commitment vs. stakeholder involvement. Commitments include such things as delivery dates, specific deliverables, requirements, etc. Commitments are those things that everyone agrees to and they must be documented to ensure a consistent mutual understanding. Documenting the commitments indentifies the responsibilities of those involved with the project (stakeholders).

Monitoring the commitments is not the same thing as monitoring stakeholder involvement. For example group A produces an interface specification needed by group B so they can perform their assigned activities. The commitment that group A has made to group B is that group A will deliver the interface specification on Friday Oct 31, 2008. Monitoring the commitment in this case is periodically checking to see if the interface specification will be delivered early, on time, or late. If the specification will be early or late, then some type of corrective action may be necessary. In contrast, the intent of SP 1.5 is to use a stakeholder involvement plan or matrix to ensure that all of the relevant stakeholders who are supposed to be involved in producing, reviewing, and accepting the interface specification are performing their roles as identified and planned. If not, then some type of corrective action may be necessary.

Granted you may have the same evidence for both practices but the evidence demonstrates different purposes and use.