David L. Hamil
Your Mission, Should you choose to accept it:
Project Management Excellence
Project failure is endemic in the geo-spatial information systems (GIS)
industry. A recent study performed by KPMG Information Technology, a
Toronto-based professional services company, showed that of the projects that
failed, 87% went more than 50% over budget, 45% failed to produce the expected
benefits, and 86-92% went over schedule. Do you know why 85% of all projects
fail to meet all of their critical measures of success? Do you know how to avoid
the pitfalls and mistakes that can cripple your projects and derail your career?
If you answered no to either of these questions, then your projects may be in
trouble. This paper presents the top 4 factors that have a direct bearing on the
success or failure of a GIS project, and the strategy for substantially
achieving project management excellence.
Technology projects worldwide are costing companies billions of dollars more
than they budgeted for, and almost half don’t live up to the clients’
expectations. Newspapers and business dailies trumpet few project successes but
a massive number of failures. As projects grow larger and more complex with
every passing year, their outcomes – both successes and failures – become fodder
for the media and our competition. Unfortunately, project failures tend to
predominate as they not only make sensational stories but also are far more
What are the odds that your next information systems/information technologies
(IS/IT) project will be delivered on time, within budget, and to user
expectations? Pretty grim, unfortunately, if you dwell on the news propagated by
IS industry analysts. META Group estimates that half of all new United States
software projects will go way over budget (META Group, 2000). The Standish group
says 53% of IS projects overrun their schedules and budgets, 31% are cancelled,
and only 16% are completed on time and on budget (Standish Group, 2000).
The mismanagement of projects to develop the geographic information systems
that companies use to run their businesses has been going on for years and the
situation has not improved. “The management of projects is still treated in a
very amateurish way,” said Nigel Kelly, a partner in KPMG’s IT practices.
For its study, KPMG surveyed the chief executive officers of 1,450 public and
private sector organizations across the U.S. and Canada, and analyzed more than
100 failed IT projects. A project is considered a failure, according to IS
industry analysts, if it was cancelled or deferred because it wasn’t delivering
its planned benefits, or if it had a budget or schedule overrun of more than 30
per cent. Bottom line is that there is an astonishing waste of money here. The
GIS sector of the IS/IT arena is no exception – project failure, sadly to say is
as prevalent in our business, also.
Wow, what a project “horror scope” for you and I. However, the real message
for you and I is not that a project fails, but rather why it fails. In analyzing
these cautionary tales, business leaders can draw on these “lessons learned” to
prevent similar fates in their own project ventures. An analysis of project
failures, both publicized and unpublicized, shows that the principal causes for
project failure can be distilled down to 4 fundamental reasons for project
failure: 1.) Poor planning, 2.) Lack of corporate management support, 3.) Poor
project management, and 4) Lack of customer focus and end-user participation.
GIS evangelists frequently tout the cost savings, improvements in
productivity and services, and market-share increases that GIS can bring to an
organization. Why then, have some organizations that have gone down the GIS road
found the process frustrating and the benefits elusive. According to Dr. Roger
Tomlinson, who is widely recognized as the “father of GIS,” “one culprit is
often to blame – poor planning (Tomlinson, 2001).”
Proper planning is a key project driver for success. The success of any
organization’s GIS implementation depends on thoughtful planning. Dr. Tomlinson
states,“ without such planning, a GIS implementation can easily run over budget
and still not provide any measurable benefits to the organization.” Thus the
formula for a successful GIS is to focus on strategic business needs and know,
going into it, what you want to get out of your GIS.
GIS project planning must occurs at two distinct times – at feasibility study
time and during project implementation time.
A. Feasibility Study Planning
A feasibility study typically is the response to some client-identified
problem or opportunity. It reveals what is required to build a solid business
case, allowing management to make an informed decision about funding or
canceling the project. “To be, or not to be?” is the primary question a
feasibility study answers. This primary question can be decomposed in three
supporting questions: What is this project all about? Should we do this project?
How should we go about this project?
i. What is this project all about?
One primary reason for project restarts, or outright failure, is the lack of
a project mission, which at this early point means a careful analysis of the
problems or opportunities and their possible impact on the organization. Team
members, customers, and other stakeholders need a good understanding of the
project’s fundamental components – goals, objectives, scope, problem statement,
constraints, and vision.
A good test of whether or not a project is understood is to walk around and
ask various participants what they think it’s all about. A crisp,
business-oriented, non-technical answer usually means the project’s groundwork
is well established. The answer could be what we refer to as a project objective
statement: a short, concise, high-level summary of the project. For example, ‘To
identify and deliver a production-ready, state-of-the-art geographic information
system to include online service provisioning and assurance subsystems by
November 29, 2001.”
ii.Should we do this project?
The second major question answered by a good feasibility study is whether or
not the project should proceed. The very name “feasibility” indicates one
possible outcome is not to proceed. A significant portion of the multi-billion
loss on software projects comes from projects that should never have gotten past
the feasibility stage, but got caught up in corporate egos and politics.
Once the problems and opportunities have been identified, the next task of
the feasibility study is to define the criteria for an acceptable solution.
Feasibility (acceptability) incorporates political, economic, technical, and
organizational components. For example, if the senior vice president of
engineering demands that a particular project to be done, why spend weeks coming
up with a detailed cost/benefit analysis? In this case, the “should” question is
fairly easy to answer. It is more effective to spend the remaining time answering
the other feasibility questions.
The second phase of answering the “should” question is to identify the
alternatives and recommend one. The alternative of not continuing the project
should always be thoroughly considered. The following table shows key signs of
an unfeasible project.
Reasons “Not to Be” (Signs of an
- Major political issues are unresolved by the feasibility study.
- Key stakeholders won’t participate in the feasibility study (and
therefore the project).
- Risks (probability of adverse consequences) are too high (technical,
- Cost and benefit ratio isn’t favorable enough, especially when
benefits are “soft.”
- Internal staff’s experience and training is insufficient for the
- Requirements are unclear, or keep changing radically during the
- Risk and reward ratio is unfavorable. High risks usually need a high
reward to be worthwhile.
- Clients (in a multidisciplinary project) can’t agree on exactly what
the problems or objectives are.
- No executive wants to be the project’s sponsor.
iii. How should we go about this project?
A good feasibility study says more than “do it.” In addition to defining the
project objectives and deciding whether or not to proceed, it provides a broad
outline of how to proceed. This involves preparing an initial, high-level
project plan that provides a gross project sizing, identifies major milestones,
and estimates resource needs. A plan of action serves two purposes: it gives the
follow-up team a direction, and it forces the feasibility study team into
thinking about critical implementation issues up front. Figure 1 depicts six simple steps
for feasibility analysis.
The success or failure of a project is often decided very early. To pull off
an effective feasibility study, you must have the right attitude and the right
approach. Having a good feasibility study process without the proper commitment
from management and staff to listen to the answers doesn’t work well – it
results in substance without form. Having a commitment to listen, but without
the substance of a reasonable feasibility study process isn’t much better. Doing
a feasibility study takes time up front, and it will likely result in a later
start date for a software project. The potential benefit you’ll receive from starting
slow, however, is a quality product finished on time and within budget.
The table below shows several tips for a successful study.
Tips for a Successful Study
- Understand the problem before jumping to a solution.
- Always include key stakeholders in the feasibility process.
- Carefully assess internal development capabilities.
- Define requirements clearly.
- Distinguish the problem from the symptoms surrounding it.
- Resolve political issues.
B. Project Implementation Planning
The solution to successful project implementation planning is to develop an
understanding of the full scope of the GIS project. Using the results of the
feasibility study as a basis, you must achieve answers to the following
questions: What you’re building? Why you’re building it? What are your
requirements? Who your customer is? Who’s in charge of the project and who are
the key or required staff? What are the risks? What are the benefits? What are
the major milestones and target dates for each? And of course, it’s also
important to understand what your project isn’t. A project that tries to meet
everyone’s objectives likely will please no one.
The answers to the above questions, along with many others, should be
documented in a formal, approved document, called the “Project Plan,” which is
used to manage and control project execution. The project plan is a single
document or collection of documents that should be expected to change over time
– a “living” document – as more information becomes available about the project.
A solid project plan is a blueprint, or a game plan, that charts the entire
project’s course. For example, the risk assessment portion of the plan should
help to minimize the cost of rework by anticipating and addressing problems
early in the project. According to the Project Management Institute (PMI, 2000),
“there are many ways to organize and present the project plan, but it commonly
includes all of the following:
- Project description and overview,
- A description of the project management approach or strategy,
- Scope statement, which includes the project deliverables and the project objectives,
- Work breakdown structure (“WBS”) to the level at which control will be exercised,
- Cost estimates, scheduled start dates, and responsibility assignments to the level of the WBS at which control will be exercised,
- Performance measurement baselines for schedule and cost,
- Definition of project success criteria,
- Major milestones and target dates for each,
- Subsidiary management plans,including:
- Risk management plan that identifies key risks, including constraints and assumptions, and planned responses for each,
- Resource management plan,
- Schedule management plan,
- Cost management plan,
- Quality assurance/quality control plan, and
- Communications plan.
C. Project Planning Summary
The fundamental premise of achieving excellence in project management states
that the project manager’s greatest challenge is effectively balancing (or
juggling) the components of time, cost, scope, quality, and expectations for each. Figure
2 shows the project diamond, which signifies this balance.
The components of the project diamond have a symbiotic relationship. For
example, when a user requests an additional report that wasn’t agreed on in the
requirement specifications, the project’s scope and quality change. This will
change the other project components as well. As a result, the diamond’s shape
will be skewed, graphically depicting a project out of control. The challenge is
managing change while keeping the diamond’s shape intact. Project planning
defines the diamond, while effective and efficient change and expectation
management lets you manage it throughout the project’s life cycle.
Effective project planning is not conducted in a vacuum. It must be carried
out in coordination and cooperation with all appropriate stakeholders. The
project manager must manage their expectations throughout the process. The
project manager must constantly look for opportunities to create win-win
relationships by negotiating work that must be accomplished. A project manager
who declares, “this can’t be done in the time frame allotted” will meet with
stiff resistance from client management. On the other hand, a project manager
who can defend this statement with a solid understanding of the project’s scope,
backed by a logical work breakdown structure; thoughtful estimate and project
schedule; and concise risk analysis will be met with a response like, “Maybe
you’re right. Help me to understand what you understand.” This is effective
expectation management and proper development of win-win relationships. Once
your project plan is in place, it’s much easier to manage your project
2. LACK OF CORPORATE MANAGEMENT SUPPORT
Does your project have the full cooperation and support of corporate
management? If not, then you’re project is likely doomed to cancellation or
cutbacks. Your project is not the only game in town. Make sure you have a dedicated sponsor who will support your
project from inception to completion, such as a project manager that communicates
resource needs early and often to his or her senior management.
A project succeeds only when senior leadership makes it a top priority and
broadly communicates their sponsorship across the organization. Organizations
respond when leadership emphatically communicates their commitment to the
project. All levels, from the bottom through the middle to the top, must remain
sensitive to the needs and priorities of the project.
Without the commitment of our upper management, then our projects may suffer
in any one or more of the following areas:
- Inadequate Staffing – Your team cannot set and maintain direction if key positions are left unfilled or
inadequately filled for a long period. This is where the inner-company politics
come into play. The project manager must aggressively seek out talent. They must
identify the critical skills and characteristics needed for success in an open
position. They must organize a selection process that leaves little question
about what team members can do and how they would fit within the project team.
A project manager is only as good as his or her team; don’t let your ego distract
you from your project’s goal. Work with your senior management to assemble a
talented team, provide resources and ground rules, and let the players take
ownership of the target solution. You’ve probably heard the statement, “80% of
management is picking the right people, and the other 20% is getting out of
their way.” A good project manager must create an environment where the “right
people” can perform optimally. You have to work hard to fail if you have the best people.
- Unfulfilled Commitments – The project manager should
always engage in good-faith commitments with customers and managers about what
is realistically achievable. In spite of this, if the project manager loses, or
never fully obtains support from his or her senior management, then even such
commitments as funding, staffing availability, and hardware and software needs
may be unachievable.
- Inadequate Funding – It almost goes without saying that a project is “dead” if funding is insufficient or if funding
is cut. Corporate management will put their money where they believe they will
receive the most benefits. If you, as the project manager, truly believe in your
project and can communicate both its short- and long-term benefits, then you
must be that “champion for the cause” to keep your project funded.
3. POOR PROJECT MANAGEMENT
Project management can be subdivided into two categories – the software
development process, and the role and responsibilities of the project
A. Software Development Process
GIS projects, like a project for constructing an automobile, must have an
ordered set of steps for taking what started as a concepts in someone’s mind to
a real product that usable by the client. Without a sound software development
process, GIS projects can easily run astray. Many organizations that undertake a GIS
project do not fully embrace a defined, repeatable, and predictable software
development process. The consequence of this behavior usually is a significantly
increased risk to the project in predicting and controlling the critical factors
of schedule, cost, scope, and quality.
According to Neal Whitten, a world-renowned project management author and lecturer, “an
organization may have currently defined processes, but those processes are
ineffective for one or more of the following reasons (Whitten, 1995):
- Not comprehensive enough: they do not already define all of the activities that
apply to all new projects,
- Overly complex: they require too much time and skill to comprehend and apply,
- Not flexible: they are not easily tailored to meet the unique needs of new projects,
- Not “owned”: there is weak or no buy-in from the project’s members,
- Not continuously improved: lessons learned from past projects are not used to improve the current processes, and
- Not enforced: the guidelines are there, but the project leadership lacks the discipline to
Even worse is the situation where a software development process is not
followed because a process has never been defined and documented fully. Having
no software development process, or not following a defined process, is
indicative of an organization that, albeit perhaps unintentionally, lacks the
vision and discipline to become or maintain a world-class position in the
fiercely competitive software industry. A software development process offers a
framework from which to plan a new project, avoid repeating mistakes of past
projects and improve on things that went well.
Whitten classified eight steps that define a software development process (Whitten, 1995). The
top three steps are:
1. Identify the software model – The first
step in defining a software development process is deciding on the software process
model that best fits the needs of your organization and the type of project you
are implementing. There are numerous models and variations of models from which
to choose. Most models are derived, at least in part, from one or more of the
following basic models: Code-and-Fix Model, Waterfall Model, Incremental Model,
and Iterative Model.
2. Identify the Activities– Once the software model has
been selected, the next step is to identify the primary activities that need to
be implemented to satisfy it. A representative list is as follows: Requirements
Definition, Functional Design, Detail Design, Test Plans/Procedures, Code, Unit
Testing and Incremental Deliveries, Integration Testing, Regression Testing,
System Acceptance Testing, Software Packaging and Delivery, Training
Plans/Procedures and Training.
3. Identify the Relationships Among Activities –
With the activities defined, now identify the relationship between related
activities. This can be achieved by listing the entry and exit conditions for
Let’s look at the entry and exit conditions for the Functional Design
Entry Conditions: The approved requirements, as set forth during the
Requirements Definition, are distributed for review.
Exit Condition: The GIS functional specifications are reviewed and approved
prior to proceeding on to the Detail Design activity.
B. The Role and Responsibilities of the Project Manager
KPMG’s Kelly stated, “The management of projects is still treated in a very
amateurish way.” Although some of the blame can be placed on the software
development process, or a lack thereof, the primary place to “point is finger”
when poor project management comes into play is a failure by the project manager
to “manage the project.”
Simply put, the project manager is “the” individual with the responsibility
for managing the project. To get results, the project manager must relate well
to: the people to be managed, the tasks to be accomplished, the tools available,
the organizational structure, and the organizational environment, including the
I have identified six key competencies of a “top gun” project manager:
1. Education and Experience in Project Management – Organizations that undertake
the management of very diverse projects must possess thorough knowledge of
project management and implementation. Along with up to date formal training,
the project manager should learn “on the job” before he or she is placed solely
in control of managing a project. Remember, project management and
implementation is a craft, not a science – you can’t quantify all of it. At some
point, you’ll have to rely on your own intuition and experience to substantially
ensure success. All in all, the project manager must possess the skill set to be
able to manage their project, from inception to completion, using the
organization’s software development process.
2. Negotiation and Communication Skills – Another of the key competencies of a “top gun” project manager are his
or her ability to effectively negotiate and communicate with senior management,
direct reports on the project team, the client, supporting organizations, and
other stakeholders who have a vested interest in the success of the project.
3.Planning and Organization Skills – Recall the number 1 reason for project failure,
is poor planning. The project manager has direct control over this and can establish the necessary measures to
“build the proper foundation” that will be a stepping-stone to project success. Coupled with proper planning,
the project manager must be a good ringleader who minimally organizes meetings, schedules,
deliveries, financial statements, and various other plans to substantially
ensure his or her project is targeted for success.
4. Effective Problem Solver –
Due to the complexity and diversity that may exist within a project (e.g., a GIS
data migration project), the project manager is often called on to analyze
problems and make timely, strategic decisions that can have a profound affect on
the project – whether good or bad. The project manager should be skilled at
being able to isolate the root cause of a problem at any given moment in a project, and if
necessary enlist the help of his or her project team to “buy into” the solution.
5. Leadership Ability – The best leaders spend much of their time just watching
and taking it all in. They avoid jumping to conclusions or leaping to premature
judgments. They try to understand what is needed and why. They are constantly
learning from minute to minute as well as from year to year.
Never forget that every leader is always being watched. Set the standard with your own
attitude and performance. If you demand thoroughness, practice it. If you expect
openness to new ideas, listen and consider. If you want to promote teamwork, be
a team player. If you want good communication, communicate well. Sure it’s
obvious, but it can be darned hard at times to practice what you preach.
6. Aims for Excellence in All Work – Although I believe much of how a project manager
functions in his or her daily work is characteristic of their very nature, the
project manager can learn to aim for no less than the best. The project manager,
of all people on the project team, must strive for excellence in “all” project
work, and expect no less than the same from his or her project team. Achieving
excellence in a couple of areas, but missing the mark in others is not
acceptable. For example, if the team meets a particular software delivery date
and kept the expenditures within budget, but what the team delivered does not
meet the quality expectations, as defined by the client, then we have missed the
mark on achieving overall project excellence. It’s a tall order, but one that we
should strive for.
All in all, seasoned project managers are good ringleaders. They know they
must balance four elements of expectations – quality, schedule, cost and scope –
at all times. Quality shouldn’t be sacrificed to adhere to a rigid schedule or a
tight budget. Nor should a schedule be tossed aside because of an obsessive
focus on quality. Yet in even the most well managed project, sometimes it makes
sense to ease up on a deadline, a budget or a quality-control process. But these
slips shouldn’t simply happen. They should come from conscious decisions made by
project managers who understand their objectives and know that project
management is a balancing act.
4. LACK OF CUSTOMER FOCUS AND END-USER PARTICIPATION
Are your users involved in the system requirements definition process, the
system design process, and throughout the project’s implementation and testing
phases? If the customer loses focus or is never fully engaged in the project,
then your faced with the situation where the project deliverables likely will
not meet the client’s expectations.
User involvement is a key driver for a successful project. It is
absolutely imperative that the customer, including the end-user of the GIS, be
proactively involved throughout all lifecycle phases of the project. The end
users are powerful and are only becoming more so. Their power can work for you,
or against you. To have their power work for you then make sure the client’s
users are a part of the project team, and that you involve them during
requirements gathering, application design, prototyping, testing, and
incremental acceptance. If you, as the project manager, do not include the very
users who will be using the GIS, then you may not achieve buy-in to the new
system. Far too often, lack of buy-in by the true GIS users causes the system to
be “shelved.” Oh yes, the system may satisfy every requirement, pass every
acceptance test procedure, and receive signoff by the client’s project manager.
However, it could fail to pass the real test – user acceptance.
The client involvement, and in particular the end-user participation, can
“make” a project. Reminder, the end users are probably the most powerful
organism in the client’s organization. Let’s ensure that they’re playing on our
Considering that billions is spent each year on IT software development in
the U.S. and Canada alone, the KPMG and Standish findings painted an alarming
picture of project mismanagement in both private and government sectors. There’s
a buyer beware message to the extent that the clients need to understand what
they want, what they are getting, and go after it with a vengeance. Clients need
to be able to quantify and qualify project benefits, have it planned initially,
managed properly, and its status monitored early, often and closely.
Remember, all software projects run into snags – no project is immune from
failure. The potential troubles are well known: missed deadlines, blown budgets,
unmet expectations, and internal resistance – the list goes on and on. How teams
respond to problems determines the project’s eventual success or failure. Avoid
past mistakes by responding effectively to problems as they arise. The trick is
to manage a project in a proactive way, preventing some problems and minimizing
the effects of others. With proper planning, support of senior management, sound
project management, and active client involvement, a GIS team can bypass many
While there are essentially 4 principal reasons why projects fail, as I have
documented here, it only takes one of them to make the difference between
success and failure.
While avoiding the mistakes of the past, never forget to stop and celebrate
successes, even the small ones. GIS technology is taking organizations places
they’ve never gone before. So when you get somewhere that you’ve never been, be
sure to have your team pull over to take in the view. Then, push on together.
META Group. 2000, www.metagroup.com, META Group, Stamford.
Standish Group, 2000, www.pm2go.com, The Standish Group International, West Yarmouth.
Tomlinson, R. 2001., Planning for a GIS, Environmental Systems Research Institute, Redlands.
Whitten, N. 1995., Managing Software Development Projects, John Wiley & Sons, New York.
David L. Hamil, PMP
Program Director - Systems Integration
MESA Solutions, Inc., a Telcordia
7800 Madison Boulevard, Tower Building; 4th
Huntsville, AL 35806
Phone (256) 864-0400
Facsimile (256) 864-0251
David was a charter member of MESA Solutions in 1997. David, along with a couple of other program
directors, oversees the management of automated mapping/facilities management/geographic information
system (AM/FM/GIS) solutions for MESA’s clients in the telecommunications, cable, electric, gas, and
water industries. In addition, David is responsible for working with his senior management to grow MESA’s
systems integration presence worldwide by participating in joint business opportunities with companies
who currently hold a worldwide presence – Environmental Systems Research Institute and Telcordia Technologies.
David has been involved in AM/FM/GIS projects since the early 1990s. He has assessed, defined, design
and implemented telecommunications and electric solutions for various customers; both domestically and
internationally. His experience lies across standard facility documentation and management, data conversion
and migration, operational support systems, SCADA, CIS, CRM, and ERP.
Prior to his AM/FM/GIS work, David designed and implemented digital image processing software for the DOD.
M.S. – Systems Analysis, University of West Florida, 1987.
B.S. – Computer Science, University of West Florida, 1982.
Honors and Professional Affiliations
- Attained Project Management Professional (PMP) status, 1999.
- Completed Project Management Certification Program, University of Alabama in Huntsville, 1997.
- Received U.S. Patent 4,901,361 for an DOD-specific image processing application, 1990.
- Member - Project Management Institute (PMI).
- Member - Geospatial Information & Technology Association (GITA).
- Presented and published several papers related to project management.