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

A CM strategy must deal with product development from both a Product and from a Project perspective. The former deals with the state of a product, the requirements, features, problems, quality, etc. The latter deals with managing the tasks that will take the product through its many milestones. Dashboard technology can help to clarify the perspectives and simplify the management functions, especially from an information perspective.

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 may allow you to change the build that you're using for your dashboard summary or build comparison.

Product Dashboards
Product dashboard areas should highlight the readiness of the product for market. This may involve comparison of current development to previous releases, looking at the outstanding problems, and consideration of the Requirements Traceability Matrix. The goal here is to be able to take outstanding requests and assess them across the business cases that form each planned release of the product, while also considering product quality.

The main goal of the product dashboard is to allow the product manager, or product management team, to assess market and contract requests and commitments in light of the overall business goals of the product division or program. Product management involves looking at the current (possibly non-existent) state of the product and the market demands and request backlog, along with any outstanding problem reports, and creating a business case that makes sense to implement. For already successful products, this typically means allocating requests into one or more release slots and justifying the releases based on the potential ROI. It also deals with coming to terms with quality requirements, in terms of non-conformance treatment, expected product reliability, and the ability to deal with change while maintaining quality.

The product dashboard allows the product manager to rapidly zero in on the items affecting this task. Ideally, the dashboard is not simply a status report, but rather is a product state summary with the ability to allow the product manager to zoom into key areas of concern. Dashboard items might include:

A sample product dashboard focusing on product changes and problem reports might look like this:

Project Dashboards
Whereas product dashboards deal with the entire product, a project dashboard deals with that portion of product development covered by a specific project. The goal here is to manage implementation of the release successfully. Project dashboards come in many flavors, depending on the role perspective. Roles include the Project Manager, Verification Manager, CM Manager and Developer, among others. And dashboards should be specific to each role.

Project Manager

In looking at these three roles, and the dashboard items that might be posted on a given dashboard, it becomes apparent that additional context can be used to automatically guide the dashboard generation. Whereas the "product" was the only context for a typical Product Manager query, an easier-to-use next generation system should allow a much wider variety of context specification. For example, the project manager should be able to specify the current project (and/or release) of interest, and the dashboard items should focus in on that project. And the CM manager, in addition to the release context, should be able to specify a build or perhaps a pair of builds (i.e. for comparison purposes) for which arbitrary queries and dashboard presentations should be generated.

For role-based dashboards, an ideal situation is where the context variables are control widgets for the rest of the dashboard display. The project manager might be able to scroll through a set of projects. The CM manager might be able to compare the current state of the product to specific builds that customers are currently using. Or perhaps (s)he should be able to scroll through builds in historical order and see the set of Problems/Features/Changes, etc. in summary and line detail formats. Such a capability really helps to eliminate the need for the user to learn where things are in menus. A dashboard comes up and the manager can quickly and intuitively navigate through projects, releases, builds, etc., and then zoom-in on details.

As the requirements of the role are better understood for a given project, company or release state, it would be even more ideal if the dashboards could be tailored by the managers themselves, perhaps by selecting potential dashboard components from a checklist, or having the capability to adjust the parameters of specific components to their preferences.

The goal of proper dashboard configuration, if the CM tool allows it, should be to ensure that each role has all of the information necessary to do the job of that role, without having to ask for special reports or even search through the menus for them.

Wrapping Up
As ALM functionality continues to grow in the CM solution space, role management becomes more and more important. The distinction between product management and project management in CM becomes more evident. Some next generation systems will permit the management of multiple products per repository, along with the capability to harvest metrics which help to compare products and others across all products.

Dashboards are a key tool in the expansion of functionality and complexity, without the corresponding growth in user interface complexity. Role-based dashboards help manage a project. Product-based dashboards help management of business case decisions.

As dashboards are a relatively recent CM tool concept, expect to see a lot of growth in this area, and a lot of streamlining of the ALM processes through the use of dashboards.

Joe Farah is the President and CEO of Neuma Technology . Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe by email at farah@neuma.com

More white papers:

Find out more ...

Neuma White Paper:

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