Project Management for GIS Technology
Paulo Henrique Rathunde
William Lopes de Oliveira - PhD
Learning Objectives:
-
Project Management is the present strategy to reach the companies objectives.
- Development of software with quality requires very well defined processes.
- Our experience with Project Management in GIS applications development – How to implement it.
1 Introduction
The new global world reality demands for strategic and project management policies combined to
generate a synergic effect toward efficiency besides the challenge of intense and constant changes.
The integration of the Project Management and the Software Development Processes assures the
elaboration of all necessary products to make software with quality within the established time and cost.
This work shows how the Project Management and Software Development processes were defined
and implemented in our company and what the strategies and difficulties for definition and
implementation were. Although there are four processes involved with the Software Quality Program, we
have concentrated only in two of them: Software Development Process and Project Management Process.
Our experience resides in GIS software development. Therefore, in this work there is a concentration
in software development, but the majority of conceptions exposed here are valid for any project, be it a
GIS development, GIS technology usage or any other project.
1.1 Our Company (COPEL)
COPEL is a vertically integrated electric utility company, in Paraná State, south of Brazil. It has 19
power plants (3,306 MW installed capacity), 6,352 km of transmission lines, 145,500 km of distribution
lines and more than 2,800,000 customers. For distribution administrative purposes, the Company is
divided in 19 areas.
1.2 Software Development Difficulties
Development of software is much more difficult than the great majority of people could
even imagine. In a recent article to the web site www.cio.com, Scott Berinato has compared software
construction with bridges construction. He has written: “Software tries to do many things, and many
of them have never been tried. And the tools used to build the software change continuously”. We,
engineers, have a long history on how to build bridges. The tools and the materials, are relatively
stable. The necessary methodology is very well defined. But with software is completely different.
When we decide to build software we have to be prepared to deal with complexity and
unexpected things. A bridge is used to link two points and that is it! All clients know perfectly what
they expect when they contract an engineer to build a bridge. A client of a software development has
an idea of the results he wants, but since he doesn’t know very well what is behind the computer
screen, he is not sure of what to ask, which the possibilities and the constraints of the whole process.
Then, when we start to build the programs we realize we have missed vital information, the “ideal”
infra-structure we decided to use is not very well known, we have misunderstood the desires of our
client and so on.
The software development professionals, are always too optimistic when they talk about
time and costs. They are used to dealing with technologic situations, programming languages,
computer architecture, etc., and they forget there are a lot of other factors which have to be
considered in a software project, simply because these factors are not direct related with code writing. For example, contracts, human resources, risks, team development, etc. These factors are
generally supplied by the organization structure and are neglected in the project. In general, the
software coordinator, a very good technician, is not trained in management activities or he just
dislikes them. The results are time, cost and scope estimation problems, with the inevitable and
serious consequences.
Since it is difficult to see all the variables involved with the software development, we have
a tendency not to value the requirements. This is the reason why the majority of software projects
collapses. We know perfectly well that if the bridge is not high or large enough it will not attend the
expected functionality, but how about software? We don’t have the software image inside our head.
An apparently simple requirement can generate a very big unexpected effort if it has not been deeply
analyzed.
Software solutions are frequently necessary to solve a business problem. These problems
are related to financial, operational or management bugs and have to be solved as soon as possible.
Then the pressures for results are always strong. The software supplier has to deal with very short
margin of time, sometimes with unrealistic perspectives, in order to have its project approved.
Commonly, the previous time and cost estimations are based just on opportunity analysis, not on
technical evaluations. When the team project receives the challenge, there is negotiation freedom,
just because it is so late.
Finally, IT professionals have a tendency to be too optimistic with new technologies,
considering them more productive than they really are. For example, there are old programming
languages which are much more productive than the new ones, despite the fact that these new
languages generate a lot of code automatically. The problem is that these automatically generated
codes, in general, don’t supply all the requirements and have to be rebuilt or modified. Then it takes
more time and cost to change the generated code than build it from the beginning.
