9.7 ESTABLISH USER INTERFACE

< Day Day Up >

One of the great problems with any activity aimed at changing an existing process is that the attempt can be made without the involvement of those people who will be affected. Such attempts are very prone to failure!

Software Metrics programs are as likely to suffer from this "ivory tower" syndrome as any other culture changing process and conscious steps must be taken to avoid it happening. Yet, at first glance, it is not easy to involve the process owners, especially when the team that is trying to effect the changes to that process are not directly involved in it. This is certainly the case in our model organization where the Software Metrics team is part of the R&D group and it is also true of the vast majority of industrial Software Metrics programs of which I am aware, both in Europe and the United States as well as elsewhere.

One of the problems is often the large number of process owners because, as I view things, anyone who is involved directly in a process has a vested interest in that process and can be seen as an owner of it. How can you involve this large number of people in the work of changing the process? How can you ensure that the process owners also own the process of 'process change?'

One of the best pieces of advice I have ever seen regarding the implementation of Software Metrics came from the Grady and Caswell book, Software Metrics: Establishing a Company Wide Program (Prentice Hall PTR). They introduced the concept of a "Metrics Council" and I have used a very similar concept when implementing metrics initiatives. Names vary: the council could be called a user group, a working party or, my own favorite, a Metrics Coordination Group.

The role of this group is simple: they act as the steering committee, they guide the direction of the program and, most importantly, they ensure that the program does not fly off into flights of fancy that do not address the business needs of the organization.

The role of this group does depend, somewhat, on the involvement and strength of the customer authority. If the customer authority is both strong and involved, the high-level requirements for the Software Metrics Program will have been set out relatively clearly but even these will probably benefit from having fresh minds applied to them. In most cases the high-level requirements that will have been placed on the metrics program will be fairly vague and, in this case, the Metrics Coordination Group will be responsible for setting the more detailed direction of the program. The group will decide if the program covers both productivity and quality measurement, for example. Should any attention be directed towards measuring soft or environmental factors? Is there a need for more effective cost estimation techniques?

The Metrics Coordination Group is there to demonstrate that the users have been consulted from the start. Establishing and involving such a group is one step towards ensuring that the Software Metrics program is owned by its users rather than being seen as an imposition on them. As you will see, achieving this ownership is an important success criteria.

The group can also act as the final review body for any products from the Software Metrics Program. This is an extremely useful way of overcoming objections from the potential market for such products, be they reports, measures or training courses. It helps combat the "not invented here" attitude of some teams. Using the phrase, "approved by the Metrics Coordination Group" can be a powerful weapon in the war to get a Software Metrics Program accepted.

The group will also help in other ways. There is a phenomena I have labeled "reverse synergy." This is where the constituent parts of a group are more powerful than the group as a whole. Unlike Grady and Caswell, I do not expect the Metrics Coordination Group to do "real work" during its meetings although I fully accept that, with the right people, a set of metrics can be defined, for example, as they describe in their book. Personally, I prefer to use the group meetings as an opportunity to share information and a time for general discussions of strategy. However, I do use the members of the group as local champions and as doorways into different parts of the organization. They provide me, as the facilitator or the leg man, with the contacts and the introductions that are so necessary to the work of a Software Metrics program. If you are able to get the right people on the Metrics Coordination Group you will quickly find many centers of interest developing within the organization. All you have to do is change centers of interest into centers of working expertise. Not an easy task but infinitely easier than trying to carve your way through the organization single-handed.

So, who should be members of the Metrics Coordination Group? There is a great temptation to insist on senior managers From our model for example we may target the R&D, the Product, Support Development and Operations Support managers. Possibly we would add in the Software Development and the Test and Integration managers as well. Great if you can get them all in one room for a day but I doubt that you will. In many ways it is unfortunate that these individuals cannot form such a group as they are the "shakers and makers." They have the power to make decisions and see those decisions acted upon quickly. I repeat, you will be very lucky if you get the level of representation, in terms of seniority, that you would like. The one exception to this is when you are completely external to the organization, i.e., a consultant. In this case you may well be able to insist on access to senior management and this is one reason why consultancy-led programs can often move a lot faster than internal programs. There is a down side to this: consultants are transitory beasts, they are not there for long and there are few consultants who can effectively accomplish the transfer of technology or knowledge that is necessary for an organization to be able to proceed under its' own steam without any slowing down.

However, even if you cannot get senior managers onto the Metrics Coordination Group all is not lost. Provided that the majority of the group members are open-minded, constructively critical and believe that process improvement is both necessary and possible, the group will still be effective.

There is even an argument for establishing two groups, one consisting of more senior managers who determine strategic direction and another made up of project managers who work on the tactical plans and oversee the introduction of operational procedures. This is certainly workable but be very aware of the costs you are incurring and the bureaucracy you could be accused of generating.

Use your own and other peoples' knowledge of the organization to target individuals. Ensure that you have at least one representative from each of your customer groups. With luck you should be able to get at least one senior manager involved. If your organization is split across sites try to get a representative mix within the group and do not forget to include your customer authority or sponsor.

Approach the targeted individuals to sound them out and, if you are happy that they will contribute positively, get their line managers' approval for attendance. This is also a good time to let senior management know that this group exists.

The first meeting is important and will really be driven by the metrics team itself. In fact this is going to be the case right through development to implementation. Ensure that you set out the terms of reference for the group and the individuals. Remember they are to act as local champions, and use the first meeting to discuss the program components and the strategy as it is perceived at this stage. If necessary, use the results of the feasibility study to underline the importance of Software Metrics and what can be achieved. Tell them what the organization, in this case the metrics team, is going to do and be prepared to discuss time scales even if you avoid the question of detailed costs for now. Above all, get their agreement to your proposals even if this means modifying those proposals. Remember, the involvement of many individuals often means that compromise is necessary.

The first meeting of the Metrics Coordination Group can be seen as the true launch of the metrics initiative. After the initial meeting, I have found it best to hold meetings at need rather than on a regular basis at least during the development of the metrics program. Once you get to implementation, the role of the group changes to become more of a true user group. At this time regular meetings, say quarterly, are probably justified.

One final point: keep in mind that the members of the Metrics Coordination Group will be helping you. Make sure that you thank them for that help; publicly and often! Remember it is their program not yours, at least it will be if you succeed. If it is not then you have failed!

< Day Day Up >