GISdevelopment.net ---> GITA 1997 ---> Fundamental & Economic Issues of AM/FM/GIS

Life Cycle Approach to Managing an AM/FM/GIS Project

Jay Stinson, PMP
Intergraph Corporation
Huntsville, Alabama 35894-0001 (LR24B1)


Abstract
When determining why projects fail or succeed, one may consider who managed the project which project resources were available, and the methodology utilized by the team to assure a valid development process. Experience indicates that a methodology that applies a disciplined, life-cycle approach offers the best chance for success. This paper will discuss a project’s major phases: assess, define, design, build, deliver, and maintain. It will discuss the project manager’s roles and how he or she can identifi and manage high risk areas. In conclusion, we will discuss why projects fail and what we can do as project managers to avoid the dangers.

Introduction
The three major components of a project are the life cycle process, project management and available resources. By recognizing and managing these aspects, you will increase the chances of being successfid. This approach will help ensure that you have precise user requirements, reasonable and achievable expectations, correct technology choices, cost-effective and efilcient resource allocation, and distinctly identified critical issues. All of this can be accomplished when the goals are well defined and teamwork is paramount.

It is important to realize that the project manager is responsible for bringing together these three major project components. IrI most companies, a project manager does not have direct managerial control over the project personnel. Instead, team members are assigned to the project on an as-needed basis. This means that a project manager cannot depend on positional power to get the job completed, but must convince people that they need to perform the work.

Typically, a project manager has a minimum often years experience and is well-respected by company executives. A project manager usually demonstrates ability in the following areas:
  • Consultation. A project manager should have a working knowledge of the technoloW being implemented. He or she must be able to discuss technical issues and make good business decisions based on that information. The project manager must also have a good working knowledge of the business being addressed by that technology.

  • Sales. A project manager must be able to state convincing reasons to support the project. Ability to sell the benefits of the project and work within the political system are very important.

  • Management. A project manager must have excellent organizational skills to administer a project eftlciently. He or she must also demonstrate strong leadership skills, possess a working knowledge of the different project phases, and define personal responsibilities clearly.
Project Phases
Previously, we referred to the major phases of a project. This section will discuss the major activities and deliverables for each phase. Prior to beginning the first phase (Assess), the company should develop a Strategic Plan, positioning the project objectives in context with the overall corporate goals and directives. Typically, a strategic plan develops a business case for fiture projects and the appropriate sequencing of each project. This three-to-five-year plan will be used as a road map for the corporation’s major system developments and integration efforts.

The company may select an outside vendor or integration company to start the project’s early phases. In an AM/FM/GIS project clients can choose vendors initially, or they can hire an independent consultant to lead them through the selection process. Selecting the primary technology providers prior to the beginning of the assessment phase is recommended.

Assess Phase
The purpose of the Assess phase is to define or develop the following:
  • High-level objectives and goals.
  • The system’s benefits (business case).
  • Diagrams of major systems and interface requirements (Context Diagram).
  • Potential users of the system.
  • The system platform (the operating system, such as Microsoft Windows NT; the relational database system; and so on,),
  • Internal and external resources.
  • Major developmental activities and schedules (high-level Gantt chart).
  • Budgetary estimates (Rough Order of Magnitude).
The result of the Assess phase is a document defining the overall project plan and budgetary estimates. This assessment can then be presented to executive management for approval to proceed to the next project phase.

Define Phase
The Define phase helps avoid a common pitfall in systems development: deciding “how” the system will do the job before deciding “what” the system will do. The tendency is to jump into development without delay. However, experience has shown that time spent in developing the functional requirements for a system reaps great rewards later in the project’s life.

Many companies will conduct Joint Application Design (JAD) sessions with a select group of users and developers to define the system requirements. During this phase, designers will develop more detailed data flow and work flow diagrams along with end-user functional requirements, Information Systems staff will focus on setting standards for technology issues such as software platforms, servers, client stations, and network requirements, The deliverable for this phase is a Functional Requirements Specification (FRS). By the end of this phase, the external vendors should know the system requirements well enough to prepare a fixed-price Scope of Work for designing and building the system.

Desire Phase
In the project’s Design Phase, the requirements and concepts from the Define Phase are refined and embodied in a Detail Design that becomes the blueprint of the system. The design team should pay close attention to design constraints, both business and technical, in order to produce a solution that meets the fictional requirements and the business decision criteria laid out in the Strategic Plan and Assessment document.

During the Design phase, a series of workshops will be held with subject-matter-experts (SMES) to document how the system will be developed. Typically, the design teams are divided into several functional groups. Engineering Design, Outage Management, Work Management and Financial are a few of the business areas that could be involved in an AM/FM/GIS project.

The deliverable from the Design Phase is a comprehensive Detail Design Document (DDD). A peer review or design review is recommended prior to final acceptance of the design. During this review session, the lead designers would walk through the document to validate its viability as a reasonable approach. This is an excellent opportunity to present any issues that management needs to resolve.

Build Phase
Armed with a clear set of requirements and a detail design, the development team can build the AM/FM/GIS application and other necessary applications and interfaces. It is critical that the lead project designers continue with the project as technical leads who will direct the development activity. Documenting the entire design intent is sometimes impossible; therefore, the lead designers must act as interpreters. This continuation of staff helps to ensure a smooth transition from phase to phase. III order to avoid the “big bang” delivery at the end of this phase, a series of incremental deliveries is recommended. This not only provides the project manager with direct feedback on the developers’ progress, but also allows the end users to verify the software by conducting unit tests. Incremental deliveries will greatly enhance your ability to manage project schedules, control user expectations, improve soflsvare quality, and provide direct feedback to your developers prior to final delivery. During the Build phase, the project manager representing the client should turn his or her focus to developing test plans and deployment schedules. These test plans will consist of fictional requirements 354?matrices and work flow scenarios that the system should support. Initial planning for the system deployment should begin in order to assure that the infrastructure will be in place prior to deployment. These activities could include purchases of client and server hardware and software, network infrastructure, end-user training, a configuration management plan, and a support organization to manage and maintain the system.

This phase is concluded with the delivery of the final product. Many clients will conduct a factory acceptance test (FAT) prior to the delivery. By performing this test you will be able to identifi and resolve many major issues prior to the delivery. It should be noted that a formal method of documenting and prioritizing issues of concern should be adopted in order to manage the overall quality and acceptability of the system.

Deliver Phase
The Deliver phase provides for the smooth transition of the system from development to production. A site acceptance test (SAT) is recommended to ensure that the system is acceptable. This phase could involve the following activities:
  1. Install both client and server hardware.
  2. Install baseline software for clients and servers.
  3. Configure the system (define passwords, partition the disk, and so on).
  4. Install custom applications.
  5. Load converted or migrated data.
  6. Execute the test plan.
  7. Resolve identified issues.
  8. Re-execute the test plan.
The system is now operational, but not necessarily in production. At this point the testing team is ready to execute the test plan. Once again, issues of concern are identified and prioritized in a formal manner. Many issues identified during this phase could actually be enhancements, meaning that the system works as designed but does not fimction in the most efficient manner. In these cases, management must be very careful to limit the number of changes necessary for the system to go into production. The danger is that you will continue in the development mode and never deploy the system. Evaluate a change by considering how it will affect the system’s achieving its business case. You carI delay resolving low-impact issues and plan to resolve high-impact issues prior to deployment. The deliverable from the Deliver phase is an integrated system that has gone through a series of tests to assure its acceptability. The system is now ready for production.

Maintain Phase
During the maintenance phase, the team will turn its focus towards deploying the system. In most cases, the greatest volume of problems will be reported to the team during the deployment period. Many new users will utilize the products in ways that the designers never imagined, and data issues will arise that affect the system’s operation. Project Managers must confront performance issues based on hardware and software constraints.

The development team should use the same life cycle approach to evaluating any changes to the system. The team should not abandon its discipline because the system is in the maintenance phase. By following this disciplined approach, you will maintain the same quality that was built into the original system.

Risk Management
One of the project manager’s major roles is managing risk in its many forms. The first step is to identifi the risk item and monitor it very closely during the course of a project. The best method of identifying a risk item is to develop a work breakdown structure (WBS). Each task in a phase should have a duration, resources, and precedents associated with it. The project manager carI monitor the progress of the project by monitoring the WBS on a periodic basis. Many excellent project management tools can be purchased commercially to aid in this effort.

In the WBS, the project manager can identifi high risk areas. Risk can be mitigated by increasing the scheduled time or taking high-risk items off of the critical path. The key is to monitor the risk items on a regular basis. The following are several recommended means of monitoring a project:
  • Conduct monthly (as a minimum) project meetings to discuss schedules and project issues.
  • Conduct peer reviews at the end of the Define and Design phases to ensure that the proper technical approach is being taken. This will also aid in keeping the proposed solution in line with the business requirements.
  • Conduct executive review board meetings on a quarterly basis with project sponsors. During this meeting, bring to their attention issues that need executive support. The project sponsors also appreciate being informed of the progress that the project team is making.
  • Conduct a series of unit tests, factory acceptance tests, and site acceptance tests based on the design specification and test plan. During these test phases, you can monitor the volume of problems reported and make adjustments to project resources based on the results. This approach will help assure that a high-quality product that meets the end users’ business needs will be met.
Once the risk has been identified, a project manager should prepare a plan for mitigating it. This could mean assigning additional resources, changing the schedule, changing the technical approach, or bringing in outside resources. The key is to identify the risk formulate a plan or options for managing it, and monitor the situation so that you will have time to react should the risk become a reality.

Why Projects fail
John Gioia wrote sn article for PMNehvork (November 1996) proposing twelve reasons why projects fail. His reasons are the following:
  1. Understanding program complexity.
  2. Lack of access and internal communication.
  3. Not integrating the key elements (managing pieces of the project in a vacuum).
  4. No measurable controls.
  5. Requirement creep (better known as “scope creep”).
  6. Ineffective implementation strategy.
  7. A software tool to manage the project is not the only answer.
  8. Vendor and customer have different expectations.
  9. No shared “win-win” attitude.
  10. No formal education (project managers are not trained on the process).
  11. Lack of leadership, commitment and sponsorship.
  12. Not viewed as a start-up business (project must be viewed as autonomous).
Mr. Gioia indicates that many of these reasons for project failure are so obvious that people discount them as possible risks. He notes, however, that these problems plague many projects and are worthy of consideration. If you take care of the basics, your opportunity for success will be much greater.

Conclusion
The life cycle approach to a project, combined with competent project management and adequate resources, will help to ensure a successfid project. This disciplined approach will result in a high-quality product that will be developed on schedule and within the budget. Such an approach will also aid in identi~ing and managing risks, ultimately increasing the probability of a successful project.

References
Gioia, John. “Twelve Reasons Why Programs Fail,” PMNetwork, November 1996. Intergraph’s Solution Engineering Methodology.
© GISdevelopment.net. All rights reserved.