Professional Documents
Culture Documents
Some Experiences With Managing GIS Projects: Henri J. G. L. Aalders
Some Experiences With Managing GIS Projects: Henri J. G. L. Aalders
Henri J. G. L. Aalders
Delft University of Technology
Faculty of Geodetic Engineering
Thijsseweg 11, P. O. B. 5030, 2600 GA Delft
E-mail: h.j.g.l.aalders@geo.tudelft.nl
Katholieke Universiteit Leuven
Faculty of Engineering
Keywords: Information Technology, GIS, management.
Abstract
In the past huge Geo-ICT systems have been developed at high cost. Often the management of such
projects was poor and so the time used for development, the amount of personnel and the costs
exceeded the planned. Strict management was necessary using a systematic development SDM was one
of the first methods that became into use and many variants of it are developed. In order to enable the
influence of the organisations management that ordered the development and the influence of the
future users better, a prototyping method became into use in the eighties. The author describes shortly
both systems and his experiences using them
Introduction
In order to use GIS successfully one has to identify the study area, define and collect the
objects we need for the application in an automated system (including their relationships), and
choose the right tools to obtain the required end-result. This approach assumes that a good
GIS design for the mentioned purpose is available to the applicant. Poor GIS-designs have
proven to result in inadequate studies or are incapable of producing the desired results.
Mainly this is because of badly organised data, poor data models, software with limited
capabilities, underestimation of time involved in developing the database and the applications,
wrong inventory of data needs, etc. On the other hand well-designed system are often underutilised because of the complexity of the system, a lack of understanding the software
capabilities or because old software and data make systems less flexible. Also many failures
are due to inadequate organisational structure that are required in relation to the new
technologies.
Nowadays, many GIS-applications are institutional, dealing with environmental studies,
economical analysis, transportation, emergency services, mining-, utility-, governmental- and
public service operations and scientific research. Often these organisations design their
systems for the kind of GIS studies they provide and have their organisation in tune with the
system. It appears that the success if any IT system (including GIS systems) are highly
depending on this. In the design of Geo-IT systems, it becomes very clear that much attention
has to be given to the financial and personnel aspects of the introduction of the system. Any
manager designing and implementing a system has to give much attention to the
technological, financial and personnel/institutional aspects of the introduction (see figure 1).
Laws and
regulations
Adminstrative organisation
Geo-IT technology
input
Personnel
process
analysis and
presentation
storage
External
models
integrity and quality of the data and the processes applied to them. The accessibility to the
data requires also measures for the security and quality control within the organisation. So
we can speak of :
2.1. technical (internal) issues dealing with functionality of the system;
2.2. and institutional (external) issues dealing with the interaction of the system and the
personnel using it.
Using a designed system for some time, employees will understand its capabilities and invent
new strategies in the operations. This often results in request for changes of the system.
Designing a system can be seen as a project but often the changes are often treated as projects
as well. All projects should have a starting data en an end-result, delivered at a certain date.
So one can speak of a project life cycle, where during the project a methodology has to be
used to give a framework to finish the project, especially when the project is executed by a
small or larger group(s). Such a methodology gives a structure to perform the project-tasks in
the right order and to test each of the tasks according to their goals. Also when more
interconnecting (sub-) projects are running simultaneously, the need for consistency between
them by a management steering committee is obvious. And for the management there should
be regular checkpoints to determine whether the project runs according the original goals and
whether the project should be continued or not.
SDM uses a method that covers all steps in a project to be taken in sequence as (as a linear
approach) to be marked as the institutional and technical aspects. SDM includes the
specification of functional needs, system analysis, detailed design, testing (modules, subsystems and the system as a whole), implementation and training. A project plan usually also
includes a cost-benefit analysis for the application in order to allow the management to check
the need for the introduction of the system (see fig 2):
Feasibility study
Project planning
System analysis
Functional design
Technical design
Coding
Technical
design
Functional
design
Testing
Implementation
Training
Evaluation
1. Feasibility study involve the inquiry amongst potential users whether they would use the
proposed system and the costs and benefits of the development. A positive result of this
study will end in a project plan, including the development, implementation and costbenefit analysis;
2. System analysis will describe the present way of operation, identifying the data and
processes as well as future requirements to the proposed system and fit the new designed
system within the organisation;
3. Functional design encompasses the development of a GIS-data-model and -structure
using the information collected in phase 2;
4. Technical design will develop a model for all subsystems and the mutual interaction
followed by the coding of to develop the required programmes that perform all operation
wanted. These programmes are tested on a testing database that is developed for this
purpose according to the functional design;
5. Implementation of the system for daily operation requires the training of the users for
daily operations according to the design of the system;
6. Evaluation afterwards reflects both to the technical design and the cost-benefit analysis.
Also the ergonomical consequences for the personnel have to be researched in order to
determine whether the system needs adjustments from this point of view.
Describing the relation between the system and its application, two types of employees are
involved, each with a different view on the system (and all should be involved in the training
and evaluation of the system):
1. Internal actors, including the system users, system operators and system owners. The
system users are the employees that apply the system to solve the spatial problems the
system is designed to do. Special attention has to be taken to new employees in sense of
system use and training. System operators are responsible for the correct functioning of
the system. Some of them will act as system administrators for the data, database,
applications, network and hard- and software. While the system owners are responsible
for the environment of the system, as providing office space, salaries, etc.
2. External players are of several kind: firstly there are the GIS-developers or the supplier
that provide the hard- and software to run the system and its updates. Secondly, often all
data is not collected by the organisation itself but comes from outside, provided by the
data suppliers. This data should be combined with the internally collected data and act as
one system. Thirdly there are the application developers that work together with system
analysts; they adjust the GIS system in such way that day-to-day operations are
performed at maximum efficiency.
there was a group dealing with the personnel and financial aspect, a group of trainers
(especially educated by the project leader for this task) and two groups of employees that
would deal with the system on a daily basis to test all the modules in practice.
As a project leader one has to deal with all characteristics of a project. Usually such large
projects include a goal, should executed only once and not be a daily operation are complex,
will have limited time and money (personnel) available and requires the co-operation of
different groups such as managers, designers, programmers, operators, researchers and
potential daily users. Very strongly I have always felt during the project the necessity to think
through the project and its sub-systems forward and backwards. Also to work from the whole
to details for all phases was imperative. Since SDM was at the time only recently developed
the project a spreadsheet type system was used to keep track of all operations with regard to
timing money and the use of personnel that can be used for each (sub-)phase (see fig. 3.).
Period of use
Total days
Total cost
Equipment
Personnel
Total
Figure 3. Basic element for project management.
For the aspect time plans were made to state the milestones and target dates to be aimed at.
Also the period of time to develop each phase and the resources available (money and
qualified personnel) are of influence of this. So there are inter-relations in the spreadsheet as a
whole. Financial aspects include budgeting (using experiences from the test groups) and the
cost/benefit analysis, as well in quantitative as in qualitative sense (how much personnel of
what qualifications).
Apart from these project management aspects the quality of the end result should meet prior
statements using standards, pre-defined procedures, audits and verifications and a risk
analysis. It is my experience that a project manager for such a large project should be a good
organiser and planner, motivate and convince the project members, facilitate the working
circumstances for the project members and present the project to the outside world (public
relations) and the institutions management. Also (s)he should be a very accurate
administrator and available for many hours per day. Reasons enough not to be such a project
manager for a long period.
As (project) manager of large automation projects one has to judge received proposals for
sub-project according to the binary rule. This rule states: proposed projects will take twice as
much time, twice as much costs and result only in half of the expected results. Colleagues of
mine at the time always told me that the factor 2 in this rule id far too low: it should 3 5!
Also I experienced the balance rule, stating never accept to become a project manager when
the responsibility that comes along is not in balance with the means to obtain the end result of
the project, i.e. enough finances, personnel and power to push the project forward.
Reflecting back it is apparent to me that much of the techniques that were necessary and their
scientific and technological implications were not known both to the organisation as well to
the project-members, while the management thought they had the outstanding group. Also the
evaluation of the project plan by the Ministry of Interior (the co-ordinating ministry of
governmental automation projects) seemed to think this way.
In 1994 Duane Marble conceptualised and developed a flexible, multi-level design process for
GIS based on a model pioneered by Boehm. It would have of great help when the method was
known in the beginning of the eighties for the two projects. Much of the processes developed
especially for the LKI system were to be developed, as using topology, access methods for
such large databases, use of object technology and object-orientation.
Correction
The result is that the many steps executed in the SDMs cascade model are now returning
stepwise in the RDM prototyping project management technique focusing towards the end
result in small steps while each step is a project in itself. The disadvantage is that during each
step things may turn up that are discovered during the sub-project that need development too.
It requires a strong hand of management by the project manager to push such developments in
front towards a next phase and stick to the original sub-projects task. During the evaluation
of the sub-project and the planning of the next stage all new developments will be reviewed to
obtain a priority lists for developments in the next phase to be decided upon by the projects
steering committee or the institutes managers.
Apart from this approach RDM Prototyping acts very similar to the SDM method.
The awareness, availability, distribution and potentials of Geo-data have become a major
issue within the Dutch Geo-scene. For this a Geo-plaza is established available expertise and
knowledge will be made available concerning geo-information infra-structure on:
awareness, information (something like a helpdesk function), communication and
exchange of experiences with inter-operability;
scanning and updating new (inter-) national developments on GII and standardisation;
harmonisation of Netherlands existing standards with international developments;
possibilities of education in inter-operability and multi-functional data use.
For the development of a communication network on Internet also the application of SDM
prototyping is chosen. The development will take place in 2000 so no experiences can be
given.
The development of IDEFIX has been very successful. Within a year the Internet site was
available. To separate the project management and the project execution is a lesson that
should be learned form it. When management and execution of a project is contracted to the
same organisation the influence of the contents of the several sub-projects depends too much
on the likes and dislikes of the contractor presenting the results of each sub-project. It is
intended to apply this separation in the developments for Geo-plaza.
Conclusions
The development of Geo-ICT often requires large amounts of hardware software development
tools and especially manpower. To organise such large projects a System Development
Methods is available with several variants.
It is a disadvantage of these methods to require a stated functional design before the
development takes place. This is because many developers withdraw in their rooms to make
these programs as stated beforehand without intermediate consultation of the potential users.
Rapid Development method/Prototyping is a solution for this but the pitfalls are also here.
Users, managers and developers should have open discussion about the evaluation of the subprojects and well as about the contents of the subsequent phases of the project.
Also a strict management methods are required on technical, personnel, ergomonic, financial
and organisational aspects of the project.
Because of the complexity of many Geo-ICT project planning and budget are often over used.
Also here a strict management is necessary.
Literature
1. Boehm B.W., 1986. A spiral model of software development and enhancement, ACM
Software Engineering notes Vol. 11, No. 4.
2. DeMers, M.N., 1997. Fundamentals of geographic information systems, ISBN 0-47114284-0, John Wiley & Sons Inc.Danvers MA. U.S.A.
3. Marble D.F., 1994. An introduction to the structured design of GIS Associtation for
geographic information. John Wily & Sons London, U.K.
4. Vonk, R., 1987. GIS ontwerp en implementatie. Prototyping Academic Service
Schoonhoven, The Netherlands