See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/316653326

GIS Project Management

Chapter · December 2017

DOI: 10.1016/B978-0-12-409548-9.09612-3

CITATIONS READS
0 1,161

1 author:

Jochen Albrecht
City University of New York - Hunter College
59 PUBLICATIONS   578 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Essential Methods for Planning Practitioners View project

The contribution of urban environments to global greenhouse gas emissions View project

All content following this page was uploaded by Jochen Albrecht on 17 January 2019.

The user has requested enhancement of the downloaded file.

Comprehensive Geographic Information Systems
Article Title: GIS Project Management

Author and Co-author Contact Information

Corresponding Author Name: Jochen Albrecht
Full Postal Address: Department of Geography, Hunter College, City University of New York, 695 Park Ave.,
New York, NY 10708, USA
E-mail: jochen@hunter.cuny.edu
Telephone: 001.212.772.5221

Abstract
After a brief flurry of monographs on business and organizational aspects of GIS in the 1990s, little
attention has been paid to a systematic approach in support of GIS project management. Most existing
efforts in both public and private enterprises are based on anecdotal evidence. This entry provides a
comprehensive overview of the subject matter starting with definitions and distinctions from neighboring
concepts and introducing important characteristics. This article describes all phases of GIS project
management and specifies the resources and tools required. It ends with an overview of external factors
and a discussion of the expertise required of a GIS project manager.

Keywords
Contract management; cost-benefit analysis; critical path; financial control measures; procurement;
project charter; project management lifecycle (PMLC); quality; risk; scheduling tools; stakeholder
management; work breakdown structure (WBS).

Glossary
Budgeted costs of work scheduled/performed – Respectively, the detailed cost estimates for each activity
in the project, or the sum of those activity costs that have been delivered so far.
Earned value analysis – the intermediate sum of all costs expended minus the values already earned.
Earned value management - periodically compares the budgeted costs with the actual costs during the
project
Myers-Briggs (Type Indicator) – a large world-wide administered survey of personality traits that helps
human resource managers to create teams that work with less inter-personal friction.
Project business case – the project proposal that describes what problem or opportunity will be addressed
by the project.
QA/QC – is the acronym for the twin concepts of quality assurance / quality control. QC embodies the set
of methods to test for adherence to quality standards at each step of the project. QA is the larger
framework, within which the QC tests are designed and implemented.
Schedule variance – the costs accrued by a project because of the amount of time it is behind schedule.
SCRUM – a project management methodology that allows a manager to start by building on empirical
data, and then re-plan and iterate from there.
SMART goals – Goals that are specific, measurable, agreed-upon, realistic, and time-framed.
Stakeholders - are individuals who either care about or have a vested interest in the project.
1. Project Management Overview
There is a big gulf between GIScience as an academic endeavor and its application in the form of GIS
project management in the real world. Project activities are complex because they rarely involve
routine repetitive acts, but often require specific knowledge and skills to be used in their design,
execution, and management. This chapter explains what project management is, its objectives and
the required ingredients from personnel to budgets and the integration of the GIS project into the
larger context of an organization’s and even societal culture.
1.1. Project attributes
Projects are temporary in nature. They are not an everyday business process and have
definitive start dates and end dates. This characteristic is important because a large part of the
project effort is dedicated to ensuring that the project is completed at the appointed time. To
do this, schedules are created showing when tasks should begin and end. Projects can last
minutes, hours, days, weeks, months, or years.
Each project is unique: they exist to produce a product or service that hasn’t existed before.
This is in contrast to operations (which a project may consist of), as they are typically ongoing
and repetitive. The purpose of operations is to keep the organization functioning while the
purpose of a project is to meet its goals and conclude. Therefore, operations are ongoing while
projects are unique and temporary.
1.1.1.Definition of a project
There are many definitions of a project. Wysocki et al. (2003), for example, define a
project as “a sequence of unique, complex and connected activities having one goal or
purpose that must be completed by a specific time, within budget, and according to
specification” (p. 38). Central to this definition is a logical sequence of activities that must
be completed within a specific time frame.
The Project Management Institute (PMI) (2013a, p. 8) defines project management “the
application of knowledge, skills, tools, and techniques to project activities to meet the
project requirement”. This definition is supplemented by five Project Management Process
Groups (PMPG) that describe the lifecycle of typical projects, and ten knowledge areas in
which project managers must be competent. The five PMPG are initiating processes,
planning processes, executing processes, monitoring and controlling processes, and closing
processes. The ten knowledge areas, on the other hand, focus on management expertise
in project integration management, project scope management, time management, cost
management, quality management, human resources management, communications
management, risk management, procurement management, and stakeholder
management.
Project management has also been defined in many other ways in the related literature.
However, it is apparent that many authors have accepted the PMI proposition that project
management is a special branch of management characterized by the application of
management principles and best practices that seek to steer the initiation, planning,
implementation, monitoring and closing of projects toward their ultimate success. It is also
apparent that many authors have adopted the PMI’s approach to group all project
management activities into five sequential phases or levels, commonly called the project
management lifecycle (PMLC).
1.2. Project characteristics
Projects have several characteristics:
• Projects are unique.
• Projects are temporary in nature and have a definite beginning and ending date.
• Projects are completed when the project goals are achieved or it’s determined the
project is no longer viable.
A successful project is one that meets or exceeds the expectations of the stakeholders.
1.2.1.Projects versus programs versus portfolios
Every organization that has multiple GIS users has de facto a GIS Program (Peters 2008). If
the users get their work done and are not aware of the business unit that allows them to
do their work, then this means that the program manager does her job well. If on the
other hand every GIS project starts from scratch and the only institutional memory is
buried in the heads of those who did other GIS projects before, then the tool that
constitutes GIS is clearly not used to its highest potential.
The PMI defines program management as “the application of knowledge, skills, tools, and
techniques to a program to meet the program requirements and to obtain benefits and
control not available by managing projects individually”, [PMI 2013b, p. 6]. The scope of
programs is hence beyond the sum of individual projects and includes training, operations
and maintenance activities. All this applied to GIS Programs as well. Two dimensions are
useful to keep in mind when there is confusion about the differences between projects
and programs:
• Uncertainty; well-managed projects generally have a low level of uncertainty
associated with them. This starts with project specification and improves as a
project moves towards its goal. Programs, on the other hand, do not start out with
a well-defined scope and require continuous adjustment. In extreme cases, a
successful project may still be abandoned because its program context has
changed.
• Change management of projects is usually in the form of fixes when the original
outcomes seem to become unattainable. Program management, however,
anticipates changes and aims to adapt the program to changing contexts.
The practice of GIS Programs would be categorized in management science as a portfolio,
a higher level management structure that has temporal bounds and combines multiple
programs to achieve an organization’s strategic objectives [PMI 2013c]. In addition,
portfolio projects do not need to be related to each other. Both of these characteristics
(no temporal bounds and possible non-relatedness of the projects) are characteristic for
GIS Programs. It follows that GIS Programs then combine the components of traditional
programs and portfolios, namely: strategic planning, governance, benefits management,
and stakeholder engagement. GIS Programs, like portfolios, manage recurring activities
(producing values) as well as projectized activities that are aimed at increasing value
production capability.
Projects come at a wide range of scopes from single-purpose projects that serve one-time
objectives to departmental projects that typically are handled within a dedicated GIS
department, enterprise-wide projects that may be line-managed by a GIS department, which
 may then play a strategic role within an organization, and finally consortial GIS projects, where
the costs are shared by a large number of stakeholders.
A project must have a well-defined goal with respect to the mission or mandate of an
organization. In many instances, a project may be too complicated to be carried out as a single
undertaking. Hence, it is necessary to divide it into several sub- or part-projects according to
the prevailing organization structure (e.g., by departments or business functions) or
geographical divisions (e.g., by regions, sales territories or watersheds). Under such
circumstances, each sub-project is considered as a separate but interdependent undertaking in
its own right. All sub-projects have their specific goals but when added together these goals
collectively constitute the specific goal of the parent project.
Every project or sub-project is generally subject to three constraints regardless of its objective
and scale. As depicted in Figure 1, these are:
• Time. Projects have definitive milestones that specify when particular components
(e.g., progress reports, prototypes) must be delivered, and a completion date when the
database system being developed will become fully functional and operational.
• Cost. Projects have cost or budgetary limits, which will impact on the availability of
human and technical resources.
• Specification. Deliverables of a project are required to meet a specific level of
functionality and quality both independently and when working as a whole.
It is important to understand that the constraints of time, cost and specification are
interdependent and, as a result, changes in one constraint always cause changes in the others.
For example, a change in the specification will inevitably lead to changes in the time and cost
requirements. Similarly, delays in the delivery of intermediate and final products inevitably
necessitate an extension of the project time frame, which will, in turn, increase the cost and
resource requirements of the project. Clearly, the dynamic nature of the interplay among the
constraints requires that projects must be properly managed in order to succeed. The principles
and practice of management are often deployed in the context of managing tangible entities
such as people, physical and financial assets, and the business operations of an organization.
These same principles, however, can be equally applied to the management of tangible
resources and non-tangible activities that are required to complete a project.
1.3. The process of project management
In spite of a long history of project management research, the application of that knowledge is
lacking in both the GIS world as well as more generally in the realms of information technology
or business administration. According to the CHAOS Report, published by the Standish Group
(2016) that tracks over 50,000 projects around the world, some 20% of all projects fail and over
52% of all projects face major challenges, with only 22% considered to be successful. The vast
majority of these challenges ad failures are avoidable by making sure that the business needs
are understood early on and assuring that project management techniques are applied and
followed. Having good project management skills does not completely eliminate problems,
risks, or surprises. The value of good project management is to have standard processes in
place to deal with all contingencies.
Project management is the application of knowledge, skills, tools, and techniques applied to
project activities in order to meet the project requirements. Project management is a process
 that includes planning, putting the project plan into action, and measuring progress and
performance.
2. Project Management and GIS Implementation Concepts
The design, development and implementation of a GIS task are complex tasks which should not be
underestimated. They require leadership, adequate planning, and a project-wise approach. This
section, therefore, provides a generic organizational framework which is meant to support the
design, development, and installation of a GIS.
2.1. The triple constraint of scope, schedule, and budget
On any project, there are a number of project constraints that are competing for the project
manager’s attention. They are cost, scope, quality, risk, resources, and time. These six points
are often abbreviated as the “triple constraint” of time, cost, and scope, illustrated in the form
of a triangle to visualize the project work and see the relationship between the scope/quality,
schedule/time, and cost/resource.
Scope

Quality

Cost Schedule

Figure 1. The triple constraint of scope, schedule, and budget.

In this triangle, each side represents one of the constraints (or related constraints) wherein any
changes to any one side cause a change in the other sides. The best projects have a perfectly
balanced triangle. Maintaining this balance is difficult because projects are prone to change.
2.1.1.Cost
The definition of project success often includes completing the project within budget.
Developing and controlling a project budget that will accomplish the project objectives is a
critical project management skill. Although clients expect the project to be executed
efficiently, cost pressures vary on projects. On some projects, the project completion or
end date is the largest contributor to the project complexity. The development of a new
drug to address a critical health issue, the production of a new product that will generate
critical cash flow for a company, and the competitive advantage for a company to be first
in the marketplace with a new technology are examples of projects with schedule
pressures that override project costs.
The accuracy of the project budget is related to the amount of information known by the
project team. In the early stages of the project, the amount of information needed to
develop a detailed budget is often missing. To address the lack of information, the project
team develops different levels of project budget estimates. The conceptual estimate (or
“ballpark estimate”) is developed with the least amount of knowledge. The major input
into the conceptual estimate is expert knowledge or past experience. A project manager
 who has executed a similar project in the past can use those costs to estimate the costs of
the current project.
When more information is known, the project team can develop a rough order of
magnitude (ROM) estimate. Additional information such as the approximate square feet of
a building, the production capacity of a plant, and the approximate number of hours
needed to develop a software program can provide a basis for providing a ROM estimate.
After a project design is more complete, a detailed project estimate can be developed.
The cost of the project is tracked relative to the progress of the work and the estimate for
accomplishing that work. Based on the cost estimate, the cost of the work performed is
compared against the cost budgeted for that work. If the cost is significantly higher or
lower, the project team explores reasons for the difference between expected costs and
actual costs.
Project costs may deviate from the budget because the prices in the marketplace were
different from what was expected. Project costs may also deviate based on project
performance. For example, a GIS manager estimated that particular survey would take 750
labor hours, but 792 hours were actually expended. The project team captures the
deviation between costs budgeted for work and the actual cost for work, revises the
estimate as needed, and takes corrective action if the deviation appears to reflect a trend.
The project manager is responsible for assuring that the project team develops cost
estimates based on the best information available and revises those estimates as new or
better information becomes available. The project manager is also responsible for tracking
costs against the budget and conducting an analysis when project costs deviate
significantly from the project estimate. The project manager then takes appropriate
corrective action to ensure that project performance matches the revised project plan.
More detail on aspects of project quality can be found in section 2.4.8.
2.1.2.Scope
The scope is a document that defines the parameters—factors that define a system and
determine its behavior—of the project, what work is done within the boundaries of the
project, and the work that is outside the project boundaries. The scope of work (SOW) is
typically a written document that defines what work will be accomplished by the end of
the project—the deliverables of the project. The project scope defines what will be done,
and the project execution plan defines how the work will be accomplished.
No template works for all projects. Some projects have a very detailed scope of work, and
some have a short summary document. The quality of the scope is measured by the ability
of the project manager and project stakeholders to develop and maintain a common
understanding of what products or services the project will deliver. The size and detail of
the project scope are related to the complexity profile of the project. A more complex
project often requires a more detailed and comprehensive scope document.
According to the Burek (2011), the scope statement should include the following:
• Description of the scope
• Product acceptance criteria
• Project deliverables
• Project exclusions
• Project constraints
 • Project assumptions
The scope document is the basis for agreement by all parties. A clear project scope
document is also critical to managing change on a project. Since the project scope reflects
what work will be accomplished on the project, any change in expectations that is not
captured and documented creates the opportunity for confusion. One of the most
common trends on projects is the incremental expansion in the project scope. This trend is
labeled “scope creep.” Scope creep threatens the success of a project because the small
increases in scope require additional resources that were not in the plan. Increasing the
scope of the project is a common occurrence, and adjustments are made to the project
budget and schedule to account for these changes. Scope creep occurs when these
changes are not recognized or not managed. The ability of a project manager to identify
potential changes is often related to the quality of the scope documents.
Virtually all GIS project scopes include background/context, research on goal, objectives,
information categories, and the actual information products depicted in Figure 2:

Goal
• Research question

Background Objectives
• Client / stakeholder • “Need to know”
aspects questions
• Literature review

Information
Products Information
• Contain information Categories
categories • Nouns of “need to
• How to present info? know” questions
• Text, tables, maps, graphs

Figure 2. Components of a GIS project scope document.

Events do occur that require the scope of the project to change. Changes in the
marketplace may require a change in a product design or the timing of the product
delivery. Changes in the client’s management team or the financial health of the client
may also result in changes in the project scope. Changes in the project schedule, budget,
or product quality will have an effect on the project plan. Generally, the later in the project
the change occurs, the greater the increase in the project costs. Establishing a change
management system for the project that captures changes to the project scope and
assures that these changes are authorized by the appropriate level of management in the
client’s organization is the responsibility of the project manager. The project manager also
analyzes the cost and schedule impact of these changes and adjusts the project plan to
 reflect the changes authorized by the client. Changes to the scope can cause costs to
increase or decrease.
More detail on aspects of project scope management can be found in section 2.4.2.3
2.1.3.Quality
Quality is a combination of the standards and criteria to which the project’s products must
be delivered for them to perform effectively. The product must perform to provide the
functionality expected, solve the identified problem, and deliver the benefit and value
expected. It must also meet other performance requirements, or service levels, such as
availability, reliability, and maintainability, and have acceptable finish and polish. Quality
on a project is controlled through quality assurance (QA), which is the process of
evaluating overall project performance on a regular basis to provide confidence that the
project will satisfy the relevant quality standards.
Project quality focuses on the end product or service deliverables that reflect the purpose
of the project. The project manager is responsible for developing a project execution
approach that provides for a clear understanding of the expected project deliverables and
the quality specifications. Developing a good understanding of the project deliverables
through documenting specifications and expectations is critical to a good quality plan. The
processes for ensuring that the specifications and expectations are met are integrated into
the project execution plan. Just as the project budget and completion dates may change
over the life of a project, the project specifications may also change. Changes in quality
specifications are typically managed in the same process as cost or schedule changes. The
impact of the changes is analyzed for impact on cost and schedule, and with appropriate
approvals, changes are made to the project execution plan (see also 2.4.5).
Although any of the quality management techniques designed to make incremental
improvement to work processes can be applied to a project work process, the character of
a project (unique and relatively short in duration) makes small improvements less
attractive on projects. Rework on projects, as with manufacturing operations, increases
the cost of the product or service and often increases the time needed to complete the
reworked activities. Because of the duration constraints of a project, the development of
the appropriate skills, materials, and work processes early in the project is critical to
project success. On more complex projects, time is allocated to developing a plan to
understand and develop the appropriate levels of skills and work processes.
Project management organizations that execute several similar types of projects may find
process improvement tools useful in identifying and improving the baseline processes
used on their projects. Process improvement tools may also be helpful in identifying cost
and schedule improvement opportunities. Opportunities for improvement must be found
quickly to influence project performance. The investment in time and resources to find
improvements is greatest during the early stages of the project when the project is in the
planning stages. During later project stages, as pressures to meet project schedule goals
increase, the culture of the project is less conducive to making changes in work processes.
More detail on aspects of project quality can be found in section 2.4.12.
2.1.4.Risk
Risk is defined by potential external events that will have a negative impact on the project
if they occur. Risk refers to the combination of the probability the event will occur and the
 impact on the project if the event occurs. If the combination of the probability of the
occurrence and the impact on the project is too high, it is identified as a potential risk,
which in turn should prompt the project manager to develop a proactive plan to manage
that risk.
More detail on aspects of project risk can be found in section 2.4.11.
2.1.5.Resources
Resources are required to carry out the project tasks. They can be people, equipment,
facilities, funding, or anything else required for the completion of a project activity.
More detail on aspects of project quality can be found in section 2.4.6.
2.1.6.Time
Time is defined as the time to complete the project. Time is often the most frequent
project oversight in developing projects. This is reflected in missed deadlines and
incomplete deliverables. Proper control of the schedule requires the careful identification
of tasks to be performed and accurate estimations of their durations, the sequence in
which they are going to be done, and how people and other resources are to be allocated.
Any schedule should take into account vacations and holidays.
The definition of project success often includes completing the project on time. The
development and management of a project schedule that will complete the project on
time is a primary responsibility of the project manager, and completing the project on time
requires the development of a realistic plan and the effective management of the plan. On
smaller projects, project managers may lead the development of the project plan and build
a schedule to meet that plan. On larger and more complex projects, a project controls
team that focuses on both costs and schedule planning and controlling functions will assist
the project management team in developing the plan and tracking progress against the
plan.
To develop the project schedule, the project team does an analysis of the project scope,
contract, and other information that helps the team define the project deliverables. Based
on this information, the project team develops a milestone schedule. The milestone
schedule establishes key dates throughout the life of a project that must be met for the
project to finish on time. The key dates are often established to meet contractual
obligations or established intervals that will reflect appropriate progress for the project.
For less complex projects, a milestone schedule may be sufficient for tracking the progress
of the project. For more complex projects, a more detailed schedule is required.
To develop a more detailed schedule, the project team first develops a work breakdown
structure (WBS)—a description of tasks arranged in layers of detail. Although the project
scope is the primary document for developing the WBS, the WBS incorporates all project
deliverables and reflects any documents or information that clarifies the project
deliverables. From the WBS, a project plan is developed. The project plan lists the activities
that are needed to accomplish the work identified in the WBS. The more detailed the WBS,
the more activities that are identified to accomplish the work.
After the project team identifies the activities, the team sequences the activities according
to the order in which the activities are to be accomplished. An outcome of the work
process is the project logic diagram. The logic diagram represents the logical sequence of
the activities needed to complete the project. The next step in the planning process is to
 develop an estimation of the time it will take to accomplish each activity or the activity
duration. Some activities must be done sequentially, and some activities can be done
concurrently. The planning process creates a project schedule by scheduling activities in a
way that effectively and efficiently uses project resources and completes the project in the
shortest time.
On larger projects, several paths are created that represent a sequence of activities from
the beginning to the end of the project. The longest path to the completion of the project
is the critical path. If the critical path takes less time than is allowed by the client to
complete the project, the project has a positive total float or project slack. If the client’s
project completion date precedes the calculated critical path end date, the project has a
negative float. Understanding and managing activities on the critical path are an important
project management skill.
To successfully manage a project, the project manager must also know how to accelerate a
schedule to compensate for unanticipated events that delay critical activities.
Compressing—crashing—the schedule is a term used to describe the techniques used to
shorten the project schedule. During the life of the project, scheduling conflicts often
occur, and the project manager is responsible for reducing these conflicts while
maintaining project quality and meeting cost goals.
More detail on aspects of project scheduling can be found in sections 2.4.5.2 and 2.4.5.3.
2.2. GIS project team roles and responsibilities
Staffing the project with the right skills, at the right place, and at the right time is an important
responsibility of the project management team. The project usually has two types of team
members: functional managers and process managers. The functional managers and team
focus on the technology of the project. On a construction project, the functional managers
would include the engineering manager and construction superintendents. On a training
project, the functional manager would include the professional trainers; on an information
technology project, the software development managers would be functional managers. The
project management team also includes project process managers. The project controls team
would include process managers who have expertise in estimating, cost tracking, planning, and
scheduling. The project manager needs functional and process expertise to plan and execute a
successful project.
Because projects are temporary, the staffing plan for a project typically reflects both the long-
term goals of skilled team members needed for the project and short-term commitment that
reflects the nature of the project. Exact start and end dates for team members are often
negotiated to best meet the needs of individuals and the project. The staffing plan is also
determined by the different phases of the project. Team members needed in the early or
conceptual phases of the project are often not needed during the later phases or project
closeout phases. Team members needed during the implementation phase are often not
needed during the conceptual or closeout phases. Each phase has staffing requirements, and
the staffing of a complex project requires detailed planning to have the right skills, at the right
place, at the right time.
Typically a core project management team is dedicated to the project from start-up to closeout.
This core team would include members of the project management team: project manager,
project controls, project procurement, and key members of the function management or
 experts in the technology of the project. Although longer projects may experience more team
turnover than shorter projects, it is important on all projects to have team members who can
provide continuity through the project phases.
Project team members can be assigned to the project from a number of different sources. The
organization that charters the project can assign talented managers and staff from functional
units within the organization, contract with individuals or agencies to staff positions on the
project, temporarily hire staff for the project or use any combination of these staffing options.
This staffing approach allows the project manager to create the project organizational culture.
Some project cultures are more structured and detail oriented, and some are less structured
with less formal roles and communication requirements. The type of culture the project
manager creates depends greatly on the type of project.
2.3. Communications
Completing a complex project successfully requires teamwork, and teamwork requires good
communication among team members. If those team members work in the same building, they
can arrange regular meetings, simply stop by each other’s office space to get a quick answer, or
even discuss a project informally at other office functions. Increasingly, however, team
members hail from widely separated locations, and face-to-face meetings are replaced by
electronic methods of communicating resulting in so-called virtual teams who may work
synchronously and asynchronously. Communications technologies require a variety of
compatible devices, software, and service providers, and communication with a global virtual
team can involve many different time zones. Establishing effective communications, therefore,
requires a communications plan.
2.4. Project management and system development lifecycles
The Project Management Lifecycle (PMLC) defines how a project is managed effectively and
efficiently from its conceptualization through implementation to its operationalization. A
further term, namely the project lifecycle (PLC) is also used to describe this process. The terms
PMLC and PLC are always used in conjunction with project management but they actually refer
to two relatively distinct sets of concepts and processes. The purpose of a PLC is to describe the
activities that must be completed in order to create a product or a service. The PLC of individual
projects varies from one to another because of the uniqueness of the nature of each project.
The Systems Development Lifecycle (SDLC) and Database Development Lifecycle (DDLC) are
examples of the PLC for GIS implementation projects.
The PLC focuses on the tasks that are necessary for a project. In contrast, the focus of the PMLC
is on how these tasks can be managed. In this regard, the PMLC is more of a conceptual
framework for the systematic application of managerial principles and best practices, rather
than the actual steps of building a product or service. As such, the PMLC remains the same for
all projects regardless of the PLC being employed. This means that while the PLC of a GIS
project is markedly different from that of, for example, a project to build a new highway, the
PMLC for both projects is essentially the same, in terms of the project management cycle or
phases. Throughout the course of every project, the PLC and PMLC work in conjunction with
one another. It is the project manager’s responsibility to ensure all PLC activities use the
conceptual framework of the PMLC.
The Project Management Institute (2013a) groups project activities generally into the five
phases depicted in Figure 3.
 Project Initiation
Identify problem / opportunity Managerial approval
Establish project goal
Define project objectives
Perform cost/benefit analysis
Determine success criteria
List assumptions, risks and obstacles Project Planning
Managerial approval Identify project activities
Estimate resource requirements
Construct workflow
Prepare project proposal

Project Execution
Feedback loop (activated as part
Recruit / organize project team
of change management process)
Establish team operating rules
Assemble project resources
Schedule / execute work plan
Document work progress
Monitoring and Control
Monitor project progress against plan
Establish reporting protocol / procedures
Running in parallel with Install change management procedures
Establish problem resolution mechanism
Revise project plan if necessary
Close-out and Evaluation
Conduct acceptance test
Establish roll out plan / schedule
Complete project documentation Preparing for completion of
Conduct post-implementation audit the project
Complete final project report

Figure 3. The five phases of the project management lifecycle.

This diagram is adapted from the PMBOK Guide (Project Management Institute, 2013a). The
five PMLC phases are essentially sequential in nature. However, there is a feedback loop from
the monitoring and control phase to the planning phase, as noted in Figure 3. This loop can be
followed as many times as is required until the project manager is satisfied that the project is
sufficiently complete for it to be closed out and for the evaluation process to commence.
The duration of each phase and the amount of overlap between sequential phases may vary
considerably depending on the nature of the project, the complexity of the activities in, and
hence the efforts and resources required by individual phases.
The full PMLC starts with the initiation phase that aims to scope the project. The deliverable of
the initiation phase is a document called the project proposal or business case that describes
what problem or opportunity will be addressed by the project, the project goal, and objectives,
the costs incurred and the resulting benefits, how success will be measured, and potential risks
and obstacles that may be encountered.
Once the project proposal has received approval from the management of the organization, the
planning phase commences. The major deliverables and the participating work groups are
identified, and the project team begins to take shape. While most of the activities in this phase
are undertaken by one or a few individuals that will form the core of the project team, it is
common practice to hold a formal planning session for all stakeholders who will affect or be
affected by the project. The deliverable of the planning activities is a detailed project plan that
provides a description of each project activity, the resources required to complete the
 activities, the project schedule, different milestones for the delivery of intermediate results, as
well as the dates for acceptance tests and final delivery of the project products.
The project execution phase, also commonly called the project implementation phase, is
probably the most labor- and resource-intensive phase of the PMLC. This phase usually starts
with the organization of the project team. Members of a typical project team include people
transferred internally from other departments within the organization, new staff hired
specifically for the project, and contract staff from external consulting firms. The actual people
assigned to work on each activity of the project are identified, and detailed descriptions of the
activities are developed, reviewed and signed off. This signifies the actual design, building and
testing of the GIS to be delivered by the project.
The monitoring and control phase begins as soon as the implementation activities have
commenced. It runs in parallel with the project execution phase as a way of quality assurance
and quality control. Generally speaking, change management is the most critical component of
this particular phase, and very clear protocols and procedures must be established to ensure
that when conflicts arise (between users and developers as well as between different users),
the problem(s) can be addressed expediently and effectively. As change requests always have
some impact on the initial time, cost and resource allocation, adjustment to the original project
plan is necessary, and the feedback loop is then activated.
Preparation for the final phase of the project usually starts well ahead of the conclusion of the
execution phase. In this phase, the close-out activities include the installation and testing of the
deliverables, post-implementation audit or evaluation, and the compilation of the final project
report summarizing all project progress reports, acceptance of test results and a brief
description of the lessons learned. The final project report may also include recommendations
to enhance and refine the GIS in response to anticipated changing user needs and
advancements in the technological environment.
2.4.1.Project initiation
The start-up of a project is similar to the start-up of a new organization. The project leader
develops the project infrastructure used to design and execute the project. The project
management team must develop alignment among the major stakeholders on the project
during the early phases or definition phases of the project. Logically, project initiation is
the first phase of the PMLC. In practice, however, project managers actually start at the
end and work backward mentally. Therefore, the discussion of project initiation starts first
by defining the required outputs upon completion of the project, then makes preliminary
estimates of the resources required, and finally develops the strategies required to
construct and deliver the project output on time, within budget and according to
specification.
All projects are created for a reason. Someone identifies a need or an opportunity and
devises a project to address that need. How well the project ultimately addresses that
need defines the project’s success or failure. Often, the pressure to get results encourages
people to go right into identifying possible solutions without fully understanding the need
or what the project is trying to accomplish. This strategy can create a lot of immediate
activity, but it also creates significant chances for waste and mistakes if the wrong need is
addressed. One of the best ways to gain approval for a project is to clearly identify the
 project’s objectives and describe the need or opportunity for which the project will
provide a solution.
Activities in the project initiation phase are conducted mostly by the project manager,
possibly with the aid of one or more systems analysts and application specialists who are
identified as potential members of the future project team. The very first task of project
initiation is to define the goal of the project including the scope of the project in terms of
what is included and what is excluded. Furthermore, the goal statements identify
constraints of time, cost, and specification.
The plan for developing and tracking the detailed schedule, the procurement plan, and the
plan for building the budget and estimating and tracking costs are developed during the
start-up. The plans for information technology, communication, and tracking client
satisfaction are also all developed during the start-up phase of the project. Flowcharts,
diagrams, and responsibility matrices are tools to capture the work processes associated
with executing the project plan. The first draft of the project procedures manual captures
the historic and intuitional knowledge that team members bring to the project. The
development and review of these procedures and work processes contribute to the
development of the organizational structure of the project.
2.4.1.1. Writing a (request for) proposal
GIS projects can be implemented by internal staff or by external consultants either in
total or in part (a process commonly referred to as outsourcing). There are three
common approaches to outsourcing, namely sole source, invitation to tender (ITT)
and request for a proposal (RFP). As the name implies, outsourcing by sole source
means that the entire contract for a project is awarded to a single contractor without
going through a competitive procurement process. When compared with the other
two approaches, sole sourcing is less flexible and not as rigorous a procedure,
although it takes much less time to pick a contractor from a list of contractors of
record and start the project. For public organizations, sole sourcing can be seen as a
form of favoritism, and the decision may be challenged by consultants or companies
who feel that they have not been fairly treated. Hence, sole sourcing should be
avoided except in the cases where the chosen consultant is the only possible
candidate who can supply the material or service required.
An ITT and an RFP are competitive processes with different intents and purposes. An
ITT is used when the organization is absolutely clear what it wants, and how it wants
things to be done. Suppliers or vendors are openly invited to bid for the contract on
the basis of factors such as price and ability to meet the specified requirements. An
ITT is most suitable in situations where the supply of materials (e.g., computers and
peripherals) and the type of services involved are relatively well-defined (e.g., facility
maintenance and security services). An RFP, on the other hand, is used when the
organization knows generally or exactly what it wants, but prefers to seek solutions
from the consulting community. In GIS implementation projects, an RFP is a more
prevalent approach than an ITT in terms of soliciting external consulting services.
An RFP is a relatively complex procurement process that demands considerable
effort and expenditure on both the part of the requesting organization and the
responding consultants. The complexity of an RFP is dependent on its objective and
scope, which may cover all or a substantial part of the project execution activities.
There is no standard procedure for conducting an RFP but the workflow of a typical
RFP exercise starts with the approval of the recommendation in a project proposal to
elicit external work. The project team then prepares the RFP information package for
approval. Since an RFP always ends up with a contract between the organization and
the selected consultant, legal advice must be sought in advance so that the wording
and general content can be reviewed from a legal standpoint, and a sample of the
contract to be signed can be prepared. Any changes that are made to the RFP or the
contract should, of course, be re-scrutinized by legal counsel before either document
is issued and signed off on.
The extent to which individual components are included in the final RFP document
and the steps that are followed in the process of compiling the RFP document is to
some extent a function of the scale of the work that is being called for. Some tasks
are relatively straightforward and have minimal risk associated with them. However,
other tasks and indeed overall projects have considerable risks, especially where
subcontractors may be involved or where the actual configuration of outputs is not
clear at the time of developing the RFP document. In the latter case, care should be
taken not to rush the preparation of the RFP document as errors or omissions that
are made at the stage of the call for work will likely be compounded into the work
that is produced. In the former case, the lines of responsibility for the completion of
any subcontracted work must be made clear in the RFP document and all legal issues
concerning subcontracting must be accounted for.
Writing a well-conceived goal statement requires considerable brainstorming and
discussion with the project sponsor and representatives of potential users of the
resulting GIS. It is sometimes also necessary to research the possible relationships
between the project and legislated responsibilities and regulatory obligations of the
organization, as well as safety and quality standards of the GIS that will result from
the project. Goal statements should be SMART, i.e.:
• Specific, so that any individuals with basic knowledge of the project can
understand the goal(s). The statement should be concise and clear, to avoid
ambiguity or project creep within the context of the project’s activities.
• Measurable, to determine clearly whether particular goal statements were
achieved.
• Agreed upon, by the sponsor and representatives of potential stakeholders.
• Realistic or achievable; this is measured in terms of affordability and fiscal
sustainability, acknowledging technical and political constraints.
• Time-framed, i.e., with a detailed schedule (see section 2.4.5).
A project proposal, also referred to as a project overview statement or project
definition form, is a document that summarizes the findings of the project initiation
phase for approval by senior management of the organization. A Project Business
Case (PBC) form can be developed for this purpose using a template. This approach is
often preferred because a template is easy to create, edit, read and standardize so
 that all projects within the same organization can be presented for management
consideration in the same format.
Alternatively, a Proposed Solution (PS) form can be used for this purpose. The PBC
form contains information that aims to help senior managers understand the
justifications of the project. The information items in the form should be written in
plain and concise business language. The PS form, on the other hand, provides a
clear description of the proposed solutions. If alternative solutions are proposed to
address a particular problem, a clear explanation of the pros and cons of different
approaches as well as the reasons for picking the final choice must be given.
2.4.2.Project planning

Requirements Application
study development

DB conceptual
design

DB logical / Data
physical design acquisition

Database
Search for data Systems testing operationalization
Data loading
resources / integration and roll-out

HW / SW HW / SW
acquisition installation

Research on HW
User training
/ SW advances

Figure 4. Project planning flow chart.

The GIS project set-up entails defining the management structure within which the GIS
project will be executed as depicted in Figure 4. This includes:
2.4.2.1. Project steering group
The GIS project steering group represents the interest of the stakeholders for whom
the system is designed. It should be chaired by the project sponsor and should
include in particular those agents who are funding the system and those who provide
the pertinent (local) data. The role of the GIS project steering group is to provide
guidance to the GIS project team.
2.4.2.2. GIS project team
The GIS project team is in charge of executing the design, development and
installation activities under the guidance of the GIS project steering group. The GIS
steering group selects the project team and receives its reports. The GIS project team
includes at least:
2.4.2.2.1. Project manager
A project manager in charge of the overall coordination of the GIS design,
development, and installation. The project manager is the key person in the
project team. In many large organizations, such as government agencies or
engineering consulting firms, there are professional project managers on the
permanent staff whose job is to lead corporate projects. However, it is
commonplace for organizations to appoint project managers from existing unit
managers or senior IT personnel who have the training and experience to
assume such a job function. All project managers are expected to be strategic
in their thinking, tactful in dealing with people, and knowledgeable in the
business area served by the project. The project manager serves as the chief
executive officer of a project. He or she is the technical advisor to the project
sponsor, mentor and supervisor of members of the project team, and
representative of the project when dealing with internal and external
stakeholders. The project manager usually has to work closely with members of
the IT department to ensure adherence to corporate standards, protocols, and
resource sharing policies.
It is the responsibility of the project manager to recruit members for the
project team and organize them into a coherent working group. Team
members can be co-opted from internal staff, or hired externally on a
contractual or permanent basis if internal expertise is not available. The
number of members of a project team varies according to the nature of a
particular project. However, it is essential to recruit and choose team members
with the understanding that they have collectively all of the necessary skills
that are required to complete the project successfully. For large-scale GIS
implementation projects, it is helpful to divide the team into small working
groups, each headed by an experienced technical lead, such as map data
conversion and acquisition, database design and system development, quality
assurance and control, and end-user training. This makes the team more
manageable and creates a clear sense of accountability and responsibility.
Experience has shown that while recruiting is seldom a problem, organizing
members into a coherent high-performance team can be problematic. It is a
real challenge for the project manager to use his or her people skills to ensure
the commitment of the members to the project (i.e., their other competing
duties or tasks will not negatively impact on the project). The project manager
must also keep motivating team members continuously throughout the course
of the project by mentoring team members, practicing open communication,
giving mutual understanding and respect, recognizing achievements, as well as
using disciplinary actions where and if necessary.
 2.4.2.2.2. Other team members
Corporate
management

Clients / Project
end users sponsor

Representatives Project Corporate IT

of clients and manager department
end users

Application Facility GIS Corporate DB

specialists planner(s) specialists administrator

Figure 5. Organigram of a GIS project and its setting in a larger organizational

context.

As such a project team has to fit into the larger organization context, an
organizational chart as depicted in Figure 5 is helpful for all stakeholders:
• Application specialists
• A database architect
• Software programmer(s)
• Independent validation team members
2.4.2.3. Defining the project scope
The project scope is prepared by the GIS project team and describes all tasks to be
carried out in relation to the design, development and installation of the GIS. The
scope has to be approved by the GIS project steering group during a kick-off meeting
between the project team and the project steering group. See also section 2.1.2 for
more on the project scope.
2.4.2.4. Sequencing of project tasks
The aim of the project work plan is to determine the most efficient order for the
tasks by maximizing the use of resources. This is usually accomplished by having
more than one task in progress at the same time and by preventing the delay of any
given task from holding up the start of another task. The concept of “precedence
relationships” between individual tasks is the governing principle for project
scheduling. This concept identifies tasks either as “dependent” or “independent”.
Dependent tasks are those that cannot proceed until another task is completed,
whereas independent tasks are those that can be carried out any time during the
course of project execution. As noted earlier, an effective way of project scheduling
is to consider the project from the end point and work backward to the starting
point. In this way, it is relatively easy to identify those tasks that must be completed
prior to the commencement of their respective predecessors. A complex project is
made manageable by first breaking it down into individual components in a
 hierarchical structure, introduced as the work breakdown structure or the WBS in
2.1.6.
A commonly used tool to list out all the phases, activities and tasks is the Gantt chart.
It also illustrates estimates of how long each should take and the dates tasks should
begin and end. A PERT chart displays the tasks in a project along with the
dependencies between these tasks. Using a PERT chart is a great way to define and
display the dependency relationships that exist between tasks. The Pert Chart is used
to document and track the critical path of the project; i.e., what essential tasks must
get done in exactly what order to successfully complete the project. Section 2.4.5.3
provides further details on such scheduling tools
Another essential component of the project plan is the identification of resources
required for each task. The project team should first identify the type of resources
needed, and then estimate the cost for that particular task. Cost can be estimated in
one of two ways, namely a fixed cost (e.g., $5,000 per year for a multi-user software
license) or a variable cost (e.g., 50 hours of initial Java programming and 20 hours or
less of additional programming work per year for maintenance and update). The
project team should carefully consider the matching of available resources and
estimated resources. If for example, a particular task requires skills that are not
found among project team members, then arrangements must be made for outside
assistance. This may necessitate amendments to estimated time and costs, and the
project plan must be adjusted accordingly.
2.4.2.5. Project requirements
2.4.2.5.1. Requirement engineering
The first step after defining the scope of the project is to conduct a needs
assessment. During this task, the GIS project team reviews, and details the user
requirements provided in the preliminary analysis and derives a consolidated
set of products and system requirements, including functional needs, data
needs and processing needs. While these all flow into the technical
specifications of the next section, it is important to integrate existing user
practices. Because the incorporation of a new system may alter or conflict with
existing systems and procedures at the level of user organizations, the linkage
between the future GIS and existing systems and procedures at the level of the
user organizations has been adequately examined. Recommendations to re-
engineer these existing systems and procedures are formulated on the basis of
a detailed analysis of the current working procedures. The results of this task
are reported in a document called Requirements Baseline (RB).
2.4.2.5.2. Technical specifications
In response to the consolidated user requirements, the GIS project team
provides a technical answer to the requirements baseline with a detailed and
complete specification of the products information system expected. The
results of this activity are reported in a Technical Specifications document and
an associated Inventory of Existing Datasets, Design Justification Report and
Data Model Report.
 The DJR assembles analyses performed by the GIS project team on all
implementation choices for proposed GIS. It describes, in particular, all trade-
offs, design choice justifications, feasibility analysis, make-or-buy decisions and
supporting technical assessments done during the software development.
Ideally, the data model report is developed in accordance with the
requirements of the ISO 19000 series and here, in particular. This includes, in
particular, the adoption of the ISO 19104 terminology, the development of
data model using the Universal Modelling Language (UML), and the adoption of
ISO 19115 requirements for metadata modeling.
2.4.2.5.3. System qualification planning
This planning process is a response to the Requirements Baselines and includes
a “scientifically sound” validation protocol for all products to be generated by
the information system, including the description of all ground and ancillary
data available. Problems, such as lack of insufficient validation data need to be
investigated, the impact assessed and the solutions identified. The results of
this task recorded in a System Qualification Plan (SQP).
2.4.2.6. Comparing options using a weighted decision matrix
Sometimes, there are multiple options to choose from when determining
requirements and deciding which project to work on. One of the preferred tools to
select the best option is a weighted decision matrix, which is a simple form of linear
programming. A basic decision matrix consists of establishing a set of criteria for
options that are scored and summed to gain a total score that can then be ranked.
Importantly, it is not weighted to allow a quick selection process.
A weighted decision matrix operates in the same way as the basic decision matrix but
introduces the concept of weighting the criteria in order of importance. The resultant
scores reflect better the importance to the decision maker of the criteria involved.
The more important a criterion, the higher the weighting it receives. Each of the
potential options is scored and then multiplied by the weighting given to each of the
criteria to produce a result.
The advantage of the weighted decision matrix is that subjective opinions about one
alternative versus another can be made more objective. Another advantage of this
method is that sensitivity studies can be performed.
2.4.2.7. Financial considerations
In many new project endeavors, it is important to find out if the project is financially
feasible. Measures for such determination include the net present value (NPV), the
rate of return (ROI), and payback analysis.
2.4.2.7.1. Net present value
A dollar earned today is worth more than a dollar earned one or more years
from now. The NPV of a time series of cash flows, both incoming and outgoing,
is defined as the sum of the present values (PVs) of the individual cash flows of
the same entity.
In the case when all future cash flows are incoming and the only outflow of
cash is the purchase price, the NPV is simply the PV of future cash flows minus
the purchase price (which is its own PV). NPV is a standard method for using
 the time value of money to appraise long-term projects. Used for capital
budgeting and widely used throughout economics, finance, and accounting, it
measures the excess or shortfall of cash flows, in present value terms, once
financing charges are met. NPV can be described as the “difference amount”
between the sums of discounted cash inflows and cash outflows. It compares
the present value of money today to the present value of money in the future,
taking inflation and returns into account. The NPV of a sequence of cash flows
takes as input the cash flows and a discount rate or discount curve and outputs
a price. Each cash inflow/outflow is discounted back to its present value (PV).
Then they are summed. Therefore, NPV is the sum of all terms.
NPV is an indicator of how much value an investment or project adds to the
firm. With a particular project, if NPV is a positive value, the project is in the
status of positive cash inflow in the time t. If NPV is a negative value, the
project is in the status of discounted cash outflow in the time t. Sometimes,
risky projects with a positive NPV could be accepted. This does not necessarily
mean that they should be undertaken since NPV at the cost of capital may not
account for opportunity cost (i.e., comparison with other available
investments).
2.4.2.7.2. Return on investment
Return on Investment is a performance measure used to evaluate the efficiency
of an investment or to compare the efficiency of a number of different
investments. It is one way of considering profits in relation to capital invested.
This is calculated by subtracting the project’s costs from the benefits and then
dividing by the costs. Return on investment studies of GIS projects are a
relatively new field of academic research. The URISA Journal devoted an issue
of its 2015 volume to this topic (URISA Journal 27/1).
2.4.2.7.3. Payback analysis
Payback analysis is important in determining the amount of time it will take for
a project to recoup its investments. This is the point at which the benefits start
to outweigh the costs. The best way to see that is by charting the cumulative
benefits and costs.
2.4.3.SCRUM development overview
“Scrum” is formal project management/product development methodology and part of
agile project management. Scrum is a term from rugby (scrimmage) that means a way of
restarting a game. It’s like restarting the project efforts every X weeks. It is based on the
idea that it is impossible to plan the whole project up front; therefore, a good program
manager starts by building on empirical data, and then re-plan and iterate from there.
Scrum uses sequential sprints for development. Sprints are like small project phases
(ideally two to four weeks). The idea is to take one day to plan for what can be done now,
then develop what was planned for, and demonstrate it at the end of the sprint. Scrum
uses a short daily meeting of the development team to check what was done yesterday,
what is planned for the next day, and what if anything is impeding the team members
from accomplishing what they have committed to. At the end of the sprint, what has been
demonstrated can then be tested, and the next sprint cycle starts.
 2.4.3.1. SCRUM roles
Scrum methodology defines several major roles. They are:
Product owners: essentially the business owner of the project who knows the
industry, the market, the customers, and the business goals of the project. The
product owner must be intimately involved with the Scrum process, especially the
planning and the demonstration parts of the sprint.
Scrum Master: somewhat like a project manager, but not exactly. The Scrum
Master’s duties are essentially to remove barriers that impede the progress of the
development team, teach the product owner how to maximize return on investment
(ROI) in terms of development effort, facilitate creativity and empowerment of the
team, improve the productivity of the team, improve engineering practices and tools,
run daily standup meetings, track progress, and ensure the health of the team.
Development team: self-organizing (light-touch leadership), empowered group; they
participate in planning and estimating for each sprint, do the development, and
demonstrate the results at the end of the sprint. The development team can be
broken into “teamlets” that “swarm” on user stories, which are created in the sprint
planning session.
Planning meetings for each sprint require participation by the product owner, the Scrum
Master, and the development team. In the planning meeting, they set the goals for the
upcoming sprint and select a subset of the product backlog to work on. The development
team decomposes these into tasks and estimates them. The development team and
product owner do final negotiations to determine the backlog for the following sprint.
The Scrum methodology has its own set of metrics to help with future planning and
tracking of progress.
2.4.4.System prototyping
The objective of this phase is to prototype the GIS project and to demonstrate a
preliminary compliance with the consolidated user requirements by executing a
representative set of the products to be routinely generated by the future system. The
system prototype does not feature the entire range of requirements which have been
identified in the requirement consolidation but should be complete enough to allow a
proper demonstration of the products to the GIS project steering group and to justify its
authorization to proceed.
2.4.4.1. Software prototype design
During this task, the GIS project team documents all architectural software elements
of the GIS following the instructions of the Design Justification Report (DJR) and the
Data Model Report (DMR). Moreover, this design task also lists and details all
verification test procedures for the validation of the different modules. The results of
this task are reported in a Design Definition Report (DDR), a Data Model
Implementation Report (DIR), and a Verification Test Procedures (VTP).
2.4.4.2. Software prototype development
This task encompasses the effective coding of the different software modules
identified and their preliminary integration into a GIS software prototype. The output
of this task is the GIS software prototype.
 2.4.4.3. Sample data acquisition
In order to test the GIS prototype and to check its ability to generate products
conform to the requirements baseline and technical specifications to verify that
products generated, sample data needs to be acquired. These data are used for the
execution of sample products (see next paragraph) and have to conform to the input
data types required by the technical specifications.
2.4.4.4. Sample product execution
On the basis of the GIS software prototype, the project team implements a sample
production. The outputs of this task are sample products generated by the GIS
software prototype.
2.4.5.Project execution and control
Project implementation (or project execution) is the third phase of the project
management lifecycle, where visions and plans become reality. This is the logical
conclusion, after evaluating, deciding, visioning, planning, applying for funds and finding
the financial resources of a project. The implementation phase involves putting the project
plan into action. It’s here that the project manager will coordinate and direct project
resources to meet the objectives of the project plan. As the project unfolds, it’s the project
manager’s job to direct and manage each activity, every step of the way. The better the
original plan, the easier it will be for the project manager to handle any problems that
come up.
It is important to take into account that independently of the nature of the project,
implementation takes time, usually more than it is planned and that many external
constraints can appear, which should be considered when initiating the implementation
step, such as for example, the seasonality in the availability of community engagement /
resources).
“The basic requirement for starting the implementation process is to have the work plan
ready and understood by all the actors involved. Technical and non-technical requirements
have to be clearly defined and the financial, technical and institutional frameworks of the
specific project have to be prepared considering the local conditions. The working team
should identify their strengths and weaknesses (internal forces), opportunities and threats
(external forces). The strengths and opportunities are positive forces that should be
exploited to efficiently implement a project. The weaknesses and threats are hindrances
that can hamper project implementation. The implementers should ensure that they devise
means of overcoming them. Another basic requirement is that the financial, material and
human resources are fully available for the implementation” (NETSSAF 2008). Other
actions need to be taken before work can begin to implement the detailed action plan,
including:
• Scheduling activities and identifying potential bottlenecks.
• Communicating with the members of the team and ensuring all the roles and
responsibilities are distributed and understood.
• Providing for project management tools to coordinate the process.
• Ensuring that the financial resources are available and distributed accordingly.
The implementation phase is where the project team actually does the project work to
produce the deliverables. The word “deliverable” means anything the project delivers,
 including all of the products or services and last but not least the documentation of these
deliverables. The steps undertaken to build each deliverable will vary depending on the
type of project, and cannot, therefore, be described here in any real detail. For instance,
engineering and telecommunications projects will focus on using equipment, resources,
and materials to construct each project deliverable, whereas computer software projects
may require the development and implementation of software code routines to produce
each project deliverable. The activities required to build each deliverable will be clearly
specified within the project requirements document and project plan.
Beyond mere direction of the work and delivery of results, it is the job of the project
manager is to also keep track of how the project team performs. The implementation
phase keeps the project plan on track with careful monitoring and control processes to
ensure the final deliverable meets the acceptance criteria set by the customer. This phase
is typically where approved changes are implemented.
Most often, changes are identified by looking at performance and quality control data.
Routine performance and quality control measurements should be evaluated on a regular
basis throughout the implementation phase. Gathering reports on those measurements
will help to determine where the problem is and recommend changes to fix it.
2.4.5.1. Project charter
A project charter, project definition, or project statement is a statement of the
scope, objectives, and participants in a project. It provides a preliminary delineation
of roles and responsibilities, outlines the project objectives, identifies the main
stakeholders, and defines the authority of the project manager. It serves as a
reference of authority for the future of the project. The purpose of a project charter
is to:
• Provide an understanding of the project, the reason it is being conducted, and
its justification
• Establish early on in the project the general scope
• Establish the project manager and his or her authority level. A note of who will
review and approve the project charter must be included.
2.4.5.2. Project schedule planning
In order to develop our schedule, we first need to define the activities, sequence
them in the right order, estimate the resources needed, and estimate the time it will
take to complete the tasks.
The activity definition process is a breakdown of the project into work package
elements. It documents the specific activities needed to fulfill the deliverables
detailed in the project plan. These activities are not the deliverables themselves but
the individual units of work that must be completed to fulfill the deliverables.
Activity definition uses everything we already know about the project to divide the
work into activities that can be estimated.
Expert judgment in the form of project team members with prior experience
developing project scope statements can help to define activities. They may be
employed to review an activity list created by the project manager, or they could be
involved from the very beginning.
 Once the activity definitions for the work packages have been completed, the next
task is to complete the activity list. The project activity list is a list of everything that
needs to be done to complete the project, including all the activities that must be
accomplished to deliver each work package. The next step is to define the activity
attributes starting with a description of each activity and determining the sequence
of the work. Any predecessor activities, successor activities, or constraints should be
listed in the attributes along with descriptions as well as any other information about
resources or time.
All of the important checkpoints of the project are tracked as milestones. Some of
them could be listed in a contract as requirements of successful completion; some
could just be significant points in the project that the manager wants to keep track
of. The milestone list needs to let everyone know which milestones are required and
which are not.
2.4.5.3. Scheduling tools
For all but the smallest projects, it is useful to familiarize oneself with scheduling
tools. The following paragraphs provide a brief introduction to four of them.
2.4.5.3.1. Gantt chart
A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt
charts are easy to read and are commonly used to display schedule activities.
These charts display the start and finish dates of the terminal elements and
summary elements of a project. Terminal elements and summary elements
comprise the work breakdown structure of the project. Some Gantt charts also
show the dependency relationships (i.e., precedence network) between
activities.
Gantt charts show all the key stages of a project and their duration as a bar
chart, with the time scale across the top. The key stages are placed on the bar
chart in sequence. A Gantt chart can be drawn quickly and easily and is often
the first tool a project manager uses to provide a rough estimate of the time
that it will take to complete the key tasks. Sometimes it is useful to start with
the target deadline for completion of the whole project because it is soon
apparent if the time scale is too short or unnecessarily long. The detailed Gantt
chart is usually constructed after the main objectives have been determined.
2.4.5.3.2. Network diagrams
Many project managers use network diagrams when scheduling a project. The
network diagram is a way to visualize the interrelationships of project activities.
Network diagrams provide a graphical view of the tasks and how they relate to
one another. The tasks in the network are the work packages of the project. All
tasks must be included in the network because they have to be accounted for
in the schedule. Leaving even one task out of the network could change the
overall schedule duration, estimated costs, and resource allocation
commitments. The first step is to arrange the tasks into a sequence. Some tasks
can be accomplished at any time throughout the project where other tasks
depend on input from another task or are constrained by time or resources.
The network diagram provides important information to the project team. It
 provides information about how the tasks are related, where the risk points are
on the schedule, how long it will take as currently planned to finish the project,
and when each task needs to begin and end.
2.4.5.3.3. PERT
Another way to show how tasks relate is with the activity-on-arrow (AOA)
diagram. Although AON is more commonly used and is supported by all project
management programs, PERT is the best-known AOA-type diagram and is the
historical basis of all network diagramming. The main difference is the AOA
diagram is traditionally drawn using circles as the nodes, with nodes
representing the beginning and ending points of the arrows or tasks. In the
AOA network, the arrows represent the activities or tasks.
2.4.5.3.4. Critical path
The critical path describes the sequence of tasks that would enable the project
to be completed in the shortest possible time. It is based on the idea that some
tasks must be completed before others can begin. A critical path diagram is a
useful tool for scheduling dependencies and controlling a project. In order to
identify the critical path, the length of time that each task will take must be
calculated.
2.4.6.Resource planning
Another essential component of the project plan is the identification of resources required
for each task. The project team first identifies the type of resources needed, and then
estimates the cost for that particular task. Cost can be estimated in one of two ways,
namely a fixed cost (e.g., $5000.00 per year for a multi-user software license) or a variable
cost (e.g., 50 hours of initial Java programming and 20 hours or less of additional
programming work per year for maintenance and update).
Resources are people, equipment, place, money, or anything else that needed to perform
all the planned activities. Every item on the activity list needs to have resources assigned
to it. Before resources can be assigned to a project, one need to determine their
availability. Resource availability includes information about what resources are necessary
when they’re available and the conditions of their availability. If for example, a particular
task requires skills that are not found among project team members, then arrangements
must be made for outside assistance. This may necessitate amendments to estimated time
and costs, and the project plan must be adjusted accordingly. It is important to schedule
some resources such as consultants or training rooms way in advance, as they might be
available only at certain times.
This resource estimation is the basis for determining how long each activity will take, a
process known as activity duration estimation, where the project manager identifies how
long it takes to perform each activity, starting with the information about that activity and
the resources that are assigned to it, and then working with the project team to come up
with an estimate.
2.4.7.Procurement management
The procurement effort on projects varies widely and depends on the type of project.
Often the client organization will provide procurement services on less complex projects.
In this case, the project team identifies the materials, equipment, and supplies needed by
the project and provides product specifications and a detailed delivery schedule. When the
procurement department of the parent organization provides procurement services, a
liaison from the project can help the procurement team better understand the unique
requirements of the project and the time-sensitive or critical items of the project schedule.
On larger, more complex projects, personnel is dedicated to procuring and managing the
equipment, supplies, and materials needed by the project. Because of the temporary
nature of projects, equipment, supplies, and materials are procured as part of the product
of the project or for the execution of the project. In GIS projects, we distinguish data,
functional, and processing needs:
Data needs:
• Every GIS project requires a data inventory
• This needs to be broken down into which maps or data are important for
successful completion of each function in the unit
• Data is rarely perfect; It is hence important to describe problems of current data
and point out future needs as well
• Although maps are usually the final output of a GIS project, creating a map
inventory form will help clarify issues involved in map use down the road
Functional needs:
• Identify activities which an organization performs to carry out its mission
• Identify all of their organizational units
• List the functions that require maps or other geographic information. Huxhold
(1996) has a nice overview list of functions requiring geographic information by
department and function.
Processing needs:
• Define how the data are to be used to fulfill the functional needs of the
organization
• An application definition form contains data input requirements, processing
requirements, and output products
More complex projects will typically procure through different acquisition and
management methods. Commodities are common products that are purchased based on
the lowest bid. Commodities include items like concrete for building projects, office
supplies, or even lab equipment for a research project. The second type of procurement
includes products that are specified for the project. Vendors who can produce these
products bid for a contract. The awarding of a contract can include price, ability to meet
the project schedule, the fit for the purpose of the product, and other considerations
important to the project. These vendors’ performances become important parts of the
project, and the project manager assigns resources to coordinate the work and schedule of
the vendor. The third procurement approach is the development of one or more partners.
A design firm that is awarded the design contract for a major part of an airport and a
research firm that is conducting a study of passenger flows are examples of potential
project partners. A partner contributes to and is integrated into the execution plan.
Partners perform best when they share the project vision of success and are emotionally
invested in the project. The project management team builds and implements a project
 procurement plan that recognizes the most efficient and effective procurement approach
to support the project schedule and goals.
Procurement management follows a logical order starting with a plan for the whole
project. Before doing anything else, it is important to identify all of the work that will be
contracted out so that one can plan for any purchases and acquisitions. For each of these
items, one then needs to set up the contract, identify the metrics that will be used need to
meet to determine that the work is considered successful, pick a seller, and have a process
in place to administer the contract once the work is happening.
The procurement management plan details how the procurement process will be
managed. It includes the following information:
• The types of contracts and any metrics that will be used to measure the
contractors’ performance
• The planned delivery dates for the work or products
• The company’s standard documents
• The number of vendors or contractors involved and how they will be managed
• How purchasing may impact the constraints and assumptions of the project plan
• The coordination of purchasing lead times with the development of the project
schedule
• The identification of prequalified sellers (if known)
The procurement management plan, like all other management plans, becomes a
subsidiary of the project management plan. Some tools and techniques used during the
procurement planning stage include make-or-buy analysis and definition of the contract
type.
2.4.7.1. Spatial data acquisition and evaluation
During this task, the complete set of input data identified in the requirements
baseline and technical specifications (see section 2.4.4.3) is actually acquired. If data
acquisition turns out to be a complex or long-term task (e.g. programming of aerial
photograph or Lidar surveys), it is recommended to establish first a data acquisition
plan. Data acquisition is often regarded as the most challenging and expensive part
of a GIS project. However, maintaining data quality through the lifecycle of a
database system can, in total, create greater challenges and be even more
expensive. Spatial data are much more readily available now than ever before. With
the construction of global and national geospatial data infrastructures, data
warehouses and Web-based information dissemination technologies, GIS projects
now rely more on third-party data than on internal data conversion. New data
collection technologies are now able to capture spatial data directly in digital form
quickly and with a higher degree of accuracy than in the past. As a result, the focus of
data in GIS projects has moved from acquisition to quality or usability. However, up
to now greater data availability has not necessarily been translated into higher
usability and, therefore, data and data quality remain mission-critical issues in GIS
projects and the compliance of all input data delivered with their technical
specifications needs to be checked (see section 2.4.12 further down).
2.4.7.2. Technology acquisition and evaluation
Technology acquisition and evaluation is a relatively straightforward process when
compared with data acquisition and evaluation. Technology, in this case, refers to
computer hardware, software, and local and wide area networks, together with
related peripherals and supplies. In many organizations, GIS must be implemented
using corporate architectures and standards. Therefore, a GIS project team is often
more concerned with the evaluation of the suitability of corporate resources
specifically for spatial applications, than with their acquisition.
Developing a technology evaluation plan is a relatively complex task. It normally
starts with a review of a user requirements study that seeks to identify both the
hardware, software and network needs of the deliverables of the project. The project
team then identifies the key features of these relative to the generation of the
deliverables. These features are progressively broken down into further levels of
detail and recorded in a software evaluation manual that is regularly updated during
the process of development. The features to be evaluated are assigned either as a
“must” or “should” requirement to indicate their relative significance in the
evaluation process.
In the evaluation process, potential vendors are required to supply in detail specific
information about each of the features of their products that are to be evaluated.
The project team then reviews the completed product evaluations and shortlists the
four or five best submissions that are deemed to meet the requirements of the
project.
2.4.7.3. HR planning
The most important resource to a project is its people—the project team. Projects
require specific expertise at specific moments in the schedule, depending on the
milestones being delivered or the given phase of the project. An organization can
host several strategic projects concurrently over the course of a budget year, which
means that its employees can be working on more than one project at a time.
Alternatively, an employee may be seconded away from his or her role within an
organization to become part of a project team because of a particular expertise.
Moreover, projects often require talent and resources that can only be acquired via
contract work and third party vendors. Procuring and coordinating these human
resources, in tandem with managing the time aspect of the project, is critical to the
overall success.
Through performance evaluation, the manager will get the information needed to
ensure that the team has adequate knowledge, to establish a positive team
environment and a healthy communication climate, to work properly, and to ensure
accountability. Managing the project team includes an appraisal of employee
performance and project performance. The performance reports provide the basis
for managerial decisions on how to manage the project team.
Working with other people involves dealing with them both logically and
emotionally. A successful working relationship between individuals begins with
appreciating the importance of emotions and how they relate to personality types,
leadership styles, negotiations, and setting goals. Emotions are both a mental and
 physiological response to environmental and internal stimuli. Leaders need to
understand and value their emotions to appropriately respond to the client, project
team, and project environment.
The Myers-Briggs Type Indicator (MBTI) is one of most widely used tools for
exploring personal preference, with more than two million people taking the MBTI
each year. The MBTI is often referred to as simply the Myers-Briggs. It is a tool that
can be used in project management training to develop awareness of preferences for
processing information and relationships with other people.
On larger, more complex projects, some project managers will use the Myers-Briggs
as a team-building tool during project start-up. This is typically a facilitated work
session where team members take the Myers-Briggs and share with the team how
they process information, what communication approaches they prefer, and what
decision-making preferences they have. This allows the team to identify potential
areas of conflict, develop communication strategies, and build an appreciation for
the diversity of the team.
No particular leadership approach is specifically appropriate for managing a project.
Due to the unique circumstances inherent in each project, the leadership approach
and the management skills required to be successful vary depending on the
complexity profile of the project. However, the Project Management Institute
published Shi and Chen’s (2006) research that studied project management
leadership traits and concluded that good communication skills and the ability to
build harmonious relationships and motivate others are essential. Beyond this broad
set of leadership skills, the successful leadership approach will depend on the profile
of the project. For example, a transactional project manager with a strong command-
and-control leadership approach may be very successful for a small software
development project or a construction project, where tasks are clear, roles are well
understood, and the project environment is cohesive. This same project manager is
less likely to be successful on a larger, more complex project with a diverse project
team and complicated work processes.
Matching the appropriate leadership style and approach to the complexity profile of
the project is a critical element of project success. Even experienced project
managers are less likely to be successful if their leadership approach does not match
the complexity profile of the project.
2.4.8.Budget planning
Every project boils down to money. If there was a bigger budget, one could probably get
more people to do the project more quickly and deliver more. That’s why no project plan
is complete without a budget. Regardless of the size of the project, and no matter how
many resources and activities are in it, the process of figuring out the bottom line is always
the same. It is important to come up with detailed estimates for all the project costs. Once
this is compiled, all the cost estimates are combined into a budget plan.
2.4.8.1. Cost estimation techniques
It is now possible to track the project according to that budget while the work is
ongoing. Here are some tools and techniques for estimating cost:
 2.4.8.1.1. Resource cost rates
People who will be working on the project all work at a specific rate. Any
materials used to build the project (e.g., wood or wiring) will be charged at a
rate too. Determining resource costs means figuring out what the rate for labor
and materials will be.
2.4.8.1.2. Vendor bid analysis
Sometimes, it is necessary to work with an external contractor to get the
project done. One might even have more than one contractor bid on the job.
This tool is about evaluating those bids and choosing the winner.
2.4.8.1.3. Reserve analysis
Most projects have cost overruns. If the risk of something expensive happening
is known ahead of time, it is better to have some cash available to deal with it.
Reserve analysis means putting some cash away in the case of overruns.
2.4.8.1.4. Cost of quality
Figure 1 alluded to the balance between costs and quality. A good project
manager will weigh the cost of all quality-related activities into the overall
budget. As it is cheaper to find bugs earlier in the project than later, there are
always quality costs associated with everything a project produces. The cost of
quality is a way of tracking the cost of those activities.
2.4.8.2. Managing the budget
An activity can have costs from multiple vendors in addition to internal costs for
labor and materials. Detailed estimates from all sources can be reorganized so those
costs associated with a particular activity can be grouped by adding the activity code
to the detailed estimate. The detailed cost estimates can be sorted and then
subtotaled by activity to determine the cost for each activity.
2.4.8.2.1. Managing the cash flow
If the total amount spent on a project is equal to or less than the amount
budgeted, the project can still be in trouble if the funding for the project is not
available when it is needed. There is a natural tension between the financial
people in an organization, who do not want to pay for the use of money that is
just sitting in a checking account, and the project manager, who wants to be
sure that there is enough money available to pay for project expenses. The
financial people prefer to keep the company’s money working in other
investments until the last moment before transferring it to the project account.
The contractors and vendors have similar concerns, and they want to get paid
as soon as possible so they can put the money to work in their own
organizations. The project manager would like to have as much cash available
as possible to use if activities exceed budget expectations.
2.4.8.2.2. Contingency reserves
Most projects have something unexpected occur that increases costs above the
original estimates. If estimates are rarely exceeded, the estimating method
should be reviewed because the estimates are too high. It is impossible to
predict which activities will cost more than expected, but it is reasonable to
 assume that some of them will. Estimating the likelihood of such events is part
of the risk analysis discussed above.
Instead of overestimating each cost, money is budgeted for dealing with
unplanned but statistically predictable cost increases. Funds allocated for this
purpose are called contingency reserves. Because it is likely that this money will
be spent, it is part of the total budget for the project. If this fund is adequate to
meet the unplanned expenses, then the project will complete within the
budget.
2.4.8.2.3. Management reserves
If something occurs during the project that requires a change in the project
scope, money may be needed to deal with the situation before a change in
scope can be negotiated with the project sponsor or client. It could be an
opportunity as well as a challenge. For example, if a new technology were
invented that would greatly enhance the completed project, there would be
additional cost and a change to the scope, but it would be worth it. Money can
be made available at the manager’s discretion to meet needs that would
change the scope of the project. These funds are called management reserves.
Unlike contingency reserves, they are not likely to be spent and are not part of
the project’s budget baseline, but they can be included in the total project
budget.
2.4.8.3. Evaluating the budget
A project manager must regularly compare the amount of money spent with the
budgeted amount and report this information to managers and stakeholders. It is
necessary to establish an understanding of how this progress will be measured and
reported.
2.4.8.3.1. Earned value analysis
A method that is widely used for medium- and high-complexity projects is the
earned value management (EVM) method. EVM is a method of periodically
comparing the budgeted costs with the actual costs during the project. It
combines the scheduled activities with detailed cost estimates of each activity.
It allows for partial completion of an activity if some of the detailed costs
associated with the activity have been paid but others have not.
The budgeted cost of work scheduled (BCWS) comprises the detailed cost
estimates for each activity in the project. The amount of work that should have
been done by a particular date is the planned value (PV). These terms are used
interchangeably by some sources, but the planned value term is used in
formulas to refer to the sum of the budgeted cost of work up to a particular
point in the project, so we will make that distinction in the definitions in this
text for clarity.
The budgeted cost of work performed (BCWP) is the budgeted cost of work
scheduled that has been done. The sum of BCWP values up to that point in the
project schedule is the earned value (EV). The amount spent on an item is often
more or less than the estimated amount that was budgeted for that item. The
actual cost (AC) is the sum of the amounts actually spent on the items.
 2.4.8.3.2. Schedule variance
The project manager must know if the project is on schedule and within the
budget. The difference between planned and actual progress is the variance.
The schedule variance (SV) is the difference between the earned value (EV) and
the planned value (PV). Expressed as a formula, SV = EV − PV. If less value has
been earned than was planned, the schedule variance is negative, which means
the project is behind schedule.
The schedule variance and the cost variance provide the amount by which the
spending is behind (or ahead of) schedule and the amount by which a project is
exceeding (or not fully using) its budget. They do not give an idea of how these
amounts compare with the total budget.
The ratio of earned value to planned value gives an indication of how much of
the project is completed. This ratio is the schedule performance index (SPI).
The formula is SPI = EV/PV. An SPI value less than 1 indicates the project is
behind schedule. The ratio of the earned value to the actual cost is the cost
performance index (CPI). The formula is CPI = EV/AC.
2.4.8.4. Estimated cost to complete the project
Part way through the project, the manager evaluates the accuracy of the cost
estimates for the activities that have taken place and uses that experience to predict
how much money it will take to complete the unfinished activities—the estimate to
complete (ETC).
To calculate the ETC, the manager must decide if the cost variance observed in the
estimates to that point are representative of the future. For example, if unusually
bad weather causes increased cost during the first part of the project, it is not likely
to have the same effect on the rest of the project. If the manager decides that the
cost variance up to this point in the project is atypical—not typical—then the
estimate to complete is the difference between the original budget for the entire
project—the budget at completion (BAC)—and the earned value (EV) up to that
point. Expressed as a formula, ETC = BAC − EV.
If the manager decides that the cost variance is caused by factors that will affect the
remaining activities, such as higher labor and material costs, then the estimate to
complete (ETC) needs to be adjusted by dividing it by the cost performance index
(CPI). For example, if labor costs on the first part of a project are estimated at
$60,000 (EV) and they actually cost $63,000 (AC), the cost performance (CPI) will be
0.95. (Recall that the CPI = EV/AC).
To calculate the estimate to complete (ETC), assuming the cost variance on known
activities is typical of future cost, the formula is ETC = (BAC – EV)/CPI. If the budget at
completion (BAC) of the project is $600,000, the estimate to complete is ($600,000 –
$60,000)/0.95 = $568,421.
2.4.8.5. Estimate final project cost
If the costs of the activities up to the present vary from the original estimates, this
will affect the total estimate of the project cost. The new estimate of the project cost
is the estimate at completion (EAC). To calculate the EAC, the estimate to complete
 (ETC) is added to the actual cost (AC) of the activities already performed. Expressed
as a formula, EAC = AC + ETC.
2.4.9.Cost benefit analysis
Many organizations require a cost-benefit analysis to be conducted as part of the project
initiation process. Cost-benefit analysis, also called investment analysis, is based on the
realization that justification for investments is best made when accompanied by some
level of analysis of the associated costs and benefits both of the investment itself and its
returns over a relevant time frame. In addition to providing a framework for planning, a
cost-benefit analysis provides some assurance of the prudence of the initial capital
expenditures on the project and the long-term support and maintenance costs of the
resulting GIS.
However, as a project management instrument, cost-benefit analyses are often imprecise
because they do not account for many of the non-monetarized subtleties and complexities
that surround GIS projects. Cost-benefit analysis is particularly difficult in the case of
largescale spatial data infrastructure projects that take several years to complete.
Although the costs of information technology are relatively easy to measure and account
for, the benefits side of the equation is difficult to formulate. This is because many
significant benefits are intangible (e.g., improving the integrity of land tenure systems,
better stewardship of the environment, and increasing public awareness of and interest in
participatory democracy), and hence, cannot be quantified precisely in monetary terms.
Cost-benefit calculations are further complicated by three other factors. One of these
includes what kinds of costs and benefits are measured and how they are measured, at
what time the benefits are realized, and whether to include the values of external benefits
or only those that relate directly to the project being undertaken. Further complicating
matters is the principle of the time-value of money, which stipulates that costs incurred
today are “worth” more than the benefits of the same monetary values received in the
future. The third factor is concerned with the variation and variability of the lifecycles of
different project components (e.g., the relatively short, perhaps three to five-year,
technology lifecycle and the longer term, and often indefinite, data lifecycle).
Working within the above limitations, a typical cost-benefit analysis can be conducted as
an “educated guess” to assist in project management decision making, using the following
two steps:
Assumptions. There are four sets of assumed parameters or variables used for the
calculation of cost and benefits. These include:
• The time frame for project lifecycle, payback period, initial investment period, and
benefit accrual period.
• Costs for personnel (wages and benefits), facilities, equipment, and materials
obtained from the Resource Requirements Form (see Section 3.3).
• Benefits from productivity gain, cost recovery (including royalty from the sale of
data, potential revenues and user fees), value-added services, economic spin-off
internally and externally.
• Discount rates for use as differential weightings in the calculation of future costs
and benefits.
 Calculation. The cost-benefit analysis calculates annual benefits less annual costs relating
to the creation and maintenance of the GIS resulting from the project. Two sets of values
are normally calculated, namely:
• The sum of Flow of Net Benefit (SFNB), which simply calculates a sum of all the
payments and income/benefits over the same assumed payback period.
• Net Present Value (NPV), also called “discounted net present value”, which
calculates the sum of future payments (negative values) and income/benefits
(positive values) over an assumed payback period and reduces them to present
value using an assumed discount rate.
2.4.10. Application development strategies and techniques
A GIS project involves a substantial amount of effort and resources to be focused on
application development. This includes the design, programming, testing and integration
of software modules for the user interface, database connectivity, information retrieval
and analysis, generation of reports, presentation of graphics, and multimedia information
products.
GIS applications are now developed predominantly using software engineering methods
(Pressman, 2005; Summerville, 2005).
2.4.11. Project risk and opportunity analysis
Despite the best of intentions and careful thought invested in the project initiation and
planning processes, the possibility of unexpected problems and benefits occurring during
the course of the project lifecycle is real. Risk and opportunity analysis are not always seen
as integral and critical components of project planning, however, a prudent project
manager should realize that there is no perfect approach to project planning, and if
something can go wrong it usually will. The idea of potential risk and opportunity analysis
is based on the belief that an experienced project team does not and cannot know exactly
what problems will occur and when they will occur, but they are able to anticipate the
types of potential problems and have the capability of dealing with them if they
materialize. In essence, potential risk analysis is a preventive measure rather than a
regular element of a project. The idea of potential risk analysis is closely related to the
notion of project quality above.
Risk analysis essentially aims to help the project team develop contingency plans so that it
can respond quickly and correctly to problematic situations before irreparable damage is
done. One of the most common problems is the resignation or reassignment of project
team members to another project. This problem is particularly acute in the case of large-
scale multi-year infrastructure projects or for projects in organizations where staff
resources are limited and priorities change within short time frames. Another very
common problem is the late delivery or delays in the availability of source materials.
In addition to risks, the project manager should also look at the possibility of maximizing
the opportunities of the project. They can do this by, for example, exploring the potential
of extending the functionality of the GIS, providing value-added sales of the data to other
users, and using their experience gained in the project being undertaken to offer
consulting services to other organizations. All these will potentially bring additional
revenue to the project, thus increasing its return on investment and long-term
sustainability.
 Risk exists for all projects. The role of the project management team is to understand the
kinds and levels of risks on the project and then to develop and implement plans to
mitigate these risks. Risk represents the likelihood that an event will happen during the life
of the project that will negatively affect the achievement of project goals. The type and
amount of risk vary by industry type, complexity, and phase of the project. The project risk
plan will also reflect the risk profile of the project manager and key stakeholders. People
have different comfort levels with risk, and some members of the project team will be
more risk averse than others.
The first step in developing a risk management plan involves identifying potential project
risks. Some risks are easy to identify, such as the potential for a damaging storm in the
Caribbean, and some are less obvious. Many industries or companies have risk checklists
developed from past experience. The Construction Industry Institute published a 100-item
risk checklist that provides examples and areas of project risks. No risk checklist will
include all potential risks. The value of a checklist is the stimulation of discussion and
thought about the potential risks on a project.
The project team analyzes the identified risks and estimates the likelihood of the risks
occurring. The team then estimates the potential impact on project goals if the event does
occur. The outcome of this process is a prioritized list of estimated project risks with a
value that represents the likelihood of occurrence and the potential impact on the project.
The project team then develops a risk mitigation plan that reduces the likelihood of an
event occurring or reduces the impact on the project if the event does occur. The risk
management plan is integrated into the project execution plan, and mitigation activities
are assigned to the appropriate project team member. The likelihood that all the potential
events identified in the risk analysis would occur is extremely rare. The likelihood that one
or more events will happen is high.
The project risk plan reflects the risk profile of the project and balances the investment of
the mitigation against the benefit for the project. One of the more common risk mitigation
approaches is the use of contingency. Contingency is funds set aside by the project team
to address unforeseen events. Projects with a high-risk profile will typically have a large
contingency budget. If the team knows which activities have the highest risk, contingency
can be allocated to activities with the highest risk. When risks are less identifiable to
specific activities, contingency is identified in a separate line item. The plan includes
periodic risk-plan reviews during the life of the project. The risk review evaluates the
effectiveness of the current plan and explores possible risks not identified in earlier
sessions.
2.4.11.1. Defining risk
Following Holton’s (2004) essay, we define risk is the probability of an uncertain
event or condition that, if it occurs, has a negative effect on a program’s objectives.
Both, the size of the effect and the probability combine to the overall measure of
risk. Damodaran (2007) offers a more expansive definition that sees risk as much as
an opportunity that gets squashed if risk management is solely aimed at minimizing
exposure to risk.
2.4.11.2. Risk management process
At a higher, overall risk is defined the exposure of stakeholders to the consequences
of variation in individual risks. The high-level process starts with an initiation step
that defines the scope and objectives of risk management. A key output from the
initiation step is the risk management plan, which details how risk will be managed
throughout the life cycle.
Risks should be identified and documented in the risk register. The relative
significance of identified risks is assessed using qualitative techniques to enable them
to be prioritized for further attention. Quantitative risk analysis may also be used to
determine the combined effect of risks on objectives. The process continues with risk
response planning, aiming to avoid, reduce, transfer or accept threats as well as
exploit, enhance, share or reject opportunities, with contingency (time, cost,
resources and course of action) for risks which cannot be managed proactively. The
final step is the implementation of agreed responses.
The whole process is iterative. For example, assessment or response planning can
lead to the identification of further risks; planning and implementing responses can
trigger a need for further analysis, and so on. It is important that risk management is
not conducted in isolation. Risks at the project level, for instance, may have to be
escalated to the program level or vice versa.
Risk management must contribute, as appropriate, to both business risk assessments
and organizational governance requirements. The manager must be aware of risks
that have an effect outside their scope of responsibility, e.g. those that could affect
the organization's reputation. The management of general health and safety risks is
usually excluded from program risk management, as the management of these risks
is traditionally handled by a separate function within the organization.
Risk by phases
Risk management consists of six steps or phases. (1) we must identify what is the
risk, and what is at risk. It could be timescales, the realization of a benefit, or the
delivery of a capability. (2) Although the program manager is ultimately responsible,
each risk should be given an owner who is best positioned to perform mitigating
actions on the risk and monitor the risk. (3) The owner then evaluates and assigns
the risk with an impact and probability score. (4) Every risk has a standard set of
mitigations which can be applied to it:
• Transfer: can the risk be transferred to another party, for example, could an
insurance policy be taken out.
• Tolerate: this is frequently used for risks with very low impact, and is
effectively the do nothing option. Tolerate effectively means the risk is
monitored but the program proceeds without proactive action being taken
to address the risk.
• Terminate: this refers to adjusting the program so the risk is no longer
applicable to the program, for example, a project may be removed entirely
from the program so the risk can never now materialize.
• Treat: this is where concrete actions are taken to reduce the probability of
the risk materializing or impact of the risk should it materialize.
 (5) The risk owner then takes concrete actions to ensure that the above mitigation
measures are carried out. (6) All risks and actions which have been created need to
be reviewed regularly, so the risk impact and probability can be updated following
any actions which have been performed to treat them.
2.4.11.3. Project risk and project complexity profile
Risk management can be understood as a complex system. It is affected by
individuals, groups, stakeholders, host organizations, clients and the broad external
environment. Fundamental to understanding this system are the concepts of risk
attitude and risk appetite. Risk attitude is an individual's or group’s natural
disposition towards uncertainty and is influenced by their perception of risk.
Perception is itself influenced by many factors, including conscious and subconscious
reactions to risk. Risk attitude will affect the way people develop responses to risk
and the way they react if a risk event occurs.
The risk attitude of a group or individual is often described in one of three ways:
• Risk averse, where risk is avoided;
• Risk seeking, where risk is actively sought;
• Risk neutral, where risk is neither actively sought nor avoided.
A risk averse attitude may be useful in some situations (e.g. local government) but
detrimental in others (e.g. an entrepreneurial, technology start-up company).
Conversely, risk seeking is a positive attribute in some situations but unsuitable in
others.
Understanding risk attitude can help geospatial managers by giving insight into why
some situations are considered more risky than others, and why individuals or
groups behave in certain ways when confronted with risk.
Risk appetite is the amount of risk an individual, group or organization is prepared to
take in order to achieve their objectives to take risk in a given situation, influenced
by their propensity to take risk and/or the organizational risk culture.
A manager needs to understand the risk appetite of the stakeholders. In the
definition phase of a life cycle, the development of a solution to meet requirements
will be heavily influenced by the stakeholders’ risk appetite. Some ways of meeting
requirements may be delivered quickly or produce high returns but also involve high
levels of risk. These would be acceptable to risk-seeking stakeholders but not to
those who are risk averse.
The manager also needs to understand the risk attitude of the team members and ensure
that they are managed in a way that is compatible with the stakeholders’ risk appetite.
2.4.12. Monitoring and control
Project monitoring and control should be done independently of project execution in
order to prevent potential conflicts of interest from occurring when the individuals
executing a project monitor and control their own activities.
2.4.12.1. Quality planning
Quality planning is a systematic process that translates the top management's
expression of its intentions, direction, and aims regarding quality into measurable
objectives and requirements, and lays down a sequence of steps for realizing them
within a specified timeframe. Identification and characterization of quality as a basis
 for quality management procedures is helped by reference to accepted geospatial
standards such as ISO, OGC, FGDC, or URISA (see 2.4.12.7).
2.4.12.2. Quality planning tools
A preventative approach to data quality uses a four-tier Total Data Quality
Management (TDQM) model to define, measure, analyze and improve data quality
(Wang, 1998). This approach differs from conventional methods in two ways. First is
the emphasis on the use of pre-defined rules to validate the data before they are
entered into the database. Second is the systematic capture and analysis of detected
errors as well as the subsequent feedback of information to develop preventative
measures at the data collection and supply end of the database construction process.
2.4.12.3. Contract management and control
Contract management requires considerable people skills. The project manager not
only deals on a day-to-day basis with the contractor but also serves as the primary
liaison between the contractor and the project team on various aspects of the
project.
A common pitfall in contract management is the use of more than one contractor in
the same project. Although it is not uncommon for a project contract to be awarded
to more than one consultant (e.g., one for the database, the other for the application
program development), awarding multiple contracts for a single project can be the
project manager’s worst nightmare and, therefore, should be avoided if possible. In
the case of large-scale projects that are difficult for one contractor to complete
alone, the usual solution is to allow the contractor to sub-contract, subject to
compliance with certain conditions (e.g., the principal contractor must be able to
satisfy the project manager that the sub-contractors have the capabilities and
resources to complete the assigned components to the required performance
standard, or the contractor takes full responsibility for delivery of sub-contracted
components). When this happens, the project manager typically only interacts
directly with the principal contractor. He or she should avoid intervening in the
working relationship between the principal contractor and any sub-contractors (e.g.,
getting involved in dispute resolution between the principal contractor and sub-
contractors on any specific aspect of the project).
During the course of the project, disagreements between the project team and the
contractor occur from time to time. In order to facilitate the resolution of potential
conflicts, it is important for the project manager to specify the rules and protocols
for communication between the two parties, and apply these rules strictly and
consistently when problems occur. Typical rules and protocols often include
communications channels (e.g., all communication must be done between the
person designated by the principal contractor and the project manager only), the
exclusive use of written communication, and the time limit for the contractor to
respond when questions are raised, as well as the time limit for the project manager
to indicate acceptance after a response is received from the contractor.
2.4.12.4. Change control
A commonly overlooked aspect of contract management is change management.
Often, no matter how carefully a project manager plans a project and develops
project specifications for hardware, software and performance standards,
unforeseen events may happen to necessitate a change in the plan and the
specifications.
Change in project plans and project specifications can be generally classified into five
categories. Whenever a change is required, the person (e.g., the contractor or a
particular project team member) initiating the change will start the change request
process. This is usually done by completing a project change request form.
When a problem occurs, one can’t just make a change, because it may be too
expensive or take too long to do. Instead, one should see how it affects the triple
constraint of Figure 1 and how it impacts project quality to determine whether it is
worth making the change. If change impact evaluation does not show an impact on
the project triple constraint, then it is alright to make the change without going
through change control. In all other cases, change control is the set of procedures
that enables the project manager to make changes in an organized way.
Any such change to a project plan starts with a change request. Every change to the
project must be documented so one can figure out what needs to be done, by when,
and by whom, as well as to form a basis for learning from the management of past
project to improve the management of new ones.
Once the change request is documented, it is submitted to a change control board. A
change control board is a group of people who consider changes for approval. If
there is no such agency, then the change request could also be submitted to the
project sponsor or management for review and approval. Putting the recommended
changes through change control will help to evaluate the impact and update all the
necessary documents. Not all changes are approved, but if the changes are
approved, they are returned to the team to put them in place.
The implementation phase uses the most project time and resources, and as a result,
costs are usually the highest during this phase. Project managers also experience the
greatest conflicts over schedules in this phase. When the project is running behind,
one can sometimes find ways to do activities more quickly by adding more resources
to critical path tasks; a process known as crashing. Crashing the schedule means
adding resources or moving them around to bring the project back into line with the
schedule. Crashing always costs more and doesn’t always work. There’s no way to
crash a schedule without raising the overall cost of the project. Therefore, if the
budget is fixed and there aren’t any extra money to spend, this technique is not
applicable.
Project fast tracking refers to a situation where two activities that were originally
planned to occur in sequence are no implemented at the same time. An example
from the GIS world would be the concurrent testing of user acceptance testing (UAT)
and the functional performance. This is a pretty risky approach though as there is
always a good chance one might need to redo some of the work that was done
concurrently. Crashing and fast tracking are schedule compression tools. Managing a
schedule change means keeping all of the schedule documents up to date. That way,
one can always compare (and report to higher management) the results to the
correct plan.
2.4.12.5. Project documentation and control
Project monitoring and control starts with proper project documentation and record
keeping and is among the greatest challenges for a project manager. Project
documentation includes all documents resulting from the project initiation and
planning phases as well as on-going amendments to project schedules, memoranda
distributed to project team members, minutes of project team meetings,
communication with the contractor and representatives of stakeholders, progress
reports from the contractors, expenditure reports, and progress reports from
internal project team members.
Project documentation and record keeping serve several important purposes in
project management. One of these is to help the project manager maintain control
of the project and keep track of its progress. They also allow the project manager to
track the resources used against the activities completed and in progress.
From the beginning of a project, its manager must ensure that all members of the
project team keep detailed notes of their respective activities (e.g., where they store
their data and application program files, and the methods used for as well as
progress made in the development of a particular application software module). As
discussed in section (g), standards are very important in this context. Even mid-sized
organizations will eventually develop their own standards as part of their GIS
program or portfolio management. If a particular member is reassigned to a new role
in the project or leaves the project altogether, these notes will allow the project
manager quickly to provide the replacement with sufficient information to continue
seamlessly with the work in progress.
Project documentation and record keeping are tedious and time-consuming tasks.
However, it is important to keep a balance between the time and cost of record
keeping on the one hand, and the usefulness of the documentation on the other
hand. Obsession with detailed documentation and record keeping may be a waste of
valuable resources, but keeping a collection of unorganized documents and project
notes will not help either. The project manager has to use his or her discretion to set
up a project documentation and record keeping system that is both economically
sustainable to maintain and easy enough to access and use.
2.4.12.6. Quality assurance
The terms quality assurance (QA) and quality control (QC) are often used in
conjunction with one another (QA/QC). In reality, however, they refer to two
relatively distinct but closely interrelated sets of concepts and practices. QA and QC
have their origin in manufacturing and engineering. The purpose is to safeguard the
quality of products against possible imperfection in design, craftsmanship, the
material used, and production processes. Thus, QA/QC are preventive measures that
are applied throughout the entire production or construction cycle of hardware
manufacturing and engineering development projects. GIS projects, being a design
and implementation undertaking, require stringent QA/QC measures to ensure that
all activities, from design, development, production, installation, servicing and
documentation, are carried out according to accepted practices and standards, and
will lead to the delivery of a system that is useful for its intended purposes.
 The relationship between QA and QC in GIS projects are often confused. QA should
be seen as the umbrella activities that provide the support infrastructure for the
technical application of QC measures. The support infrastructure includes corporate
information quality and standards, competencies of project staff, and performance
standards of business procedures served by the GIS resulting from individual
projects. Of particular interest here are the ISO and OGC standards that will be
discussed in the next section.
At the technical level, QC is applied by conducting a sequential series of software
tests that include:
• Unit tests. These tests target the smallest unit of software construction, namely
the functional modules, and are carried out immediately after the source-level
code is developed, reviewed and checked for correct syntax.
• Integration tests. These tests aim at detecting potential errors associated with
the interaction between individual functional modules. There are different
approaches to integration testing. The most commonly used one is called
regression testing, which is carried out incrementally each time a new module is
completed and added to the software system.
• Systems test. This is the final stage of software testing conducted when the
entire development process is complete. In practice, systems testing is actually a
series of tests with different purposes that collectively seek to verify the
functionality of the database system as a whole. The four commonly used tests
are a recovery test (to verify the ability of the system to restore itself to the
state before the failure), a security test (to verify the ability of the system to
protect itself from unauthorized use), a stress test (to examine the response of
the system to abnormal events such as excessive interruption, excessive number
of users, and maximum memory use), and a performance test (to monitor the
functioning of the system in run-time). As the systems test is carried out to
determine whether the final system is functionally acceptable for
implementation, it is also commonly called the acceptance test.
Once fully operational, the GIS has to be validated in accordance with the validation
protocols agreed in the system qualification plan. Modular tests are conducted by
team members who have not taken part in the coding operations. Tests have to
conform to the verification test procedures. The results of this task are reported in a
verification test report. On the basis of that report, a final tuning of the information
system specifications is then carried by the GIS project team. This tuning may result
in improved versions of the requirements baseline, technical specifications, the
design justification report, data model report, and system qualification plan.
2.4.12.7. Standards
Identification and characterization of quality as a basis for quality management
procedures is helped by reference to accepted standards such as:
The family of ISO technical specifications 191xx (as of 2016, some 68 different
specifications have been passed; hence the ‘xx’). The International Organization
for Standardization (ISO), is an independent, non-governmental organization, the
members of which are the standards organizations of the 162 member countries.
 Its technical committee 211 has been tasked with the development of technical
specifications for digital geographic information, covering areas such as
• Simple Features access
• Reference models
• Spatial and temporal schemas
• Location-based services
• Metadata
• Web feature and map services
• Classification systems
The Open Geospatial Consortium (OGC) is an independent standards organization
with participation of industry and government organizations and coordination
with professional associations and other standards organizations. The OGC has
established standards for spatial data format, data classification, geospatial
services and applications, and GIS operational practices. The OGC standards have
been adopted by many GIS software and databased companies and by user
organizations. As of 2016, the OGC has published some 49 standards including
CityGML, GML, NetCDF and the plethora of web services such as WCS, WFS,
WMS, WPS) that are now the foundation of all Web-based geospatial
applications.
The Federal Geographic Data Committee (FGDC) is a U.S. Federal government
organization, which develops and approves standards for GIS data and metadata
quality, format, content, and classification and related GIS data collection and
maintenance practices. Similar organizations exist in Europe (INSPIRE), Canada
(CGDI), Australia/ New Zealand (ANZLIC), and elsewhere.
The Urban and Regional Information Systems Association (URISA) is an international
professional and educational association that promotes standards and best
practices for the management and use of GIS technology. Of particular relevance
to this article is their GIS Management Institute (GMI), which develops tools and
best practices useful for GIS planning and management.
2.4.12.8. Ethical responsibility in publicly financed projects
While the topic of ethics will be discussed in more general terms in 4.5, this section
here deals with the need for an extra layer of monitoring and control in publicly
financed projects. This starts with the procurement process, where the bidding
process may involve criteria that go beyond the scope of the GIS project itself, e.g.,
minimum wage requirements or a preference to women- and minority-owned
enterprises. Lobbying rules and other conflict of interest declarations will put
additional burden on the monitoring requirements, sometimes dismissively labeled
as ‘red tape’.
2.4.13. Deployment (technology roll-out activities)
After the deliverables have been physically constructed and accepted by the customer, a
phase review is carried out to determine whether the project is complete and ready for
closure.
 2.4.13.1. System engineering
During this task, the GIS project team completes all developments in accordance
with the refined technical specifications and data model report. This includes the
final coding of software modules and their final integration into an operational GIS
package. Beside the GIS package itself, it is the project manager’s responsibility to
also refine the design definition report and the data model implementation report.
Critical success factors for implementation of comprehensive GIS systems will require a
large investment in staffing resources and its funding as an information technology
project. The implementation process must be recognized as such, therefore being
managed like any major IT project to achieve optimal benefits and results.
2.4.14. Close-out and evaluation
2.4.14.1. Development and testing
The objective of this phase is to complete the development of the geographical
information system and to demonstrate the compliance with the consolidated user
requirements refined during the prototyping phase.
2.4.14.2. Support (user documentation, training, technology transfer)
Prior to its installation at the users’ premises, the information system has to be
adequately documented. This documentation includes all the documents mentioned
above, extended to the documents described hereafter.
Installation guide
The installation guide describes all operations to install and configure the
information system at the users’ premises. It specifies, in particular, the minimum
hardware requirements and versions of operating platforms. Another important
item at this stage is the need to pay attention to the implementation of the data
model into the GIS software.
Software User Manual
The software user manual describes all the functionalities of the software
elements of the GIS package and has to be written in such a way that it is
understandable by the users’ organizations.
Manual of procedures
The manual of procedures describes all procedures which support the operations
routinely performed by the information system, especially those which require a
human intervention. These include:
• Overall system administration procedures including back-up and archiving
procedures, maintenance operations, the configuration of new users, etc.
• Data diffusion policy and procedures (including pricing policy if any)
• Quality control procedures
• Financial procedures
• Documentation procedures
• Annual performance review procedures
Training plan
The training plan aims at specifying the human skills which are required to
operate the information system properly and the training efforts to be
undertaken so that the staff of the users’ organizations matches these human skill
 requirements. The training plan describes the different training modules which
are required and for each of them the number of hours which will be lectured, the
list of staff members who will attend the module, and a preliminary investigation
of potential training service providers.
2.4.14.3. Closing-out contracts
Contractual closeout includes identification and status of each project contract and
subcontract, their values and their terms and conditions. The contract status should
include any incomplete deliverables; terms, conditions, and dates for obtaining
remaining deliverables; real and potential claims; pending and any ongoing legal
actions; warranties made as part of the contract; and any other information that
might prove useful to the user organization in relation to legal, contractual,
warranty, or deliverables.
Before the contract is closed, any minor items that need to be repaired or completed
are placed on a punch list of all the items that still remain to be done. The project
team will then work on all of the items on the list, building a small schedule to
complete the remaining work. Once the punch list becomes smaller, the project
manager begins closing down the project, maintaining only enough staff and
equipment to support the team that is working the punch list.
In many public projects, a major component is regulatory compliance, which
ascertains that no additional active management is needed.
The development and execution of closing-out contracts may take as much time as
the project itself because once signed, it usually does not allow a client to request
any changes or repairs, and it serves as protection against legal recourse once the
project is finished. Signing of the closing-out contract usually coincides with the last
payment as well.
2.4.14.4. Post-project evaluations
In many cases when a project is completed, it is time to start thinking about its
upgrade and enhancement. The purpose of the post-implementation evaluation is to
summarize the experiences gained in the project just completed so that the same
mistakes will not be repeated in the next version of the database system and in other
similar projects.
In essence, a post-implementation evaluation is a comparison between the predicted
events and the events that actually occurred during the entire course of the project’s
lifecycle. Experience has shown that projects rarely run exactly as planned and
scheduled. Variances between planned and actual events can often be generally
traced to two primary causes, namely technical and personnel. Thus, a post-
implementation evaluation report is best approached from these two perspectives. It
is common practice for the project sponsor to analyze the performance of project
personnel while the project manager is responsible for the evaluation of the
performance of equipment and applications. In conducting the technical portion of
the evaluation, the project manager should pay special attention to the problems
encountered and the solutions that were used to deal with the problems
successfully.
 Upon completion of the evaluation report, the project manager should submit copies
to the project sponsor and senior management to signify the completion of the
entire project. He or she should distribute copies of the report to all project staff.
2.4.14.5. Project archival
The documents associated with the project must be stored in a safe location where
they can be retrieved for future reference. Signed contracts or other documents that
might be used in tax reviews or lawsuits must be stored. Organizations will have legal
document storage and retrieval policies that apply to project documents and must
be followed. Some project documents can be stored electronically.
Care should be taken to store documents in a form that can be recovered easily. If
the documents are stored electronically, standard naming conventions should be
used so documents can be sorted and grouped by name. If documents are stored in
paper form, the expiration date of the documents should be determined so they can
be destroyed at some point in the future. The following are documents that are
typically archived:
• Charter documents
• Scope statement
• Original budget
• Change documents
• Manager’s summary—lessons learned

3. Stakeholder Management
People and organizations can have many different relationships to the project. Most commonly,
these relationships can be grouped into those who will be impacted by the project and those who
can impact the project. A project is successful when it achieves its objectives and meets or exceeds
the expectations of the stakeholders. This insight is fairly new: the Project Management Institute,
for example, added stakeholder management to its core list of knowledge areas only in its latest
(5th) edition of the project management guidebook. Stakeholders are individuals who either care
about or have a vested interest in the project. They are the people who are actively involved with
the work of the project or have something to either gain or lose as a result of the project. In a
project to add lanes to a highway, motorists are stakeholders who are positively affected. However,
they negatively affect residents who live near the highway during the project (with construction
noise) and after the project with far-reaching implications (increased traffic noise and pollution).
A successful project manager will identify stakeholders early in the project. For each stakeholder, it
is important to identify what they want or need and what influence or power they have over the
project. Based on this information, the need to communicate with the stakeholder or stakeholder
group can be identified, followed by the creation of a stakeholder management plan. A stakeholder
register is used to identify and track the interactions between the project and each stakeholder. This
register must be updated on a regular basis, as new stakeholders can arise at any time, and the
needs and interest levels of a particular stakeholder may change through the course of the project.
Often there is more than one major stakeholder in the project. An increase in the number of
stakeholders adds stress to the project and influences the project’s complexity level. The business or
emotional investment of the stakeholder in the project and the ability of the stakeholder to
influence the project outcomes or execution approach will also influence the stakeholder complexity
of the project. In addition to the number of stakeholders and their level of investment, the degree to
which the project stakeholders agree or disagree influences the project’s complexity.
A small commercial construction project will typically have several stakeholders. All the building
permitting agencies, environmental agencies, and labor and safety agencies have an interest in the
project and can influence the execution plan of the project. The neighbors will have an interest in
the architectural appeal, the noise, and the purpose of the building.

Figure 6. Project stakeholders.

The following section details the functions and relationships of the stakeholders depicted in Figure
6.
3.1. Stakeholders
3.1.1.Top management
Top management may include the chief executives, directors, division managers, and
others. These people direct the strategy and development of the organization. If one has
top management support, it will be easier to recruit the best staff to carry out the project,
and acquire needed material and resources; also visibility can enhance a project manager’s
professional standing in the company. That comes with the risk though that failure can be
quite dramatic and visible to all, and if the project is large and expensive (most are), the
cost of failure will be more substantial than for a smaller, less visible project.
3.1.2.Project team
The project team is made up of those people dedicated to the project or borrowed on a
part-time basis. A project manager has to provide leadership, direction, and above all, the
support to team members as they go about accomplishing their tasks. Working closely
with the team to solve problems helps to build rapport. Team management is not an easy
task; some of the difficulties that many projects run into include:
• If project team members are borrowed and they don’t report to the project
manager, their priorities may be elsewhere.
• They may be juggling many projects as well as their full-time job and have
difficulty meeting deadlines.
• Personality conflicts may arise. These may be caused by differences in social style
or values or they may be the result of some bad experience when people worked
together in the past.
 • If communication breaks down, one may learn about missed deadlines only when
it is too late to recover.
3.1.3.Internal customers
Internal customers are individuals within the organization who are customers for projects
that meet the needs of internal demands. The customer holds the power to accept or
reject the project outcomes. Early in the relationship, the project manager will need to
negotiate, clarify, and document project specifications and deliverables. After the project
begins, the project manager must stay tuned into the customer’s concerns and issues and
keep the customer informed.
• Common stumbling blocks when dealing with internal customers include:
• A lack of clarity about precisely what the customer wants
• A lack of documentation for what is wanted
• A lack of knowledge of the customer’s organization and operating characteristics
• Unrealistic deadlines, budgets, or specifications requested by the customer
• Hesitancy of the customer to sign off on the project or accept responsibility for
decisions
• Changes in project scope
To meet the needs of the customer, client, or owner, be sure to do the following:
• Common stumbling blocks when dealing with internal customers include:
• A lack of clarity about precisely what the customer wants
• A lack of documentation for what is wanted
• A lack of knowledge of the customer’s organization and operating characteristics
• Unrealistic deadlines, budgets, or specifications requested by the customer
• Hesitancy of the customer to sign off on the project or accept responsibility for
decisions
• Changes in project scope
3.1.4.Contractors and suppliers
There are times when organizations don’t have the expertise or resources available in-
house, and work is farmed out to contractors or subcontractors. This can be a construction
management foreman, network consultant, electrician, carpenter, architect, or anyone
who is not an employee. Managing contractors or suppliers requires many of the skills
needed to manage full-time project team members.
Any number of problems can arise with contractors or subcontractors:
• Quality of the work
• Cost overruns
• Schedule slippage
Many projects depend on goods provided by outside suppliers. This is true for example of
construction projects where lumber, nails, bricks, and mortar come from outside suppliers.
If the supplied goods are delivered late or are in short supply or of poor quality or if the
price is greater than originally quoted, the project may suffer.
Depending on the project, managing contractor and supplier relationships can consume
more than half of the project manager’s time. It is not purely intuitive; it involves a
sophisticated skill set that includes managing conflicts, negotiating and other interpersonal
skills.
3.2. Politics of projects
Many times, project stakeholders have conflicting interests. It’s the project manager’s
responsibility to understand these conflicts and try to resolve them. It’s also the project
manger’s responsibility to manage stakeholder expectations. Be certain to identify and meet
with all key stakeholders early in the project to understand all their needs and constraints.
Project managers are somewhat like politicians. Typically, they are not inherently powerful or
capable of imposing their will directly on coworkers, subcontractors, and suppliers. Like
politicians, if they are to get their way, they have to exercise influence effectively over others.
On projects, project managers have direct control over very few things; therefore their ability
to influence others – to be a good politician – may be very important
Here are a few steps a good project politician should follow. However, a good rule is that when
in doubt, stakeholder conflicts should always be resolved in favor of the customer.
3.3. Culture of stakeholders
When project stakeholders do not share a common culture, project management must adapt
its organizations and work processes to cope with cultural differences. Communication is
perhaps the most visible manifestation of culture. Project managers encounter cultural
differences in communication in language, context, and candor. Language is clearly the greatest
barrier to communication. When project stakeholders do not share the same language,
communication slows down and is often filtered to share only information that is deemed
critical. The barrier to communication can influence project execution where the quick and
accurate exchange of ideas and information is critical. The interpretation of information reflects
the extent that context and candor influence cultural expressions of ideas and understanding of
information. In some cultures, an affirmative answer to a question does not always mean yes.
The cultural influence can create confusion on a project where project stakeholders represent
more than one culture.
3.4. Strategies for stakeholder management
Securing stakeholders’ support is absolutely critical to the success of a project. Even if all the
deliverables are met and the objectives are satisfied, if the key stakeholders aren’t happy, the
project will be deemed a failure. The first step, therefore, is to identify who the stakeholders
are. Just because someone is important in the organization does not necessarily mean she is
important to the project. The typical suspects are the manager, her boss, the client, the client’s
manager, any subject matter expert whose involvement is necessary, and the board reviewing
and approving the project. In some situations, there are people who think they are
stakeholders. From the manager’s perspective, they may not be, but these need to be handled
carefully. They could be influential with those who have the power to impact the project and
should not be dismissed out of hand.
Second, a project manager needs to determine what power they have and what their
intentions toward the project are. Do they have the power to have an impact on the project?
Are they in support or opposition to the project?
Third, what’s the relationship among stakeholders? Can the project’s chances be improved by
working with those who support the project by co-opting them to improve the views of those
who oppose it? A key piece of stakeholder management efforts is constant communication to
her stakeholders.
4. Project Management Expertise
4.1. Application knowledge
Application-specific knowledge and skills pertaining to a particular GIS project are not
particularly important at the management level. The project manager can usually pick up
relevant knowledge and skills through interaction with application specialists and user
representatives as the project unfolds. Technical competencies and skills, on the other hand,
are essential throughout the entire project lifecycle, and especially so in the project execution
phase. Such competencies and skills are project-specific because different types of projects
require different technical skill sets. A project manager is not normally expected to be a
technical expert. However, it is essential for the project manager to have, as a minimum, a
good understanding of the basic principles of GIS. It is useful to consider application knowledge
from another perspective by taking technical competencies and skills into consideration.

Strategic
Tactical
Technical

Initiation

Planning

Execution
Monitoring /
Control
Evaluation /
Close-out

Figure 7. Project management competencies and skills.

Figure 7 shows the role of technical competencies and skills in project management. Project
management competencies and skills are classified into three categories according to their
respective nature, namely strategic, tactical, and technical. Strategic competencies and skills
cover mainly the two areas of “organizational culture” and “communication”, which are both
described in the following sections. These two areas of competencies and skills are applied
mainly in the initiation and closing phases of the project lifecycle. The tactical competencies
and skills discussed in section 3 are needed most for the planning and monitoring and control
phases of the PMLC.
4.2. Understanding the project environment
There are many factors that need to be acknowledged in the project environment. At one level,
it is important to think in terms of cultural and social environments such as people,
demographics, and education. Many GIS projects take place in an international context where
projects are doomed to fail if they do not heed political and cultural influences.
Of all the factors, the physical ones are the easiest to understand, and it is the cultural and
international factors that are often misunderstood or ignored. How we deal with clients,
 customers, or project members from other countries can be critical to the success of the
project. For example, the culture of the United States values accomplishments and
individualism. Americans tend to be informal and call each other by first names, even if having
just met. Europeans tend to be more formal, using surnames instead of first names in a
business setting, even if they know each other well. In addition, their communication style is
more formal than in the United States, and while they tend to value individualism, they also
value history, hierarchy, and loyalty. Francis Harvey (1997) did a fascinating study on the
differences in the culture of GIS implementation between Münster, Germany, and Seattle, WA
(United States).
Cultural differences of a very different kind occur also within (larger) organizations. All projects
inevitably involve changes in the organizational culture, institutional structure, business
processes and people and it is the responsibility of the project manager to steer the
organization through the transition with minimum disruption to the organization’s business,
the least anxiety of its staff, at the lowest possible cost, and within the shortest realistic time
frame.
4.3. Management knowledge and skills
Project management is the responsibility of a project manager. This individual seldom
participates directly in the activities that produce the GIS, but rather strives to maintain the
progress and productive interaction of various parties in order to minimize the overall risk of
failure. A project manager is expected to have a specific level of competency and skills in
technical management, financial management, and people management in order to accomplish
this objective. In many organizations, the project manager is required to possess a professional
designation from an accreditation body such as the PMI noted above. Although a professional
designation for a manager is by no means a panacea for the success of a project, such a
requirement at least reflects the general realization that a set of managerial competencies and
skills is essential for the practice of effective project management. Typical project manager job
functions include:
• Define scope of project • Identify and evaluate risks Prepare
• Identify stakeholders, decision-makers, contingency plan
and escalation procedures • Identify interdependencies
• Develop detailed task list (work • Identify and track critical milestones
breakdown structures) • Participate in project phase review
• Estimate time requirements • Secure needed resources
• Identify required resources and budget • Manage the change control process
• Evaluate project requirements • Report project status
The New York State Project Management Guidebook (Mulholland, 2003) identifies five core
sets of competencies and skills for project managers. These include:
4.3.1.Communication
Good communication skills are a critical requirement for project managers. Project
managers spend 90% of their time communicating. Communication in project
management is bidirectional in the sense that talking and listening are equally important.
The project manager must be able to convey his or her messages clearly both verbally and
in writing. At the same time, he or she must be willing to listen to suggestions and ideas
 put forth by project sponsors, project team members, and other stakeholders of the
project both within and outside of the organization. Project communication can thus be
summed up as knowing “who needs what information and when” and making sure they
have it.
4.3.2.Trust building
Project management can be a very difficult task if the project manager is unable to gain
the trust of the project sponsor, project staff, and other stakeholders. Trust and credibility
cannot be built overnight. They must be developed over time and can be inspired only if
the project manager exhibits behaviors compatible with the competency and skill
requirements described above, is willing to admit mistakes and accept responsibility for
actions, values differences and diversity of opinions and cultures, and treats everyone
equally and equitably.
4.3.3.Leadership
Leadership is the ability to motivate and inspire individuals to work toward expected
results. Leaders inspire vision and rally people around common goals. A good project
manager can motivate and inspire the project team to see the vision and value of the
project. The project manager as a leader can inspire the project team to find a solution to
overcome perceived obstacles to get the work done.
Experience has shown that project teams seldom become high-performing immediately
after their formation. It takes time and effort to build an effective and coherent project
team. As the team leader, the project manager should continuously motivate members by
letting them know the benefits and potential opportunities of the experience and skills to
be gained in the project. He or she must provide team members the necessary training to
perform their assigned tasks effectively, and recognize their efforts and accomplishments
appropriately. Team leadership also means delegation and empowerment, where
necessary, to increase the sense of belonging among team members. At the same time,
team leadership never ignores accountability and discipline, which will be applied
impartially, transparently and promptly when and if the situation warrants them.
4.3.4.Problem solving
While a project manager has considerable responsibility for the success of a project, he or
she does not always have absolute authority and control over human, financial and
technical resources allocated to the project. Therefore, it is essential for a project manager
to be politically astute, and have good networking and negotiation skills to deal with senior
managers and all stakeholders to ensure appropriate and sustainable support for the
project. It is also important for a project manager to have good mediation skills to resolve
disputes or conflicts among members of the project team as well as those between the
project team and other stakeholders of the project.
4.4. Certification
Certification is a process designed to recognize individuals who have demonstrated a level of
expertise in their profession. Although there are specialized certifications for a number of
disciplines (e.g. intelligence, photogrammetry, surveying,) the GIS Certification Institute’s
(GISCI) designation of GIS Professional (GISP) is the most widely accepted industry-wide,
internationally-recognized, software-agnostic certification available to geospatial professionals.
There are, as of 2016, more than 8,000 GISP certified professionals in 25 countries. The GISP
 helps employers identify professionals who are committed to the skilled and ethical use of GIS.
GISPs have a unique set of skills and responsibilities that can enhance their workforce. In
contrast to a degree, the GISP certification emphasizes regular renewal intervals that require a
combination of work experience, education, and contributions to the GIS profession. The value
of a GISP is acknowledged by the fact that they demand on average about 25% higher salaries,
all other qualifications being equal.
4.5. Ethics
Good ethics is good business (Jakobs 2017). In the United States, both the PMI and the GISCI
require their members to sign a Code of Ethics and Professional Conduct. GIS professionals are
expected to deliver quality work. Part of this is addressed by the certifications discussed in the
previous section. This includes the need of the professional to keep current in the field through
readings and professional development. Each member of the project team is expected to
identify risks and the potential to reduce them. Many of the characteristics project
management are mirrored in the expectations of the individuals working on the project. They
include the identification of alternative strategies to reach employer/funder goals and the
implications of each as well as the requirement to document one’s work so that others can use
it (see also 2.4.12.5)
Ethical behavior assumes GIS professionals to hold information confidential unless authorized
to release it. Any conflict of interest ought to be avoided and when this is not possible to be
disclosed.

5. Summary
GIS project management is somewhat of a neglected child in the academic treatment geospatial
work. Management practices are seen as just that: applications that do not merit further
investigation. The fact that business schools exist and thrive hints at the gaping hole that
GIScientists have left uncovered. One of the main messages of this article is that we need to look
beyond the immediate application of GIS and see GIS implementations in a larger enterprise
context. Much can be derived from the body of traditional management literature. But even here,
the bon mot ‘spatial is special’ holds true. It starts with the characteristics of spatial data and
continues with the unusual breadth of application areas that require generalists and specialists to
collaborate even more than in in standard information technology.
Most college-level GIS programs teach the technology and the science behind it, which serves the
science community well, and the industry adequately – up to a point. GIS certificates, both academic
and vendor-driven abound, addressing the needs for the bottom strung of a hierarchy of GIS
professionals. There is, or at least has not been, a corresponding body of knowledge for higher level
GIS professionals or managers, which is surprising given that there are thousands of GIS
departments in the United States alone. A systematic investigation of what makes a GIS program
successful (the URISA Awards for Exemplary Systems in Government come to mind) requires
analyzing and abstracting all the aspects of GIS project management discussed on the previous
pages. A compendium of best practices and how they might even inform GIS use in more traditional
academic settings has yet to be written. In the meantime, this article will hopefully shed some
insight on the complexities that experienced GIS managers have learnt to deal with.
Cross References
This requires either us having access to the other submissions or the editors to complete this section.

References
Barron, M and Barron, A. (2011) Project management for scientists and engineers. Galway, Ireland:
Connexions
Burek, P. (2011). Influence of the scope statement on the WBS. Newtown Square, PA: Project
Management Institute.
Chapman, A.D. (2005) Principles of data quality, Copenhagen, Denmark: Global biodiversity information
facility.
Chrisman, N.R. (1983) “The role of quality information in the long-term functioning of GIS”, Proceedings
of AutoCarto 6, Vol. 2, pp. 305-321, Falls Church, VA: ASPRS.
Damodaran A (2007). Strategic Risk taking: a framework for risk management. Upper Saddle River, NJ:
Prentice-Hall.
EPA (2003) Guidance for geospatial data quality assurance project plan, Washington, DC: Office of
environmental information, US Environmental Protection Agency.
Harvey, F. (1997) “National cultural differences”, in Theory and Practice. Information, Technology, and
People. 10(2) 132-146.
Holton G. (2004) “Defining Risk”, Financial Analysts Journal, 60(6): 19-25.
Huxhold, W. (1996) Managing geographic information systems projects. New York: Oxford University
Press.
Jakobs, R. (2017). Good business: Why placing ethics over profits pays off. Philips Blog, online resource,
available at http://www.philips.com/a-w/innovationmatters/blog/good-business-why-placing-ethics-
over-profits-pays-off.html, last accessed 11/25/2016 .
Mulholland, N. (ed.) (2003) New York State project management guidebook, Albany, NY: New York State
Office for Technology.
NETSSAF (2008). Proceedings, Network for the Development of Sustainable Approaches for Large Scale
Implementation of Sanitation in Africa Conference, 24 - 27 September 2008, Ouagadougou, Burkina
Faso. Online resource, available at http://www.ircwash.org/resources/netssaf-international-
conference-pathways-towards-sustainable-sanitation-africa-24-27, last accessed 23 May, 2016.
Peters, P. (2008) Building a GIS. ESRI Press, Redlands, CA.
Pressman, R. (2005) Software engineering: a practitioner’s approach, 6th ed., New York, NY: McGraw Hall.
Project Management Institute (PMI) (2013a) Guide of the project management body of knowledge
(commonly referred to as the PMBOK Guide), 5th ed., Newtown Square, PA: Project Management
Institute.
Project Management Institute (PMI) (2013b). The standard for program management. Newtown Square,
PA: Program Management Institute.
Project Management Institute (PMI) (2013c). The standard for portfolio management. Newtown Square,
PA: Program Management Institute
Shi, Q., & Chen, J. (2006). The human side of project management: leadership skills. Newtown Square, PA:
Project Management Institute, Inc.
Standish Group (2016). The CHAOS report 2015. Boston.
Summerville, I. (2005) Software engineering, 7th ed., Boston, MA: Addison Wesley.
Tomlinson R (2005). Thinking about GIS: geographic information system planning for managers, Redlands,
CA: ESRI Press.
URISA Journal (2015). Special issue on Return on investment in GIS, 27(1): 13-46. Des Plaines, IL: Urban
and Regional Information Systems Association (URISA).
 Wang, R (1908) “A product perspective on total data quality management”, Communications of the ACM
41(2): 58-65.
Wysocki, R.K., Beck, R. Jr. and Crane, D.B. (2003) Effective project management, 3rd ed., New York, NY:
John Wiley & Sons.

Further Reading (optional)

Tomlinson R (2005). Thinking about GIS: geographic information system planning for managers, Redlands,
CA: ESRI Press. Written for system implementation rather than project management, it is still a useful
source for the latter. See especially his nine-stage planning methodology on page 7.

Relevant Websites (optional)

There are no publically accessible web site relevant to this particular encyclopedia entry.

Author Biography and Photograph (optional)

Dr. Albrecht is a professor for computational and theoretical geography at Hunter College, New York City. He
is author of over fifty refereed publications in the realm of spatial analysis and dynamic modelling. Dr.
Albrecht has been the editor of the URISA Journal for many years and serves currently on their Board of
Directors. In addition, he is involved with the GIS Management Institute and the GIS Certification Institute.

Figures (optional)
Figures are at this point inserted into the body of the text as vector graphics, i.e., resolution-independent.

Permissions
We ask that you complete the permissions template which is available on the project’s website
(http://mrw.elsevier.com/gisy/instructions.html) to identify whether the artwork is either original,
copyright free or copyrighted material.

View publication stats