Changes: The Crossroads Between Project CM and Product CM

in time, the WBS need only be developed to a level which permits the development team to give a bounded estimate of the cost, schedule and risk. This is where the history from earlier projects pays off. If there are no significant risk factors, history may be used to produce fairly accurate estimates. Where there are significant risk factors, history can be used to predict the probability of success and to help bound the cost and schedule estimates. In some cases, activities will need to be broken by the develoment team down further to more accurately assess risk and or budget.

Project Management

Project Management begins in the development team as the contract (with the customer or with Product Management on behalf of the customers) approaches sign-off. The WBS must evolve into a tree of activities which can be prioritized, ordered (e.g. pre-requisites and high risk items up front), sized and assigned. For a large number of activities (several dozen to hundreds), even a rough sizing with some experience will lead to an overall fairly accurate overall budget. Activities should be broken down until they are in a specified range of effort (e.g. from 2 to 8 weeks in size). Even a vague level of uniformity will permit fairly accurate accounting of progress. If this step is missed, you may have 95% of activities completed but find that the project is less than 50% complete. You then would need to rely heavily on effort-to-date figures, which typically incur some time lag and inaccuracy. Having the activity completion (or intermediate checkpoint completion) automatically signalled to your repository of data will help ensure more accurate reporting (e.g. S-curve reports which project actual completion based on the existing plan, forecast and actuals.

Here is where integrated process and tools are important. If your specifications are tied directly to your activities, your checkpoint status can be updated whenever a specification is submitted, reviewed and/or approved. Your completion roll-ups will reflect these events without depending on someone to fill in their actuals. If your time sheet system is integrated to your project management tools, your actual roll-ups will be more timely and accurate. They will also work with your checkpoint states to help you to identify areas which are over budget and have schedule risk.

The WBS should be broken down to include specification activities, design activities, implementation/unit test activities, verification activities, documentation activities, etc. A good project tool will allow you to look at progress by phase simply by selecting the appropriate types of activities. For example, specification activities would comprise most of the Functional Specification phase and might have submitted, reviewed and approved checkpoints associated with each. By rolling up the actual checkpoints against the plan early on in the phase, an accurate 95+% completion date can be inferred so that resources may be scheduled effectively.

Relating Project CM to Product CM

The WBS for a project serves multiple purposes. If integrated with the rest of your processes and tools, it will permit a high level of traceability, allow automatic generation of release content documents and release notes, and generation of complete test plans by rolling up the test specs for each activity into functional and non-functional areas. It will allow you to quickly identify which requirements are at risk for your delivery schedule. This in turn permits non-compliance negotiations to occur up front, not after delivery. In many cases customers will be more willing to negotiate away high risk items rather than risk overall delivery.

In a typical scenario, the WBS should be viewed as a transformation mechanism: it transforms one release