policy

A technoscope is an analytical tool, intended to help managers solve technical and organizational problems

Looking at problems through technoscopes W hen things go so wrong with a

project that it has to be scrap- ped, then il: is time to ex-

amine the way the project has been managed, particularly in its initial

stages. Take the experience of a Euro- pean Corporation where the president

had to scrap a large-scale computer

project, despite the fact that it was considered vital to the efficient man-

agement of the Corporation. The Corporation’s corporate in-

formation system, CIS as it was known, had been set up five years ear-

lier by the president’s predecessors, with a budget of eighty work-years of corporate computer staff. By the time it was scrapped it had already used

twice that amount but was nowhere

near to producing any useful results.

The Corporation believed it had done all the right things:

l It had consulted American business

management publications and had accepted the idea that a centralized

information system was needed. l It had hired a famous Californian

Abstract: EJficient project management

depends first upon tdentifkkg the problem to

be solved. The management ‘technoscopes’

outlined in this puper ure ejrf,ctive tools in this

process.

&words: managewnt operations,

management techniques, systems analysis.

Tom Gilb is a management consultant.

‘Think Tank’ to do a feasibility

study, which took two years and fifteen work-years to complete. It had made use of the largest com- puter manufacturer’s biggest and

most modern computers and data-

base software. It had uncomplainingly paid several million dollars extra in develop-

ment costs when the initial budget

allocation was exhausted. It was using all the latest ‘structured

programming’ techniques recom- mended by the computer supplier.

The project ‘functioned’. That is to say all the necessary programs were actually running. But the program-

mers and the project staff claimed they

needed more time and more computer

resources to ‘tune’ the system so that it would be able to do a day’s work in a

day. There were twenty thousand changes that had to be fed into the computer database daily, just to keep

it up to date, and one particular update took 20min. Fortunately not all up- dates were so time-consuming, but all efforts to tune the system to better

efficiency failed. Furthermore it was discovered that

it would take an estimated two years of

additional system development effort for a new factory or a single one of the wholly-owned suppliers to be added to the integrated system. Apart from the intolerable delay involved, the Cor- poration was faced with the fact that

by TOM GILB

such corporate changes were taking

place at the rate of about one every six months.

If the CIS project were v.hrown out, the Corporation would be left without

a proper management control system and it would have lost five years in

which its competitors might have

achieved some real results in this area. This illustrates the unpleasant real-

ity that confronted the new corporate president just one year after he took

office. But why did it happen? How

can all the ‘right things’ produce such very wrong results? It has become both popular and acceptable to blame these type of problems on anything and

everything but the people involved.

But I believe it to be a failure of man- agement .

The role of fki: manager

The role of the manager could be de-

scribed in a simplified form as:

l to define objectives,

l to create, evaluate, and select alternatives far reaching them,

l to control the implementation of selected alternatives.

But it is common to find instead:

that objectives are not clearly spe- cified, that alternatives are not thoroughly explored, that the implementation of solu- tions is not properly controlled.

vol25 no 3 aprill98.’ 001 l-684X,83’030013-05$03.00 0 1983 Butterworth & Co (Publishers) Ltd 13

Table 1. Characteristics of functions and attributes

FllRCcionr Attributes

Can be defmed in terms Measurable of subfunctions Can have any set of Quantifiable attributes

‘Are’, or ‘Are not’. Variable (no in between)

Can apply to any function

Most real-world decisions are multi- dimensional in nature, and the range of considerations they involve is con- fusingly wide.

Managers, thus, need tools that pro- vide them with the means to see the real problem, to formulate, ~~~~i~ and compare elements of the problem and its possible solutions, to communi- cate these facts to others, to control the implementation of solutions, and to measure the degree of success in achieving specified ends.

Technoscopes

What follows is not so much a ‘system’ as a set of ideas for aiding what is no more than ‘common sense’ thinking. These tools are called ‘teclmoscopes’ because they help us to see complex ideas, such as technical ideas (includ- ing management technology) more clearly. Technoscopes are a set of tools for management which can help it to:

formulate problems to be solved, co~uni~ate the nature of prob- lems to others, analyze the quality of the proposed solutions, register the results of partial imple- mentation of the solution for the improvement of the rest of the solu- tion.

Technoscopes are applicable to a wide range of management problems - from the very small and ‘personal size’ problems, to problems which involve hundreds of work-years or over a de- cade of calendar years to solve. Tech- noscopes are applicable to highly tech- nical engineering problems, as well as

complex organizational ones. These tools have strong roots in the best en- gineering traditions. They can be re- garded merely as formalized common- sense or as a more highly structured version of the common thinking pat- terns which we normally apply to our problems.

The general aim of these tools is to increase the degree of success of man- agement efforts, to produce the re- quired results in a way in which risks are controlled, and to keep desired control over the side-effects of solu- tions. Technoscopes will have diffe- rent, though often somewhat overlap- ping uses. Each of them helps us to define, analyze and organize our ideas about what we want and how to achieve it. The technoscopes as they are defined here revolve around the concept of management ‘goals’. Be- tween them, they can perform a wide range of tasks.

Some of the tools are packaged as formal methods for working with problems, while others are merely principles or checklists to ensure more systematic thinking. This article will consider the tools that help in defining the problem to be solved.

What is the real problem?

It is very rare to find management objectives clearly and completely stated. Often, project documentation is available, but with few or no effec- tive cost goals, with vague remarks ab- out vital subjects such as ‘improved customer service’ and ‘better product reliability’, and with no precise spe-

cification as to adaptability or produc- tivity.

There is usually no clear distinction made between the results or goals we must aim for, and the more ‘optional’ solutions which in our opinion will get us those results.

To become capable of choosing the right solutions, controlling the pace and cost of implementation, and knowing that our solutions have actually worked, then we must first of all state our objectives or goals clearly.

Functional and quality requirements

There are two fund~ental concepts to be distinguished when considering ‘objectives’ (see Table 1):

l functional requirements o attribute requirements

Functional

The ‘functional requirement’, in the sense used here, is absolutely basic to the solution. The decision in favour of a particular solution has many, seemingly complex, aspects. What- ever solution is chosen, the functional requirement must be met as a mini- mum for us to claim a valid solution of any quality at all. For this reason, functional requirements are virtually impossible to ignore.

At~.bute~

The second part of the objective, the one which is most likely to be incom- pletely and unclearly defined, is the set of requirements called ‘attributes’.

Typical attributes or quality areas which we might want to consider would be:

Short range attributes

0 accuracy l availability l development cost l answer production cost l ease of change 0 ease of learning

14 data processing

policy

l maintainability l project completion date

l security

l calculation speed

Longer range considerations

l compatibility with. standards l expected practical lifetime l portability to new environments

l stability in the face of change

We can consider attributes under the headings of resources and qualities:

Resources, e.g. time, money, human effort or system capacity. Resources tend to be limited. They can also be viewed as ‘constraints’ or as ‘limita-

tions’. We usually aim to reduce re-

source consumption as far as possible while still reaching our quality attri- bute objectives. Usually there is an in-

ternal fight amongst resource ideas for priority consideration - which man-

agement must resolve by defining priorities and maximum or minimum

limits on certain resources.

Qualities, e.g. reliability, availability,

maintainability, ease of use, timeli- ness. They tend to be desirable, and

we usually want to get as much of them as we can. There is, once again, a need to set priorities and minimum levels. and to balance quality improvements

against the added resource consump-

tion needed to obtain the desired qual-

ities. In any statement of management ‘objectives’, it is common to find a de-

tailed description of the ‘functional’ requirements, but at the same time it is even more common to observe a total failure to state the attribute require-

ments clearly and completely. with re- gard to both resources and qualities.

In most projecrs our actual solutions fall short of the requirements, not be-

cause of a lack of functional capability, without which the somlution would be

completely invalid, but rather because ofinadequate attributes. This failure is a design failure---prompted by a man- agement failure; the failure to define and control all critical attribute areas.

For example, in the corporate in-

formation system which we described

at the beginning of this article, the system was ‘functioning’ perfectly. It failed in practice for two reasons relat-

ing to its attributes:

l Its work capacity was such that it could not do a day’s work in twenty-

four hours. l It could not be adapted to twice

yearly major corporate additions within less than two years.

Critical attributes

When reading a typical statement of

management objectives, it might be prudent to work on the sceptical

assumption that several of the most important attributes of the desired

solution have not been clearly stated. This, surprisingly, is because these

goals are so critical to the solution that

management takes them for granted,

often assuming that everybody else has taken them into account and does not

see the necessity for stating them ex-

plicitly. A critical attribute is one which, if it

got out of control, would threaten the

viability of the whole solution.

l Projects which fail to specify clear- ly, and exercise control over, even

one single critical attribute, can ex- pect project failure to be caused by

that uncontrolled attribute.

l Critical attributes must be planned for with particular care. ‘Obvious’ things, which ‘everybody knows’,

cannot be left to take care of them- selves. Somebody must take expli- cit responsibility for them.

Quantification

Attributes are characterized by the fact that they are variable in nature, and that this variability can be measured on a scale. Attributes, particularly ‘quality’ attrihutes, are often not stated very clearly because people have not yet learned how to do so. It is

therefore common to see objectives for

major projects stated in such vague terms as ‘high security’, ‘improved

adaptability’, ‘more effective market-

ing’ and so on. These are, unfortunate-

ly, all subject to a. wide variety of possi- ble interpretations, e.g.:

l what level of security is acceptable?

l how adaptable does it need to be? l how effective is it now, and how

much better do we really want it to

be and need it to be?

When we do spelcify a goal clearly and

quantify it (finish the proiect by 10th March - or else’) then that goal is

unwittingly given more consideration,

higher priority, than goals which, while they may in fact be more impor- tant, are obfusca.ted by the use of un-

clear words, such as ‘better’ and ‘more

effective’. The only realistic defence against

this is to make :sure that ull critical

goals are formulated in equally clear language, at the same stage of develop- ment and in one place in the project

documentation. There is a cert,ain ‘art’ to finding the

necessary metrics coccepts and

measuring tools. Often they have no traditional written form, and they

must be tailored to the particular case at hand. You will have to exercise im-

agination and co:mmon sense to find

interesting measures, but nothing else

is really required. We must, frequent- ly, ‘explode’ vaguer concepts into their

natural subconcepts so as t:) give better

definition and a much greater ease in expressing them in a qumtified and measurable form;.

Examination of higher level goals is important. since it effectively !eads

you to a much broader choice of solu-

tions than if you try to solve the narrow lower level problem formulation in isolation.

Examination 01. lower level goals is important because it helps you com- municate and control ideas more effec- tively by giving them better definition.

Best and worst case levels

It becomes immediately obvious,

whenever we try to write down all cri- tical attributes, that some of them will tend to be in conflict with one another.

And what is not obvious about these

conflicts at this stage, will almost cer-

tainly surface sooner or later as a con- flict after implementation. There is at

least the very basic demand that each

quality attribute makes on resources, coupled with the fact that many re-

sources can seemingly be traded off for one another on occasion.

So, while we may have formulated a practical way of measuring numerical- ly how much of each attribute we

want, how are we going to resolve the

conthcts among them, when it seems impossible to attain two or more of our

‘wants’ at the same time? One of the ways in which we can

resolve these conflicts, is to state attri-

butes in terms not merely of the plan- ned level, but also of other ‘level’ ideas for the same attribute. We have

already said that projects without clear goals will not achieve those goals clear- ly. This implies that we need a posi-

tively planned level for each attribute. The planned level should be a realisti-

cally attainable level, when taken

together with all other planned levels for the same problem. This ‘balance’

of planned levels is certainly impossi- ble to predict accurately at early stages

of planning, so you may be forgiven for intentionally setting all planned levels at ambitiously demanding levels until

the conflict between them demands some compromise. We have to start somewhere, and our plans may as well be ambitious, though everybody in-

volved should be made aware of this, for example by a formal warning in writing on the initial goal statement.

‘These goals are intentionally set at very ambitious levels. It is not ex- pected that all of them will be attain- able at once.’

Trying to exercise control over a dozen or more critical attributes simul- taneously is a most difficult, although

16

necessary, exercise of management

and planning. When the pressure is on, something must give way. In order

that we make planned sacrifices, with- out sacrificing too much, it is essential that we establish a lower limit for each

attribute. We call this a ~lnrst case level, according to common terminolo- gy. This is agreed upon in calmer

times. It reflects the worst acceptable

level at any time for the system. Below the worst case level for any attribute of

the delivered system in question, the entire system is considered ‘not deli- vered’ (to minimum requirements).

For instance, we may stipulate a worst

case in legal contracts with outside suppliers, and have no legal obligation to pay for delivery, no matter how good the other attributes are, when one single attribute measures out below the worst

case level.

The worst case level can also serve as a simple criteria for making rough de-

cisions about solution suppliers. It provides a formal level regarding the quality of resources of what is being

supplied, below which we are not obliged to take delivery, or pay for, anything in the entire delivery of

which that attribute is a part. The worst case concept provides us with a

formal criteria for early or partial de- livery, at acceptable, even if not ideal,

levels of quality and cost. Worst case levels help us keep the deviations from

our planned levels within acceptable limits.

Projects which do not clearly define the worst case level for each attribute,

are likely to end up worse than the worst case that would have been de- fined.

The statement of a ‘best case’ is

more of a luxury than planned or worst case statements, but it has a mission worthy of consideration. The estab- lishment, or estimation of a best case level is intended to give a message to management ultimately responsible for the project:

l You have chosen a plan which is less than the best.

You cannot get the best until you

give us additional resources, or

until you sacrifice some other attri- bute, or until we learn of a new ‘state of the art’.

in addition, a best case statement says,

l you have no right to expect better

than this level at any time, so if that

is unacceptable, you have a duty to take up the matter now, and if necessary cancel the project.

Consider for a moment how many un- reasonable expectations, and conse-

quent personal disputes this mechan- ism saves. The best case also gives

some idea of how well the project would succeed if that particular attri-

bute were given top priority and if full resource support were available.

Now level specification

It is important, in practice, to allow

management to contrast future plans. The ‘now’ or ‘present level’ specifica- tion is customarily included together

with the future planned levels of any attribute, in order to give management a reliable and comparable number by

which to judge the future planned

levels of that attribute. Many people initially object that

they are planning an entirely new sys- tem, and that there is no present level

with which to compare things. This is not usually true, it is simply a narrow viewpoint. With only a little imagina-

tion most people can find some corres- ponding measure in the present state of things which represents what you have today, and which gives a useful

comparison basis for management for the planned levels. Management is pri-

marily concerned with the following questions:

are we talking about improve- ments? or simply holding on to present levels? or must we be prepared to accept a conscious degradation in some quality or cost level? and what is the degree of change?

data processing

policy

Table 2. An attribute specification

Attribute Measure name concept

Planning Time to make speed 100% plan

revision

Stock control Working cap. effect/cost concept

Meet customer ‘% orders requirements ex. by 24h

Worst case

1.75h

113 best case

75%

Plan level

Ih

‘I2 Now level

85%

Best case

30min

Now level

90%

NOZV level

Ih

78%

Attribute specification form

Information about planned levels, best case, worst case and now levels can be

conveniently collected and presented

to management on an attribute spe- cification form (see Table 2). With this form we can get a complete picture in a singie overview, in terms which are

clear and easily communicable, and

which will point out, lby means of un- filled spaces, the gaps in our know- ledge.

Hierarchies

The hierarchical description of the

The concept of hierarchical explosion

can be applied to all types of specifica- tion described in this text. It can be applied at several levels of explosion in

order to give sufficiently realistic detail in large and complex systems. The reg- ular use of multilevel hierarchical ex-

plosions of all the aspects of viewing and solving management problems is

the key idea of the tools in this text which allows management to apply

them to both small and large prob- lems. In addition to the power of de-

scribing large systems in sufficient de- tail, it can also supply rough descrip- tions of a problem, or its solution, by using the upper levels of the hierar- chical description only, either by hid-

ing unnecessary detail for the moment,

or by waiting until later stages to detail the lower levels of the hierarchy. In

this way managemem technoscopes meet the recurrent need of manage- ment to avoid being flooded by un- necessary detail at too early a stage of work.

~0125 no 3 april 1983

problem at hand, and its proposed

solutions help us to see relations in the upward, downward and peer levels of

the hierarchies. There are neither de-

tails nor broad brush ideas which are ‘unconnected’ to the total ‘model’ of the problem at hand. This means that every element of the problem state-

ment and solution is integrated into a ‘big picture’. It becomes easier for

management to ascertain whether it is dealing with relevant or irrelevant in-

formation, by trying to relate it to the

model.

Hierarchies of descriptions of a problem and the proposed solutions

should be used whenever the detail seems cluttered and unorganized.

Summary

The process of problem definition is

by no means completed on the first cycle of attempted definition. The need for more detailed specification

becomes apparent only after the

initial levels cause confusion, because of too vague or too narrow definitions.

The nature of the solutions themselves often remind us that there are perhaps more critical factors than we originally

envisaged.

We can improve our perception of

Technoscopes are as much a learn-

ing tool as a specification tool. The

learning process about future new sys- tems is never complete and the docu- mentation is forever subject to some

change, which is one reason why you will want to consider using flexible ways of writing it, such as using hierar- chies, pencil and erasure, or auto- mated text processing.

almost any management or technical

problem by:

Identifying all critical functional re- quirements, quality requirements and resource limitations (function

and attribute goals). Making sure that attributes have ali been described in practically

measurable terms (however ‘fuzzy’ the numbers need to be at this

stage). Describing the attributes in terms

of pianned levels, worst acceptable

level, present level and best possible

level.

Organizing both functional and attribute objectives into hierarchies wherever necessary for the sake of better overview.

Making sure that the attribute goals are in accordance with the real high-

er level management goals, such as

higher managernent plans and poli- cies. Get them to sign it.

To achieve this we will probably have to be creative. To enhance Intr creativ-

ity we also need tools, such as:

Checklists of common, but some- times overlook’ed, goals and sub-

goal definitions. ‘Brainsto~ing~ sessions with ques-

tions like, ‘which attributes, if they got out of control, could “kill” the solution?

The use of a quality inspection team to try to find d.iscrepancies between

more detailed problem statement or

solution leveIs, and the higher

levels of requirements (especially top management wishes, plans and budgets). The mere existence of such inspection teams for this pur-

pose will motivate planners to do a higher quality of initial work at this critical stage.

The use of an outside \of the im-

mediate project group) consultant to review the goals and to identify areas where formulation of them is incomplete or inconsistent. 0

Iver Halters vei 2, N-1410 Kolbotn, Norway. Tei: (472) 80 1697.

17