Software Metrics: Best Practices for Successful IT Management

8.6 INITIAL MARKET RESEARCH

Having gained some understanding of Software Metrics and how they can be used, the feasibility team will need to establish the needs of the organization and the potential market for the use of metrics within that organization.

The users and customers of the metrics program will be varied and will impose different requirements on the program. This is a very important point. Many Software Metrics programs concentrate on one group of these customers and this can cause problems later on as you realize that you need the cooperation of other groups within the organization — but that you are offering them nothing in return for this.

During the initial market research activity, the first thing the team will have to do is to broadly identify the potential customers of the Software Metrics program. To do this it is best to divide the organization into a number of functional groups. At this stage, a high level division will be sufficient. One such grouping is:

• Senior management

• Project managers

• Support groups such as the planning department or the project control group

• Any process improvement teams or groups in the organization

• The software engineers or program.

This last group is important but is often ignored. The success of your Software Metrics program will depend, at least in part, on information supplied by engineers, a term I prefer to programmers. If you ignore their needs then you may well find their co-operation difficult to obtain and the data you are given suspect. After all, why should an engineer, for example, carefully record the way his or her time is spent if they get nothing back from that additional work?

Another group of potential users of the Software Metrics program are the organization's own customers or the internal users of software that is produced. It can sometimes be difficult getting access to these people but they should be added to the above list. A strategic decision must be taken by the customer authority, namely should the organization's own customers be approached at this point or not? This will depend on the relationship between the organization and the customers but I feel that they should be approached unless there are good commercial reasons for not doing this. At the very least you can make them aware of your organization's commitment to improved service. However, be careful not to build false expectations of rapid improvement. Change takes time.

Having identified the potential users of the Software Metrics program the team will need to go and talk to these people. Obviously, the team will not be able to talk to every single potential customer: after all there may be hundreds of engineers alone. The team should identify a representative sample from each group and arrange interview sessions with these individuals. The team should also concentrate on people they think will be receptive to new ideas but should not totally exclude the ones they think may be less positive. You might as well get an appreciation of the problems these people will raise as early as possible.

Each interview should address three areas:

• The interviewer should be prepared to provide a brief introduction to the subject of Software Metrics and the reasons why the organization is looking at the topic. This should not be prescriptive because you do not want to constrain the interviewee but you will have to provide a reason for the interview and an initial direction.

• The second point that must be addressed concerns the problems faced by the interviewee in his or her work. One way to get this part of the conversation going is to ask the interviewee to briefly describe his role in the organization. This will usually bring up areas that can be explored in more detail given the high level requirements placed on the Software Metrics program.

• Finally, the interviewee should be asked what additional information they feel would be beneficial in their work. The interviewer will often need to drive this part of the session and should link the way other organizations have used Software Metrics to the role of the interviewee.

The results of the interview should be documented. I will call the store of this, and other information, the SMP Repository. This is no more than a convenient name for what may, in reality, be no more than a filing cabinet or electronic folder (don't forget to back up!).

Another area that the initial market research activity should address is the size of the potential market. How many groups or teams are involved in developing or enhancing software or in supporting applications? Each of these groups is a potential customer. How many projects are each team involved in? How many engineers are in each group? How many senior managers or management groupings are there? How many organizations are customers for the software produced? How many support groups, for example planning departments, are there and how are these organized? How is the process improvement group organized and how large is it? Surprisingly, a considerable amount of effort may be required to get this information but it will pay dividends in the future. "Know your market" is a good maxim that we often ignore.