Transport Research Laboratory Department for International Development

Old Wokingham Road 94 Victoria Street

Crowthorne, Berkshire, RG45 6AU London, SWIE 5JL

Overseas Road Note 15

Guidelines for the design and operation of

road management systems

ORN 15
First Published 1998
ISSN 0951-8797
Copyright Transport Research Laboratory 1998.

Subsector: Transport

Theme:; T2

Project title: Road Network Management

Project reference: R6024

This document is an output from a project funded by the UK

Department for International Development (DFID) for the
benefit of developing countries. The views expressed are not
necessarily those of the DFID

TRL is committed to optimising energy efficiency, reducing

waste and promoting recycling and re-use. In support of these
environmental goals, this report has been printed on recycled
paper, comprising 100% post-consumer waste, manufactured
using a TCF (totally chlorine free) process.

Transport Research Foundation Group of Companies

Transport Research Foundation (a company limited by guarantee) trading as Transport
Research Laboratory Registered in England, Number 3011746
TRL Limited. Registered in England, Number 3142272
Registered Offices Old Wokingham Road, Crowthorne, Berkshire, RG45 6AU.
ACKNOWLEDGEMENTS

This Overseas Road Note provides detailed guidance on the design and operation of computer-based road management
systems. It has been issued in parallel with a reference textbook published by Macmillan Press Ltd covering the wider
area of road maintenance management (Road maintenance management: concepts and systems by Robinson, Danielson
and Snaith). Mr C C Parkman (TRL) was project officer and editor. The original draft of the Note was prepared by Dr R
Robinson in association with May Associates. Contributions were also made by Dr J Rolt, Mr T Toole, Mr P May and
Mr R Abell. Mr H Lewis performed a final technical edit.

The Note draws on material from a number of sources as well as experience gained by this team working with many
institutions. Chapter 3 has been developed from guidelines produced by May Associates for the European
Commission. The recommendations for information quality and data design are developed from work at the World
Bank. Much of the document draws on the on-going research carried out by TRL in this subject.

The helpful comments of Mr H S Thriscutt and Mr N Ings on earlier versions of the draft are gratefully
acknowledged.

OVERSEAS ROAD NOTES

Overseas Road Notes are prepared principally for road and transport authorities in countries receiving technical
assistance from the British Government. A limited number of copies is available to other organisations and to
individuals with an interest in roads overseas, and may be obtained from:

International Development Advisory and Information Unit

Transport Research Laboratory
Crowthorne, Berkshire, RG45 6AU
United Kingdom

Limited extracts from the text may be reproduced provided the source is acknowledged. For more extensive
reproduction, please write to the address given above.
CONTENTS

Page

1 Purpose and structure of the note 1

Purpose 1
Structure 1

Part A: Principles 3

2 Road management 5

Categories of work 5
Management functions 5
The management cycle 5
Introducing procedures 7
Computer-based systems 7

3 Approach 11

External factors 11
Institutional factors 12
Stages in the design process 12
Multiple system implementation 12
Use of technical assistance and the private sector 12

Part B: System design 15

4 System requirements 17

Identifying objectives 17
Cost-benefit analysis 17
Priorities for system implementation 19

5 System specification 23

Identifying the system users 23

Confirming system outputs 23
Identifying data and models 24
Information quality levels 24
Types of model 26
Criteria for model selection 27
Model calibration 27

6 Specification of network information systems 29

7 Specification of planning systems 33

iii
 Page

8 Specification of programming systems 39

9 Specification of preparation systems 43

10 Specification of operations systems 49

11 Computer requirements 53
Sources of procurement 53
Customisation 53
Modular approach to software 53
Programs and databases 53
Hardware 54

Part C: System operation 55

12 Training 57

Training needs analysis 57

Training levels 57
Training topics 57
Monitoring training 60

13 Systems management 61

Defining responsibilities 61
Control of systems and data 61
User access 61
Data updating 61
Data control 62
Monitoring and feed-back 62
Institutional issues 62
Technical issues 62

14 References 65

Appendix A: Glossary of terms 67

Appendix B: Institutional appraisal check list 73

Appendix C: Example applications of the information

quality level concept 78

iv
1 Purpose and structure of the note 1.6 Part B is intended for use by professional staff who
have the task of recommending the type of system design
Purpose to be adopted. It addresses the processes involved in
1.1 This Note is intended for engineers and managers in system design, starting by identifying the objectives of the
road administrations who are responsible for the system and the components it needs to include (Chapter 4).
specification, procurement, implementation and operation It then identifies a generic approach to system
of computer-based road management systems. It offers specification, based on the outputs that might be delivered
guidance to help them reach informed decisions about the by the system and the data and computer models required
type of road management system which will best match the to produce those outputs (Chapter 5).
needs of their administration and the most effective
methods to be used for operating the system. 1.7 Chapters 6 to 10 discuss in turn the development of
specifications for management systemsconcerned with
1.2 As well as explaining the benefits which computers road network information, strategic planning, work
can bring to the task of data management, the Note points programming, work preparation and operations, while
to the problems that can occur if computer-based systems Chapter 11 reviews the procurement of computer software
are designed inappropriately or operated without a full and hardware.
awareness of their strengths and limitations. The aim is to
alert managers to these risks so that, in planning and 1.8 The operation of road management systems is the
implementing their systems, they can take steps to prevent subject of Part C, which is intended for staff involved in
problems from developing. Engineers and managers do not system implementation. Chapter 12 deals with the training
need to be computer specialists to gain advantage from the and competence-building activities needed within an
Note; but they should be familiar with computer administration to ensure the successful introduction of a
applications such as spread sheets and word processing computer-based system and its continuing operation. Issues
programs, in addition to having a sound basis of related to the day-to-day management of the system are
professional experience in road management. covered in Chapter 13.

1.3 The Note does not discuss management methods 1.9 The Note concludes with a series of Appendices
which do not rely on computers, though manualprocesses which provide reference material and background
are likely to be involved to some extentin any system. information on specific issues raised in themain body of
Manual management methods are described in Overseas the text.
Road Note 1 (TRRL Overseas Unit 1987) for road
maintenance systems, and Overseas Road Note 7 (TRRL
Overseas Unit 1988b)for bridge inspection and data
systems.

1.4 While the Note is not addressed to organisations

engaged in developing or marketing road management
systems, or to institutions funding projects for system
implementation, they too may find it a useful source of
reference.

Structure
1.5 The Note has three main parts, each focusing on
the priorities of a different level of responsibility in the
road administration. Part A is meant for senior policy and
decision-makers. It outlines the principles of best practice
in road management and the role of computer-based
systems in supporting management procedures (Chapter 2),
and defines the philosophy underlying the Note (Chapter 3)
- in particular, the need to ensure, before a computer-based
system is introduced, that the road administration has the
institutional capability and the commitment to implement
it effectively and to sustain its use over the long term.

1
2
Part A: Principles

3
4
 • The focus of attention is transferred from the network
2 Road management as a whole to the specific locations where works are
being undertaken.
2.1 Road management starts from the premise that • The time horizon narrows from a span of several
the road network is an asset which needs to be years to the individual budget year and then down to
maintained and improved so as to secure the best the current week or day.
performance and value-for-money and the maximum • The level of management responsibility decreases.
service life. The aims of road management are to • The information required for each function changes in
enable the network to withstand the damage caused scope from summary or sampled data about the entire
by wear and tear, to prevent sub-standard conditions network to detailed and precise data about specific
from developing, and to ensure that traffic can road sections.
continue to travel, in a manner which is safe, efficient, • Where computer systems are used to support
reliable and which causes the least damage to the management activities, automated processes which
environment. These aims are achieved through a produce standard reports on a pre-defined basis are
series of works and activities which depend for their progressively replaced by processes in which
effective management on the maintenance of up to- managers work interactively with the computer.
date information about the features and condition of • There is a transition from tasks which are
the road network. conventionally viewed as client function to tasks
which are increasingly amenable to being contracted
Categories of work out.
2.2 The works and activities undertaken as part of
road management are generally categorised by their The management cycle
frequency and the budget from which they are funded 2.5 In performing each of die four road management
(Table 2.1). The terms used in the table are explained functions set out in Table 2.1, managers need to follow a
in the glossary which forms Appendix A. logical and clearly defined sequence of steps. This
approach, termed the `management cycle', is shown
Management functions diagramatically in Figure 2.1. Each successive step in the
2.3 The management of these works and activities cycle requires an accurate and up-to-date supply of
is best viewed in terms of four main functions: information if the correct decisions are to be made. For
this reason, the maintenance of a database of management
• Planning. information is at the heart of the cycle.
• Programming.
• Preparation. 2.6 Road management can be viewed as a process which
• Operations. integrates the cycles of activity involved in each of the
management functions of planning, programming,
2.4 Table 2.2 indicates the application of these preparation and operations. While these functions have
management functions within a road administration. different objectives, they draw on a shared fund of
The progression from planning through to operations information about the road network: in other words, there
is accompanied by several changes in emphasis: needs to be a continuous flow and

Table 2.1 Categories and examples of road management works

5
Table 2.2 Road management functions

Figure 2.1 The management cycle

6
feedback of data both within each management cycle management through the use of manual techniques:
and between successive cycles. Table 2.3, which operating check-lists, equipment use and maintenance
spans the whole process of road management, shows cards, diagrams and wall charts have a part to play even
examples of management cycles and their component in the most advanced management system. But effective
tasks. road management requires continuous access to
information about every aspect of the road network and
Introducing procedures the activities undertaken to keep it in good condition.
2.7 To ensure consistency in its approach to each With their power and relatively low cost, modern
management function, a road administration should computer systems are ideally suited to assist in this task,
have a clearly defined policy framework. In order to particularly where large amounts of data have to be
adhere to the standards as set out in this framework, it managed. Even so, it needs to be remembered that the
is important, amongst other things, to introduce and sole purpose of computer-based systems is to support the
document procedures for each activity in the road human resources engaged in the management process,
management process. A procedure will normally and not the other way round.
specify:
2.10 Each of the management functions inherent in the
• the purpose and objective of the activity; care of the road network can benefit from the power of
• the units within the administration to which it computers, notably through the creation and
applies; maintenance of a network-wide database. It is essential
• the meanings of any terms requiring definition to use a computer system as a means of reinforcing the
used in the procedure; effectiveness of agreed procedures, rather than allowing
• the component tasks of the activity, shown as a it to dictate the way road management is to be
logic network, flow chart or work plan; performed. In the past, computer systems have
• the responsibilities for fulfilling the procedure sometimes been brought into operation without being
which attach to particular posts within the matched correctly to the priorities and procedures of the
administration, including requirements for liaison administration. As a result, they rapidly lose credibility.
and consultation; The situation becomes even worse when the operational
• any special considerations of health and safety procedures of the road administration are expected to
and environmental protection which may apply change to reflect the particular requirements of a
to the tasks covered by the procedure. proprietary computer system.

2.8 If a procedure is to work successfully, the staff 2.11 Two types of computer-based systems are used
who will be involved in managing and implementing in road management:
it need to understand what it is intended to achieve,
and it has to be accepted as a logical and practical • network information systems, which correspond
course of action. For this reason, it is important to to the core of the management cycle (Figure 2.1)
consult them when the procedure is being drafted and and are used to assemble, organise and store data
to give them an opportunity of contributing to its about road network
detailed formulation. The aim is to arrive at a • decision-support systems, which are used in each
procedure which staff regard as helping rather than stage of road management to assist in the tasks that
hindering their work, and to which they can feel a form the perimeter of the management cycle -
sense of professional commitment. The quality of planning, programming, preparation and operations;
road management practice is largely dependent on the they process network data as a basis for decisions
degree to which appropriate and clearly documented about road management activities and almost
procedures are applied within a road administration. always require a fully functioning network
So far as developing a computer-based road information system.
management system is concerned, it will be difficult
to achieve worthwhile results until sound and 2.12 Terms such as `maintenance management system'
effective management procedures are in place. and `pavement management system' can easily cause
confusion, since systems described as such and
Computer-based systems produced by different vendors often possess quite
2.9 Once an administration is equipped with these different characteristics. Table 2.4 gives examples of the
procedures, it makes sense to consider introducing a way systems offered in support of road management
computer-based system to assist in the process of functions are commonly described.
road management. There is, of course, much that can
be achieved in road

7
Table 2.3 Examples of management cycles for road management functions

8
Table 2.4 Examples of different system descriptions

Related
management
function System description

Planning Strategic analysts system

Network planning system
Pavement management system

Programming Programme analysts system

Pavement management system
Budgeting system

Preparation Project analysis system

Pavement management system
Bridge management system
Pavement/overlay design system
Contract procurement system

Operations Project management system

Maintenance management system
Equipment management system
Financial management/accounting system

9
3 Approach Organisations will have differing strategic objectives -
for example, a public sector administration may be
3.1 The guidance set out in this Note reflects a concerned to maximise overall social benefits from the
structured approach to the design and operation of road network, whereas for a private toll road operator
computer-based systems. Its key principle is the need maximising revenue may be a corporate priority - but in
to ensure that a road administration has the both cases the feasibility of a computer-based system
institutional capability to specify a computer-based depends on the capability to sustain it. Experience from
system which will match its requirements and road administrations in industrialised economies shows
priorities correctly, and that it has the competence to that the implementation of a new management system,
use the system efficiently before investing resources with all its institutional changes, takes a period of
in the procurement of hardware and software. In the between five and ten years and requires a considerable
past, there has been a tendency for road investment of financial and human resources. The
administrations to review the existing range of process should not be expected to require less time or
commercial products and then simply choose the one investment in developing and emerging economies.
which appeared to have the most functionality within
the available procurement budget. This course of 3.4 The external and institutional factors that
action, which omits a rigorous and comprehensive determine the feasibility of a computer-based system
assessment of a road administration's abilities and need to be addressed before any start is made on
requirements, has usually proved unsuccessful, with designing the system.
the result that resources have been wasted and
administrations left with systems which created more
problems than they solved. External factors
3.5 By definition, external circumstances such as the
3.2 A computer-based system is a technical state of the economy, the legal and regulatory framework
response to the challenge of managing and applying and, to an extent, the budgetary limits within which the
road management data. For this response to deliver its road administration is required to operate are outside its
expected benefits, two prior conditions have to be own control; but it is essential for any administration
fulfilled: first, the social, economic and regulatory setting out on the path of computerisation to try to secure
context in which the road administration functions - the most favourable climate for change. Measures which
the set of external factors which govern its need to be explored include:
activities- needs to be conducive to effective
performance; and second, the road administration • obtaining from government a commitment to view
itself has to develop the institutional competence to road management as an economic priority and to
support the introduction of a computer-based system. provide the necessary :Funding to launch management
The relationship between technical, institutional and systems successfully and sustain their operation over
external factors is shown in Figure 3.1. Simply the long term;
implanting a computer system in an organisation that
is ill-equipped to use it will be a waste of resources; • gaining government commitment to the establishment
without the underlying base of institutional capability of effective legal, regulatory and administrative
and external support, the pyramid will collapse. mechanisms to reinforce the responsibilities and
powers of the road administration;
3.3 This principle holds good whether the
organisation responsible for managing the road
system is in the public or the private sector.

Figure 3.1 Hierarchy of factors affecting road management (the `Brooks pyramid')

10
• examining the potential for innovative methods of 3.10 The physical design and implementation stage
financing and possible partnerships with the private focuses on the technical aspects of the system. It covers
sector, to see whether these may offer a more the procurement and commissioning of the appropriate
dependable continuity of funding; hardware and software and the operational, training and
management measures that bring the system into
• promoting the concept of efficient road implementation.
management both in government circles and in the
wider public forum (for example, by publicising 3.11 Figure 3.2 shows the overall sequence of stages
the economic and political consequences of not and activities forming this design process. The sequence
maintaining the road network to the required is fully consistent with the structured approach to
standards); systems design applied in the information technology
sector.
• communicating effectively the message that
neglected roads mean higher operating costs for all 3.12 The approach may appear unduly complicated for
road users. a small system, but its applicability needs to be viewed
against the potential costs of implementing and
Institutional factors operating the system. These costs are normally
3.6 As a further preliminary step, the road dominated by the expense of data collection. In the
administration needs to undergo an institutional appraisal absence of a rigorous approach to system design, there is
that will assess its readiness and suitability for the a considerable risk that data requirements will be
introduction of a computer- based system, identify specified inappropriately, with the result that the costs of
management characteristics which may constrain the acquiring and maintaining data far outweigh the
effective implementation of the system, and provide the practical benefits of the system.
basis of a programme of action to resolve constraints and
improve and strengthen the technical capability of the Multiple system implementation
administration. An example of the factors which have to 3.13 An institutional appraisal may sometimes indicate
be examined in this appraisal are listed in Appendix B. a requirement for several different types of computer-
based system. In such cases the process of
3.7 One important point to confirm as part of this implementation has to be undertaken carefully and needs
appraisal is the degree to which senior management staff to be phased in gradually as part of along-term
of the administration understand the implications of development plan. The temptation to try to do
computerisation and share an intention to meet the everything in a single bout of procurement should be
institutional and technical challenges which it presents. avoided; experience suggests that it is much better to
move forward step by step. In this way each step is fully
Stages in the design process assimilated within the administration before moving on
3.8 The steps which result from the institutional to the next. This type of approach should enable the
appraisal may be categorised as the logical and physical administration's longer-term objectives to retain
stages of the design process. The first step in the logical flexibility for change and adaptation, while allowing
design phase, that of obtaining commitment to proceed each successive stage of implementation to benefit from
with the development of any system, is of prime the build-up of experience and competence.
importance and its need cannot be overstated. Without a
firm commitment from an organisation, both with regard Use of technical assistance and the private sector
to external factors (3.5) and also institutional factors 3.14 Systems do not necessarily need to be
(3.7), there will be limited potential for a system developed in-house by the road administration. Box 3.1
achieving its objectives. indicates parts of the process where the use of
consultants and other sources of technical assistance
3.9 The logical design stage starts from a commitment from the private sector may offer advantages.
on the part of the administration to introduce the system
and make it work. The administration has then to confirm
the objectives of the system and decide its requirements
in terms of the components to be included. This leads to
the preparation of a detailed specification for the system,
which identifies users and their required outputs and
hence defines the required data and analytical processes.

11
 Figure 3.2 Overall approach to the design and operation of systems

12
Box 3.1 Use of technical assistance from the private sector

Requirements
During the requirement phase, some knowledge of the market may be helpful to confirm what is technically feasible.
It can be useful to seek an objective outside assessment. Those involved within the roads administration may lack
up-to-date knowledge of the capabilities of modern systems, or may find it difficult to identify the real business
benefits of systems being considered. Similarly, few consultants have in-depth knowledge of developing and
implementing a wide range of systems. Those that are experienced often have proprietary systems of their own.
Such systems may be very competent and robust, but may not meet all of the requirements of the road
administration. Clearly, the choice of objective outside assistance, and the terms of reference for its employment, are
important.

Specification
During the specification phase, the investment should be justified in terms of costs and benefits. A specification
can then be written that focuses on the minimum facilities that are needed to deliver those benefits. At this stage, it
is vital to avoid expansion of the scope of the system (as this can affect the cost significantly) without being sure
that the incremental benefits outweigh the additional costs. There have been many examples where the perception
of the success, or otherwise, of a new system has been affected because of unrealistically high initial expectations.
When drafting specifications, it is important that engineering requirements are translated into a suitable logical
design that can be understood by information technology (IT) specialists.

Procurement
Available products should be reviewed, either as off-the-shelf solutions, or as a basis for local customisation. The
cost of this approach can then be compared with the cost of bespoke development. The sustainability of any off-the-
shelf systems should always be reviewed in terms of the required on-going support that might be necessary after
initial implementation. Each case will be slightly different, but it should be noted that purpose-written systems are
normally considerably more expensive than customised products, irrespective of whether the work is done in-house
or by outside firms. Engineers are advised to seek the advice of IT experts to write operational requirements (i.e., the
functional user requirement of the system), detailed specification and contract documents, as appropriate. The
procurement should be handled by someone who is familiar with computer system projects, but always with
reference back to the road administration in the event of technical queries.

Operation
The greatest disappointments often occur during system implementation. The setting of unrealistic delivery
schedules and underestimation by the road administration of the time required to collect, load and validate data, can
all contribute to delays. Firm project management is required and outside assistance may be appropriate. The private
sector can also be used to assist with on-going operation of the system. Tasks such as network referencing, inventory
collection, traffic counts, axle load surveys, and condition surveys (carried out by manual methods and by machine)
can all be undertaken in this way, often more cost-effectively than by the road administration using its own
resources. These works are relatively easy to define and, in several countries, specialist contractors have evolved for
these activities. Similarly, for bridge management, consultants and contractors can often bring specialist skills and
equipment to the tasks of bridge inspection and assessment. More radically, consultants can be used for all aspects of
system operation, including the provision and operation of all hardware and software. Use of the private sector also
gives access to state-of-the-art technology without the need for investing directly in development costs. Such an
approach reduces the need for institutional development within the public sector.

Source: Button, C, 1994. Computerised road rnanagement: the appliance of computer science. Highways, 62 (No 4) London:
Thomas Telford, pp. 12-13.

13
14
Part B: System design

15
16
4 System requirements management produced by the Commission of the
European Communities (1993).
4.1 Defining the requirements of the systems needed
within the administration is a matter of identifying the
4.5 Problem tree analysis establishes cause and effect
objectives which each system is intended to fulfil, and
relationships between the negative aspects of the
determining the components needed to meet these
existing situation, and identifies `bottle- necks' that
objectives.
should be treated as matters of priority. The results of
the analysis can be recorded in a tree diagram showing
Identifying objectives
the effects of a problem and its causes. The `negative
4.2 Two approaches can be used to help identify
situations' of the problem tree diagram are then
system objectives. The first is related to the framework
converted into `positive achievements' in the diagram
of strategic policies adopted by the road administration;
by replacing the causes of the problem with the means
the second uses a method known as `problem tree
of achieving the required end. The effect of the problem
analysis'.
will generally have several impacts and causes, and
several means and results will be needed to achieve the
4.3 The policy framework approach derives its logic
objectives by addressing all aspects of the problem.
from the principle that the introduction of new
technology should assist the administration in
4.6 Box 4.2 sets out an example of problem tree
achieving its strategic objectives. It therefore makes
analysis in the field of road management. This
sense for the objectives of the computer-based system
demonstrates the conclusion that the implementation of
to reflect the broader policy framework adopted by the
a road management system is likely to be only one
administration, in terms of its overall aims and the
component of an overall solution. A range of measures
means by which achievement of these aims is
will normally be required to help improve road
measured. Box 4.1 offers examples of the use of this
management capabilities within an administration.
approach.
Cost-benefit analysis
4.4 The method termed ‘problem tree analysis’
4.7 The decision to introduce a computer-based road
examines the effects of problems identified within an
management system has to be seen as a business
organisation to determine their basic causes. The
decision, not as simply a technical option. This decision
results of this analysis are then used to identify the
needs to be reached on the basis of a
means of achieving the desired solution or objective.
The method is described in more detail in a document
on project cycle

Box 4.1 Use of a policy framework approach in deciding system objectives

System objectives can be defined by reference to the objectives of the road administration. A typical objective
in the area of road user costs might be:

Arterial roads will be maintained, so far as budgets will allow, to minimise the sum of road user and road
maintenance costs in the longer term.

This objective would need to be met by a system designed to minimise the longer-term road user and road
maintenance costs in a constrained budget situation. An appropriate planning system would be required to help
achieve this objective. Decisions would be needed about which road user costs (vehicle operation, travel time,
accidents, and so forth) should be included, since the phrasing of the objective does not specify this point. In
addition, turning longer-term plans into actual programmes of work, with agreed budgets, and arranging for the
budgeted work to be performed would require die implementation of programming and preparation systems.
Similarly, a typical road administration cost objective might be:

The road administration will endeavour to provide value-for-money by meeting the above
objectives at minimise cost, subject to the available budget.

An operations system would be needed to support this objective. The scope of the system could include the
facility to develop effective costing procedures for works, and the generation of work records that could be used
to monitor and audit performance against targets.

17
 Box 4.2 Use of problem tree analysis

A road administration may be concerned that its road maintenance activities are incurring costs which perhaps
seem high by international standards, or when its overall costs per km are compared with those of neighbouring
administrations. Analysis of this problem might identify several possible causes of high cost levels. These could be
shown in the form of a problem tree, such as that below, which only isolates one of a number of possible causes.

The tree diagram can help identify possible solutions to the problem. The effect of the problem `high road
maintenance costs' can be converted into the objective of achieving `lower road maintenance costs'. The impact of
'inefficient use of resources' can be converted into the desired result of `effective use of resources', and the cause of
`lack of resource management' can be converted into the means of `implementing an operations management
system', as illustrated below.

18
comparative assessment of costs and benefits. Though administration, but planning systems are likely to be
it is not always easy to quantify the potential benefits easier to implement, even though the immediate benefits
of the system, experience suggests there is a real risk of may be less. This is because planning systems may
costs escalating out of control unless they are analysed require fewer data to be collected on a relatively
carefully in advance. infrequent basis, and will be operated by staff in the
organisation who are more likely to have computer
4.8 The costs of a computer-based system will skills. Box 4.5 provides additional examples of system
typically be incurred by: implementation priorities.
• data collection and updating - the principal cost
4.15 Funding agencies such as the World Bank, EBRD
item;
or the European Community may well attach the
• hardware and software; highest degree of priority to a planning system, since
• staff training and retraining. this will provide the macro-level data which funding
agencies find useful when developing the sector policy
for a country.
4.9 The benefits of the system are likely to result
from:
• improved asset management;
• improved control of contracts and costs;
• better management information.

4.10 Cost-benefit analysis should follow normal

procedures for an economic appraisal in the road sub-
sector, as set out in Overseas Road Note S (TRRL
Overseas Unit 1988a).

4.11 Boxes 4.3 and 4.4 offer examples respectively of

costs and benefits typically associated with the
introduction of a computer-based road management
system.

Priorities for system implementation

4.12 The order of priority for implementing systems of
different types will be determined from the assessment
of requirements, supported by the results of the cost-
benefit analysis. Each road administration will have
specific needs, but in most instances the first priority
will be to introduce a network information system, if
one is not already in place. The reason is that a more
comprehensive and reliable base of information about
the road network can in itself yield significant benefits
to the administration. In any event, all other types of
system require a network information system as a
database on which they can operate.

4.13 Issues determining priorities for

implementation include the following:

• the level of institutional development within the

road administration;
• the nature of the administration's existing
procedures;
• the form of work procurement - i.e. in-house or
contracted out;
• the competencies of staff at various levels in the
organisation.

4.14 There are also other factors to be considered.

Operations systems may hold out the possibility of
greater benefits to the road
19
 Box 4.3 Typical costs of implementing a road management (planning and programming) system

Implementation costs Annual running costs

Computer hardware Computer support staff

Cost of new hardware or the upgrading of existing Cost of all staff involved in providing support to
facilities to the standard of the new system, including computing operations
computers, printers, storage devices, cabling, and so
forth Engineering staff
Cost of all engineering staff including inspectors,
System surveyors, engineers, etc.
System licence cost
Maintenance of hardware
Other software licences Cost of maintaining computers and ancillary
Cost of licences for software purchased for, or for use
equipment, including all necessary computer
with the system, including database management
consumables
system, system interfaces, and so forth
Maintenance of software
Data collection equipment
Cost of in-house maintenance of the system
Cost of equipment purchased for use with the system,
database system as well as any third party software
including data capture devices (data loggers), rut depth
maintenance and upgrade costs
measuring devices, distance measuring devices and
safety equipment for condition surveys; this would
Maintenance of fretwork
include the cost of vehicles if purchased solely for use
Cost of keeping the network referencing
with the system
information up to date, including any
Establishment of network surveying and data entry
All costs of setting up or integrating an existing
referenced network for the system Maintenance of inventory
Cost of keeping inventory data up to date,
Entry of network to database including inventory surveys and data entry
Personnel and other costs of entering the
network into the system database Maintenance of equipment
Cost of maintaining data collection equipment,
Collection of inventory including vehicles
Cost of item inventory collection or the
upgrading of existing inventory Record keeping and presentation
Cost of collecting and presenting records
Entry of inventory to database
Personnel and other costs of entering inventory to the Preparation of annual maintenance programme
system database Personnel costs

Initial staff training Production of scheme plaits

Cost of training staff to facilitate the introduction of Personnel costs
the system, including training of inspectors,
computing staff, engineering staff, and so forth

Note: In some cases, these costs will treed to reflect the

Source: UKPMS annualised cost of items not expended in every year

20
Box 4.4 Typical benefits of implementing a road management (planning and programming) system

Better economic management:

• Priorities based on economic return; treatments selected on the basis of highest return on investment in
different maintenance options within a constrained budget.

• Priorities based on projection of pavement condition; treatments selected for the time that they are
applied, based on projection of pavement condition rather than existing condition.

Improved advice:
• Availability of information on historic and future trends to assist in establishing budget
requirements and formulation of investment policies.

• Possibility of authority-wide assessment and management for different pavement types, footways,
cycle tracks, and so forth.

Better design:
• Selection of treatment being based on the separation of defects into those relating surface, structure and
edge (on asphalt pavements) or joints (on concrete pavements).

• Incorporation of historical data into the design process.

• Interfaces with other highway management systems in use.

• Ability to consider combinations of machine-derived and visual condition data.

Improved monitoring:
• Automatic recording of original defects, design decisions and information, and works records

Improved general management:

• A more comprehensive and complete system than those commonly in use, applicable through all stages of
the pavement management process from defect identification to the implementation of works, and suitable
for use by all the different types of highway authority.

• Ability to define different inspection cycles to meet needs of different authorities; encouragement for the use
of network and project level surveys which make better use of engineering resources.

• An assessment system which can operate at appropriate but different levels of detail on major and minor
roads.

• Ability to collect data at different levels of detail depending on the importance of the highway feature
being assessed.

• Output provided in a more readily understandable form, using text and graphics in conjunction with a
flexible enquiry system.

Source: UKPMS

21
Box 4.5 Examples of system implementation priorities in different situations

Well-established road administration

An administration that is experienced and efficient may have operations and preparation systems already in place.
In that event, the prime objective may be to improve the way budget needs are determined and to develop a
strategic planning capability. The priorities would then be as follows:

1 Development of a programming system to improve the needs-based determination of budgets

2 Implementation of a planning system to enable scenario analysis of strategic planning options

New or relatively inexperienced road administration

In an administration where road management practice is not well advanced, and where the control of activities is
relatively weak, the most important need may be to ensure that costs and work practices are managed more
efficiently. In this situation the following order of system implementation may be more appropriate:

1 Ensuring adequate identification and control of costs through the use of an operations system

2 Budgeting and setting priorities under budget constraint by the use of a programming system

3 Introduction of a planning system to provide forecasting tools for assisting with policy
formulation and identifying longer-term budget needs

4 Implementation of a preparation system, which would receive the lowest priority since most
administrations already deploy reasonably effective manual systems for works preparation.

Note that operations systems are appropriate mainly in administrations which undertake works in-house, though
they can be used to assist with the letting and management of contracts.

22
5 System specification
5.1 After deciding the types of system that the road Box 5.1 Typical users of road management
administration will need, and defining their requirements systems
in terms of objectives and priorities, the next stage in the
design process involves the specification of systems - in Network information system
other words, determining the outputs which each system • All staff in the road administration
will need to deliver and the categories of data and models
that it will use to produce the intended outputs. Planning system
• Top management of the road
5.2 The recommended procedure for system administration
specification is as follows:
• Planning or economics unit within the
1 Identify the prospective users of the system. administration

2 Confirm the outputs that its users will require. • Funding agencies

3 Identify the categories of data and models needed Programming system

to produce these outputs: this step will entail a • Professional staff in the road
process of continual iteration because data and management/maintenance department
model requirements are interdependent.
• Budget holders
5.3 This chapter sets out practical guidance on each of Preparation system
these steps as they apply to computer-based road • Road management/maintenance
management systems in general. Detailed points of advice department
on the specification of systems for network information,
planning, programming, preparation and operations • Design department
respectively are offered in the five chapters that follow
(Chapters 6-10). • Contracts/procurement department

5.4 The form of approach recommended here, in which Operations system

outputs are defined before data and models, is the logical • Works supervisors
procedure for system specification. It is fundamentally at
variance with the way in which in the past, where the
emphasis has been on defining models and data
requirements at the start. Confirming system outputs
5.7 Once the users of the system have been identified,
they need to be consulted about the specification of its
Identifying the system users proposed scope and outputs. While consultation with
5.5 This initial step draws on the findings of the users is the key to this task, it is important to maintain a
institutional appraisal (3.6) to identify which staff in the practical and realistic view of the results that the system
administration will wish or need to use a computer-based can be expected to achieve and to resist over-ambitious
system. Talking to staff, both in workgroups and demands. Wherever possible, cost-benefit analysis
individually, to determine their attitudes to should be used to assess the likely value of the proposed
computerisation and their degree of familiarity with outputs (4.7-4.11).
computer processes, is an essential part of this task.
External assistance - for example, from IT specialists - 5.8 The types of output required will depend on the
also may be useful. Box 5.1 indicates typical categories policy of each administration, on its institutional
of user for different road management systems. arrangements, and on the detailed objectives of the
proposed system. For this reason, it would be unrealistic
5.6 Many users will regard the system as a collection to be prescriptive on this point. Chapters 6-10, which
of `black boxes', and they will have no wish to deal with the specification of particular categories of
understand its detailed structure or contents, nor should system, offer guidance on typical forms of output; but
they be required to do so. Their main concern will be to these are put forward only as examples which serve the
have available a system which produces results that are purpose of demonstrating the types of issues that arise in
believable and in keeping with their engineering designing outputs to meet user needs. The actual outputs
judgement. The design of the system needs to reflect this obtained from particular systems will be determined by
priority. the objectives of the system and the specific
requirements of its users, and may differ widely from
those shown in the examples.

23
 Table 5.1 Information groups
5.9 Outputs will often need to be provided at more than
one level of detail: some managers will require only
Element Aspects
summary information, while other will also want to
receive supporting data. Additional outputs should be Road inventory Network/location
available to show data inputs, often in the form of data Geometry
Furniture/appurtenances
sets with dates and times of processing. All outputs
Environs
should be clearly and precisely referenced to avoid
confusion. Pavement Pavement structure
Pavement condition
5.10 Most outputs will be produced in a tabular format: Structures Structures inventory
all outputs should be available in this format, though Structure condition
some will also be amenable to graphic presentation. For
Traffic Volume
example, the outputs from planning systems, which are Loadings
intended for use by senior management, can often be Accidents
communicated more effectively in the form of line
Finance Costs
graphs, histograms and pie charts. Similarly, many of the Budget
outputs from programming systems lend themselves to Revenue
reproduction as strip diagrams, which provide schematic
representations of a length of road. Activity Projects
Interventions
Commitments
5.11 Some systems produce outputs using map-based
graphics depicting the whole or part of a network, Resources Personnel
Materials
accurate to scale in two dimensions. While these outputs Equipment
may be visually attractive, the costs of collecting,
maintaining and updating the spatial data needed to Source: Paterson arid Scullion 1990
support them can be substantial. Before a system with
this facility is procured, the additional benefits that are need to be provided between old and new forms of data
expected to be obtained from map-based graphical to preserve the value of historic information and allow it
presentation need to be reviewed to make sure they will to be used in trend projection.
outweigh the recurring data costs.
5.16 Systems have often fallen into disuse because of
Identifying data and models their onerous requirements for data collection and
5.12 The outputs of a system are produced from a processing. Staff may collect huge quantities of data
combination of data and models. Specifying these outputs simply because the system has a vast potential for
will determine the data items to be collected and stored storage. The urge to store every piece of data must be
within the system and the types of model, in the form of balanced pragmatically against the costs involved in the
algorithms and relationships, needed to process these process, the demands placed on the time of relevant staff,
data. Since the annual costs of data collection are and the practicality of actually making use of the outputs
typically five to ten times as high as the costs of generated from the data.
purchasing the computer hardware for a system, accurate
data design is essential if the system is to be cost- Information quality levels
effective. 5.17 In 2.4 it was observed that as the road
management process moves from planning, through
5.13 Table 5.1 identifies information groups which programming and preparation to operations, the level
might be used as a basis for classifying data items of detail required in the system data increases
relevant to road management activities. (though the extent of the network to which the data
refers decreases). Determining the appropriate level
5.14 Box 5.2 comments on the key criteria to be used in of detail therefore depends on the road management
selecting data items, which are: function for which the data will be used.

• Relevance 5.18 An example of the change in data requirements is

• Appropriateness that of cost estimation, which is a key task in each
management cycle. Both the accuracy of cost information
• Reliability
and the level of detail will need to become sharper as the
• Affordability process of road management moves through its
successive stages. Overseas Road Note S (TRRL
5.15 As road administrations develop and extend their Overseas Unit 1988a) reviews different methods of cost
resources, they will be in a position to adopt improved estimation.
methods of data collection. Suitable links

24
Box 5.2 Criteria for selecting data

Relevance
Every data item collected and stored must have a direct influence on the output that is required from the system.
Other data items which may be considered as desirable, interesting or possibly useful in the future, should be omitted
in favour of those that are essential, relevant and of immediate use unless a very good cost-benefit case can be made
for their collection.

Appropriateness
The volume of data and the frequency of updating them are major determinants of the cost of operating the
management system. Some types of data are collected at different times in a staged process, and the intensity and
detail of measurement may differ between these stages, usually adding progressively more detail to the basic
information acquired originally. For example: for pavement structural assessment as part of a strategic planning
process, data on road condition would need broad coverage across the network, but would have a low sampling
rate; however, for engineering design of a project at the later preparation stage, intensive sampling over the limited
extent of the project would be necessary to refine the design and contract quantities.

The technology and resources involved in acquiring, processing and managing the data should be appropriate to
the administration's capacity for maintaining the equipment, conducting the surveys, and sustaining the data
processing.

Reliability
Data reliability is determined from the following:

• The accuracy of the data, defined by a combination of precision (the error associated with repeated
measurements made at separate times or places, or by separate operators and/or instruments) and bias (the
degree to which the mean measurement reflects the range and variability of all data points).

• Their spatial coverage; for network-level planning, low intensity sampling is adequate whereas, for
engineering design of projects at the preparation stage, intensive sampling is needed with full coverage of
the project area.

• Completeness of data is important because missing items degrade the reliability of the outcome.

• Currentness ensures that data which change rapidly from year-to-year, or which have a large impact on
the ultimate decision, are kept up-to-date more than data which do not change so rapidly or are less
sensitive.

A balance between the reliability of data and certainty of outcome should be sought. For example: high precision,
intensive sampling of entire networks, such as can be obtained using mechanised methods, may represent over-
investment if the results are only to be used for broad planning.

Affordability
The volume and quality of the data items, and the associated data acquisition, must be affordable in terms of the
financial and staff resources available to collect data and keep them current. The scope and quality of data are
choices that must be weighed against the resources required to sustain them in the long-term, and against the value
of the management decisions that rely upon them.

Available resources and skills vary between road administrations, and may change over time. For small
organisations, or where skills and resources are scarce in a larger organisation, simple and basic types of data,
quality and collection methods must suffice. Where skills and resources are more abundant, a wider range of data,
including the use of automatic collection methods, may be appropriate. Problems arise when administrations with
very limited resources are responsible for managing large road networks.

Source: Paterson and Scullion 1990

25
 Table 5.2 relates the use of these methods to the will help maintain data integrity when values are
component functions of road management. updated. The network information system should have
the ability to reflect these strategies, and to store and
5.19 The management function that the particular system report on data at different levels of detail. Box 5.3
is intended to support can be related to all the information outlines typical strategies for data collection.
groups shown in Table 5.1 to provide a rigorous basis for
classifying data needs. This is achieved using the concept Types of model
of information quality levels (IQLs), as shown in Table 5.21 Models, which contain relationships and
5.3. Expressed in simple terms, the relationship between algorithms, are often embedded in the design of the
appropriate information quality levels and system types is system. In road management systems, models are
shown in Table 5.4. Reference should be made to the typically used for the following purposes:
World Bank document Draft guidelines on system design
and data issues (Paterson and Scullion 1990) for detailed • representing physical sections of road;
recommendations on the appropriate level of data detail to • summarising pavement condition as an index
be used for each IQL for many of the information groups based on measured defects;
shown in Table 5.1. Appendix C provides summaries of • projecting road conditions over time;
data requirements at different IQLs for some information • selecting appropriate maintenance treatments
groups based on the Draft guidelines. based on condition;
• estimating and assigning costs to activities;
5.20 Most road administrations collect and store network • predicting traffic, in terns of both flows and
inventory, traffic and finance data at one level only. The damaging effects;
data may then be summarised for use in the different • congestion analysis;
applications that compose the system, or selected values • analysing road user costs;
only may be used. The exact level of detail of the data • deriving works priorities under budget
collected for road inventory and traffic will be governed constraints;
by the nature of the road hierarchy. It makes sense for • allocating funding to geographic areas, budget
data values to be recorded in only one place in the system heads, projects, and so forth.
since this

Table 5.2 Cost estimation methods

Table 5.3 Information quality levels

26
 Table 5.4 Application of information quality levels planning and programming. These models are
comprehensive and many of them represent the current
System type Information quality level state of knowledge in their specific areas. But they are
not universally applicable, and care should be taken to
Planning IQL-IV ensure that they are used only in appropriate situations,
Programming IQL-III/IV and with local calibration, which can be time-
consuming. One disadvantage of these models is that
Preparation IQL-II/III they impose substantial data requirements, typically at
IQL-I and IQL-II levels. Before incorporating these
Operations IQL-I/II models in a system specification, road administrations
need to give careful thought to their ability to meet the
data requirements on a continuing basis.
Criteria for model selection
5.22 Since each model has its own data requirements,
models should be selected on the basis of the same Model calibration
criteria used to select data -namely, relevance, 5.24 Many models contain calibration factors which
appropriateness, reliability and affordability (Box allow them to be adjusted to suit local conditions. If
5.2). An extensive range of models is available, which these calibration factors are not determined properly, the
it would not be practical to attempt to review in this outputs from the model are likely to be inaccurate and
Note: where an administration does not possess in- inappropriate. For this reason the calibration of
house the expertise to evaluate different models, relationships within the model is an important step in the
external consultancy assistance may be helpful. system design process. Box 5.4 outlines a recommended
approach to calibration.
5.23 Models from the World Bank's HDM system form
part of several road management systems for

Box 5.3 Typical strategies for data collection

Strategy A
High level condition data (typically IQL-IV) are collected across the whole network each year. The data are used for
planning and programming purposes. The programming exercise then collects more detailed data (typically IQL-III)
on those sections where works are likely to be undertaken. Further detailed data (typically IQL-II) are then collected
on some of the sections for which designs are produced, or for which works are undertaken. As more detailed data
are collected on any section, they replace the data collected in the earlier phase, with the result that different sections
in the database store data at different levels of detail.

Strategy B
Relatively detailed data (typically IQL-II/III) are collected across parts of the network on a rolling programme,
perhaps with a cycle of three to five years. Each year, programming decisions are taken either by using current
data for individual sections, if available, or by projecting condition data from previous years. All condition data
tend to be stored at the same level of detail, though data collected as part of the works design or execution
processes may also be stored.

Other strategies
Combinations of these strategies are also used, including the following examples:

• Annual data can be collected on the primary road network, whereas a cycle of data collection may be used on
roads lower in the hierarchy.

• The cyclic approach can be used for the whole network, collecting data at low levels of detail (IQL-III/IV).
Cyclic collection methods can be used without projection of condition.

• Detailed data can be collected annually across the whole network, though this approach is probably not
cost-effective and is not recommended.

All these strategies have different implications for the detail of data stored in the system database.

27
 Box 5.4 Understanding network behaviour

Many models have been created to suit the conditions of a specific environment. Others have been developed and
extended to cover a range of different environments and this is often achieved by including within the models
calibration factors which permit their local adaptation. The important point is that the use of any model requires a
correct understanding of the behaviour of the road network. This will ensure that money is not wasted on
inappropriate maintenance and rehabilitation measures.

To achieve a sound knowledge and understanding of network performance, an administration should consider
monitoring a representative sample of the network on a long-terns basis. The monitoring will probably be carried
out at the IQL-I level of detail. A representative sample should be selected to span the full range of traffic,
materials, environments and construction methods as appropriate. This activity is often performed by a local
research institution or similar organisation.

28
6 Specification of network
information systems

Figure 6.1 The function of a network information system

6.1 A network information system forms a central and 6.4 Boxes 6.1-6.3 illustrate three examples of outputs
integral part of the decision-support systems used in road from network information systems. Box 6.1 shows a
management, as shown in Figure 6.1, and can also be used typical roads gazetteer for a district. This is a simple list
as a system in its own right. Its purpose is to provide a of all sections in the district road network. Users should
single point of storage for data on every characteristic of be able to select which types of sections in the network
the road network. By definition it is a database which can to include in the output, and to specify the details that
be interrogated to produce reports. The likely users of are to be shown for each section. In this particular
network information systems are noted in Box 5.1. example the gazetteer includes the section label, section
length, start and end node references, and a description
6.2 The standard outputs available from a network of the section. The node references, given as six figure
information system are likely to include: grid co-ordinates, enable the sections to be located
spatially.
• Gazetteer of road sections, in user-defined
order, giving attributes of sections (such as 6.5 The information in the gazetteer is shown
label, description, and other data) plotted to scale in Box 6.2. This graphical output
• Lists of sections based on user-defined selections of indicates each road section with its label, the direction in
section attributes (for example, all sections in one which data are to be collected on the section, and the
geographic district, all gravel roads and their total labelled nodes. For a plot like this to be produced,
length, all paved roads in a particular district carrying strings of grid co-ordinates need to be stored at regular
more than 1000 vehicles per day). intervals along each section. These are normally
obtained by digitising data from maps. Data recording
6.3 It should be possible to report on most of the quality needs to be high if this type of graphical
information stored in a database. User-friendly systems presentation is to be meaningful, since errors in the
employ customised query languages which give users location of sections are obvious when plotted spatially.
ready access to reports (sometimes known as ad hoc There are particular problems involved in digitising data
reports) on relevant data items. In other systems it will be from maps where sections extend over -matching is a
necessary to use the query language of the database necessary but tedious process. The plot also shows the
software itself. This latter approach may permit a large position of certain footpaths. If road administrations are
measure of flexibility in report production, but it is likely responsible for the maintenance of footways and
to be more difficult to apply than a system-specific report footpaths, sections for these should be created in the
generator. same way as for carriageways.

29
 Box 6.1 Example of output of roads gazetteer

6.6 Box 6.3 shows details of a user-selected list of 6.7 The categories of data stored in a network
sections in the district. In this example, all details of all information system will be determined by the particular
unclassified roads have been requested. Details of management strategy for data collection used by the
carriageway length and width, surface, road base and sub- road administration (5.12-5.19). The key data will
base materials are shown, as are shoulder width and belong to the inventory data group shown in Table 5.1.
construction type. Certain sections do not have shoulders They will need to be stored at the most detailed IQL
or, if they do, the relevant information has not been value required to support the applications included in the
recorded. Traffic has been grouped by ranges (hierarchy system.
or class), indicated for each section on the output. The
information system may also store data on other attributes 6.8 For decision-support systems, all the data required
of the section, for which reports would be available in by the system models can be stored with the inventory
other forms of output. data. It should be possible to produce output reports on
these together with the inventory data.
30
Box 6.2 Example of graphical output of roads gazetter

31
 Box 6.3 Example of output showing section pavement and traffic details

6.9 Network information systems do not use models,

although advanced systems may perform arithmetic
calculations and store and apply this information to assist
in decision making. For example, some systems can
estimate cyclic maintenance requirements. These systems
can accumulate the total quantities of certain entities or
their attributes from the inventory data, and combine
these with stored information about standards or
intervention levels to determine maintenance quantities.
This can be taken further by applying unit costs to the
quantities to build up maintenance budgets. In this
situation, the network information system is being used as
a programming system.

32
7 Specification of planning systems

Figure 7.1 Example applications of planning systems

7.1 Planning systems assist in the strategic 7.3 Two types of forecast commonly produced by
management of the road network. For example, a planning systems are those for road conditions and
planning system might be used to help determine budgets. An example of a road condition forecast is
appropriate treatment standards for the various road shown as a tabular output in Box 7.1 and graphically in
hierarchies within the network, so as to minimise the Box 7.2. The example indicates the effect over a ten-year
life cycle costs of road construction and maintenance period of a fixed budget level on the surface and
and reduce road user costs; or to help examine the structural condition indices of Class B roads and
likely effects of different budget levels on future road unclassified roads. The tabular output form is of more
conditions. Figure 7.1 summarises the management general use, enabling reports to be produced on indices
cycle of decision-making for these typical applications. of four types of road. Analysis can also demonstrate the
Planning systems are used for analysis of the entire effect of different budgets being specified for different
road network, typically categorised by traffic level and years. With the particular maintenance and priority
road condition; individual sections are not identified. regimes adopted in this example, road conditions are
The likely users of planning systems and their ouputs predicted to decline over time. Structural conditions will
are noted in Box 5.1. deteriorate more rapidly than surface conditions, perhaps
reflecting a maintenance policy which focuses on surface
7.2 The outputs of a planning system are likely to treatment rather than structural repair. Note also the
include: predicted acceleration of structural deterioration in the
second half of the projection period.
• Projected annual capital and recurrent
budget requirements to meet road 7.4 Boxes 7.3 and 7.4 show examples of typical
administration standards over a user-defined outputs from an analysis which determined the annual
period into the future budget necessary over a ten-year period to ensure that the
• Projected road conditions resulting from the surface and structural condition of the network remained
application of pre-defined annual budgets for a unchanged. In this example, budget levels would need to
user-defined period into the future rise steadily over the first part of the projection period,
• Projected road administration costs and road and slightly more rapidly over the second period. This
user costs for pre-defined standards, or annual reflects the deteriorating structural condition illustrated
budgets, for a user-defined period in Boxes 7.1 and 7.2. The budget figures normally used
• Incremental net present value (NPV) of adopting in such outputs are stated at constant prices, with no
one set of standards compared with another, or allowance for inflation.
of adopting one particular stream of annual
budgets compared with another.

33
Box 7.1 Example of output of projected road condition for given budget

7.5 Because a key purpose of planning systems is to and future traffic is normally based on simple
illustrate trends, graphical outputs are particularly percentage growth rates for each class of vehicle.
useful. The graphs in Boxes 7.2 and 7.4 could be shown Loadings are modelled in terms of equivalent
as histograms. Other types of graphical outputs can be standard axles for the purposes of pavement design
produced. For example, pie charts are a useful medium and strengthening, and in terms of mean gross
for communicating proportional data about the road vehicle mass for the purpose of bridge design.
network, perhaps indicating different types of
construction, or sections in different states of repair. A Road deterioration: Predictions of road deterioration
good planning system should be sufficiently versatile to are needed for the projection of conditions into the
offer the user a range of possible graphical presentations. future, and for projecting historical condition data to
present-day values when current information is not
7.6 The data used in planning systems normally cover available. The various models are normally based on an
the entire road network at a coarse level, probably analysis of past trends, using either deterministic or
IQL-IV (Table 5.3). Table 7.1 lists the information probabilistic methods. A range of mathematical
groups likely to provide data for a planning system. formulations is available for this purpose.

7.7 The models required by a planning system will Treatment selection: Models for treatment selection
depend on the details of the applications involved. Those are used to decide appropriate works to correct road
required by the two applications used as examples would defects, reflecting the judgement of a practising
probably include the following: engineer. They are often termed `treatment selection
rules'. The methods available are typically defined in
Traffic growth: Models for traffic growth normally terms of matrices of the various parameters that affect
require data grouping by vehicle class. Ranges of the treatment selected, or in the form of decision trees.
existing traffic levels are required,

34
Box 7.2 Example of graphical output for projected road condition for given budget

Box 7.3 Example of output of budget required to maintain condition

35
Box 7.4 Example of graphical output of budget required to maintain condition

Table 7.1 Information groups likely to be used in planning systems

36
Prioritisation: A number of models are available for 7.8 Various planning models used in road
setting priorities when budgets are constrained. These management are described in Road maintenance
models offer varying levels of sophistication, require management: concepts arid systems (Robinson and
different amounts of data and computation time, and others 1998).
produce recommendations that differ in terms of their
impact on the longer-term condition and works
requirements for the network. Methods which relate
priorities principally to the severity of road condition
are not recommended, since they tend to lead to
conditions that worsen over time and to increasing
works cost requirements. Other methods have the
characteristics shown in Box 7.5. Where road user cost
and pavement performance models are used, treatments
can be prioritised only for the road pavement itself. Off-
road defects cannot normally be prioritised with models
involving concepts of treatment life. The choice of
model will therefore depend on the feature being
prioritised, as well as on the ability of the road
administration to satisfy the data and computational
requirements of the various methods.

Box 7.5 Prioritisation methods

Methods based on treatment choice

Priorities are related to treatment type and road hierarchy or importance. The methods recognize that some
treatments are more cost-effective than others if applied at the right time. They have modest requirements in
terms of data and computation time. Overseas Road Note I includes an example of this approach.

Cost-effectiveness methods
Priorities are related to the `cost-effectiveness' ratio of treatment life to treatment cost. These methods reflect
the higher value of a treatment which lasts longer. They too can be relatively modest in terms of data and
computational effort.

Optimisation methods
The optimum combination of a number of different works options is selected to achieve a given objective, which
might be to minimise the life cycle costs on the network or to maximise the quality of road condition. Costs normally
include both road administration and road user costs. These methods provide solutions based on a long-term view of
the network, but are demanding in terms of data and computational effort. One example of this approach is the
Expenditure Budgeting Model (EBM) used in conjunction with HDM-III.

Reduced time period analysis methods

These methods address the theoretical concern that life cycle optimisation methods base their decisions on long-term
predictions which might turn out to be inaccurate. For example, budgets may change from those predicted, or traffic
levels and road conditions may differ significantly from those projected. This type of method addresses these
concerns by basing decisions on a limited time period of analysis. Their performance is similar to that of
optimisation methods, but they are less demanding in terms of data and computational resources.

37
8 Specification of programming
systems

Figure 8.1 Example application of a programming system

8.1 Computer-based programming systems are used in • Projected rolling programme of work over a three-
the short to medium-term planning of road management: year period, reflecting any user modifications to the
they serve a tactical role as distinct from the strategic role list of sections to be treated.
played by planning systems. In their most common
application, they help decide which road sections are 8.3 Box 8.1 shows a specimen output for all sections in
likely to warrant treatment in the next budget period, and the network, summarising condition, and indicating
they assist in prioritising treatment by indicating the best recommended treatments and costs. Sections are listed in
combination of options that can be funded within budget label order. Section lengths are also shown to help relate
constraints. Figure 8.1 shows the management cycle for the scale of costs to the work to be done. Various
this application. These systems are used also to produce methods of summarising condition can be used: in this
rolling programmes of work, typically for three to five- particular example, condition indices are quoted for road
year time horizons. Programming is performed on road surface, pavement structure, road edge and shoulders.
sections across the entire network. The likely users of Outputs from programming systems often show the
programming systems and their outputs are noted in Box priority index against each section where treatments have
5.1. been recommended.

8.2 The outputs of a programming system are 8.4 Treatments recommended by the system are
likely to include: generic. Since relatively coarse data are used for this
network-level analysis, it is not normally possible to
• List of sections, in priority order and in section design detailed treatments; these are produced instead at
order, showing recommended treatments and costs the preparation stage. For example, the `Olay' treatment
that can be funded in the budget year under pre- is a generic overlay, and no recommendation is made at
defined capital and recurrent budget constraints. It this time about its thickness or composition. Similarly,
should be possible for the user to work the treatment costs too are generic. Because it is
interactively with these lists so as to amend necessary to plan for uncertainty prior to detailed design,
treatments, costs and the order of projects in the 20 per cent more treatments than can be funded are
priority list. usually taken forward to the preparation stage.
• List of user-selected sections, in section order, Treatments and costs are then refined, allowing the final
showing conditions and recommended treatments. programme to be confirmed.
• List of user-selected sections, in section order,
showing traffic, axle loading and road user costs.

38
 Box 8.1 Specimen output for section treatments and costs

8.5 Box 8.2 lists sections where treatments have been projects ranked second and third, and the engineer has
identified, in priority order. In many instances the selected the projects ranked in 4th and 5th place to
priority index (for instance, cost/benefit ratio) might also complete the programme.
be shown. It is normal to indicate cumulative costs in
this type of output so as to make it clear when the budget 8.6 Data will typically be at level IQL-III/IV (Table
cut-off has been reached. In the example set out in Box 5. I ). The information groups from which data are
8.2, the road engineer has been working interactively likely to be needed are shown in Table 8.1.
with the system to select projects from those
recommended for inclusion in the programme. The 8.7 The models required by programming systems
selected projects are shown in the final column. Since are similar to those used in planning systems. The
the available budget is no more than 20 000, it will not comments made in Chapter 7 are applicable also to
be possible to fund the programming systems.

39
 Box 8.2 Specimen output for section priority list

Table 8.1 Information groups likely to be used in programming systems

40
9 Specification of preparation
systems

Figure 9.1 Example applications of preparation systems

9.1 Preparation systems perform a variety of road a more detailed condition assessment of a project selected
management tasks at the stage when works are being for potential funding. The output provides information on
packaged for implementation. Typical applications the locational, geometric and structural features of the
include the detailed design of works or treatments, and section, and summarises at 100m intervals the condition
the letting of contracts or issue of work instructions. measurements for a range of parameters. In this example,
Figure 9.1 shows the management cycle for these the areas of cracking and ravelling have been recorded, as
applications. In this stage, detailed site investigations have the number of pot-holes, the length of deteriorated
may be undertaken, detailed specifications, quantities edge on each side of the road, and the depth of ruts.
and costings are likely to be determined, and any cost- Though the output includes a column for deflection
benefit analysis that formed part of the requirements measurements, none have been recorded on this section,
phase (4.7-4.11) is reviewed to confirm the feasibility of perhaps because the parameter was considered
the final works. In addition, preparation systems may be inappropriate for a Class B road. The final column
used in contract packaging to combine works from indicates roughness results. Data such as those recorded in
adjacent or near-by sections into projects of a size that is the example provide the road engineer with valuable
cost-effective for works execution. This category of background information when designing or verifying
system operates at the road section level. The likely specific treatments.
users of preparation systems are noted in Box 5.1.
9.4 Box 9.2 shows an interactive treatment design
9.2 The outputs of a preparation system are likely application, related to surface dressing The output states
to include: that the design has been undertaken using the method
described in TRL Overseas Road Notes 2 and 3 (TRL,
• Detailed design information. 1982, 1985). The road length and width are obtained from
• Work packages. the road inventory and are used to calculate the area to be
• Works orders for projects, including bills of treated. The engineer has worked interactively with the
quantities. system and entered certain data: the system has then
computed the design implications. The interactive process
9.3 Three examples illustrate these outputs. The first, continues until the engineer is satisfied with all aspects of
shown in Box 9.1, includes the results of the design. During this process, the

41
 Box 9.1 Example of output showing condition assessment

engineer would have access to condition data, as shown characteristics; the engineer has then entered the road
in Box 9.1, and to other information stored in the system surface temperature and, using all of these values, the
- for example, on traffic volumes, accidents, or sources system has determined the grade and the application rate
of materials. of the bitumen. The total quantities of both chippings and
bitumen required for the section are then calculated by
9.5 The output shown in Box 9.2 has been obtained in the system.
the following way. Under the heading of `chippings', the
engineer has entered the road surface type and the lane 9.6 Box 9.3 offers a third example, which shows a bill
traffic category, and the system has determined that of quantities for surface dressing produced by the system.
10mm chippings are required with an application rate of The engineer has decided to combine the works on the
14kg/m2. Normally, for each input value, the engineer three sections selected at programming stage into one
would be able to call up from the system the allowable contract package, which is reflected in the bill of
range of possible inputs to assist with the selection. quantities. The preparation system has to include a library
Under `bitumen', the engineer has entered the traffic of works items to enable these outputs to be produced.
constant, the existing surface, type of chippings, and the
climate. The system has used a `look-up table' to 9.7 The data required for preparation applications are
determine the design constants relevant to each of these likely to be quite detailed, but related only to a few
individual sections. They will

42
Box 9.2 Example output for interactive treatment design

probably be at the IQL-11/111 level. The information 9.9 Typical models required by preparation systems
groups from which data are likely to be needed are include:
listed in Table 9.1.
Traffic growth (as described in relation to
9.8 Where preparation systems are used to assist with planning systems).
the preparation and letting of contracts, one item of data
that may be needed is the type of contract to be applied. Road deterioration (as described in relation to
Standard forms of contract, such as those produced by planning systems).
FIDIC and the New Engineering Contract, are normally
used for road works but local forms also may be in use. Works design: Models used for this purpose will be
It is beyond the scope of this Note to enumerate the standard design methods for activities such as surface
various types of local forms: in these instances, data dressing, pavement and overlay design, and geometric
may also include standard bill of quantity items required design. Some of these models may be available as
for different works, libraries of costs, suppliers of computerised systems, either integrated into the road
materials, and approved contractors. management systems, or produced as stand-alone
systems.

43
Box 9.3 Example of output from a bill of quantities

44
Table 9.1 Information groups likely to be used for preparation systems

45
10 Specification of operations systems

Figure 10.1 Example application of operations system

10.1 Operations systems assist with the management of • Annual cost summary by road section, activity and
on-going activities, supporting decisions that are typically budget head, with totals.
made on a daily or weekly basis. Operations are focused
on individual sections or sub-sections of road: typical 10.4 Performance standards are used to ensure quality
tasks include work scheduling; monitoring the use of and consistency when managing operations. The example
labour, equipment and materials; and recording completed in Box 10.1 sets down the basic procedures for an
work. Figure 10.1 shows the management cycle for a individual activity, in this instance surface dressing. It
typical application. In addition, operations systems may includes a method statement, and defines resource
contribute to cost accounting and financial management, requirements, costs and the expected productivity.
equipment management and facilities management. Performance standards of this type should form part of
the road administration's quality management system.
10.2 A road administration will need an operations They will need review and updating to reflect changes in
system only if it has in-house works units. Where work is costs or the introduction of modified work practices.
contracted out, it is the contractor who is likely to need to
use operations systems. In this case, operations 10.5 Performance standards can be used as the basis for
management by the road administration becomes a matter issuing work instructions. Some systems combine the two
of project management: since computer-based systems for documents by showing target output, and providing a box
project management are widely available and their use is where the work achieved can be entered by the supervisor
already well documented, they are not included in the or foreman. This information is needed by the system to
scope of this Note. Typical users of operations systems are enable performance to be monitored over time. Inclusion
noted in Box 5.1. of both pieces of information on the same form simplifies
data entry into the system, and ensures that those involved
10.3 Operations systems are likely to have the following are aware of any shortfall in performance. Recording
outputs: information in this way allows weekly, monthly and
annual summaries to be produced for monitoring
• Performance standards for works, defining the purposes.
minimum requirements and specification for
activities, and including schedules and costs for 10.6 Box 10.2 shows a weekly staff time summary. The
equipment, materials, and labour. information is produced directly from time sheets which
• Work instruction/accomplishment. need to be completed daily. These can either be paper-
• Weekly labour time summary by person and based, or maintained in electronic form, with staff
budget head. entering details directly into the system. The weekly staff
• Weekly cost summary by activity and budget time summary can feed into the staff payment system and
head, with totals. into progress and performance monitoring systems.

46
Box 10.1 Sample output of a performance standard

47
 Box 10.2 Sample output for weekly staff time summary

10.7 A key aspect of operations systems is that they 10.9 - This particular example indicates that there was
allow monitoring of both achieved output and cost. under-performance for Activities 04021 and 04024, with
Weekly monitoring (sometimes extended over low productivity and an over-spend of budget. The
fortnightly intervals) is necessary in most situations to reasons for this would need to be investigated by the
avoid under-achievement and cost over-runs escalating engineer, though the problem would have been apparent
out of control. Weekly reports can be produced for from the monitoring reports produced through the year
activities under all budget heads showing target and which give an opportunity for more speedy remedial
actual output and expenditure, under the headings of action. For Activity 04025, the budget figure was met
labour, equipment and materials. Spend-to-date and with a 32 per cent increase in productivity. For Activity
remaining budget should also be shown. Similar reports 04029, there was 24 per cent over-production at a cost of
are normally produced on an annual basis, typically for only 43 per cent of the budget, suggesting that the targets
costs by activity and section. All of these reports can be set for the activity were low. Information fed back from
produced automatically from weekly work achievement outputs such as this provide a sound basis for
returns. investigating specific problems affecting individual
activities or sections, and defining more realistic targets
10.8 Box 10.3 provides an example of a report for an for the following year.
annual cost summary. It relates to the capital budget
allocation for a district, and is disaggregated by activity 10.10 The data required for operations management
codes. This example shows annual targets and actual are likely to be highly detailed -probably IQL-1/11 -
outputs, with the percentage achievement for each but they will apply only to a short length or sub-section
activity. Costs are disaggregated by labour, equipment of road. Table 10.1 lists the information groups from
and materials. For each activity code, the budget and which data are likely to be needed for operations
actual expenditure are shown, with the percentage spend systems.
against budget.

48
 Box 10.3 Sample output for annual cost summary

Table 10.1 Information groups likely to be used for operations systems

10.11 While the recommendations derived from decisions made by users. For this reason, operations
operations systems tend not to be based on the use of systems can properly be regarded as decision-support
models, and it is unusual for these systems to include systems.
models, their outputs are used to support

49
11 Computer requirements integration through a common data bank. This modular
structure has to reflect the administration's road
management procedures as grouped into functions and
Sources of procurement tasks. Some proprietary systems fail to match
11.1 Earlier comments on the use of manual adequately the needs of an administration because they
techniques are reiterated here (see 2.9). However, once lack the potential for modularity.
the decision has been taken to adopt a computerised
approach, hardware and software requirements need to 11.5 The road information system or data bank, which
be addressed. Road administrations are often keen to provides the core of the road management system,
develop their own in-house software for proposed road requires a network referencing system around which is
management systems. Sometimes a `not-invented-here' built an inventory of the road network to which all other
attitude leads to a reluctance to use proprietary products, information can be related. Figure 11.1 depicts this
or to adopt systems that are widely used elsewhere. But modular framework, which includes data items from the
the systems discussed in this Note may have to manage information groups listed in Table 5.1 and the five types
substantial volumes of data: unless highly efficient of information and decision-support systems identified in
software is applied to this task, their running costs can be this Note (2.11). An integrated approach of this kind has
extremely high. Few road administrations have the to be a long-term aim. In the short to medium-term, most
competence in software development to produce for road management systems may contain only part of the
themselves systems that will be powerful and efficient framework, so the software that is procured needs to be
enough to perform successfully. In most cases, flexible enough to accommodate future change and
procurement and customisation will offer the most growth.
economical solutions.
Programs and databases
11.2 Any software product for use in road 11.6 The modular framework shown in Figure 11.1 is
management has to be robust and dependable, implemented through a series of application programs
particularly where large databases are involved. Some operating in conjunction with a database. Application
of the computer applications that are commercially programs are needed for input, output and processing
available do not meet these criteria. For this reason, (models). All management information required for
administrations need to assess rigorously the viability decision-making is held centrally, while data and
of the software and the competence of its supplier technical processing may be decentralised. The structure
before committing themselves to its procurement. allows the flow of information between modules to be
controlled, so that data are checked to ensure quality and
consistency before being used by other modules.
Customisation
11.3 Any proprietary product that is worth buying has 11.7 Ideally, the functions of the core database should
to offer, above all else, the potential for customisation to be built around a relational database management system
meet the precise needs of the purchaser. This factor (RDBMS), preferably using fourth generation (4GL)
should in large measure determine the choice of software programming languages. Applications programs can be
to be adopted. Some software products are designed in a written in the same 4GL as the database, or they can
flexible way and need to be customised before use by interface to the database through what is known as
setting parameter values known as 'meta data'. Though `middle-ware', which is purpose-written software for
the process of customisation can be undertaken by the linking the applications programs to the database. This
road administration itself, it will normally be more approach offers two key advantages: first, it allows
economical to have the system supplier do this. Less modules to be procured from a number of different
flexible software can be customised only by the supplier sources at different times; second, it avoids having the
changing the software code, which is likely to prove road management system tied down to one software
more expensive than customising parameter-based vendor through its proprietary RDBMS. For example, a
software. Some software is designed in such a way that proprietary project management package could be used
anything other than superficial customisation is for work scheduling, with a standard database providing
impossible. the data storage. The choice of RDBMS will depend on
the availability of specialist expertise and the degree of
sophistication needed to support the proposed
Modular approach to software applications.
11.4 The most efficient and flexible solution for
software procurement is normally the adoption of a 11.8 The disadvantages of this approach are that
modular software structure, which achieves considerations of the long term will be dictating

50
 Figure 11.1 Modular system framework

short-term actions, so that the initial solution may be on whether multi-user access to the management system is
more expensive and complicated than a dedicated required. For mufti-user access, either a local area network
application, while the development of middle-ware (LAN) or a mufti-user operating system such as UNIX will
demands sophisticated programming resources which be needed. For single user access, which will be the case in
are expensive and may not be available. most situations, conventional systems using a Windows
operating environment will be sufficient. Trained personnel
11.9 Since the most costly part of any road will be needed to maintain the selected operating system,
management system is the data, as noted earlier, it is drawn either from the road administration or from local
essential to make sure that any future upgrading of the computing companies under contract.
system is able to use the existing network information.
An administration introducing computer-based 11.12 Once the requirements for the system software and
systems for first time will have most to gain by operating system are defined, the choice of hardware will
adopting a simple approach that is in scale with its usually be self-evident. In most instances a
institutional capability. Once the simple system microcomputer-based system will be preferred because it
becomes institutionalised, and as technology advances, allows easy access to hardware maintenance. But the use of
the system can be replaced. Providing the system uses workstations should not be overlooked, particularly where
an RDBMS or a spreadsheet to store data, it is a large volumes of data will need to be processed, since
relatively straightforward exercise for a computer workstations can substantially improve the efficiency of
specialist to transfer these data (possibly after data storage and operation at little additional cost.
transforming them) to a new, upgraded system.
11.13 In all cases, the system has to include adequate
Hardware facilities to back-up hardware and software in the event of
11.10 The final decision to be made when planning unforeseen failures. Software back-up can be achieved
the implementation of a road management system through magnetic or optical devices for the storage of
involves the choice of hardware. This approach - leaving system information and road management data. The
hardware to the last - is in marked contrast to the minimum requirement for hardware back-up, in the form
approach taken in the past by almost all projects to of un-interruptible power supplies (UPS), is the ability to
develop and implement computer-based road allow the system to be shut down properly if a power
management systems in non-industrialised countries. failure occurs.

11.11 The choice of hardware will be influenced by

the operating system selected, which depends

51
52
Part C: System operation

53
54
12 Training • Extent of responsibility and authority for
- planning, programming, preparation, operations
12.1 Training improves job performance by extending - finance, staff and equipment.
knowledge, improving skills and modifying attitudes. It • Management skills required.
enhances the ability of personnel to work in the most • Computer skills required.
economical, efficient and satisfying way to achieve the • Technical/engineering skills required.
objectives of the organisation. Training in the operation
and use of road management systems has to be viewed 12.6 The analysis is likely to identify requirements for
against this background. training in excess of the available funding. This means that
priorities will have to be set, and this should be undertaken
12.2 The staff of the road administration will need to in accordance with cost-benefit principles so that the
receive specific training in the skills that will equip them choice is made to provide the training that will yield the
to work with the management system and make the best best return on investment.
use of its outputs. Once the system has been
implemented, they will require a continuing programme
of further training. If specialist consultants are used to Training levels
perform the training function, they should concentrate on 12.7 Road management systems include a broad range
training counterpart staff who will then be able to of applications, while their potential users will possess a
undertake future training unassisted. This approach calls variety of skills and backgrounds. For this reason, training
for the assignment of consultants and counterparts who has to be approached in a flexible way. The concept of
are well motivated and who have high levels of training levels, outlined in Box 12.1, offers a useful means
interpersonal skills. of building flexibility into training provision. As the
training level rises from appreciation to ability, there is a
12.3 Detailed guidelines for training are beyond the corresponding increase required in the depth of
scope of this Note, but some recommendations on knowledge of the systems, but a decrease in the number of
training needs analysis are provided. Training of staff by potential users.
Thagesen (1996) addresses the subject in more depth.
12.8 Training courses at one level can assume
competence at the preceding levels, so as to keep the
Training needs analysis training programme focused and avoid repetition. At the
12.4 There is a high degree of correlation between first level of `appreciation', training is likely to be more of
training issues and institutional issues. The institutional a dissemination exercise. Much of what is needed at this
appraisal undertaken at the start of the design stage (3.6) level would be undertaken at the commitment stage of the
should identify clearly the training which the road system implementation process (3.9). The second and third
administration will need to provide to help achieve its levels - `knowledge' and `experience' -will relate to the
objectives. Since the institutional objectives will majority of the users of the system, with Level 2
determine the required training interventions, it is addressing staff whose use of the system is infrequent and
important that no training is planned or implemented Level 3 aimed at regular users. Level 4 - `ability' - will be
without first conducting an institutional appraisal. This required by those who have the responsibility for
will identify any human resource constraints and maintaining the system and undertaking other specialist
indicate the necessary remedial measures. tasks, such as model calibration.

12.5 The training needs analysis and the institutional

appraisal should, ideally, be undertaken simultaneously. Training topics
The training needs analysis, normally based around a 12.9 Though requirements for preliminary and ongoing
structured interview, compares the performance level training will be based on the results of the training needs
required from an individual with the level recorded at the analysis, it is likely that training needs will be identified in
time of the analysis. The gap between the two levels the general areas of
indicates the training requirement. 1n addition to
collecting factual information about the individual in • Management techniques (Box 12.2).
terms of qualifications, experience and so forth, the • Computer awareness (Box 12.3).
training needs analysis should identify the following • Systems operation (Box 12.4).
points: • Technical matters (Box 12.5).

55
Box 12.1 Training levels

Box 12.2 Course outline: management techniques

56
Box 12.3 Course outline: computer awareness

Box 12.4 Course outline: systems operation

Box 12.5 Course outline: technical matters

57
12.10 Detailed advice about the content of training
courses is outside the scope of this Note. Guidance on
training programmes for management, general co-
ordination, field engineers and road inspectors is
available in a report produced by the OECD (1995).

Monitoring training
12.11 To make sure that training objectives are being
met, continual monitoring will be required. The results
will be used to improve and strengthen the training
programme. Monitoring can be undertaken through tests,
questionnaires and feedback from participants, as well as
performance assessments by personnel responsible for
training. These assessments should be made at regular
intervals throughout the training.

12.12 Meeting training objectives does not necessarily

mean that the road administration's objectives will be
achieved. The road administration may fail to draw on
the outputs available or use the new systems; some
trainees may not want to share their new knowledge with
others. Issues such as these become evident only after
training participants have been working for some time in
their assigned positions. A post-evaluation is seldom
made, but it can be a source of valuable information for
the road administration generally, and its findings can be
applied specifically in the design of subsequent training
programmes.

12.13 It has to be admitted that training has a poor

record of success in supporting the implementation and
operations management of systems. Emphasis has
often been placed on inputs (such as the number of
people trained) rather than impacts (such as the effects
of training). Training should always be designed to
meet clear objectives, with achievement targets that are
both manageable and measurable.

58
13 Systems management 13.6 When new systems are introduced there may be
advantages in starting with a specialised unit, and then
extending systems operation more widely within the
13.1 Managing the road management system is a administration. This approach has attractions in terms of
function that needs to be treated like any other producing both early and longer-term benefits. However,
operational activity undertaken by the road once specialist cells are formed, they often create their
administration. The benefits which a computer-based own vested interests and are difficult to disband. They may
system can offer, in terms of improved management of also make the subsequent institutionalisation of the system
the road network, will be lost if this aspect of its more difficult because inter-departmental rivalries may
operation is neglected. Systems management involves the develop during the early stages of implementation. The
following sectors of activity: initial institutional appraisal (3.6) needs to examine these
options and decide on the best long-term alternative.
• Defining responsibilities.
• Controlling systems and data.
• Monitoring and feed-back. Control of systems and data

User access
Defining responsibilities 13.7 Where the system is intended to be used by
13.2 There are two possible approaches to the many individuals within the administration, controls
operation of a road management system within a road need to be set up so that different users have access only
administration. One approach is to make the use of the to the specific applications and data groups that are
system widely available throughout the organisation; the appropriate to their work. Even where system use is
other is to concentrate its use inside a specialised unit centralised in a specialised unit, access control is no less
which supplies system outputs as reports to decision- a requirement because several members of the unit may
makers. be working with the system at any one time.

13.8 Control can take several forms:

13.3 The first of these approaches has the advantage
of developing across the administration a sense of
• Full access with the ability to run applications or to
`ownership' of the results, and hence of the system. This
enter and modify data.
is likely to yield long-term benefits since the system will
• ‘Read only’ access restricting users to viewing or
become closely integrated into the operations of the
producing reports.
administration. On the other hand, it will incur higher
• No access.
costs - since more staff will need to be trained to run the
management system, and more computer hardware will
13.9 This control is a basic security feature and will
be required - and it will generally take a long time for the
normally be implemented through the use of passwords. It
benefits to be realised.
also permits the results of sensitive reports to be viewed
only by nominated persons in the administration.
13.4 Operation through a specialised unit allows
systems to be introduced more quickly. With activities
focused within a small group, fewer people need to be
Data updating
trained in system operation, and hardware requirements 13.10 Because data become obsolete over time, the
will be reduced. The benefits of system use will probably management of the system has to include procedures for
be more immediate, but it will be more difficult to their updating. Data that change rapidly, such as details
institutionalise the system in the long term. of road condition, will need to have an updating regime
that reflects the road administration's management
13.5 Regardless of the mode of operation, there is
strategy (5.20). For data that change less frequently,
usually a need to appoint a system administrator. This
such as inventory information, there are two options:
person should be a computer specialist who has overall
responsibility for the functioning of the system. The • Continuous updating, either as an on-going exercise or
responsibilities of the post will include ensuring that the as part of the process of condition surveys.
system is running correctly and that operating • Updating at fixed intervals of time, either for the
procedures are adhered to; maintaining data security, whole road network or for defined portions of the
access control, back-ups and archiving; issuing network on a cyclical basis.
passwords; and managing modifications and upgrades to
the system. In a central unit responsible for the
management system, the system administrator will often
be the head of the unit. In an organisation-wide
operation, an individual in the Computer Department
will usually be an appropriate person to fill the post.

59
13.11 Continuous updating is often preferred on the 13.16 Monitoring should provide a check that the
grounds that the alternative would result in the inventory policies, objectives, budgetary processes and final works
falling into disrepute. On the other hand it is difficult to programmes are linked together coherently. There will
capture all inventory changes in this way, and a major inevitably be a need to modify system outputs before final
periodic updating exercise may still be required. In some implementation owing to the practical realities faced by an
instances, a blend of the two options may offer the most administration. Even so, the following questions should be
practical course of action. kept under constant review:

Data control • Are strategic objectives and desired levels of

13.12 Data security is achieved by defining and service being achieved?
observing strict procedures for regularly backing up the • Do works programmes reflect the results of the road
system database. Generally, at least part of the database management system?
will need to be backed up each day. Nowadays, • Is value-for-money being obtained?
hardware is also available to support recovery from the
inevitable system crashes and power interruptions. 13.17 Failure to address these institutional issues will
have technical repercussions (Figure 3.1). For example,
13.13 The regular archiving of data that are no longer the same works implemented at a later date on roads
current can help minimise the need for system storage, which should have been treated earlier may prove
reduce hardware requirements and increase the speed of inadequate, and significantly more expensive treatments
database access. Procedures should be introduced which may be required. In this case it will be necessary to re-
specify archiving functions and define the actions to be examine the administration's wider maintenance strategies.
taken on those occasions when the archive needs to be
accessed.
Technical issues
13.14 Data integrity is often neglected, but is
particularly important when databases are used. For Data
example, when changes are made to the physical road 13.18 Implementing a computer-based road
network it should not be possible to change section management system generally entails large numbers of
details in the database without also changing all other surveys, measurements and observations. It is essential to
data relating to that section. The system needs to validate maintain up-to-date data (13.10-13.11), otherwise the
all new data entries to ensure that they are consistent with administration's perception of the network grows
the data already stored, and that values lie between outdated, and the system gradually but inevitably loses
defined tolerances. Data integrity becomes critical in a credibility, leading to its ultimate demise.
system offering multi-user access because more than one
user may be working on the data for an individual section 13.19 Updating the database includes the following
of road at the same time. activities:

• Annual or mufti-annual surveys collecting

Monitoring and feed-back monitoring data.
• Collecting works records when activities on the road
Institutional issues have been completed.
13.15 Introducing a road management system can have
a significant impact on the institutional arrangements of Models
the administration (see 3.9). For example, the definition 13.20 Planning and programming systems, in particular,
of a mufti-year programme of works is likely to have are likely to include models based on assumptions that
implications for the administrative structures, finance, may need to be verified. This is critically important in the
staffing and other resources needed for its preparation and case of techno-economic models such as HDM-III, even
implementation. The required institutional structures need where they are calibrated properly. The consequences of
to be in place and functioning as planned from the outset, using unverified models include:
and typical problems that may need to be addressed
include: • Works failing to improve the condition of the road
as predicted.
• Difficulties in financing successful operation of the • Road sections considered as non-urgent
system. deteriorating more quickly than expected.
• Difficulties in adapting administrative methods.
• Over-estimating the ability to undertake data 13.21 The effects of such disparities may not be
collection surveys. apparent in the short term. For this reason a selected
sample of the network needs to be monitored in

60
detail to establish differences over time between
predicted and observed behaviour (see Box 5.4). In
addition, those responsible for maintaining and operating
the system need to ensure that the technical methods
employed by the system continue to reflect the technical
approaches being adopted by engineers and managers in
the wider organisation.

System operation
13.22 Monitoring the operation of the system is
essential if it is to sustain the ability to meet objectives
which may alter over time. This final step in the
management cycle is an on-going activity, identifying
where the system is not meeting requirements and
acting as a trigger for action and improvement.

13.23 In some cases the action required may involve

minor modification to the system or to the procedures
which the system is supporting; but on occasions a more
significant system upgrade may be necessary. An
upgraded system needs to be subject to the same steps of
commitment, requirements, specification and
procurement as a new system. The results of all
monitoring activities should feed into the process for
reviewing the administration's policy framework.

Audit
13.24 This provides a physical check, usually on a
sample basis, that work has been achieved in conformity
with standards and procedures, and that costs and other
resources have been accounted for properly. The
feedback from road management systems provides a
key input to this process.

61
14 References

Commission of the European Communities (1993).

Project cycle management. Brussels: Commission of the
European Communities.

OECD (1995). Road maintenance management systems

in developing countries. Paris: Organisation for
Economic Co-operation and Development.

Paterson W D O and Scullion T (1990).

Information systems for- road management: draft
guidelines on system design and data issues.
Infrastructure and Urban Development Department
Report INU 77. Washington DC: The World Bank.

Robinson R and others (1998). Road maintenance

maintenance: concepts and systems. London:
Macmillan.

Thagesen B (ed) (1996). Highway and traffic

engineering in developing countries. London: Sport.

TRRL Overseas Unit (1987). Maintenance management

for district engineers. Overseas Road Note 1. 2nd edition.
Transport Research Laboratory, Crowthorne.

TRRL Overseas Unit (1985). Maintenance

techniques for district engineers (2nd Edition).
Overseas Road Note 2. Transport Research
Laboratory, Crowthorne.

TRRL Overseas Unit (1982). A guide to surface

dressing in tropical and sub-tropical countries.
Overseas Road Note 3. Transport Research Laboratory,
Crowthorne.

TRRL Overseas Unit (1988a). A guide to road

project appraisal. Overseas Road Note 5. Transport
Research Laboratory, Crowthorne.

TRRL Overseas Unit (1988b). A guide to bridge

inspection and data systems for district engineers.
Overseas Road Note 7- Volume 1. Transport Research
Laboratory, Crowthorne.

62
Appendix A: Glossary of terms

Activity Any work or intervention that is earned out on the road network.

Audit A physical check, usually on a sample basis, that work has been carried
out, where specified, to pre-defined standards or procedures, and that
costs and other resources have been accounted for properly.

Budget head Normal pre-defined headings under which expenditure is allocated by a

Ministry of Finance.

Capital budget The government budget normally used to fund major projects.

Condition index A parameter that combines individual defect measurements to provide a

summary indication of defectiveness.

Cost-effective The ratio of `effectiveness' to `cost', where effectiveness is a measure of

the future value or worth resulting from a decision that is taken, and cost
is the present-day cost of implementing that decision.

Cost-benefit analysis A formal comparison of costs and benefits to determine whether or not
an investment is worthwhile.

Cyclic works Scheduled works whose needs tend to be dependent on environmental

effects rather than traffic. These works are programmed in advance and
include such activities as, for example, culvert cleaning.

Data integrity That feature of data that relates to its completeness and internal
consistency.

Database A computer-based collection of data that normally uses formalised rules

for the way that the data are stored.

Decision-support system A computer-based system comprising applications modules to process

data and provide enhanced information on which informed decisions on
road management can be based and, ultimately, implemented.

Deterministic The class of decision making processes where outcome is predicted as a

precise value on the basis of mathematical functions of observed or
measured inputs.

Development works Projects planned at discrete points in time that result in improved road
capacity or changes in alignment.

Emergency works Works undertaken to clear a road that has been blocked.

Fourth generation (4GL) An advanced computer programming language, usually used for
programming language interrogating databases.

Global cost The `broadest brush' category of cost-estimating technique which relies
on libraries of achieved costs of similar works; eg cost per kilometre of
bituminous resurfacing.

Hardware The physical components of a computer system, including processor,

keyboard, monitor and printer.

HDM-III The `Highway Design and Maintenance Standards Model Version III',
which is a computer-based decision-support system, developed by the
World Bank, and used for economic appraisal of road projects.

63
Information quality level (IQL) Criteria developed by the World Bank for grouping data in terms of their
level of detail and other attributes to assist in specifying data collection that
is cost-effective when used in conjunction with road management systems.

Information system A computer-based system that collects, organises and stores data.

Information technology (IT) All aspects related to the use of computers to assist with management or
other activities.

Institutional appraisal An investigation of an organisation that identifies its strengths and

weaknesses, success in meeting defined aims, and the constraints under
which it operates.

Inventory A record of the physical attributes of the road network or other asset being
managed.

Local area network (LAN) A system of linking computers in fairly close proximity, such that each can
have access to common peripherals, data and software.

Logical design A written description used as a starting point in developing computer

software. This includes a detailed description of the functions, processes
and data structures of the processes for which computer software is to be
written, but described in such a manner that is independent of the
programming language to be used by the software or the hardware on which
it will run.

Maintenance management system A computer-based system for assisting with the management of maintenance
(note that in UK English, this term will often be used synonymously with the
term `pavement management system' whereas, in US English, the term will
normally refer to an `operations management system'); to avoid confusion,
the use of this term should be avoided.

Management cycle A series of well-defined steps which take the management process through
the decision making tasks. Typical steps would be i) define aims; ii) assess
needs; iii) determine actions; iv) determine costs and priorities; v) implement
activities; vi) monitor and audit. The process typically completes the cycle
once in each periodic cycle of the particular management function.

Management function A means of defining a management task based on its objective. Management
functions are undertaken so that the requirements of the policy framework
are met; examples are planning, programming, preparation and operations.

Map-based graphics Computer output that shows features and attributes of the road network
spatially against a map background.

Meta data Parameters input to a computer system that define the fundamental processes
of operation of the system.

Middle-ware Computer software that is used to interface between applications software

and an RDBMS, such that the way that the applications software can be
written is independent of the RDBMS.

Mission (statement) This outlines, in broad terms, the goal of the organisation responsible for the
road network, and justifies its existence.

Model A mathematical function or algorithm that is used to simulate real life

effects.

Module/modular An entity that is broken down into discrete parts that can be developed,
tested and operated independently of each other.

64
Multi-year programme A schedule of road works planned to take place in discrete years into the
future.

Networks A particular grouping of roads for management purposes; examples are

the national road network; trunk road network; paved road network, etc.

Network information system An information system that stores data about the road network and its
inventory.

Network referencing The process of breaking the road network down into successively smaller
links, segments and sections, each of which can be defined uniquely for
road management purposes.

Operating system Software mounted on a computer that provides an interface between

applications software and the computer hardware. The operating system
enables a user to make use of the hardware facilities of the computer, for
example by organising where information is stored in memory, by storing,
retrieving and copying files, and by looking after the input and output.

Operation(s) The on-going activities of an organisation, for which management

decisions are made on a near-term basis. Examples include the scheduling
of work to be carried out, monitoring in teens of labour, equipment and
materials, the recording of work completed, and the use of this
information for monitoring and control.

Operational cost A fundamental cost-estimating technique that builds up the total cost of the
work from its component activities described by the method statement and
programme, in terms of labour equipment and materials.

Pavement management system A computer-based road management system, typically used to assist with
planning, programming or preparation; to avoid confusion, the use of
this term should be avoided.

Performance standard This specifies the quality of finished work for an activity, and builds up a
consistent description of the activity based on a preferred method of
working, and requirements for equipment, labour and materials.

Periodic works Works planned on a regular basis to take place at intervals of several
years.

Planning This involves an analysis of the road system as a whole, typically requiring
the preparation of long term, or strategic, estimates of expenditure for road
development and conservation under various budgetary and economic
scenarios; predictions may be made of expenditure under selected budget
heads, and forecasts of road conditions, in terms of key indicators, under a
variety of funding levels.

Policy framework A set of statements, normally comprising a mission statement, objectives

and standards, that define in detail the aims of an organisation and how it
proposes to achieve these.

Preparation The near-term planning stage where road schemes and projects are
packaged for implementation. At this stage, designs are refined and
prepared in more detail; bills of quantities and detailed costings are made;
together with work instructions and contracts; detailed specifications and
costings are likely to be drawn up.

Preventive works Addition of a thin film of surfacing to improve surface integrity and
waterproofing that does not increase the strength of the pavement.

65
 Priority index A parameter whose value gives an indication of the priority of the associated
activity.

Probability/probabilistic The class of decision making processes where outcome is predicted as a

probability function of a range of possible inputs.

Problem tree analysis A method of problem solving that works backwards from a problem
statement, breaking this down into more detailed components, and then
develops these to find a solution.

Procedure A documented series of steps for carrying out a particular activity or task.

Programming The preparation, under budget constraints, of mufti-year works and

expenditure programmes in which those sections of the network likely to
require treatment, and new construction possibilities, are identified and
selected; a tactical planning exercise.

Reactive works Works responding to minor defects caused by a combination of traffic and
environmental effects.

Recurrent budget The government budget which is normally used to fund those works that are
needed every year, including such items as staff salaries, running costs of a
road administration, and maintenance works for the road network which are
undertaken on a regular basis.

Reduced time period analysis A method of analysis used in computer-based prioritisation of road works that
uses an approximate approach to life cycle costing that is less demanding of
computer processing requirements.

Relational database management Computer software designed to construct, modify and maintain a database,
(RDBMS) system where the database stores data in a structured way in a number of database
files, and where the detailed relationship between specified data items is
defined.

Road class/hierarchy A grouping of road sections according to pre-defined rules, often based on
issues of ownership, function, funding source, etc.

Road management The process of maintaining and improving the existing road network to enable
its continued use by traffic efficiently and safely, normally in a manner that is
effective and environmentally sensitive; a process that is attempting to
optimise the overall performance of the road network over time.

Road management system A computer-based system used to assist with road management.

Routine works Minor works that need to be undertaken each year.

Software A set of instructions that can be stored in a computer and used to carry out
pre-defined tasks; often referred to as a `program'.

Spatial data Data that include geographic co-ordinates among their attributes so that they
can be displayed using map-based graphics.

Special works Works the frequency of which cannot be estimated with certainty in advance.

Specification A detailed description of the attributes of the output from an activity, or of the
steps by which that activity is earned out.

Stakeholder Those with a vested interest in the performance of the road administration,
including the road users, industry, agriculture and commerce, who are its
`customers', plus the road administration itself and the road engineering
industry.

66
Standard (maintenance) A requirement, sometimes legally enforceable, that a road administration is
obliged to meet as part of its road management activity.

Strategic Pertaining to actions, often wide ranging, designed to achieve defined

objectives in the long term.

Strip diagram A report, often in the form of a computer output, that shows road features and
attributes relative to the longitudinal, but not cross-sectional, position along
the road.

System A structured group of discrete entities which interact for a particular purpose;
examples are:

• A `computer system', which is a collection of software and hardware

designed to carry out a particular function

• A `management system' which is a set of procedures designed to assist

the management process (which may also include a computer system)

Tactical Pertaining to actions designed to achieve defined objectives in the short to

medium term.

Training levels A formalised approach to classifying skills and needs of individuals that
assists in identifying training needs.

Unit rate A cost-estimating technique based on the traditional bill of quantity approach
to pricing engineering work, typically relating to aggregate quantities of work
to be carried out, measured in accordance with an appropriate method of
measurement.

Un-interruptible power A device for storing electricity, that can be placed between computer
supply (UPS) hardware and a mains power supply, that enables continued operation of the
hardware for a reasonable period in the event of a failure of the mains power
supply; the device normally has the further ability to `smooth out' power
surges and peaks in the mains power supply that could otherwise damage
operation of the hardware or corrupt the software.

UNIX (UNiplexed Information A proprietary computer operating system designed for efficient and operation
Computing Service - UNICS) with large software systems and where many users are accessing the software
or data at the same time; often used in connection with mini-computer or
`work station' hardware, but also available on micro-computers.

Works All construction and maintenance activities.

67
Appendix B: Institutional appraisal check list
(Developed from: Brooks, D M and others, 1989. Priorities in improving road maintenance overseas: a checklist for
project assessment. Proc Institution of Civil Engineers, Part 1. 86 (Dec), 1129-1141.)

1 External (socio-political, contextual or environmental) factors

1.1 Legal and regulatory
1.1.1 Is there a Roads Act which defines clearly the role and
responsibility of the road administration?
1.1.2 Which organisations are responsible for different classes
of road?
1.1.3 Are the legal powers adequate and, generally, are they
understood by the road administration?
1.1.4 What is the influence of government or civil service
procedures on operations of the road administration?
1.1.5 Is the road administration subject to external
monitoring and audit?
1.2 Socio-cultural
1.2.1 Are there historical, social or cultural factors which
affect the road administration's operations?
1.2.2 Is there a recognisable management culture in the
country?
1.2.3 Are decisions in government independent of the
influence of nepotism, favouritism, or corruption?
1.3 Political
1.3.1 What priority is given to road management compared
with other sectors, and with other activities in the road
sub-sector?
1.3.2 To what extent are road administration staff political
appointees?
1.3.3 To what extent are decisions made influenced by
political factors?
1.4 Economics and resources
1.4.1 To what extent is the economy governed by market
forces, and to what extent is it planned or controlled
centrally?
1.4.2 What impact does the general economy have on the
ability to manage the road effectively?
1.4.3 Is a budget awarded, is it adequate, and can it be
relied upon?
1.4.4 Are operations independent of foreign exchange
constraints?

68
1.5 Overall employment policies
1.5.1 Are there sufficient personnel available at all levels?
1.5.2 Are they adequately educated?
1.6 Private sector
1.6.1 What is the government policy towards private sector,
and how is this implemented in practice?
What is the availability of domestic project financing?
What is the availability of international/donor project
financing?
1.6.2 What locally-based road consultants exist and where
are they located:
Domestic?
International?
1.6.3 What locally-based roadworks contractors exist and
where are they located:
State-owned domestic companies?
Joint venture state/private?
Private domestic? International?
1.6.4 What is the workload of:
Consultants?
Contractors?
1.6.5 Competence:
How well qualified and experienced are the domestic
staff of:
Consultants?
Contractors?
What equipment holding do contractors have?
What is the quality of work produced?
1.6.6 Are bidding procedures:
appropriate?
transparent and free from corruption?
How do contract documents compare with
international norms, such as FIDIC?
Is payment for works timely?
Does the client have the ability to supervise, measure,
test, etc?
Is there access to arbitration?
1.7 Related institutions
1.7.1 Is the performance of the road administration
dependent on the output of other organisations over
which it has no control?
1.7.2 To what extent is the road administration subject to
external competition?
1.7.3 What external incentives to performance exist?

69
 2 Internal institutional (organisational, managerial and human resource) factors
2.1 Policy framework
2.1.1 Does the administration have a mission statement,
objectives and standards, and are these appropriate?
2.1.2 Is the policy framework appropriate and achievable?
2.1.3 Is policy based on economics, or other factors?
2.1.4 Are road plans produced for:
Construction?
Maintenance?
and at what frequency?
2.2 Organisational and administrative structure
2.2.1 Is there an administrative structure that is appropriate
for and capable of managing roads?
2.2.2 Are responsibilities defined, and are staff aware of
these?
2.2.3 Is there an unambiguous chain of command?
2.3 Procedures
2.3.1 Do documented procedures exist for:
Planning?
Programming, including budgeting and setting
priorities?
Project preparation?
Management of on-going operations?
2.3.2 Are the procedures understood and applied?
2.4 Resource management
2.4.1 Is there a regular and formal budgeting process?
2.4.2 Is the budget based on assessed or measured need?
2.4.3 Is the budget related to actual costs and the ability to
disburse?
2.4.4 Are procurement procedures appropriate, efficient and
independent of corruption?
2.4.5 Does full financial control reside within the
maintenance organisation?
2.4.6 Are accounts independently audited?
2.5 Human resources
2.5.1 Is there a manpower inventory, and career development
records for all staff?
2.5.2 Is there a manpower plan which is used as the basis of
staff recruitment, deployment, utilisation and
advancement?
2.5.3 Are compensation, benefits and incentives adequate
to motivate staff?
2.5.4 Is systematic staff appraisal carried out against
performance standards as an input to the career
development process?
2.5.5 Do adequate sanctions exist to deal with indiscipline,
and are these implemented?
2.5.6 Are staff adequately trained, and is there an internal
training scheme?

70
3 Technical (engineering and physical) factors
3.1 Data
3.1.1 Is the network referenced, and is this up-to-date?
3.1.2 Does an inventory exist for the road network and its
structures, and is this up-to date?
3.1.3 Is there adequate traffic and axle load data, and is this
up-to-date?
3.1.4 Does sufficient up-to-date condition data exist to
enable needs to be assessed?
3.1.5 Is road accident data collected and analysed in a
systematic manner?
3.1.6 Is unit cost data available and up-to-date?
3.1.7 To what extent are computer-based information and
management systems available and used?
3.2 Materials and supplies
3.2.1 Are appropriate materials and supplies of the right
quality available as required?
3.2.2 Are the properties of materials used fully understood?
3.2.3 Are there adequate testing facilities, and is the quality
control of products and materials adequate?
3.2.4 Are appropriate materials always used?
3.2.5 Does an adequate system exist for ordering, storing
and stockpiling materials arid supplies?
3.3 Plant and equipment
3.3.1 Is there a fleet of plant and equipment of the size and
composition required?
3.3.2 Is the availability adequate?
3.3.3 Is the utilisation adequate?
3.3.4 Are the workshops and stores adequate to support it?
3.3.5 Is there an organisation capable of managing the fleet
cost-effectively?
3.3.6 Is adequate financial provision made for replacement
and repair?
3.4 Operations
3.4.1 Do appropriate design methods exist, and are they
used?
3.4.2 Are there specifications for work, and are these met in
practice to achieve adequate quality control on site:
For works carried out by direct labour/force
account?
For works carried out by contract?
3.4.3 Are contract procedures satisfactory and enforced?

71
3.5 Monitoring acid feed-back
3.5.1 Is work done measured and costed?
3.5.2 Are costs realistic in terms of overheads, equipment,
materials and labour?
3.5.3 Is cost and monitoring information collected centrally
and used for planning and budgeting purposes?
3.5.4 Is there a physical inspection and audit of work done?
3.5.5 Is productivity measured?
3.6
3.6.1 Is there adequate access to current research work and
good practice from other organisations or research
centres?
3.6.2 Is relevant research currently carried out within the
organisation?
3.6.3 Are new techniques and practices introduced as a
result of research results?

72
Appendix C: Example applications of the information quality level concept
(Source: Paterson, W D, 1991. Choosing au appropriate information system for road management. In: PIARC. 19th
World Congress of PIARC, Marrakech, September 1991. Paris: Permanent International Association of Road
Congresses).

Table C.1 Road inventory

73
Table C.2 Methods of measurement for pavement structural evaluation

Table C.3 Characteristics of options for deflection measurement

74
Table C.4 Minimum spatial sampling rates and methods for pavement structural evaluation

Table C.5 Traffic volume and axle loading for different information quality levels

75
76
OS-E
ISSN 0951-8797

Guidelines for the design and operations of

road management systems ORN 15