CM: THE NEXT GENERATION - Project vs Product SCM Using Dashboards

A product's lifetime is typically broken up into a series of releases, with development of successive releases usually having some level of overlap.  A release is typically accomplished through one or more projects which move the product through its milestones.  For many products, a project is defined to move the product to a new milestone.  Traditionally, a large project is defined to move a product from one release to another.  In this case, the project transforms the product from one release state to another (see diagram).

Projects are also created to create major variants on a release.  For example, a project may be defined to take a North American product and adapt it for release in the Asian market.  We use the term variant here, rather than release, because the variant will persist across all future product releases.

More recently, the term Project has been blurred by various strategies and technologies.  For example, the use of highly iterative agile methods can tend to blur release boundaries.  This is the case when the iterative methods apply, not only to development, but to requirements specification as well.  In a highly competitive market where requirements are rapidly changing, release boundaries are often not defined prior to development.  When market conditions dictate, the focus of the iterations may change to bring the product to a release point.  Or the agile methodology might be such that product quality is maintained at a high level at the end of each iteration such that any iteration can be used as a release point. 

Since there is not a fixed set of requirements being worked to, it's hard to define a project at release level.  Instead, it might be more appropriate to treat iterations as mini-projects.  When a fixed set of requirements is defined for a release, even if there is some give and take in the requirements, a traditional project, with project management, be it schedule-based or agile, may be defined.

The term Project has also been used by IDEs, typically to identify software associated with different target deliverables.  For purposes of this discussion, we will ignore this use of the term.

Dashboard View of Management
Next Generation CM systems can clearly distinguish between Product and Project CM through their dashboard views.  A Product dashboard is very different from a Project dashboard.  If we take a look at the types of things you might find in a Product dashboard and compare that to the sort of things you might find in a Project dashboard, we'll get a good idea of the differences between product and project management and the different CM/ALM roles.

When you're looking at next generation CM dashboards, it's important to distinguish a few different capabilities.  First of all, if the CM system deals primarily with traditional CM as opposed to end-to-end ALM, your dashboards are going to have limited information with respect to product and project management, even though they may provide excellent CM.  Another distinction to look for is whether dashboards are all pre-canned or configurable.  Pre-canned dashboards are nice in that a single button brings up the information.  However, dashboards that can be easily customized will provide you with the best management capabilities. 

Dashboards should not simply be information displays.  They need to be fully interactive, allowing you to zoom in on summaries whether in tabular, graphical or other format. Some dashboards will let you control one or two variables and display the rest of the dashboard based on your choices.  For example, a project management dashboard may let you dynamically change the project you're looking at. Or a configuration management dashboard