Measurements and reports

Today I was confronted with a question what SCM measurements we would need and what SCM reporting. Although measurements are often put in reports, our objective was quite different for the two.

The SCM measurements were intended to give us information about the SCM processes. By measuring some primary indicators we want to get an idea about how accurate SCM processes are followed and how efficient the SCM processes are. For example, suppose a subsystem baseline is created more than 10 times a day, there probably is something strange going on.

On the other hand, SCM reporting was intended to support the operational project execution. For example, to support the integration process the integration managers need to know what changes are made in the new baselines compared to the previous baseline that was integrated. Managers may argue that this is listed in the baseline report, but the author of the baseline report has to get the info from somewhere. As the SCM system keeps track of all changes made to the product, SCM reporting may provide the info the integration manager needs.

Other examples of SCM measurements are:

• Number of parallel streams that are used
• Number of deliveries from a developer to the integrator, per day
• Number of changes per delivery
• Amount of time to get a change of one developer to another, going through all the formalities, quality checks (build, tests, reviews) and data transfers (deliver, export, import, install)
• Number of problem reports solved per week, and the trend over the past year.

Other examples of SCM reporting are:

• Changes made in a baseline compared to a previous baseline
• Problem solutions present in a particular stream
• Problem Report and Change Requests found a particular release
• Persons accountable for creating, testing, integrating a particular change
• Evidence of a particular SCM promotion step

I do not claim that the distinction between SCM measurements and SCM reporting is universal. But that is what I ran into today.