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.
www.broadswordsolutions.com
2 comments:
I'm a little surprised to find a process policy stating only that employees are required to follow the process. It seems to me that one single policy phrase would suffice in that case, something along the line of: "All employees are required to read, understand, and follow company processes as detailed in the Business Manual."
When I'm involved in process improvement, I try to express policies based on company goals. For example, a policiy might refer to expectations the quality of the product, and then I'll try to adjust processes for development, verification, quality assurance, etc. so that they conform to this policy.
This way, if the processes can be shown to meet company objectives, then in turn the work procedures for each process guarantee that the employees are working towards the company goals. I think this approach can be viewed as a requirements traceability matrix for the OPD/OPF processes.
Does your suggestion reflect a common policy descriptions, or could you perhaps give examples of other policies?
Ahhh, you and I are in violent agreement! I policy can't stand alone - but needs to be linked closely to one or more related processes. This integration in one of the KEYS to an agile approach to process modeling.
Processes can be shown to meet objectives when they satisfy the measures set up when the policies are first enacted. That's why it's important to have a fully integrated and traceable process architecture that includes goals, objectives, policies, processes, and measures that all integrate.
Post a Comment