Does a Configuration Management Plan satisfy the pratice "SP 2.3 Plan for Data Management"?
You will likely get many different ideas on this . . . I would start with the notion that it COULD if all of the appropriate information is in the CM plan.
Some will say no, a CM Plan is distinct from this practice. That's true if you interpret the CM plan in its most narrow form, but I would argue that even the term "configuration management" is something in our industry that means many things to many people, so it's not beyond the realm of possibility to include "project data" as part of the plan.
As practical appliers of process, we are able to interpret artifacts in any way we please, as long as they satisfy the minimum requirements - why not let the artifacts work harder and satisfy the MAXIMUM requirements - and include things like "project data," roles& responsible for the artifact (geez, maybe a little GP2.7, GP2.2, GP2.3 . . . ) and who approves them, when they're audited, and by whom (oh, a little more CM "evidence" here) and so on?
I borrow a concept from the building industry where they architect rooms and buildings that "work harder." A gym that is also a meeting place that is also a performance space. Why have more artifacts than you need? Make the one's you have work harder.Just remember that the intention of the practice is to plan for the management of all data produced by the project - including things like test data, customer files, and other work products not always traditionally placed under "configuration management.
"Think agile, and reduce the burden on your practitioners. Engineers will love you for it.
http://www.broadswordsolutions.com/
1 comment:
..."but I would argue that even the term "configuration management" is something in our industry that means many things to many people"
Very Nice! Coolness!
Post a Comment