A system analyst asked me how often he should be checking for inconsistencises between the project plan, work products, and requirements. I told him that he should be checking at least at each milestone, ideally at each week, to verify that the interim work products satisfy the baselined requirements; if he finds any gaps, document them in the defect log, and send it to PM for resolution. If he thinks that the project plan needs to be revised, document that in the defect log too. My answer is based on the fact that the PM reviews the project activities/schedules weekly. Could anyone provide more practical way to do this practice?
In my opinion checking for inconsistencies between the requirements, work products, and project plan each week is overkill. It would be proper to check for inconsistencies at each project milestone and probably each time the requirements, work products, and/or the project plan are updated. By updating the project plan, I mean re-planning or re-baselining the project plan, NOT the regular updating of the project status (e.g. % complete, etc.). If you checked at a higher frequency, most likely you won’t find any inconsistencies and whoever is performing this check will begin to question its business value.
Once an inconsistency is found, the process you described seems reasonable to me.
2 comments:
Isn't REQM SP 1.5 a duplicate of CM SP 3.2, "perform configuration audits?" Everytime you update your configuration baseline, you should perform a configuration audit to ensure that what is there is supposed to be there. REQM SP 1.5 seems to be saying the same thing.
Hi Allen,
Since REQM is a special instance of CM, you might think that there is some overlap between these two practices, but there really isn't any. The SEI has made a lot of effort over the years to clean up the model and remove redundancies. There was a major improvement to the CMMI with v1.2.
REQM SP 1.5 is about looking at all of the different plans, work products, and requirements and taking steps to identify inconsistencies between them that will develop over time as requirements etc. evolve. All of these items are in the baseline, but the Configuration Audits of CM SP 3.2 are not for determining if there are any inconsistencies between configuration items. The intent of a Configuration Audit is to provide an objective way of knowing that what is supposed to be controlled is in fact controlled and can be retrieved as needed. Retrieval of accurate information is one on CM's many benefits. A Configuration Audit most likely will not identify inconsistencies between configuration items, just the right items are resident in the repository.
Post a Comment