Changes: The Crossroads Between Project CM and Product CM

Product, Project, Program

Product: When we talk about product, we're focusing on Deliverables. A product may consist of a single deliverable or a set of deliverables. Often a product will have sub-products which are themselves products which are incorporated into a higher level product. Their development will typically span multiple releases over many years. For example, A Space Shuttle is made up of Canadarm, Solid Rocket Boosters, Liquid Fuel Tank, Shuttle. Each of these have many subsystems and sub-products (e.g. the Main Computers aboard the Shuttle, the Main Engines, etc.). In the end, all of the deliverables must come together to create the first release of the shuttle (i.e. Columbia) and then the next release (Atlantis, Discovery, etc.). Sometimes a product release is an upgrade; sometimes it is simply a template for creating a new version of the product. Often, its both (e.g. Windows XP is both an upgrade and a new version of the product).

Project: A project transforms a product, through a series of activities, typically to the next release stream. (e.g. Chicago took Windows to Windows XP (or was it 2000?). Projects come in all sizes and shapes. The activities are typically collected into a hierarchical decomposition known as a WBS (Work Breakdown Structure). The WBS helps to outline budget, risks, resources and schedule.

Program: A program is a larger effort with an overall goal in mind. For example, the U.S. Manned Space Program (Super-program) and individually the Mercury, Gemini, Apollo and STS Programs were created to give the U.S. leadership in space technology; Nortel Network's DMS Family of Telephone Switches was a program instituted to put Nortel on the map as a leader in the Telecom industry. A Program is more far reaching than a large project or a series of Product releases. It involves both Products and Infrastructure which will sustain a goal over a long period of time.

Project CM vs Product CM

Project CM starts with establishment of Requirements, typically on a per-release basis, and translation of the requirements into project activities. These typically form a WBS which through implementation will transform a product from its pre-project form (e.g. release 1) to its post-project form (e.g. release 2). Project CM also deals with traceability issues - the assurance that the project has indeed performed the necessary transformation to meet the requirements.

Product CM deals with management of all releases of the product. This includes all of the configuration items and deliverables, and the relationships between them, as well as the identification of products and sub-products. It deals with issues of build, deploy and related workspace management. It includes management of product defects and of test suites.

Project CM

Project CM starts with the formal creation of a customer requirements tree. The top level of the tree reflects the purpose of the project. Requirements are typicially broken down from there into fixed groups dealing with things such as Functionality, Performance, Environment, etc. and the customer requirements in each area are laid out. The tree will be refined over time as the customer and supplier better understand the customer constraints and supplier capabilities over time.

As requirements become firm, the supplier will use them to put together an initial project plan through development of a Work Breakdown Structure (WBS) detailing all of the activities the supplier will have to perform in order to deliver a solution which meets the requirements. In some cases, the activities cover building a solution from scratch, perhaps with a plan to capitalize on the supplier's own experience and perhaps some previously developed components. More frequently though, the activities are transforming