the FS Task which created the FS Document. Along side the Design Task might be a couple of other tasks under the FS Task: A Test Plan for the Feature, and a User Guide snippet for the feature (assuming this is different than the Functional Spec).
Now put in a CM tool that works on this WBS. Instead of the WBS being a planning and tracking it is now a living organism. Traverse the WBS and it becomes the total content of the project. The tasks, the feature specifications, the changes, build records, and so forth. As well, the changes made to the requirements, documents, source code, and test cases are part of the WBS.
Now a project is typically used to transform a product from one (possibly empty) release to another. So: Product.rel1 + Project.rel2 => Product.rel2. The idea is that each WBS can capture everything, from changes in requirements through to source code and test case changes. On the CM side, intermediate steps collect changes to create baselines along the way, whether for requirements, documentation, source code or test cases. Build records are used to record intermediate builds in terms of a baseline plus a set of changes, as the WBS continues to grow, until finally the project is done.
In this integrated view, not only do we see full traceability enhanced through the WBS, but we also see progress measured by the actual completion of tasks - check in of changes for requirements, documents, software and test cases. And furthermore, these changes are promoted as they move through the verification tasks.
One of the major benefits here is that the visibility of the WBS across the team allows the visibility of the entire set of project data. As the WBS grows, clarity is provided for each of the team members. And as the WBS grows, a visible measure of progress is provided.
Mitel - The First Test Bed
The first time I implemented this architecture for an integrated CM/PM tool and process was in the mid-1980s at Mitel (a PBX manufacturer in Ottawa, ON). Even though we were at the time restricted to command-line user interfaces (which didn't appear widely until the
'90s), the success of the approach was widely evident to all, including upper management. Product Managers and VPs would regularly access the system to identify an up-to-date state of each project. Risk management was simplified as all of the data was integrated into the same repository and accessed through the same tool.
The entire team, used the same tool and even the marketing people wanted to go into the CM database both to provide product input and to identify the status and contents of each release. A quick by-product was to generate and circulate regular documents so that the less technical minded did not have to learn a command line interface to the tool. Initially deployed on the SX-2000 project, the approach continued through at least 2 decades.
We made an effort to continue to use integrated CM and PM ever since at Neuma (using CM+). We've reaped the benefits of rapid development and better communication - the result: a more agile, higher quality development environment.
The bottom line: Don't treat Project Management as an add on function to your
development; and don't treat CM as an add-on function to your development. Integrate them and reap the benefits.