Chapter 12: Stage 5: Implementation

---

Key Points

Making a success of implementation means making a success of working with people

The best plans, requirements and design still need work to make them a success

12.1 A PEOPLE-ORIENTED ISSUE

The problem with implementation is that it involves other people.

This is a key point to remember because a Software Metrics program is more to do with people than about the metrics and the techniques normally associated with such initiatives.

People are awkward. They come in many shapes and sizes but more importantly they all have personalities that must be catered for and egos that must be stroked. To successfully implement a metrics program you must develop and apply interpersonal skills like you may never have before.

Imagine that you have senior management commitment to take your program forward and that this involves introducing something new to a project team. We could be talking about different ways of deriving cost estimates, we may be talking about using Applied Design Metrics to get designs better. If you look at any project team I can guarantee that you will find a broad range of personalities with which you have to interact. You have no choice about this if you are to succeed.

During the industrial revolution in England a group of workers went around the country smashing the new machines because they feared they would put them out of a job. These people became known as Luddites and their genes are still with us today. Of course you would not expect today's Luddites to attack your proposals with crowbars and hammers although you never know. Today's Luddite uses more subtle but equally effective techniques of destruction.

The situation is made worse because individuals who appear to us to be Luddites are often sincere in their criticism. Put forward any new idea in any field and there will be those who balk at its introduction, people who wish to preserve the status quo or those who have heard all the hype before and who genuinely believe that software development, for example, can never be managed and controlled through the use of quantified information.

As you start to work with the project team you will see these attitudes manifest themselves in "office games." An individual may continually seem to agree with you and then throw in the dreaded word, "but." "Yes, but we work in a different way;" "Yes, but we do not have the resources to devote to this kind of initiative;" "Yes, but this is just common sense."

Of course you can counter most of these arguments. If you look at how the team develop software you will probably see some differences in detail or terminology but I guarantee that software development does not differ much between teams or even organizations. Requirements, Design, Build, Implementation and Testing; these basic components will be there in some form or another.

How much is being wasted within the team through delivered defects that need to be fixed or through poor maintainability. Only a small proportion of this will pay for the metrics initiative. If you never invest in the future you will have no future.

And of course it is common sense! If we only applied common sense in what we did then our problems would disappear overnight. Unfortunately common sense is like expert estimators: both are rare commodities especially within software development. Common sense says you try out high-risk, new systems on low-key, unimportant projects.

How much has your organization invested in CASE technology over the years based on a gut feel that it will pay benefits? Incidentally, Software Metrics is a low-risk proposal compared to most initiatives that occur within software development. To support this statement I would ask you to compare the cost of implementing a new design tool, project planning techniques or a new development environment to the cost of a Software Metrics program. I believe that you will find the cost of the measurement initiative significantly lower than the others.

My favorite "yes, but..." is the one that goes, "yes, but we need the tools." By tools what is meant is "where are the whiz-bang computer systems to support these metrics, where are the expert systems, where are the relational databases?" These questions fascinate me for two reasons. First, we have managed to develop large, complex systems in both the IT world and the non-IT world with little more than pencil and paper so why do people believe that the "tools" are a prerequisite to improvement? Second and more importantly, "tools" can only be introduced when a process is understood to the degree that it can be de-skilled and if the environment is amenable to the application of "tools." For instance, you cannot automatically collect design metric data unless your designs are held in an electronic media.

This does not mean that I am in any way "anti-tool." Indeed I long for the day when every stage of software system development is supported by an effective tool-set. When that day comes, Software Metrics will be part and parcel of development — always assuming, ,of course, that we can get the people issues right!

The "yes, but..." game is just one of many that you may come across but, if you will excuse the pun, it is especially difficult to counteract. If you continually try to defend the program in the face of a continued onslaught you will eventually run out of ammunition. A question will be asked for which you do not have an effective defense. The only way to counter this ploy is to meet it head-on but to use the age-old principle of turning an opponent's energy back on themselves. "Yes, but given the current state of software development we have to do something positive to make things better. We have to make this program work for us. Unless you have an alternative, of course?"

This approach takes confidence but then if you do not believe in what you are proposing you cannot expect others to!

Office games apart, resources can be the biggest problem with the implementation stage. Implementing a Software Metrics program within a team does mean that the team itself must put some "cash" up front. This is usually in the form of resources or effort. The problem is that the amount of resources needed is very difficult to quantify until you have some experience of doing it within your environment. Here honesty really is the best policy. You should be able to give some broad brush estimates for the amount of effort involved and you should do so, but do tell the team manager that these are estimates. Setting yourself a limit, basically using a banded estimate is often worthwhile. After all, software development team leaders are well used to working with rough estimates, they do it every day or they would not need Software Metrics to help improve estimation!

If you do make the mistake of dodging the effort issue you will be storing up trouble for yourself in the future.

All of this sounds rather negative but remember that most individuals involved in software development are only too aware that they need to improve the way in which they work, manage and control software development. Most are also very willing to try pragmatic approaches to get that improvement.

In any team there will be the natural Luddites. There will also be natural champions. Concentrate your efforts on the champions and accept that there will always be some people you will not convince.

The whole point of the implementation stage is to turn potential customers of the metrics initiative into participants in the program. If you succeed in this they will quickly become the owners of the program and you will have delegated its operation and continued enhancement to them.

Remember what you have to achieve; you will do some selling and telling to achieve participation. You and your customer will work closely together until you can pull back, having delegated the program to them. One trick is knowing when to let go; learn it.

The time to let go is when they are doing more of the positive talking and technical innovation than you are, then you have succeeded.

---