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

• with a focus on problems and features they address

• Non-conformances of the current state of the release against the official requirements baseline

• Test run summary against builds for this release

CM Manager

• Build Progress (e.g. Gantt chart)

• Problems addressed by a build (as compared to the previous build or a reference build)

• Features added by a build (as compared to a previous/reference build)

• Changes that have gone into a build (as compared to previous/reference build)

• Test run summary against builds for this release

• Changes ready for integration by product stream

• Summary of newly added/moved/deleted files for this release

• Build pair specification for comparison of two specific builds

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.