14.4 HARD AND FAST

< Day Day Up >

This final alternative is one that demands a high degree of senior management commitment because it involves money.

One of the biggest problems with any Software Metrics program can be the lack of in-house experience, either in terms of technical knowledge or in terms of experience relating to the management of cultural change. This means that individuals who are responsible for doing the work have to spend time learning the subject. They will also spend time investigating specific techniques that turn out to be unsuitable for their particular environment. They may try things out within pilots and evaluation exercises where somebody with experience of such techniques would have been able to say, with confidence, "this will work if we do it this way because, in a similar environment, it worked last time."

Of course, just because something worked before somewhere else does not guarantee that it will work in your environment, but there are some requirements and, more importantly, some solutions to these requirements that are common to most organizations. An expert should be aware of these and will also be able to identify what needs to be changed to tailor a generic solution to a specific environment or organization.

For example, most organizations would benefit from being able to record information about defects in their software systems as delivered to the customer. One question that must be asked is "what information should be recorded and to what level should those records be kept?"

An in house team could spend a considerable amount of time researching this concept by reading technical papers and talking to other organizations; discussing in committee what would be the best data and finally drawing up the proposals for a defect recording system. Experience shows that the eventual system may well be difficult to operate and to use to get meaningful results because the first attempt is often too detailed.

Any expert should also talk to potential users and operators of the system to ensure that he or she does not try to make a solution fit where it really does not. However, an expert should be able to help an organization establish a workable and useful defect recording system very quickly.

In this case, the solution may be as simple as agreeing to a high-level lifecycle for software development and putting in mechanisms, often no more than simple forms and a database, to record point of injection and point of discovery of the defect together with some additional information such as system name, date of discovery and date of closure. This limited amount of information can be used to provide data which, in turn, can be used to assess the effectiveness of the development process. An expert should also be able to determine quickly, whether defects should be recorded at the system, program or program component level so that the needs of the organization are met.

The obvious question is, from where do we get this expertise? If expertise does not exist within the organization the only solutions are to recruit it or to buy it in. In other words we are talking about the use of external hires or consultants. To get external hires may not be acceptable if it increases the permanent headcount of the organization and even if you get the go-ahead there are not many experienced metrics practitioners in the marketplace. This is slowly changing but it will take some time before the demand for such experience is less than the supply. You could also be very unfortunate if you recruit the services of a consultant only to find that they have a large learning curve to climb. This may sound like a contradiction but most organizations have experience of a consultant arriving to carry out a piece of work only to find that very large briefcase you hoped contained the fruits of past experience actually contains lots of books about the topic in question. Not exactly a good way to build confidence in the eventual solution.

Now the big problem with consultancy, even assuming you can get the right people, is that it costs money! For this reason you can only use the strategy of a consultancy driven program if you have senior management commitment to spend the necessary money.

You also need to have clear objectives that you expect the consultant or consultancy team to achieve. This can be more difficult than you may think and it often pays to set things up in three distinct stages. The first stage is simply to identify suitable consultants. If you are already involved with a consultancy organization and you feel comfortable with them then you have a good starting point but do remember that Software Metrics is a young discipline and that, even among consultants, practical experience of the topic is scarce. How you identify suitable consultants is something that only you can determine, but the one suggestion I would make is that you do look for evidence of previous experience, preferably in the area you are interested in. For example, someone with experience of Applied Design Metrics, say the use of McCabe metrics or Information Flow Metrics may or may not be knowledgeable about cost estimation models.

The second phase is all about scoping and planning. Many organizations are reluctant to pay consultancy rates simply so that the consultant can prepare a proposal and plans for the real work. The advantage that you get from this approach is that you can get to know the consultants and you get some indication of their effectiveness without contracting large sums of money. The consultants get the opportunity to get close to your organization and the time to properly plan the work ahead. This increases the likelihood of success so everyone wins.

Of course, you must make it clear to the consultants that the proposals and plans produced must be for your organization. You do not want to pay for generic solutions lifted from textbooks, even this one! You can do that yourself.

Once you have an agreed proposal you can start the third phase, the real work. You will need to consider the management of this strategy. Someone from your organization must have responsibility for the project because, at some time in the future, the consultant will walk away and you will be left to carry on. A clear customer authority and resources to review deliverable are vital components of a consultancy driven program.

The transfer of knowledge from the consultant to the organization is also a deliverable of the project. This strategy only works when the consultants and the organization's own staff work together. Consultancy-driven with organizational ownership and involvement are what you aim for. To help achieve this, do not lock your consultant away in an ivory tower; instead, have regular project meetings to discuss the approaches being used, progress, plans and deliverables. This may add slightly to the cost as it all takes time but it is money well spent. As has been said many times by many people who have suffered the pain, "we never have the time (or budget) to do it right, but we always have the time to do it wrong."

The consultancy-driven approach to metrication depends upon senior management commitment because it costs money, cooperation and, most importantly, trust between the consultants and the organization and vice versa.

The disadvantage of the consultancy-driven approach is that it costs. Its advantage is that you can have a working software measurement program in place much more quickly than if you try to do it solely with internal resources.

These alternatives can all help with the metrication process but underlying them all is a project-based approach that uses a lifecycle of the kind described in this book. Do not be tempted to cut corners on that or you will increase your probability of failure significantly.

< Day Day Up >