14.1 PHASING OR SCOPE VARIATION

< Day Day Up >

Software Metrics is a wide-ranging specialty covering the whole of the software development and support lifecycle. It is likely that your organization is also large with many functional groups making it complex in structure. An obvious way to reduce costs, duration and up front commitment is to reduce the scope of your initial program in one or both dimensions.

Targeting one development team, for instance, can enable you to develop a Center of Excellence within your organization and you can use this to demonstrate the beneficial effects of what you wish to implement across the whole organization. Working with one team that is not too large should mean that you can get a program running within six months. Of course you will depend upon the willing cooperation of the development team and you will still have to go through the various metrics program development and implementation lifecycle stages. You benefit from having a very limited marketplace for this first phase of the program.

Of course, there are a number of problems with this approach to metrication. If there were not then all organizations would do it this way. One problem is that really being able to demonstrate benefits will take much longer than six months. You may be able to get your program running in six months but to genuinely show benefits you may have to wait for perhaps another twelve months before hard data becomes available that you can use to convince others in the organization. This is especially true if you are concentrating on things like the measurement of field reliability.

Another problem is to do with the "not-invented-here" syndrome. Even if you have hard data available you may find that other teams take the attitude that just because it worked for one group does not mean that it will work for them. This is always a danger with pilots, and really we are talking about a form of pilot here. The reverse can also happen where you find it difficult to promote the use of something tried in the pilot group because that group is seen as a center of excellence. The feeling you then encounter is one of resistance because the pilot group are seen as being favored in numerous ways.

The last major problem with this approach is that you can suffer from a lack of visibility. Especially in large organizations, working with only one team may mean that your metrics initiative is unnoticed by those in the organization with real power. You need that notice if you are to effect real change.

Despite all of these problems, tackling the first phase of your initiative in this way can pay off, especially if you take care to abate the risks outlined above.

And then there is the second dimension: Software Metrics is a big topic — what if we make it smaller?

This approach can work very effectively and has been the seed from which some of the best regarded measurement initiatives, certainly in Europe, have grown. I include in these a leading UK Bank, a large government department and a leading European industrial organization. All of these organizations now have established, and it would seem effective, measurement programs and all of them started by concentrating on specific areas within the Software Metrics domain.

The technique is to identify a key trigger that is very important to your organization or to a specific customer. Whoever the customer, senior management must be aware of the area of concern.

Concentrating on a very specific area of Software Metrics means that you can reduce the learning time for the individuals involved by a great deal. If you then drive things forward such that you essentially pilot a technique or approach, possibly under the guise of an evaluation, you can get results quite quickly, certainly within nine months providing your topic is amenable to that time scale. Do bear in mind that you can not expect to show benefits from the use of, for instance, design metrics in that timescale if it takes nine months for your project to simply move from design through to coding.

Provided that you are sensible in choosing a topic that can give results within a reasonable time and that you then push those results up to senior management you could quickly end up with a full-scale metrics initiative to manage.

As always, there are no perfect answers to life's problems and there are some problems with this approach. Addressing one area of Software Metrics may mean that you pick the wrong one for your organization or that, for whatever reason, you do not get good or helpful results on your first attempt. Another danger is that the focus of the organization shifts so that what was a vitally important problem yesterday is suddenly less important. In wider ranging initiatives the occasional failure can be hidden behind successes. Of course, one way to reduce the risk is to go for two topics at a time if you have the resources.

< Day Day Up >