Using Dashboards to Clarify Project and Product Perspectives in SCM

A configuration management (CM) strategy must deal with product development from both a product and from a project perspective. Theformer 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, 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 the user 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:

• Outstanding problems by priority: Show a prioritized list of problems which have not yet been fully addressed.
• Recently added features :  A list of features recently added sorted functionally or by completion date
• Non-conformances (i.e., requirements not yet addressed):  Features which have not yet been verified as conforming to the product requirements
• Problem arrival/fix rates:  Comparison of arrival and fix rates for problems, with sufficient history to infer some information about the current quality of the product
• Updates/changes by release: Change packages which have been applied by release and/or iteration
• Recent requests:  Shows the recently raised requests for new features and problem fixes
• Requirement changes : Identifies changes to the requirements tree since the currently assigned requirements baseline

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

• Gantt chart and/or Pert chart for current release (i.e.,  project) activity
• Work breakdown structure of the current project
• Open release (i.e., project) activities by priority
• Gating release problems by priority for the upcoming release
• Tasks at risk by priority and assignee
• Outstanding tasks by group/team member for the current release/project
• Updates/changes in progress targeted to the current release/project
• Planned versus actual effort and/or checkpoints for the current release/project

 Release Manager

• Failed test cases for the current release build of a given promotion level
• Problems fixed this release to date
• Features added in this release to date
• Updates/changes applied to this release along with any notes attached to such changes
• Updates/changes in progress, 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, along with 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.  Also, 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.