Can you explain following two REQM practices with some practical examples?
- Identify inconsistencies between the project plans and work products and the requirements
- Establish and maintain an organizational policy for planning and performing the requirements management process
Sure! Practical examples is what this 'blog is all about.
I'll start with the last first. Your question appears to be about REQM.GP2.1 "Establish an Organizational Policy." Let's start with a question: "what's an organizational policy?" According to the CMMI, an OP is: "A guiding principle typically established by senior management that is adopted by an organization to influence and determine decisions." To put it more simply, it's management's expectations for performing a process.
My advice to you here is to keep it simple and not use your policy to describe the process. You will probably be going through an exercise to define a Requirements Management process, so there is no need to be redundant within the policy. A simple documented policy that sets management's expectations is sufficient.
"All employees are required to read, understand, and follow the REQM process as defined in the process guide."
Of course, there needs to be a process guide for this to be valid, and a valid REQM process as well to point to.
The second part of the practice refers to "maintaining" the policy. This implies a cyclical review of all policies, and updating or changing it as appropriate (keeping it all under CM of course!)
You first question refers to REQM SP1.5 Identify Inconsistencies Between Project Work and Requirements. What could this possibly mean, and whose job is it?
To begin with, we can think about this practice as part of PMC because it is clearly a project management activity. It involves keeping up to date on all of the latest requirements changes, and ensuring that the tasks being performed by the project team reflects the latest approved requirements set.
Imagine a large scale project with dozens of developers who are each assigned a set of requirements or features to implement. They may not be involved in all of the meetings and approvals for new or changed requirements. How does the PM ensure that, as requirements change, the developers are working on the latest and greatest requirements set? How do we avoid having them work on the old requirements, or when the requirements have changed to something different?
The place to manage this, IMHO, is in the traceability matrix. This tool can quickly identify who is working on what code and gives the PM a way to rapidly determine what work needs to be halted, modified, or added.