SE GIS
Project Plan
Project Plan
SE Spatial Data Management Project
A Component of
Saskatchewan Environment Enterprise SDE/GIS Implementation
Author: Ken Yurach
Creation Date: November 21, 2003 Last Updated: ongoing
Version: 1.0
Acknowledgement :
Saskatchewan Environment adapted the following project plan from a document created by Alaska Department of Natural Resources with permission and assistance from the author, Richard
Clements.
Clement, R. 2000. A Component of
TABLE OF CONTENTS
APPROVALS
...4SIGN-OFF SHEET ...4
INTRODUCTION
...5PURPOSE OF PLAN...5
BACKGROUND INFORMATION ABOUT THE PROJECT...5
PROJECT APPROACH...5
GOALS AND OBJECTIVES
...7BUSINESS GOALS AND OBJECTIVES...7
PROJECT GOALS AND OBJECTIVES...8
SCOPE
...9SCOPE DEFINITION...9
COSTS, BENEFITS AND RISKS...10
PROJECT PRODUCTS/DELIVERABLES LIST...10
MILESTONES...16
IMPACTED BUSINESS AREAS...16
ASSUMPTIONS
...17 PROJECT ASSUMPTIONS...17CONSTRAINTS
...17 PROJECT CONSTRAINTS...17 RELATED PROJECTS...17 CRITICAL DEPENDENCIES...18QUALITY MANAGEMENT APPROACH
...18ACTIVITY REVIEWS/WALK-THROUGHS...18
PERFORMANCE/QUALITY STANDARDS...18
TRAINING...18
PROJECT MANAGEMENT APPROACH
...19WORK BREAKDOWN STRUCTURE (WBS) GANTT CHART...19
BASIS OF ESTIMATES...19
PROJECT EFFORT ESTIMATION...19
PROJECT STANDARDS...19
PROJECT ROLES, RESPONSIBILITIES AND COMPETENCIES...19
PROJECT TEAMS MEMBERSHIP SELECTION CRITERIA...21
CHANGE AND ISSUE MANAGEMENT APPROACH...21
COMMUNICATIONS AND CONTROL APPROACH...21
ATTACHMENTS/APPENDICES
...23APPENDIX A – PROJECT WORK PLAN...23
APPENDIX B – RISK ASSESSMENT...28
APPROVALS
Sign-off Sheet
I have read the above Project Plan and will abide by its terms and conditions and pledge my full commitment and support for the project.
Executive Sponsor:
EXEC. Com Date
Executive Sponsor:
EXEC. Com Date
Executive Sponsor:
EXEC. Com Date
Executive Sponsor:
EXEC. Com Date
Executive Sponsor:
Grant Godwin, Director IMB Date
Project Manager:
Ken Yurach Date
Project Team Member:
IMB Staff Date
Project Team Member:
IMB Staff Date
Project Team Member:
F&W Staff Date
Project Team Member:
FEB Staff Date
Project Team Member:
INTRODUCTION
Purpose of Plan
The purpose of this plan is to provide definition of the SE Spatial Data Management Project, including the business goals, objectives and project scope. This plan will serve as a contract between the Project Manager, Departmental Sponsor and Project Team members and other Saskatchewan Environment management associated with or affected by the project.
Background Information About the Project
The SE Spatial Data Management Project began during 2002 – 2003 budget cycle and serves as a vehicle to reach many long-term goals identified over the past years. Earlier initiatives were
smaller in scope due to lack of funding, lack of resources and technological constraints. SE staff have been working towards an operational Enterprise GIS model which included SDE implementation over the past few years. Acquiring many of the necessary components as funding became available from a variety of sources.
Project Approach
To be successful, this project will require a common vocabulary, teamwork, leadership and a well-defined and accepted project cycle. These elements are common to successful projects that have been implemented in the public and private sectors.
The project will depend on these teams:
Team Team Members Responsibilities1
Project Team Project Manager and technical staff
Planning, scheduling and controlling (Project Manager) Completing the deliverable
product at the User-Required performance, within cost, on time and within scope.
Project Review Team Representatives of the financial, business and technical sectors of SE
Ensure that the project is within scope, on or under budget and satisfies the customers’ needs
Status Plat SuperUser Team
Technical representatives from all impacted SE areas
User Requirements and Functionality Review Transition Stage / Training
This project will be proactively managed in an orderly, methodical and disciplined way. The project cycle will be conducted in a sequence of three or five stages. The number of stages will be
determined after the initial Study Stage (see Appendix A – Project Work Plan). These phases represent milestones in the project timeline.
The project is controlled by a series of gates. These gates occur at the end of each phase (see Appendix A). At these gates, the Project Review Team will analyze the deliverables. This analysis results in acceptance, rejection or a request for project change. If accepted, the Development Team continues to the next phase. If rejected, the Development Team starts the phase again. If the Project Review Team requests a change in the project, the Development Team calculates the results of the change. These results are used to update the deliverables. These deliverables are resubmitted to the Project Review Team. This cycle is performed until the Project Review Team accepts the phase deliverables.
GOALS AND OBJECTIVES
Business Goals and Objectives Goals: Saskatchewan Environment 6DVNDWFKHZDQ(QYLURQPHQWPDQGDWHLVWRPDQDJHHQKDQFHDQGSURWHFW6DVNDWFKHZDQV QDWXUDODQGHQYLURQPHQWDOUHVRXUFHVILVKZLOGOLIHODQGVIRUHVWVSDUNVDQGSURWHFWHGDUHDVDLU ZDWHUDQGVRLOIRUFRQVHUYDWLRQUHFUHDWLRQVRFLDODQGHFRQRPLFSXUSRVHVDQGWRHQVXUHWKH\DUH VXVWDLQHGIRUIXWXUHJHQHUDWLRQV 6SHFLILFDOO\WKHGHSDUWPHQWVPDQGDWHLV
• Protection of primary resources including air, water and soil using regulatory and non-regulatory controls;
• Management and protection of natural resources including forests, fish, wildlife, lands, parks and their natural and cultural resources, in such a way as to ensure their sustainability and biological diversity;
• Assessment, regulation, minimization, and mitigation of the impact of alterations to the natural
environment by development activities through implementation of the environmental impact assessment program;
• Maximization of economic and social benefits from renewable resources and programs while maintaining resource sustainability;
• Promotion of public, stakeholder and Aboriginal peoples’ involvement in environmental and resource management through developing and enhancing public involvement programs and partnerships;
• Promotion of respect and a sense of stewardship for the environment and its natural, recreational and cultural resources through interpretive programs, partnerships, and informational materials; and
• Cooperation in the development of interjurisdictional, national and global initiatives aimed at enhancing environmental and resource conservation and management.
Project Goals and Objectives Goals:
This project shares many goals in common with departments roles and responsibilities. Some of these are listed below along with those that are unique to the SE Spatial Data Management Project.
• Improve corporate and public access to Environmentally sensitive data
• Bridge related provincial and federal land record systems by implementing open systems, standards-based design for accessing and maintaining provincial land data.
• Significantly reduce the amount of time for decision-making by providing better access to current and timely information about current land conditions and related information.
• Deliver accurate Internet-based mapping and data querying capability to the department
• Build a foundation that will accommodate other program’s based components
• Design and implementing standard map products displaying land status information that serve the business needs of SE staff and the general public
Objectives:
• Improve access to land related information
• Decrease duplication of effort and data redundancy by over 25%
• Reduce risk to Province due to inaccurate land status information
• Upgrade all department spatial data to the provincial and national standards - NAD83 (North American Datum 1983)
SCOPE
Scope Definition
These items are within the scope of this project:
1. Design, develop and implement a relational database system containing spatial and tabular SE data and selected base/framework data (NTS, Cadastre).
2. Design, develop and implement a data warehouse methodologies using relational database technology containing a selected subset of SE data
3. Design, develop and implement a system to maintain SE spatially referenced information utilizing ArcSDE technology.
4. Design, develop and implement systems to update a selected subset of SE data in geo-database.
5. Eliminate redundant data entry tasks identified in the current SE Datasets and business processes.
6. Design, develop and implement a publicly available web-based application to view provincial land status information.
These items are NOT within the scope of this project:
1. Design and develop a system to maintain existing applications.
2. Design and develop a system that delivers on-line mapping capabilities of Environmental and resource information.
3. Provide maintenance for any and/or all systems completed by the Project Team while carrying out this project, t he data maintenance work will be performed by other designated staff in SE.
Costs, Benefits and Risks
The benefits of this project will be realized by the department and the entire provincial environmental community and other members in the public and private sectors by decreasing the amount of time required to publish the results of a change in land status (cycle time). This will lead to more informed decisions by private and public parties when determining areas open for access, permitting, leasing, and other land transactions.
Project Products/Deliverables List
Each phase deliverable will require and include:
• An analysis of the risks involved in implementing the results found in the phase. These will address the technical, budget and business aspects of the phase. This will include a risk mitigation analysis.
• A detailed Work Breakdown Structure (WBS) describing the next phase. • A signed document by the sign-off participants.
The Project Deliverables are listed on the following pages. The deliverables roughly correspond to the project phases, yet not all phases of the project have a deliverable. Some phases have been rolled together to form one deliverable. Each phase listed below is described by:
Product Name The name of the physical product or deliverable. Product Type Format of the product.
Description Description of the product.
Purpose The reason that the product is required for the projects’ success.
Tasks An overview of the types of tasks required creating the product. This is not intended to be exhaustive; The WBS will list all tasks for each phase. Audience A list of the team(s) that will be involved in creating the product. Sign-off
Participants
1. Study Stage
1.1 User Requirements Definition Phase Product Name: User Requirements Document Product Type: MS Word2000, MS Excel2000
Description: Descriptive document and spreadsheet identifying all user requirements. Purpose: Comprehensive listing of requirements for Project Team evaluation.
Tasks: Assessment by the Project Team as to the difficulty of implementation on a scale of 1 to 10, with 1 being simple and 10 being impossible. Each requirement will be assigned a value/cost to implement. Each requirement will be evaluated to determine if the requirement is within scope, as defined in this document.
Audience: Project Team, Status SuperUser Team Sign-off Participants: Project Review Team
1.2 Current Functionality Assessment Product Name: Current Functionality Document Product Type: MS Word2000, MS Excel2000
Description: Listing of current functionality used by Status Graphics technicians (Cartographers) to create, update, read and delete the LSGIS data. List of interfaces with other systems or subsystems and their purposes. List of data access methods used by customers.
Purpose: To support an analysis of the gap between the required functionality and the current functionality. This analysis will identify the “must have” function that are required by the business to support the users and is an important ingredient for phase 1.6, Software Evaluation Phase.
Tasks: Assessment by the Project Team of the current software modules that are required to support the business needs.
Audience: Project Team
Sign-off Participants: Project Review Team 1.3, 1.4 Database Design
Product Name: Database Design
Product Type: Entity Relationship Diagram with supporting textual description Description: Entity relationship model (ERM).
Purpose: Develop an unambiguous, implementation-independent data model that can be used by developers for constructing the database.
Tasks: An iterative, prototyping approach will be taken for the database design. The system will be designed to support the create, replace, update and delete functions (CRUD) for the spatial data. It is assumed that the FEB and FWB data will supply all the textual components of the database. These textual components will be stored in a data warehouse within the same system as the spatial data. This warehouse will be updated from their respective databases of record.
Audience: Project Team
1.5 Database Physical Implementation
Product Name: Database Physical Implementation
Product Type: MS Word2000, MS Excel2000 and other diagrams and code; database implemented with Oracle8i and ArcSDE technologies
Description: Documents describing database implementation in Oracle8i Purpose: Describe the methods used to implement the logical database design
Tasks: Implement the database described in the Database Design documentation, write DDL statements to create the physical database
Audience: Project Team
Sign-off Participants: Project Review Team Data Conversion
Product Name: Data Conversion
Product Type: MS Word2000, MS Excel2000, diagrams and charts, code and spatial/tabular database(s).
Description: Documents describing the mapping of the current FEB, IMB, and FWB data to the logical database design described in the Database Design documentation. Code (most likely AML and SQL), which performs the conversion of the data and the population of the physical database.
Purpose: To document the data conversion process, and convert the data.
Tasks: Writing documentation; designing, developing, prototyping, debugging and executing scripts that perform the data conversion. Performing quality control, statistical analysis and verification on data conversion methods and results.
Audience: Project Team
Sign-off Participants: Project Review Team 1.6 Software Evaluation
Product Name: Software Evaluation
Product Type: MS Word2000, MS Excel2000, diagrams and charts.
Description: Documents describing the evaluation of commercially available software based on the business needs and technical requirements identified in phases 1.1 and 1.2.
Purpose: To quantify the functionality of database and data input/update software and assess the use of those software tools with the required functionality described in the User Requirements Document. Tasks: Design an evaluation strategy based on the business objectives, scope and risks. Assess qualified vendors products against the requirements. Identify a possible commercial, off-the-shelf (COTS) solution if no customization to the products is required. Identify any needed customization to the products and assess degree of difficulty required to customize the products.
Audience: Project Team, Project Review Team Sign-off Participants: Project Review Team
2. Interface Design Stage 2.1 System Model
Product Name: System Model
Product Type: MS Word2000, MS Excel2000, diagrams and charts. These will use the UML1 (version 1.2) notation.
Description: Detailed analysis of the business activities described by the project scope.
Purpose: To create an abstract model of the processes described in phases 1.1 and 1.2. This model is critical for the system design.
Tasks: Analyze and model all processes that will be used to create, replace, update, delete and read all the data.
Audience: Project Team
Sign-off Participants: Project Review Team 2.2, 2.3, 2.5, 2.6 System Design
Product Name: System Design
Product Type: MS Word2000, MS Excel2000, diagrams and charts. These will use the UML (version 1.2) notation.
Description: Detailed system design that supports the system model.
Purpose: To create a system design in terms of the automated and manual procedures that will comprise the system. Develop outline dialogs and proposed screen layouts for the most important automated system procedures.
Tasks: Map the system processes (identified in phase 2.1) to procedures that can be translated to application code. An iterative approach will be taken with validation of the design by the Status Plat SuperUser Team and Status Graphics Unit technicians.
Audience: Project Team, Status Plat SuperUser Team, and Project Review Team Sign-off Participants: Project Review Team
2.4 Prepare Implementation Strategies
Product Name: System Implementation Strategy
Product Type: MS Word2000, MS Excel2000, diagrams and charts. These will use the UML (version 1.2) notation.
Description: Documentation of a transition, or “cut-over” strategy
Purpose: To plan the implementation of the new system. This may include dramatic changes to the current processes that support the requirements of the current system.
Tasks: Identify and document the new business practices that are defined in the system design. Audience: Project Team, Status Plat SuperUser Team, and Project Review Team
3. Construction Phase 3.1 Preparation
Product Name: Construction Preparation, Requests for Proposals (RFP’s) Product Type: MS Word2000, MS Excel2000, diagrams and charts
Description: Documents describing the testing facilities and test strategy. Requests for Proposals that can be delivered to prospective software engineering firms.
Purpose: To identify the criteria that will be used to test the completed system, identify software engineering firms.
Tasks: Develop a comprehensive set of testing procedures for all aspects of the system. Develop detailed RFP documents. Identify software engineering firms. Release RFP
Audience: Project Team
Sign-off Participants: Project Review Team 3.2 Construction
Product Name: System Construction
Product Type: Computer code, MS Word2000, MS Excel2000, diagrams and charts
Description: Completed business system, description of construction methods, testing methods and source code.
Purpose: Completed business system that satisfies the functional requirements identified in the system Design document (phase 2.5)
Tasks: Build completed business system.
Audience: Contractor (?), Project Team, and Project Review Team Sign-off Participants: Project Review Team
3.3 System Documentation
Product Name: System Documentation
Product Type: online user help files, MS Word2000, MS Excel2000, diagrams and charts Description: Detailed documents describing system as coded.
Purpose: Document the final system and develop operational instructions.
Tasks: Through documentation that describes all aspects of the completed business system. Audience: Contractor (?), Project Team
Sign-off Participants: Project Team, and Project Review Team 3.4 Transition Preparation
Product Name: Transition Preparation
Product Type: MS Word2000, MS Excel2000, diagrams and charts
Description: Documents describing the implementation of the completed business system Purpose: Development of a transition plan to implement the completed business system
3.5 Verify Construction
Product Name: Completed Business System Acceptance Product Type: MS Word2000
Description: Verification of completed business system
Purpose: To ensure that the system meets the required functionality
Tasks: System testing as described in the documents developed in phase 3.1. Audience: Project Team, Status Plat SuperUser Team
Sign-off Participants: Project Review Team 4. Transition Stage
4.1 Conduct User Training Product Name: User Training Product Type: MS Word2000
Description: Initial user training with the completed business system.
Purpose: To develop new training material and to augment the operational material developed in phase 3.3
Tasks: Plan training curriculum, plan training dates, develop training material. Audience: Project Team
Sign-off Participants: Project Review Team 4.2, 4.3 Install Production System
Product Name: Production Installation
Product Type: MS Word2000, MS Excel2000 Description: Installation of the production system
Purpose: To create a manual for the installation of the production system that accounts for the current hardware and computer systems.
Tasks: Analyze current (and possibly planned) hardware and operating systems, including versions, etc. Update any installation procedures developed during earlier project phases. Install production system; negotiate maintenance, turn over maintenance to operations personnel. Verify that installation was performed successfully. Tune infrastructure, fix problems.
Audience: Project Team
Sign-off Participants: Project Review Team 4.4 Wrap-up
Product Name: Completion Report
Product Type: MS Word2000, MS Excel2000 Description: Quantitative summary of the project
Purpose: To bring an orderly conclusion to the project and to document the results.
Tasks: Summarize project achievements, identify lessons learned, evaluate possible best practices for future projects, release project resources.
Audience: Project Team
Milestones
The completion of each stage in the project cycle defines a milestone. Other intermediate phase completions may be considered a milestone, as defined by the Project Manger, Project Team, Project Review Team and management.
Impacted Business Areas
These areas of the Saskatchewan Environment and the public will be impacted during and after the execution of this project:
Operations Division Programs Division
Policy and Assessment Division Corporate Services Division Information Services Corporation
Other Departments of the Province of Saskatchewan Public
ASSUMPTIONS
Project Assumptions
The Project Team and the Project Review Team will work together to satisfy the needs of the customers.
Management will gain support from all affected parties to ensure that a spirit of cooperation exists during the execution of this project.
SE resources will be made available as described in the Work Breakdown Structure (WBS) for each phase.
An open systems approach will be taken when selecting tools and components.
The Java/Xml programming language will be used wherever possible to leverage cross-platform deployment and utilization of existing SE computer systems.
CONSTRAINTS
Project Constraints
The project must work within the limited budget and tight timelines agreed to in this document. The project will use the current hardware and network configuration in existence at SE.
Related Projects
Other projects within SE have been identified which have similar or complementary goals and objectives. These are:
- SWIM - TIS
- FIS
- SFC VDW
The Project Manager for the CoreGIS project will make every effort to work together with the other project managers so that efforts are not redundant and that resource conflicts are resolved.
Critical Dependencies
Cooperation between all impacted SE divisions to ensure that all user requirements are gathered during the Study Stage, and that all users validate the functionality of the products prior to the Transition Stage. These stages will require that users’ time is made available by SE management.
QUALITY MANAGEMENT APPROACH
Activity Reviews/Walk-throughs
A thorough review of the results from the Software Evaluation and Application Solution Phase will be conducted. If the products require customization or a completely new application is constructed (Stage 2 – Interface Design Stage and Stage 3 – Construction Stage), then a thorough review will be
conducted at the completion of Stage 2. It is important to review the project deliverables at that time with a wide audience (customers, management, Project Review Team and other affected parties) to validate that the system design is meeting the customers’ requirements, the business need for the products. It is also a critical time to review the project budget.
Other reviews will be conducted as needed. These will be arranged through negotiations with the Project Manager.
Performance/Quality Standards
The project will use these database and software development standards: • OMG Unified Modeling Language Specification (version 1.2)
• ????? database modeling notation
• Conformance Test Guidelines for OpenGIS Simple Features Specification for SQL, Revision 1.1 The project will also use the following standard as a guide for database design:
• Cadastral Data Content Standard for the National Spatial Data Infrastructure, version 1.1, Cadastral Subcommittee, Federal Geographic Data Committee, April 1999
Training
Training should been planned during spring of 2004 for the Project Team for Oracle 9i and ArcSDE. This will be an introductory class, and will be followed by training for an Oracle DBA and for the ESRI ArcSDE Spatial software.
Training for customers (users of the system) will be planned and executed during the Transition Stage (stage 4). This training will be performed in the method identified by the customers in the User
Requirements Document, completed during phase 1.1.
PROJECT MANAGEMENT APPROACH
Work Breakdown Structure (WBS) Gantt Chart
CoreGIS WBS
Basis of Estimates
Estimations of phase schedule times are a rough estimate at this time. A refined, accurate schedule will be prepared as part of each stage. The goal of this refined schedule is to estimate phase
deliverables within 10%. Project Effort Estimation
See Work Breakdown Structure Gantt Chart (above). The chart was created with the assumption that project resources would be available 100% of the time required for each project phase. Project Standards
The Project Team will use the technical standards used at LRIS. The Project Team will develop technical standards in areas (e.g., coding standards, naming conventions) where necessary. Project Roles, Responsibilities and Competencies
Project Manager: Responsible for making sure that the project is completed on time, within budget, within scope and at the desired level of performance. The Project Manager will ensure that the project objectives are met by proactive planning, scheduling and controlling. The Project Manager is responsible for day-to-day management, Project Team leadership and all communications. The Project Manager is responsible for negotiating with management to ensure that resources are allocated to the project when required to complete the next phase.
Project Manager Composition and Required Skills: This position is filled by a single person and will be a permanent employee of the Information Management Branch of SE. The skills required for this position are characterized by the specifications for SR. GIS Analysts.
Project Team: Responsible for executing technical tasks as outlined in the Work Breakdown Schedule as the project progresses through each phase. Where necessary, a member of the Project Team may be identified as a technical lead for an aspect of the project (e.g., user interface, database design, etc.). The Project Team will choose these roles. The Project Team will also be responsible for documenting the effects of proposed changes to the project plan and deliverables. The Project Team members are responsible for identifying resources.
Project Team Composition and Required Skills: The Project Team will be composed of staff members from all relevant branches within the department. Team members may also be contracted employees from private agencies. The size of this team will flex according to the tasks defined by the Work Breakdown Structure for each project phase. It is anticipated that there will be no fewer than three and no more than ten members on this team during any project phase.
Team member skills include those described in the department Career Descriptions 183, 190, and 191.
Project Review Team: Ensure that the project is within scope, on or under budget and satisfies the customers’ needs. Review of phase deliverables for acceptance, change or rejection. Review of proposed changes and their affects as documented by the Project Team.
Project Review Team Composition and Required Skills: This team is composed of managers representing the impacted branches, divisions, sections or agencies. These members can be characterized by the provincial classificaition system with expertise in areas related to Resource Management. Representatives from impacted provincial agencies may also act as members of this team. It is anticipated that there will be no fewer than five and no more than seven members on this team during the life of the project.
Status SuperUser Team: Provide expert advice to the Project Team when questions arise regarding User Requirements and conceptual design of entire system or system components. Status SuperUser Team Composition and Required Skills: This team is primarily composed of highly experienced users of GIS related technology. It is anticipated that there will be no fewer than eight and no more than twenty members on this team during the entire life of the project.
Project Teams Membership Selection Criteria
Membership Category Membership Selection Criteria
Project Manager Selected by Project Sponsors
Project Team Project Manager and Project sponsors develop a list of candidates from SE staff and interview candidates. Candidates are offered a position on the team and either accept or reject the offer. The manager and sponsors may override this method if critical skills are not present in the pool of candidates that accept the offer.
Project Review Team Project Manager and Project sponsors develop a list of candidates from SE and other impacted agencies. These candidates are invited to join the team. The project sponsors may petition the division or agency management if the team does not attain a critical distribution across divisions to achieve its’ goals.
Status SuperUser Team Project Manager and Project sponsors develop a list of candidates from SE staff. These candidates are invited to join the team. The project sponsors may petition the division management if the team does not attain a critical distribution across divisions to achieve its’ goals.
Change and Issue Management Approach
Changes to the Project Plan and project deliverables will be implemented by the procedure outlined in the Change Control Procedure Document. Click here to view the Change Control Plan
Communications and Control Approach Communications
The Project Manager will report the status of the project according to the Work Breakdown Structure, which describes the detailed tasks and each project phase. This communication will be in the form of a memorandum submitted to SE Executive management on a monthly basis. This
communication will be distributed to all affected parties via the web and/or email. The memo will describe status of current tasks and tasks scheduled for the next month.
Control
The Project Manager will control the project while each phase is in its formative stage; that is, while the Project Team is developing the deliverables. The main control will be ensuring that the project tasks as defined in the Work Breakdown Structure (WBS) are being performed on schedule. The Project Review Team is responsible for controlling the project at a higher level. This control is implemented by a series of control gates. These gates occur at the end of each project phase. To accommodate changes in the project plan or changes to the project deliverables, a standard process will be used. This process is described in the document “Change Control Process”. At the end of each phase, the Project Review Team will meet and the Project Manager will present the results of the project phase. The Project Review Team evaluates these results (deliverables). The Project Review Team will use these criteria to analyze the results of the project phase deliverables: • Ensure that all current phase activities and deliverables are complete.
• Ensure that moving to the next project phase is based on hard evidence that the Project Team is prepared and that the risk of proceeding is acceptable.
This review results in one of the following: Acceptance – proceed to the next phase
Acceptable with changes – Change Control Process* is used to implement change Unacceptable – do not proceed; repeat review
Unsalvageable – terminate project
Phase Deliverables Project Review Team Acceptance Rejection Change Request Continue to Next phase Project halted Indefinitely Calculate Effect on Project scope, Budget, time
ATTACHMENTS/APPENDICES
Appendix A – Project Work Plan
This section describes a high level view of the Project Work Plan. Each phase has a deliverable product that will be reviewed by the Project Review Team (see section “Project
Products/Deliverables List” for a description of the deliverables). The Project Team prepares the deliverable products.
This document describes the Stages, Phases, Task Groups and tasks to be performed by the Project Team. The goal of this document is to categorize the tasks to be completed during the course of the project. This is a ‘living’ document and will be updated as the project progresses through its’ Stages. Ultimately, this document will identify tasks that take no longer than two weeks to complete. A Gantt chart for the entire project and each Stage will be created based on the tasks identified in this document.
This document has this format:
X. Stage
X.X. Phase
X.X.X. Task Group X.X.X.X. Task
The Project Team will be responsible for identifying; scheduling and estimating the time required completing the tasks for each Task Group. This will be conducted at the beginning of each Phase.
1. Study Stage
1.1. User Requirements Definition Phase 1.1.1. Create Customer Survey
1.1.2. Identify Customers 1.1.3. Plan Customer Surveys 1.1.4. Perform Customer Survey
1.2. Current Functionality Assessment Phase
1.2.1. Identify and document current relationship with other systems 1.2.2. Identify and document current systems and subsystems 1.2.3. Document and describe current functionality
1.3. Database Design Phase (see Data Conversion, below)
1.4. Finalize Database Design Phase (see Data Conversion, below)
1.5. Database Physical Implementation Phase (see Data Conversion, below)
1.6. Software Evaluation Phase
1.6.1. Design and implement a stable technical environment
1.6.2. Design and implement a data model supporting the functional requirements 1.6.3. Refine data model
1.6.4. Identify products that meet the functional requirements
1.6.5. Populate database by converting geographically contiguous data
1.6.6. Create evaluation criteria (‘must haves’, weighted requirements and performance) 1.6.7. Acquire products that satisfy functional criteria
1.6.8. Perform testing of products 1.6.9. Assess Products
If any products satisfy enough of the functional requirements (without customization) as determined by the Project Team and the Project Review Team, then State 4 is initiated. This identifies the non-customized, COTS-based solution will be chosen as the final product.
If the products tested did not meet the functional requirements, the project moves to Stage 2. This is the customized product or ‘build your own’ solution.
2. Interface Design Stage 2.1. System Model Phase
2.1.1. Complete Entity Model 2.1.2. Complete Process Model 2.1.3. Perform Interaction Analysis 2.1.4. Confirm Model
2.1.5. Develop Entity/Process Model 2.2. System Design Phase
2.2.1. Define System Design Procedures 2.2.2. Identify Reusable Design Components 2.2.3. Design System Structure
2.2.4. Design Screen/Report Layouts 2.2.5. Review Transition Requirements 2.2.6. Identify Open Issues
2.4.2. Finalize Construction Approach 2.4.3. Develop Testing Strategy 2.4.4. Develop Transition Plan 2.5. Finalize System Design Phase
2.5.1. Resolve Open Design Issues
2.5.2. Discuss Suggested Design Improvements 2.5.3. Review Transition Plan
2.6. Validate System Design Phase 2.6.1. Prepare for Design Review 2.6.2. Perform Design Review 3. Construction Stage
3.1. Preparation Phase
3.1.1. Test Production Facilities 3.1.2. Finalize Testing Strategy
3.1.3. Identify Software Engineering Firms 3.1.4. Prepare RFP documents
3.1.5. Finalize RFP documents 3.1.6. Release RFP documents 3.2. Construction Phase
3.2.1. Review Proposals 3.2.2. Select Contract Winner 3.2.3. Generate Code
3.2.4. Perform Unit Tests
3.2.5. Manage Coordinating Model 3.2.6. Perform Integration Tests 3.3. System Documentation Phase
3.3.1. Develop Operations Instructions 3.3.2. Develop Documentation
3.4. Transition Preparation Phase 3.4.1. Finalize Transition Strategy 3.4.2. Develop Training Plan 3.4.3. Finalize Contingency Plan 3.4.4. Complete Transition Work Plan 3.4.5. Develop Training Materials
3.4.6. Follow-up on Organizational Issues 3.4.7. Prepare Transition Procedures 3.5. Verify Construction Phase
3.5.1. Review Integration Testing 3.5.2. Review System Test Plan
4. Transition Stage
4.1. Conduct User Training Phase 4.1.1. Finalize Training Materials 4.1.2. Schedule Training
4.1.3. Conduct Training
4.1.4. Develop Permanent Training 4.2. Install Production System Phase
4.2.1. Adjust Hardware and System Software 4.2.2. Train Operations Staff
4.2.3. Raise System Components to Production Status 4.2.4. Update Production Libraries
4.2.5. Configure System Environment 4.2.6. Activate Help Support
4.2.7. Deploy Databases 4.2.8. Deploy System 4.2.9. Fix Problems 4.2.10. Tune Infrastructure 4.2.11. Deploy Systems to Users 4.2.12. Set Maintenance Procedures
4.3. Verify System Installation Phase
4.3.1. Review Hardware and System Software 4.3.2. Review Training
4.3.3. Develop in-place System Testing Procedures 4.3.4. Conduct in-place System Testing
4.4. Wrap-up Phase
4.4.1. Summarize Project Results 4.4.2. Identify Lessons Learned 4.4.3. Collect Project Metrics 4.4.4. Throw a REALLY Big Party 4.4.5. Release Project Resources
Data Conversion
For the purposes of this Project Plan, Data Conversion is not considered a Stage or a Phase. The initiation of the Data conversion process is dependent on a preliminary physical data model, developed and completed as part of Phases 1.3, 1.4 and 1.5. The successful completion of Data Conversion determines the date that the Transition Stage can begin. Successful Data Conversion is critical to the project deliverables.
1. Data Preparation
1.1. Create Data Conversion Plan
1.2. Devise Data Conversion Quality Control Standards 1.3. Review Data Conversion Plan
2. Data Inventory (Current Format)
2.1. Collect Statistics 2.2. Analyze Statistics
2.3. Prepare Data Inventory Report 2.4. Update Data Conversion Plan
3. Database Design
3.1. Create Logical Model 3.2. Refine Logical Model 3.3. Validate Logical Model 3.4. Finalize Logical Model
3.5. Create Data Map (current format to converted format)
4. Database Physical Implementation
4.1. Code DDL for database 4.2. Enforce Database Security
4.3. Convert Logical Model to Physical Model
5. Populate Spatial Database
5.1. Code Data Loading Scripts 5.2. Test Data Loading Scripts 5.3. Execute Data Loading Scripts 5.4. Fix Problems
5.5. Quality Control
6. Data Inventory (Converted Format)
6.1. Collect Statistics 6.2. Analyze Statistics
6.3. Prepare Data Inventory Report
7. Verify Data Conversion
7.1. Perform Database Tuning 7.2. Test Data Queries
Appendix B – Risk Assessment
Risk assessment will be performed as part of each phase. This will described the risks involved in implementing the phase deliverables. The risk assessment will describe each risk as identified by the Project Team as it affects the business, budget and technical aspects of the phase. This will include any risk mitigation strategies recommended by the Project Manager and the Project Team. Appendix C – Project Budget Report/Cost Benefit Analysis
Report
Not available at this time.
Appendix D – Project Impact Report Not available at this time.
Appendix E – Revision Chart
This chart contains a history of this document’s revisions.
Version Primary
Author(s)
Appendix F – Team Members Project Team Members
Name Division/Office Section/Team Class Primary Role and
Responsibilities
Project Review Team Members