9.5 CUSTOMER IDENTIFICATION

< Day Day Up >

One element that adds complexity to a Software Metrics Program is the number of customer types that the program must satisfy because the various customers have different requirements.

You may still be unsure about the use of the term "customer" in this context so a few more words about this may be appropriate. I am convinced that all projects, be they to develop software, to introduce a new development tool or to implement Software Metrics, should have a customer or group of customers associated with them from the earliest possible stage. Now it may be that the customer is only a pseudo-customer, as in the case of a marketing group when a new software product is being developed as a speculative venture, but the customer still exists.

Why is the customer so important? Unless you recognize your customer you cannot effectively capture the requirements for the project deliverable and this is as true for Software Metrics as it is for anything else. The customer requirements should always drive the project, otherwise there is a very real danger that the deliverable will not have a market and that the effort expended on the project will be wasted. Conversely, a project that recognizes its potential customers and that involves those customers has a much greater chance of success and needs to spend less effort in marketing its products.

While the specific customers of the program will differ between organizations there does seem to be very definite similarities between programs. I have used these to develop an approach to customer identification. The first step is to model the organization that the program will service in terms of major functional groupings.

Looking at the organizational structure of our example we can easily see a number of clearly identifiable groups. First we have the senior organizational management group. This consists of the managing director or CEO and his or her first-line reports including the Systems Development Manager. This group will probably possess certain characteristics that should be noted. Some senior managers view Systems Development or IT as a "black hole" into which they pour resources for very little quantifiable return. They also tend to view Systems Development, rightly or wrongly, as something that is very poorly managed. There are some good reasons for these views.

Historically, the drive for IT within organizations has been to put systems in place regardless of cost. Often, it has been thought that if systems were not developed then the competition, if they developed IT systems, would gain such a competitive edge that the very survival of the organization would be in doubt. This led to a "blank check" style of systems development that has cost many organizations a great deal of money, often justified by the flimsiest of cases, for little return.

In addition to this fear-driven investment, there has also been an element of "momentum drive" acting on organizations. Momentum drive is something that has probably never been experienced before in the history of commerce but which has typified the IT industry. Information Technology appeared within the last sixty years or thereabouts but within this relatively short period of time has impacted almost every walk of life and has truly brought about a second industrial revolution. You know that this is true, but have you considered the effect?

The most dramatic effect has been on time. Time, unlike most physical dimensions, is not fixed. We perceive time differently in different circumstances and the effect of the IT explosion has been to dramatically speed up our time perception. For example, acceptable time-to-market is now much shorter than it was ten years ago, product lifespan is much reduced and even in our personal lives we are no longer willing to accept delays in, say, transatlantic telephone calls that were previously considered normal. What all this means is that many organizations have invested in IT, at high cost, with little or no control. They have been pulled along by the momentum of the second revolution.

The second major push to the momentum drive came with the Internet and this is accelerating at an ever-increasing pace. While most organizations have already addressed the obvious applications of IT the focus in commerce today is often on E-commerce, often with great diversity. At the more technical end of the industry the impetus comes from the capacity of the technology to deliver ever more functionality, often for less unit cost. Simply consider the cell or mobile phone explosion.

But there was ever such a slight lull, a slowing down. For some parts of our industry this came at the point when the majority of basic applications had IT systems associated with them. The end of the cold war gave a pause to the defense industry. Non-IT managers had just a short time when they could think without the full pressure of the momentum drive bearing on them.

They took stock and started to insist on greater control over their Systems Development functions. This is true for organizations whose Systems Development functions service internal requirements and it is equally true where such functions earn the organization revenue. Senior management is demanding that greater control be applied to such divisions to reduce risk and maximize return on investment.

Another driver towards greater control is the appalling reputation that the IT industry has concerning cost and time scale over-runs. Senior management who, previously, accepted this state of events, will no longer accept this.

So senior management at the organizational level will become important customers of the Software Metrics program and we can guess that they will see the program as a vehicle by which greater control can be obtained.

The second customer grouping is the Systems Development manager and his or her first-line reports. Note that the Systems Development manager is in both of the groupings identified so far. Such an overlap or intersection almost always identifies a key player!

While this identification can be trivial, such a diagram does highlight the fact that someone like the Systems Development manager will, in fact, be relating to the program in different ways to others in the groups of which they are part.

The Systems Development manager may well wish to use the Software Metrics program to gain greater control over his own managers, especially the Product and Support Development managers. However, the Systems Development manager will also see the metrics program as something that may provide a defense against the bullets other directors fire his way.

Some organizations initiate a Software Metrics program to gather information to protect themselves from what they see as the threat of outsourcing. However, the decision as to whether or not to outsource an IT function is often a political one rather than one that is taken based on objective, quantified information. To be frank, if you initiate a Software Metrics program in response to such a threat you probably have insufficient time to gather the necessary information before the decision will be made.

For the moment I am going to include the Software Development and the Test and Integration managers as part of the Systems Development senior management group. This group is typified by the fact that its members are not responsible for the day-to-day activities of specific projects. They are a functional management group rather than a group focused on specific projects.

Which brings us nicely to our third customer grouping, the project managers, who in terms of our example organization are the Team Leaders. These individuals are right there on the firing line. They are responsible for the day-to-day work on specific software development projects. These people tend to be technically oriented. Given our industries propensity for taking good technical staff and then putting them in positions where they have to manage people — which often demands a very different skill set — you should not be surprised to find some interesting interactions occurring between this group and the Software Metrics program.

Project managers tend to fall into three camps. They may latch onto Software Metrics as something that can actually help them get control over their projects and enable them to communicate facts to their own managers. Alternatively, they may be the kind of technician who insists on proving the theoretical concepts behind every idea or suggestion. This can cause problems because of the immaturity of many Software Metrics techniques. Finally, they may be pragmatists. Of the three camps this is the one I find it easiest to work with. A pragmatic project manager knows he has problems and has tried to address these, often with limited success simply due to a lack of available time for thought let alone action. He also knows that life holds no guarantees but because he does not have an answer to a specific problem he is quite willing to listen and to try something new.

A pragmatic project manager will often gratefully accept a new idea, the use of a metric or a metric-based technique. Typically, you as a consultant, internal or external, go back to that manager one, two or maybe three months later to find that he is doing things that you never even thought of. Now you become the pupil and he or she becomes the teacher. This is one of the most satisfying times within a Software Metrics program.

Not only have you succeeded in getting something useful in place but you now have a practical application that can be used to convince others and, as a bonus, you probably have new ideas developed in the field.

It is often said that senior management commitment is THE prerequisite for a successful Software Metrics program. I disagree! It is a prerequisite but I believe that identifying project managers who are sufficiently open-minded and who are prepared to work with you in implementing Software Metrics is equally important.

Another important group is the support units. These are functional specialists whose role is to facilitate software development within the organization. This group covers departments such as marketing, planning and project control offices. An R&D function can also be included as can the process improvement function. In many cases groups like these need information such as productivity and quality levels to be able to function effectively but such information is often unavailable. Once they see that the Software Metrics program intends to make such information available to them, support groups can become good customers of the SMP.

In particular, you may well find that the process improvement function welcomes such a program with open arms. The process improvement philosophy is relatively new to western business as a whole and yet it has become very popular over recent years. All implementations of such a philosophy, whether they are based on the Capability Maturity Model, International Standards, the Business Excellence Model or even if they have their roots as far back as Crosby or Deming, emphasize the need for measurement; but most process improvement functions struggle with the application of measurement on a broad scale.

For example, the application of Statistical Process Control in its traditional sense is difficult within software engineering functions because of the general skew of data sets from that environment and because of the need to get a reasonable data set to be able to apply this technique. However, the link between this and Software Metrics is obvious: Software Metrics is a specialty that can satisfy the requirement for measurement within a practical application of Statistical Process Control and such a link should be exploited as much as possible.

And so we come to our final group of potential, internal customers of a Software Metrics program. This group is often overlooked yet their involvement and acceptance of a Software Metrics program is vital to its success. The group I am talking about is the software engineers, or programmers.

I vividly remember one occasion when I spent half an hour going through my standard introduction to Software Metrics with such an engineer. He nodded in all the right places and even asked one or two pertinent questions. He saved his real bombshell until the end when he simply asked, "what's in it for me?" This really drove home the point. Why should engineers take time to supply information, accurately, when they get nothing directly back in return? This important group exists and, please, do not ignore them. Simply taking the time to talk to and involve as many engineers as is practical could pay handsome dividends. But do be honest, the engineers may not get much benefit directly from the Software Metrics Program until the data that comes from it is used to improve the working environment by setting, for example, more realistic timescales for projects.

Having talked about internal customers, that is groups that are involved in the production of software within an organization, we really must consider external customers of the metrics program. I mean now the actual consumers of the products of software development. In the case of our example this means true customers, individuals or organizations that pay real money for the products of software development. But customers can also get their hands on such products without paying real money.

We all have customers even if we never speak to or see anyone who is not part of our employing organization. For example, our organization model contains a number of support development teams who generate products that are used by the product development group. These people are customers in almost every sense of the word. I consider it so important that we consider our customers as just that, be they external, paying customers or internal users of our products, that I do not intend to distinguish between them.

Customers will not generally be involved in the day-to-day use of Software Metrics, but they can be considered as a specific customer group for that program. They may even be driving that program but, more often, they will be more passive during the early stages. Depending on the commercial environment in which you work you may have to make some assumptions about their requirements.

Once you have derived a high-level breakdown of your potential customer set you should consider this in more detail. For example, within the Systems Development Senior Management set we have two levels to cater for, the Test and Integration and the Software Development managers. Also, the actual number of support groups seen as customers of the program will be dependent on the program's terms of reference and the detailed organizational structure.

I do not intend to discuss the derivation of the lower level breakdown as it is so dependent on these factors but please let me emphasize that performing such an analysis is worthwhile and should not be ignored. I have produced a table, Table 9.1, showing one lower-level breakdown that could apply to our model organization.

Table 9.1
Organizational Senior Management
Managing Director
*Systems Development Director
Finance Director
Personnel Director
Systems Development Senior Management
*Systems Development Director
R&D Manager
Product Manager
Support Development Manager
Operational Support Manager
Test and Integration Manager
Software Development Manager
Support Groups
R&D
Planning
Project Managers
Engineers

Notice that this breakdown can include functional groups or individuals where they carry out a functional role. One way to derive this lower level identification of customers is to merge the reporting hierarchy such as is shown in Figure 9.5 with the functional linkage chart shown in Figure 9.4.

< Day Day Up >