8.1 THE INITIAL MANAGEMENT DECISION

---

8.1 THE INITIAL MANAGEMENT DECISION

Two things lie behind the start of a Software Metrics program: an organizational trigger and an initiator. The trigger comes from some need within the organization. The initiator realizes that the need exists and seeks to satisfy that need.

Software Metrics programs can be triggered by many different situations or events and some of these are listed in Table 8.1.

General quality or productivity concerns

Concern about customer complaints

Customers requirements for increased information

Knowledge of competitors' activity in the metrics area

Process improvement programs

A cost-cutting environment

Management pressure for more information

A consultancy recommendation

New awareness of the possibility of measurement, perhaps as a result of someone attending a conference or seminar

One point that should be recognized is that it is rarely possible to attribute a single trigger to a Software Metrics program. The reality is that there tend to be multiple triggers for such an initiative. This can be both a blessing and a curse. A blessing, in that it tends to widen the scope of the work so that difficulties, and even failures in one area, can be outweighed by successes in others. A curse, because widening the scope of the work can slow things down — and one problem with any metrics program is that the lead time, as it were "the time to market," can be seen as a liability by an organization.

This problem is often a result of limited understanding of Software Metrics within the organization. "After all, we are only talking about a putting in a bit of measurement aren't we? Other industries measure so it can't really be that difficult. We should be able to get something going by next month." Well of course we can. It will not work, will probably cost money and will also probably result in at least part of the organization being turned against metrics for the foreseeable future!

It is vitally important that a Software Metrics program is not seen as a quick fix. Software Metrics is about fixing the process rather than patching to fix the fault.

For example, it will take a certain amount of time to develop and implement a productivity measurement program, some time to collect data and a small amount of time to interpret that data. This is not a rapidly deployed defense against the threat of outsourcing within the next two weeks! Depending on the scope of the program and the size of the organization there will be a minimum elapsed time necessary before the program can be implemented and the lifecycle that lies behind this book will enable a manager to assess that minimum time for his or her organization. After all, if you know what needs to be done you stand a much better chance of estimating how long it will take.

Recognizing the trigger or triggers is important because they can affect the Software Metrics program by driving it down a particular road. For example, it is no good advising people how to measure software usability if the sole trigger is concern over productivity levels. When you start to plan your own Software Metrics program, it is a useful exercise to list the triggers acting within your organization as you see them. This gives you your initial focus but bear in mind that this is not cast in stone. You will be gathering specific requirements as you progress through the lifecycle and these can broaden the scope of the program.

We can now consider the initiator of the program. I view the initiator as someone who is external to the Software Metrics Program but someone who will still interact with that process especially during the earlier stages of its lifecycle. Generally, an initiator identifies a need for measurement, determines that something will be done to satisfy that need and then promptly delegates the responsibility for development and implementation to someone else. This is generally known as management! Seriously, such delegation makes sense. Initiators tend to be in positions where they are affecting strategic positioning whereas the developers and implementors function at the tactical and operational levels.

The initiator sets out the scope of the work and will often obtain or even give the initial authorization for that work. The initiator's role is important because he or she sets out the boundary of the eventual system, thus bringing in the first set of constraints. At the same time, the initiator will not be a Software Metrics expert and so should not aim to constrain the program too tightly. In many ways, the initiators role is akin to the person who chooses a site for a new building. Picking rocky terrain will mean that the builders will have their work made more difficult by external constraints, they will have to cut through solid rock. Pick shifting sand, by giving no guidance on the initial direction, and there will be many false starts.

The initiator must draw a balance between constraining or tightly defined requirements and a vague problem definition that is liable to drastic changes. Different initiators tend to lean one way or the other as illustrated by Table 8.2:

Table 8.2

Initiator		Too Rigorous	Too Vague
Chief Executive or Director		X
QA Function				X
R&D Group				X
Customers or Users	X
A Technocrat		X
Management Consultant			X
Auditors			X

As a guideline, during the initiation stage it is better to tend towards vagueness rather than rigor. After all, at this stage we do not really know what we are getting into, so a rigorous definition will probably be incorrect anyway. Notice that I said "tend towards vagueness." Make sure that you, as the initiator, do not put your people on shifting sand by at least giving them the space to define their own terms of reference. These can then be reviewed by you to ensure that they meet business goals.

The people responsible for the development and implementation of the Software Metrics program will probably have little to do with the early part of the initiation stage so let us now assume that a decision has been taken within the organization to do something about Software Metrics. Now we get down to the real work.

---