Some experiences with managing GIS projects
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 organisation’s 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 under-utilised 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).
The designing a Geo-IT system depends strongly on the quality of the functional specifications that are stated in a very early phase of the design project. No matter which of the well-structured methods and techniques are used to determine the specifications. It will always be a difficult problem to find out the requirements of the future users of the system. This is mainly because the user will only be familiar with the possibilities the new system after the use has started and will understand what the systems allows to do. Structured design methods do not incorporate the experiences that users get after learning to apply the systems to their problems and so change their needs. This results in a large amount of requests to change the systems immediately after finishing the design. Prototyping is such a system.
In this presentation the author will present his experiences in designing a large cadastral information system applying a structured methodology for designing, implementing and converting the analogue to digital data process. Further more the use of prototyping will be discussed in a project for designing the communication and awareness to use a national geo information infrastructure.
Structured Development Method (SDM)
Although failures in the design of a Geo-IT system are usually not so dramatic as a wrong design in some machinery that can cause human injury, designing Geo-IT systems is very complex. Small design errors may cause a cumulative effect on the performance of the systems and eventually becoming highly accentuated.
Regarding the personnel and institutional aspects of the development of a Geo-IT system one has to concern about two basic functions:
1. serving the proper users. Often systems are designed for certain applications and perform well as such. Within an institution co-operation between sub-divisions and departments is often lacking due to poor management and lack of overview of the overall needs. Combined development of systems may reduce the time and costs of design and implementation enormously. A well-structured development and implementation plan should be approved by the institution’s management overseeing all the consequences and accepted by the personnel on the work-floor in order to make the system successfully operational.
2. serving the users properly relates to the software capabilities, data needs and institutional fit. The first two have to be determined before the system is designed and as such suffer from the result as described in 1. GIS users from different organisations differ in applications. If data is widely applicable (such as cadastral and basic topographic information) the organisation that provide data should incorporate the needs of all the other users also. Such applications can be in a university research environment pushing the capabilities to the extreme of its possibilities (and the needs may change also very rapidly ) while in businesses there is a more consistent workflow and so may need a better design for combining several, often applied operations for decision making.
With regard to the technical design of a Geo-IT system one may distinguish two major parts:
1. software design, including data structures, data models and programming, requiring highly skilled personnel.
2. system design, concerning with the interaction between personnel (individual or as groups) and the system. The introduction of new technologies requires different attitudes and additional training to the personnel. It also changes the flow of information and therefor modifies the organisation’s structure. Besides, using digital available data structured in object occurrences in Geo-IT systems we can now be concerned with the 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, sub-systems 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):
Figure 2. Cascade model of a life cycle.
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):
Experiences with SDM
Beginning of the seventies the Netherlands Cadastre has performed a feasibility study for the automation of its work. This resulted in two mayor projects: one for the creation of the alpha/numeric database and one for the graphical database. Both models include a logical link between the two systems using the unique cadastral parcel number. The research to determine capabilities of the systems have lead to a system for detail survey finished in 1976 and a prototype for the alphanumeric cadastral information system in the end of the seventies. Based on the experiences with these prototypes the two project leaders were asked to make a project plan for the implementation of an automated system for cadastral registration. These were finished in 1983. Based on these plans it was decided by the management to start the automation of the cadastral registration (AKR) to be finished in 1990. The alpha/numeric data of all cadastral units were digitised in sequence. It was assumed that the automated system for the land-surveying and cartographic information system (LKI) would create a much larger database. In order to gain experience with such a system the management decided – also based on cost/benefit calculations – to introduce the LKI system for 15% of the country within six years. Afterwards the system was introduced in all country and was finished in 1998. The original system design for LKI included a field-tree data storage and access system. In the beginning of the nineties the system became so large that a new design was required. Now a special designed Spatial Location Code is designed combining the field-tree with a Peano space division.
The size of the LKI project was huge. Including the data conversion the AKR was estimated around Mƒ 300.- and involved the daily work of 725 employees. The LKI project was estimated around Mƒ 800.- and involved around 2100 employees. The author was at the time project leader of the LKI project. The project organisation included around 100 persons comprising of a project steering committee and a project management group, a research group for the functional and technical design (not all requirements and possibilities were known at the time), system analysts, program designer and programmers. On the institutional aspects 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 |
Cost per day |
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 institution’s 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.
Prototyping – Rapid Development Method (RDM)
Prototyping is characterised by extensive use of operating models (prototypes) of systems under development in order to automate the (sometimes already automated) processes.
The RDM is a method that is used for the development of systems for which the end result is unknown. Basically the project is ongoing developed, i.e. a short-term project is planned and designed, after the end of the project its result is evaluated and based on the experiences of the previous project a new short-term project is executed, and so on. For each sub-project a well-defined goal is stated. Parts of the development that are not defined and appear during the sub-project are pushed forward in time to other sub-projects in order to allow the management to examine and prioritise all developments to get to a final result. Often also time-boxing is used for such a development since the development of each sub-project requires a prior stated period of time.
So prototyping RDM usually iterates the functional specifications in close co-operation between developers and future users using prototypes. Often discussions give better results to train users as manuals do when written by developers and read by users. So, prototyping RDM starts with generic functional specifications creating a generic system that is evaluated by the users convoluting to more precise specification and correction of the model, etc. (see fig. 4)
Fig. 4. The iterative process in prototyping RDM.
The result is that the many steps executed in the SDM’s 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-project’s 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 project’s steering committee or the institute’s managers.
Apart from this approach RDM Prototyping acts very similar to the SDM method.
Experiences with RDM prototyping
For the development of the Dutch World Wide Web site IDEFIX in 1996 RDM prototyping was used. IDEFIX was an Internet based prototype for the Geo-clearinghouse in the Netherlands. Since it has become to operate under a private organisation (1998) and last year a development is started using links to organisational databases (instead of using a central controlled metadata database), forcing the participants to update their own metadata instead of having a central organisation that provides metadata.
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:
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 sub-projects 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