Changes: The Crossroads Between Project CM and Product CM

an existing solution from one stage, typically a release, to another.

Who Does Project CM

In the early stages, the supplier will need a Product Management Team which acts on behalf of the customer(s), and a Project Management Team which acts on behalf of the supplier. If a solution is being delivered for a single customer, the Product Mangement Team will likely be a composite of customer and supplier team members. A specific contract might be used in isolation to establish the business case. In a more generic solution, customer representatives in the supplier organization will feed customer input into the Product Management Team. The team must put together a supporting Business Case to move the bid forward. This will likely involve additional areas such as Competitive Analysis, Market Research, and Opportunity Costs.

In an ideal world, the customer knows exactly what the requirements are. In the real world, the development organization has plenty of input on helping the customer. For example, if the customer is a software development organization and the development organization a CM supplier, the CM supplier might take a requirement such as:

To support the extensive merge activity expected, the CM tool must provide an intuitive, high performance merge capability.

and recommend that it be turned into the following:

Minimize the effort spent on merging through CM tools which reduce the need to merge and through strong merge capabilities.

As well, where there are multiple customers involved for a solution, the supplier will need to evolve an internal requirements tree which has the proposed market segment as the customer. The supplier is trying to get its initial customer(s) to pay for the generic feature development, while the initial customer(s) try to keep contract costs to a minimum.

In order to successfully negotiate this requirements enhancement and clarification process, a CM tool would provide the capability to capture requirements, perform change control on the requirements, and baseline the requirements. It should also allow easy comparisons on both baselines and changes in progress so that customers can quickly review changes against both their initial and subsequently agreed upon baselines.

Development of a Work Breakdown Structure

Product Management must negotiate a contract which has a specific set of signed-off requirements. To do so, the project development team will have to be involved. The Project Manager will work with the development team to establish a WBS. As the WBS activities are enumerated, the development team must take each activity and produce estimates with respect to Budget (time and cost) and Risk/Feasibility. Each activity should clearly show a list of deliverables/objectives which can be verified to meet the requirements. It is helpful, at this point, to have a Project Management tool which is both multi-user capable and integrated with the Requirements Management tool. Ideally, these are the same tool and it is easy to trace the activities back to the requirements.

Note that whereas it's essential to have requirements under version and change control, the same is not necessarily true of activities. Activities need to reflect the signed off requirements. An activity will have a definite set of objectives which are implemented. There will not be different versions of the objectives each of which are to be implemented. Instead the objectives of each activity must be clearly defined prior to development. Still it may be interesting or even useful to capture revisions of the WBS over time as it evolves. What will be important for each activity is the specification that it spawns. This will need revision control as the specification will undergo change to reflect reviewers' feedback.

At this point