Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 2002


GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997
Sessions

Applications

Data Development & Evolution

E-Biz

GeoSolucions

Mobile

Municipal Perspective

Network Operations Management

New Technology

Project Management

System Architecture

System Integration

The Human Factor

User Presentations

Work Management


GITA 2002


Project Management


Your mission, should you choose to accept it: Project Management Excellence


1. Poor Planning
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?
  1. 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 July 9, 2002.”
  2. 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 losses 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. Table 1 shows key signs of an unfeasible project.

    Table 1. Signs of an Unfeasible Project
    Reasons “Not to Be” (Signs of an Unfeasible Project)
    1. Major political issues are unresolved by the feasibility study.
    2. Key stakeholders won’t participate in the feasibility study (and therefore the project).
    3. Risks (probability of adverse consequences) are too high (technical, economic, organizational).
    4. Cost and benefit ratio isn’t favorable enough, especially when benefits are “soft.”
    5. Internal staff’s experience and training is insufficient for the project.
    6. Requirements are unclear, or keep changing radically during the feasibility study.
    7. Risk and reward ratio is unfavorable. High risks usually need a high reward to be worthwhile.
    8. Clients (in a multidisciplinary project) can’t agree on exactly what the problems or objectives are.
    9. No executive wants to be the project’s sponsor.

  3. 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.

    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. Table 2 shows several tips for a successful study.

    Table 2. Tips for a Successful Study
    Tips for a Successful Study
    1. Understand the problem before jumping to a solution.
    2. Always include key stakeholders in the feasibility process.
    3. Carefully assess internal development capabilities.
    4. Define requirements clearly.
    5. Distinguish the problem from the symptoms surrounding it.
    6. 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.”
Page 2 of 5
| Previous | Next |

Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book