10.11 PREPARE A BUSINESS PLAN

---

10.11 PREPARE A BUSINESS PLAN

Most organizations are large and complex beasts. Once you have gathered in the requirements for your program and designed specific components to satisfy those requirements (whether this involves deriving particular metrics or adopting techniques to help with, say, cost estimation), you will still have to implement the use of those components.

We have already looked at phasing within the metrics program and it is easy to understand how you may have to address certain requirements immediately while others are left on the shelf until phase two or three. We also briefly mentioned the other aspect of phasing, the phased implementation across the business. This is important because of the situation outlined below and the fact that we will probably be operating with limited resources.

It is very easy to fall into the trap of thinking that your work is complete with the issuing of instructions or standards. Please do not think that this is enough. .

People need help to change. They may wish to adopt the ideas and concepts that you put forward but they will almost certainly run into problems trying to turn the concepts into a reality and they will need support to do this. I have come across examples of this in the areas of metrics, CASE technology and the introduction of Fagan inspections. All of these aim to improve the business efficiency of a software development organization and all of them have the real capability to achieve this goal but, so often they fail to deliver the goods because the support function is underfunded. For evidence of the importance of the support function I would suggest you read of the experiences of the Hughes Aircraft Software Engineering Division, Humphrey (1) .

If you accept the necessity for support during implementation (and this can be as little as visiting a development team once a month to check on how things are going and to, let us say, keep the plate spinning), then I suggest you do a number of things.

First, build into your design the concept of support during the early stages of implementation. Based on experience, I believe it takes about thirty days of external support per development team to get a metrics program up and running within that team. This does assume that the team is adopting a number of components within the Software Metrics program. It is obviously less if you are simply, say, introducing productivity measurement.

If your organization agrees that a support team will exist for metrics implementation then a good way of building this support strategy into the design is to treat each development, or support, team as an account or client. Within the team you should identify a customer authority, preferably the team leader, and a facilitator. The facilitator acts as the local person on the ground who ensures that processes are put in place, data is collected and problems are identified.

The local customer authority manages the implementation of metrics within the team. It is also a good idea to draw up a contract or service level agreement between the metrics support group and the team. In this case, the metrics support group is servicing the team but there is also an element of service from the team to the support group. The contract or service level agreement should clearly state what will be provided by each party and when it will be provided. A real life example of such a document is given below although the names have been changed to protect the innocent. Note that the contract does not require a formal signature to work but it does no harm at all if you can get such a thing!

Service Level Agreement - Metrics Support Group and ALPHA Team.

As Agreed 20.11.20xx

1. Introduction

This document sets out the agreed level of support that will be provided to ALPHA Team by the Metrics Support Group relating to ALPHA Teams involvement in the Metrics program.

This Service Level Agreement, SLA, covers ALPHA Teams involvement in the four components of the Metrics program, Estimation, Applied Design Metrics, Local Project Control, and Management Information together with the Process Definition activities.

2. Staffing

• Metrics Support Group facilitators: Paul Goodman.

• ALPHA Team Customer Authority: A N Other.

• ALPHA Team facilitator: J Doe, (up to 50% of his time will be allowed for metrics related activities over the next twelve months).

Viewpoint Authorities:

Estimation	A N Other
Applied Design Metrics	To be decided
Local Project Control	J Smith
Management Information	A N Other
Process Definition	J Smith

(Note that this is a large team so we have introduced the idea of local viewpoint authorities to spread the work, and the enthusiasm across the group. I also apologize to anyone with the surnames Other, Smith or Doe!)

3. Estimation

Metrics Support Group will provide:

• A one-day training course on the 12th December 20xx.

• Six days on-site support to assist in setting up Delphi sessions and the use of other estimation techniques. The dates of this support are to be agreed but will be provided during the period January - April 20xx.

• Bureaux service providing off-site access to the CHECKMARK and GECOMO PLUS estimation tools.

ALPHA Team will provide:

• General administration for the one-day training course including organizing attendance by ALPHA Team staff, provision of training room, overhead projector, white board and flip-chart.

4. Applied Design Metrics

To be decided.

5. Local Project Control

Metrics Support Group will provide:

• A draft proposal document covering the recommended monitoring technique for submission to ALPHA Team management, after modification by ALPHA Team staff.

• A half-day discussion session with J Smith and other interested parties to provide sufficient information for them to set up a project control system. This is scheduled for 20th November.

• Two further half-day on-site sessions with ALPHA to address any problems that may arise. These will be provided during January - February 20xx depending on the current ALPHA Team workload.

ALPHA Team will provide:

• Resources from J Smith's area to establish and administer the monitoring technique.

6. Management Information

Metrics Support Group will provide:

• The Software Metrics Standards together with any updates.

• One day of on-site support to discuss data collection, storage, analysis and feedback. This is scheduled for 8th January.

• Further on-site support at one day per calendar month during February to June.

ALPHA Team will provide:

• J Doe will act as the local metrics coordinator. His role will be to establish the mechanisms for collection, storage, analysis and feedback.

The metrics that have been targeted for initial use are:

Workarea Reliability Measure	Group Reliability Measure
Local Correctness Measure	Maintainability Measure
Development Productivity Measure

7. Process Definition

Metrics Support Group will provide:

• Up to two days on-site assistance to derive a DFD representation of ALPHA Team's current development process. These days are scheduled for 14th and 22nd of January.

• A further one day is scheduled for 30th January when the derived model will be presented to various ALPHA Team staff. J Smith will carry out the actual presentation.

ALPHA Team will provide:

• The resources outlined above.

* Already provided to date.

Notice the way in which specific responsibilities are allocated to individuals, and the use of dates. As well as documenting what will be done when, this document is also a useful way of focusing the teams involvement in the program. Basically, they can see what they are getting into.

Notice also that one component of the program has been held back. In this case it was felt that we had enough to work with but as it turned out the development team did do a great deal of work on the Applied Design Metrics component before they formally adopted it.

It is good to build this concept of support into your program but you do need to be sure that you can supply that support, so you will need to do certain other things. Look at the resources you have available, then look at the number of teams within the organization that you have to support. At this point, you should realize that other functional groups not directly involved in development may also require support,.for example, your project control office, the marketing group and the testing teams. In fact, all of your customer groupings should be treated as potential accounts with their own contract covering implementation.

If my model is correct, one person working flat out can only support six startup accounts, allowing some time for holidays and for administration, during a full financial year. Such a situation will almost certainly force you to adopt a phased implementation and this should be reflected in your business plan. The plan should state how many teams will be addressed during each future financial year and should express the percentage impact of the metrics program across the organization year by year. Not only does this quantify how resources within the support group will be used but it also gives you clearly defined targets and shows that you are approaching the implementation in a businesslike manner.

Of course, your program may be structured in such a way as to work from the top down. It may be that you are introducing measurement initiatives across the whole organization and in this case your phases will concentrate more on the requirements that are being met rather than the penetration you are achieving year by year. This should also be expressed by your business plan which will form a cornerstone of your presentation to senior management when you seek approval to proceed.

---