3.2 WHY DO WE NEED MANAGEMENT INFORMATION?

< Day Day Up >

Having discussed some of the background issues relating to Management Information let us take a step back and consider something even more fundamental: why are we bothering, anyway?

One of the most widely used, valid and succinct justifications for the collection of management information comes from Tom DeMarco and says simply that if you don't measure it, you can't control it. I would also like to paraphrase a statement from Dieter Rombach, at the time working with the Software Engineering Laboratory in the United States. He said, at the Eurometrics '91 conference in Paris (was it so long ago, yet still it rings true), that we no longer seem to be asking if we should measure, the question today is how do we measure? This is certainly true for some organizations and individuals but it is still true to say that many still need to be convinced or even exposed to the idea of measurement within a software development or support environment.

The next few paragraphs are included for those people who have the job of convincing such organizations or groups that management information is necessary.

The verb to manage is defined in my dictionary as "to control the movement or behavior of," which implies some form of control mechanism or loop. Control loops operate on a very simple principle. Measurements are taken of the process output, either by sampling or some other means, and these are fed into a comparator to relate attribute levels of the output to target or ideals. The difference between actual and optimum is then used to instigate corrective action if necessary. Such a control loop is easy to understand if you are a hi-fi buff or if you think in mechanistic terms, but what about other processes? Well, I suggest that the same control loop model can be applied to any process.

For instance, consider the situation where you have to move from point A to point B, twenty miles apart across open moorland or heath. You have with you a compass and you know that B is due west of A. Assuming that you walk at four miles an hour would you walk from A for five hours without checking your compass and expect to be at B?

What you would probably do is use your compass and bearings to periodically check your course and to make corrections to it. In other words, you are sampling the process and, through measurement, initiating corrective action. This type of process control is epitomized by long distance sailors who use celestial navigation, by means of compass, timepiece, sextant and chart to get from one coast to another.

It is worth noting that all of these examples include the concept of instrumentation and this idea has been extended to the control of software development and support through the dashboard analogy put forward by Howard Rubin, Rubin(1) , and others.

This simply says that managers within the software industry need instrumentation if they are going to be able to control the processes they manage and that part of Software Metrics is the discipline of supplying that instrumentation.

Another analogy that I use likens management in the software industry to the job of flying a plane. In the past it was very similar to flying one of the old biplanes. It was new, exciting and there were few rules. Instrumentation was rudimentary; if you wanted to know how high you were you looked over the side of the cockpit; if you got lost you just followed a convenient road or railway track. Even a disaster like running out of fuel wasn't too bad: if you were lucky, you just set down in a convenient field.

Nowadays, things are different. Software development has increased in complexity and in importance to the core business of most organizations. We can think of management within the software industry of today as akin to flying a jumbo jet. We have to get there on time, we have to give "good" service and we have to be reliable because many others depend on us. And yet, for most organizations their managers are flying that jumbo with the same instrumentation that they were using when they flew the old bi-planes. Is it any wonder that we have so many disasters within the software industry? Do you still wonder why we need that instrumentation?

Having said all of that, let nobody think that putting in the right instruments guarantees success or removes the need for good management. Instruments in a jumbo jet do not remove the need for a pilot nor will Software Metrics ever replace good managers. What Software Metrics can do is improve the probability that a good manager will succeed!

So, one reason for installing a management information system is to do with controlling the processes for which managers are responsible.

If controlling the process you are responsible for does not interest you then perhaps you might like to think about protection.

Protection and fear are two very emotive words but they are starting to have real meaning within the IT industry. Amazing things are happening; much of what is going on around you today was science fiction ten years ago, our culture has changed almost beyond recognition in the space of one generation, the policemen really do look young and the management are thinking about shutting down the IT function!

What was that last one again? Well, you may think that it is unbelievable but, unless IT is your core business, you may be shocked to learn that this is a very real option open to managers. If you need convincing I suggest you consider the following: A few of years ago the whole team on a large UK Government project was disbanded and the work was handed over to a private contractor. Again in the UK, some Government departments have been converted into "agencies," basically private companies owned by the Government but managed under normal market forces. Almost invariably this has reduced job security. Finally, you need look no further than the growth in the facilities management sector of our industry.

Think about facilities management for a moment. An organization is going to come in, take over your IT function and, for let's say, the same amount of cash that you pay out now, will provide you with the same IT support. Why do they do this? Quite simply, they know that, for most organizations, the IT function is performing so badly that the facilities management company can make a significant profit just by improving working practices and, it must be said, by either redeploying some of the staff onto other work or by shedding some of those staff. Of course it could never happen to you, or could it?

The one way to protect yourself from these kinds of threats is to be able to demonstrate that your IT function runs as a tight, lean machine and that nobody could do IT better! Of course you cannot do this without effective, quantitative management information.

The other side of this coin is how do you manage the situation when you do outsource, or "off-shore" aspects or even most of your IT operations and projects? Effective measurement becomes even more vital from the point when the contract is first being drafted, and the relevant measures are being defined, through to...

Hold on. Over recent years I have come across numerous situations where outsourcing contracts have been set up and agreed to by both supplier and client only for them to find that the measurement clauses, often labeled as the Benchmarking Clause, is indecipherable and/or unworkable. What follows is often acrimonious, time consuming and counterproductive, even in otherwise well-founded relationships. I cannot stress strongly enough that great care needs to be taken when establishing the measurement aspects of any outsourcing arrangement. If the situation arises whereby the measurement clause is either nonexistent or unworkable, both parties must recognize this and work together to rectify a situation that is harmful to both.

Software Metrics work within outsourcing arrangements just as with any other management scenario. In fact, it is often easier to get the measurement momentum going in these situations. Apply the principles embodied in this book and I suggest you will not go far wrong but above all else, keep it simple! The other key thing to remember is that a deal that only benefits one party may make you feel great, for an hour or two, but it is ultimately a sucker deal!

Fear can be a powerful motivator. Management through control is appealing. However, by far the most attractive reason for collecting and using management information has to be the concept of optimizing the process, actually using information about the process and its products, in our case the software development process and the systems that result, to improve the process.

This fundamental concept underlies the Crosby, [Crosby (1) ] and Deming, [Deming (1) ], quality models and Deming in particular points out that the concept cannot be applied without having the necessary information provided as part of the process itself. In fact, Deming uses various experiments to illustrate that tweaking the process, whatever it is, can actually make the results worse if this tweaking is done in a random and haphazard way. In other words, if you try to fix the process on gut feel rather than on the basis of quantitative information you will probably make the process and the results worse! I would suggest that there is an exception to this: if you are so intimately involved with the process as to be a complete and integral part of it then you probably can fix things on gut reaction and make it better. Equally, if you are that close to the process you probably do not have the power to change it. This is why engineers and IT staff are very good people to ask if you think there are problems. They know many of the answers but cannot do much about it. They are constrained by the very organization they seek to serve. That is quite an indictment of our society. Management information enables management by fact rather than management by opinion.

Let us now assume that I have browbeaten you into accepting that there is a need for management information. We now need to consider the typical requirements for management information, the problems of data collection and how we present results. I am going to do this in a slightly different order, looking at data collection first. The reason is that this is still the way many organizations approach the provision of management information and measurement in general. I hope to show that this is not the way to do things!

< Day Day Up >