9.6 MARKET IDENTIFICATION

< Day Day Up >

Having identified the potential customers of our program, we should consider the potential market and the size of that market. This activity is similar in scope to the initial market research work done during the feasibility study. The difference lies in the amount of detail, this market identification being more than a sizing exercise. Surprisingly, this is an activity that is often ignored within Software Metrics programs yet it is important. To all intents and purposes you are going to be establishing a business within your own software development function that will service the needs of that organization. If you were setting up an external business, one step that you would most certainly consider is to establish the potential market. There is no reason why you should not do the same for an internal business!

There are various questions that should be addressed by this activity and the answers you obtain will form the basis of a "business plan," as opposed to a project plan, later in the program. It can be argued that market identification does not need to be carried out until you get nearer to implementation but, from my own experience, the earlier that you start to address this issue, the better. The information you gather during this activity will also directly affect the next job, establishing a user interface.

You may be surprised how difficult it is to get some of the information you require. It never ceases to amaze me how little basic management information is available within software development functions of any size and, if nothing else, this activity will give you a better understanding of the organization in which you work.

Typical questions that should be asked during this activity include:

How many sites is software development carried out on and where are they located?
Is there any functional specialization between sites? For instance, does one site concentrate on integration and testing of software developed on other sites or are different products developed on different sites?
How many project teams are in existence at the current time?
How many software engineers do we have?
Do engineers work exclusively on one product/project at a time?
Are projects grouped under functional headings? For instance, do we have a team leader managing more than one project team, each developing say a build of a current product?
How many project teams do we plan to have at the start of the next three financial years?
What is the relationship between the planning function and the project teams?

You may find that some of this information is readily available from organizational data. Other items of information will certainly require some digging. You may also find that these questions, in turn, raise other questions. For example, what do we mean by a project? Does the project team include the team leader? Has anyone ever defined our development process?

When in doubt remember the first principle of Software Metrics: be pragmatic. At this stage you are trying to get information that will allow you to proceed with the Software Metrics program. This does not have to be correct to three decimal places nor will it be used in any way that involves significant business risk. Yes, you may well need to define what is meant by a project and have that agreed by your customers but that comes later so use any sensible definition at this point.

Having obtained this information you can now proceed to the next activity:

< Day Day Up >