Fiesta Pa Sow v1.5 Final

8/3/2019 Fiesta Pa Sow v1.5 Final

1/25

IMS FIESTA PA Project

STATEMENT OF WORK (SOW)

Prepared By: Charlotte L. GreggDate: 05/11/2004

FINAL: Version 1.5


2/25

Statement of Work for IMS FIESTA PA

REVISION HISTORY

Date Description Version

05/11/2004 Created (draft version) by Charlotte Gregg. 1.0

05/20/2004Incorporated Kimbers changes. Inserted picture of new baselined project plan. Newending date for entire project is 09/13/04. Assigned document version number 1.1. Sentout to Kimber, Sesh, and Robert for their review.

1.1

06/08/2004

Incorporated Sesh Paladugus changes. Changed three sentences in theBACKGROUND section:1. Data entry of site inventory, related party, permit type, and phase of application is

performed at Department headquarters and/or District offices was changed to readData entry of site inventory, related party, permit type, and status of application is

performed at Department headquarters and/or District offices.2. the intent is to encourage them to be eager to bring their particular program area date

into the core when it is time changed to read the intent is to encourage them to beeager to bring their particular program area data into the core (at the appropriatetime).

3. The project is completed prior to any current PA business processes requiring

modifications due the IMS project was changed to read The IMS FIESTA PAproject is completed before any other IMS projects require that any current PAbusiness processes be modified.

1.2

06/08/2004

Incorporated Robert Rouses comments into the document. Changed the followinginformation in the BACKGROUND, History section:1. The primary function of the schema is to track permits from the application received

through application issued/denied phases for all permitted DEP sites changed to readThe primary function of the schema is to store data about environmental permitsrequired by DEP. This includes the point from application reception, through theapplication review process, and up to final agency determination.

2. Removed the following out-of-date and incorrect sentences: The application is usedboth within and outside the agency for determining permit trends. The trends areused to track enforcement of permitted requirements within the Florida.

1.3

06/08/2004

Charlotte inserted Project Risk Assessment Matrix (PRAM) into appropriate section.

Added Ron Wright to the Project Roles and Responsibilities table as Oracle Forms SMEand added the following new responsibility Provide assistance to lead programmer withthe analysis, design, and development of the new form(s). Inserted a new Project Plan

picture with actual hours entered through 06/03/04.

1.4

06/09/2004

Modifications suggested during review of SOW in 06/09/04 Project Kickoff Meeting.1. Changed the PROJECT SCOPE: Out of Scope section to eliminate the following

item: Modifications to the existing PA ERD or Server Model. It has beendetermined that two new PA tables are needed; therefore changes to the ERD andSMD will be made.

2. The Project Organization Chart was modified to include Ron Wright and to addKimber Allen as Project Sponsor.

3. The Project Roles and Responsibilities table was modified to add Ron Wright underthe following existing roles: Data Architect, Programmer, and Testing Lead.

4. The Project Roles and Responsibilities Table was modified to add a Tester Role.

5. Modified the Probability from H to M for the Project Manager Availability row in thePRAM.

1.5

81271623.doc > 1/13/2012


3/25


DEFINITIONS

Abbreviation Meaning

BCRP BIS Control and Reporting Process

BIS Bureau of Information SystemsDBA Database Administrator

DEP Department of Environmental Protection

FIESTA Florida Integrated Environmental System TodAy

GUI Graphical User Interface

IMS Integrated Management System

ISDM Information System Development Methodology

MS Microsoft

PA Permitting ApplicationPMO DEP Project Management Office

PRAM Project Risk Assessment Matrix

SOW Statement of Work

81271623.doc > 1/13/2012


4/25


TABLE OF CONTENTS

REVISION HISTORY ................................................................................... 2

DEFINITIONS ............................................................................................. 3

TABLE OF CONTENTS .................................................................................. 4

I.REQUEST .................................................................................................. 6

BACKGROUND ............................................................................................ 6

History of the Project .................................................................... 6

Business or IT Objectives of the Project ....................................... 6

Critical Success Factors of the Project .......................................... 6

PROJECT SCOPE ......................................................................................... 7

In-Scope ....................................................................................... 7

Out of Scope ................................................................................. 8

MANAGEMENT APPROACH .......................................................................... 8

Plan Management ......................................................................... 8

Communications Management ...................................................... 8Team communications ............. .............. .............. ............... .............. .............. .............. ............. ..... .8Customer communications ............. .............. .............. .............. .............. ............... .............. .......... ..8Project Notebook .............. .............. .............. .............. ............... .............. .............. .............. ........... ..8

Issues Management ...................................................................... 8

QUALITY ASSURANCE ................................................................................. 9

TECHNICAL ENVIRONMENT ........................................................................ 9

Oracle Development Environment ................................................. 9

GIS Development Environment ................................................... 10

Middle-Tier Environment ............................................................. 10

Access & Security ........................................................................ 11

WORK APPROACH AND DELIVERABLES .................................................... 11

Work Approach ........................................................................... 11

Deliverables (& Milestones) ........................................................ 12Strategy Phase .............. ............... .............. .............. .............. .............. ............... ............ ..... ...... .....12

(#1)MS Project Plan ............................................................................................................... .12(#2)Statement of Work (SOW) ...............................................................................................12Milestone - Project Kickoff Meeting ......................................................................................13Milestone - Project Notebook Setup .......................................................................................13

Needs Assessment Phase ............. .............. .............. .............. ............... .............. .............. ......... .....13(#3)Candidate Needs ...............................................................................................................13(#4)Candidate Requirements ...................................................................................................13(#5)Impact Assessment Summary (IAS) .................................................................................14

System Design Phase ............. .............. .............. ............... .............. .............. .............. ............. ..... ..14Alpha Development Phase .............. .............. ............... .............. .............. .............. .............. ..........14

Milestone - Database and all Database Objects (ALPH) .......................................................14(#6)Forms / Screens / Menus .................................................................................................. .14(#7)Beta Test Plan ...................................................................................................................15

81271623.doc > 1/13/2012


5/25


(#8)DBA Migration Package (from ALPH to BETA) ............................................................15Milestone - Supplement to the PA Users Manual (DRAFT) ..................................................15

Beta Testing Phase .............. .............. .............. ............... .............. .............. .............. ........... ...... .....15Milestone - BETA Environment Setup ...................................................................................15(#9)User BETA Testing ..........................................................................................................16Milestone - Supplement to the PA Users Manual (FINAL) ...................................................16Milestone - Training Plan ........................................................................................................16(#10)Training Plan Checklist ..................................................................................................16(#11)Implementation Plan ................................................................................................. ......17(#12)DBA Migration Package (from BETA to PROD) .........................................................17

Implementation Phase ............. .............. .............. .............. .............. ............... .............. ...... ...... .....17

(#13)Production Move and Verification .................................................................................17

ROLES & RESPONSIBILITIES ................................................................... 18

Project Organization Chart .......................................................... 18

Project Roles and Responsibilities Table ..................................... 18Executive Project Sponsor ............. ............... .............. .............. .............. .............. ......... ...... ...... ...19Project Role .............. .............. ............... .............. .............. .............. .............. .............. ..... ..... ..... ....20Project Customer .............. .............. ............... .............. .............. .............. .............. .......... ..... ..... ....20Project Manager .............. .............. .............. .............. ............... .............. .............. ....... ..... ..... ..... ...20

Business Analyst ............... .............. .............. .............. .............. .............. ............... ............. ..... ..... ..20Data Architect .............. ............... .............. .............. .............. .............. .............. .......... ..... ..... ...... ...20Programmer ............. .............. .............. .............. .............. ............... .............. ............. ..... ..... ...... ....20Testing Lead ............. .............. .............. .............. .............. ............... .............. ............. ..... ..... ...... ....20Testers .............. .............. .............. .............. ............... .............. .............. .............. .......... ..... ..... ..... ...20Project Role .............. .............. ............... .............. .............. .............. .............. .............. ..... ..... ..... ....21Project Officer ............ ............... .............. .............. .............. .............. ............... .............. ............ ....21SME-Permitting Application .............. ............... .............. .............. .............. .............. ........... ..... ...21SME-Applications .............. ............... .............. .............. .............. .............. ............... ......... ..... ..... ...21SME-Oracle Forms .............. .............. .............. .............. ............... .............. .............. .............. ...... .21BIS Management Group ............. .............. .............. .............. .............. ............... .......... ..... ..... ..... ..21SME-Database Administration ............... .............. .............. .............. .............. ........ ...... ...... ...... ...21SME-Network & Systems .............. .............. .............. .............. .............. .............. ............... ...........21SME-Middle Tier .............. .............. .............. .............. ............... .............. .............. .............. ...... ....21

Permitting Application (PA) Data Entry Team .............. .............. ............... ......... ..... ..... ...... .....21

PROJECT PLAN ......................................................................................... 22

RISK MANAGEMENT .................................................................................. 22

Project Risks ............................................................................... 23

CHANGE MANAGEMENT ............................................................................ 24

Change Procedure ....................................................................... 24

Change Criteria ........................................................................... 24

ACCEPTANCE MANAGEMENT .................................................................... 24

Acceptance Procedure ................................................................. 24Final Acceptance ......................................................................... 25

APPROVED BY: ......................................................................................... 2525

81271623.doc > 1/13/2012


6/25

I. REQUEST

In late March 2004, Charlotte Gregg was assigned as Project Manager of the IMS FIESTA PAsub-project. (IMS stands for Integrated Management System. FIESTA is the acronym for

Florida Integrated Environmental System TodAy and PA is the Permitting Application shortname.) Linda Lakes was the original PM; she created the initial project plan. After a meetingwith select team members (Robert Rouse, Linda Lakes, Charlotte Gregg and Kimber Allen), itwas decided that this project would change significantly in nature. This project will no longerwait on the other IMS integrations (WAFR and CHAZ), but will immediately create a singlemethod for permit data entry purposes, with the IMS FIESTA look and feel. Thedevelopment of the new FIESTA PA form(s) will comply with current existing businessconstraints; when the business rules in the various program areas are changed based on new rulesimposed by the IMS, at that time, modifications to FIESTA PA (and the unchanged PA) will beaddressed at that time. The form(s) created/modified for this project will still use the existingapplication area data stores. Changes to the existing database(s) will be minimal; therefore,several deliverables are not required for this project, including the ERD and Server Model.

BACKGROUND

History of the ProjectThe following information is taken from the IMS master SOW, in the IMS Sub-Projects PhaseI section for this project:

FIESTA Permitting Application: A common, high-level IMS interface for creating new Managed Entitiesthat result from the processing of Permit Applications. Staff would interact with a common interface that

prompts for CORE information. Until designated applications are integrated, the appropriate "specialized"

PA interface (Generic PA, ARMS PA, etc.) would be invoked as necessary.

The Permitting Application (PA) contains information relating to permitted sites within Florida.The primary function of the schema is to store data about environmental permits required byDEP. This includes the point from application reception, through the application reviewprocess, and up to final agency determination.

Data entry of site inventory, related party, permit type, and status of application is performed atDepartment headquarters and/or District offices. Many DEP divisions use the PermittingApplication. There are currently over 800 users of PA.

Business or IT Objectives of the ProjectThe primary IT objective for this project is to provide a single method for permit data entrypurposes with the look and feel of the other IMS FIESTA Oracle forms. Another objective ofthis project is to encourage the PA users to come on board the IMS bandwagon. By providingthese users the slick, modern FIESTA PA form, the intent is to encourage them to be eager tobring their particular program area data into the core (at the appropriate time).

Critical Success Factors of the ProjectThe Critical Success Factors constitute the Project Sponsors answer to the question: How willyou define the success of the project? These factors are prioritized and serve as a guideline


7/25

used by the Project Manager to do trade-off analysis. Whenever these factors come into conflictthroughout the project, the Project Manager will use this list as a guide for decision-making.The Critical Success Factors for this project are the following:

1. The IMS FIESTA PA form(s) provide a single method for permit data entry.2. The IMS FIESTA PA form(s) mirror the look and feel of the other IMS FIESTA

Oracle forms.3. The IMS FIESTA PA project is completed before any other IMS projects require that

any current PA business processes be modified.4. The project is implemented according to the project plan and SOW.

PROJECT SCOPE

In-ScopeThis project involves the development of new Oracle form(s) to allow for the following highest-level functions:

1. Input of DEP permit data;2. A new method (entry point) for data entry PA users to access ARMS PA, WAFR PA and

Generic PA; and3. A format within the new form(s) that mimics the look and feel of other IMS FIESTA

Oracle forms.

The project is divided into the following phases:

ISDM Phase Purpose

Strategy Phase:The purpose of this phase is to initiate the project. Developed in thisphase, the detailed, agreed upon, approved project plan and Statement ofWork should comprise the road map that is used to navigate the project.

Needs AssessmentPhase:

The purpose of this phase is to determine the user needs and applicationspecifications.

System DesignPhase:

The purpose of this phase is to convert all logical requirements (gatheredin the previous phase) into physical/technical specifications to be used fordeveloping a working system.

AlphaDevelopmentPhase:

The purpose of this phase is to create the first working system1 based onthe physical/technical specifications.

Beta TestingPhase: The purpose of this phase is to review the system to ensure it achieves thegoals specified during the System Design Phase.

ImplementationPhase:

The purpose of this phase is to install the system on the appropriateproduction platform, grant access to users and provide training.

The work in detail will be outlined in the WORK APPROACH AND DELIVERABLES section.

1 The definition of System encompasses the database and the application. Database is defined as a sharedcollection of logically related data. Application is a finite set of job functions, which have been automated, andact on data residing in a database.


8/25

Out of ScopeThe following items are out of scope for this project:

1. Modifications to existing business rules and/or procedures currently followed in theprogram areas using PA;

2. Changes to the existing PA system to comply with IMS constraints (whether related to

the core database or any Clearinghouse issues);3. Creation of FIESTA PA reports;4. Changes/enhancements to existing PA reports; and5. Clean up of any PA data.

MANAGEMENT APPROACH

Plan ManagementBIS will develop a detailed project plan at the beginning of this project using MS Project 2000.The plan will be baselined at the beginning of the project. The baseline will only be adjusted

when the customer approves a change request that affects the schedule.The Project Manager will update the project plan weekly with data supplied by all teammembers in the progress reporting process. The Project Manager will control potential changesto the baseline project schedule and/or estimates through the use of the change procedure asdescribed in this SOW.

Communications ManagementCommunications Management will focus on providing regular updates on the contributions,commitments and challenges for the project effort to all project participants as defined in theproject roles and responsibilities and/or project organizational chart. Communications consist ofthe following processes:

Team communicationsEach project participant will submit to the Project Manager a weekly Individual ProjectStatus Report (IPSR) that identifies completed tasks, tasks expected to be completed in thenext reporting period, lost time, issues, and time reporting by task (including actual effort,effort estimates-to-complete, estimated completion date). The weekly individual reports areconsolidated into a summarized weekly project report. The project team will meet weekly toshare overall project status, to discuss issues, and to provide assignments and goals.

Customer communicationsThe Project Manager will meet weekly with the customer to review overall project status, toreview deliverables and discuss issues. A weeklyProject Status Report (PSR) will bedistributed to the customer and all project participants.

Project NotebookA project notebook is kept as a single repository for all documentation of projectmanagement, project reporting and control materials. It is accessible to the project team as areference document throughout the project.

Issues ManagementAn issue is defined as any item adversely affecting execution of the project plan. Issues mayadversely impact the cost, time frame and/or quality of the deliverables of the project. Resolvingissues is an on-going process throughout the life of any project. The keys to effective issueresolution are early identification, communication and management. Our process is as follows:
http://opt/scribd/conversion/tmp/scratch6190/IPSR%20template.xlshttp://opt/scribd/conversion/tmp/scratch6190/IPSR%20template.xlshttp://opt/scribd/conversion/tmp/scratch6190/ProjectStatusReportTemplate.dochttp://opt/scribd/conversion/tmp/scratch6190/ProjectStatusReportTemplate.dochttp://opt/scribd/conversion/tmp/scratch6190/IPSR%20template.xlshttp://opt/scribd/conversion/tmp/scratch6190/IPSR%20template.xlshttp://opt/scribd/conversion/tmp/scratch6190/ProjectStatusReportTemplate.doc


9/25

Issues are recorded into a Project Issue Log. Every record in the Issue Log contains a descriptionof the issue, actual or potential impact if not resolved, who raised the issue, when the issue wasraised, updates, and final resolution. Every issue has a target date for resolution after which theproject is impacted. Every issue has an owner responsible for driving resolution and keeping theProject Manager up to date on progress.

Issues are listed (or the Issues Log is attached) in the weekly Project Status Report (PSR). Issuesare reviewed weekly in team status and customer status meetings. Issues are closed only whenthe initiator is comfortable that the resolution addresses their problem.

Note: Critical issues will be reported to the Project Manager as they are identified,without consideration to the standard status reporting procedures.

Escalation: There may be instances where an issue needs to be escalated. Escalationinvolves bringing the issue to the attention of the Project Sponsor for resolution.

QUALITY ASSURANCE

This project will use the standard BIS Control and Reporting Process (BCRP) to monitor projectquality. BCRP deals with project management expectations within BIS and sets rigorous, butminimum standards for quality in project management. Projects within BIS are randomlyselected for review at Project Initiation, Quarterly, and at Project Closure.

The quality processes that will be used on this project are: quality audits from the BIS ProjectManagement Office (PMO), Peer/Quality Assurance Reviews of project deliverables, and thestandard quality processes built into the BIS Information System Development Methodology(ISDM).

TECHNICAL ENVIRONMENT

Oracle Development EnvironmentThe Oracle forms development work will conform to the standards described below: User Workstation requirements - Any user must have the following software on their PC:

Internet Explorer and the current version of JInitiator. A user must have a valid Oracleaccount on the appropriate database (on ORABETA for beta testing; on ORAPROD forproduction). Also, a user must have been granted access, in the Web Access ControlApplication (WACA), to the appropriate application(s).

Development environment - Forms will be created on the development middle tier server,EPIC227 (ALPH). The database that will be used for development and testing is ORADEV.

The developers will use the Development URL for testing: http://depdev.dep.state.fl.us:8888.

Testing environment -The application will be moved to the Beta region of EPIC227 by oneof the BIS developers. The users in this region should test the application by using the betaURL: http://depbeta.dep.state.fl.us: 7777. The database that will be used for applicationtesting is ORABETA.

Production environment - Once approved by BETA testers the application forms can bemoved to production. The items will be moved from EPIC227 (BETA) to the productionserver, by one of BIS Database Administrators (DBA), at the request of the BIS project
http://opt/scribd/conversion/tmp/scratch6190/Issues%20Log%20Template.dochttp://opt/scribd/conversion/tmp/scratch6190/Issues%20Log%20Template.doc


10/25

lead. The new system will then be available from this URL: http://depapps.dep.state.fl.us:7777/. The production database is ORAPROD.

GIS Development EnvironmentGIS products, services and data will conform to the standards below:

User Workstation Requirements - ArcIMS users must have MS Internet Explorer 5.5 orbetter. Desktop GIS users must have ArcGIS 8.1.2 or better and a workstation that conformsto the ESRI hardware recommendations for the current release of ArcGIS.

Development Environment - ArcIMS applications and web services will be developed inArcIMS 4.0.1 on either the developer's workstation or on GISAIMSDEV1. ArcIMSapplications and web services must conform to the published BIS/GIS Web Mapping System(WMS) technical standards (which can be viewed at http://depnet/gis/services/arcims.htm).ArcIMS applications must use data provided by ArcSDE rather than local copies of data.Data products will be developed on GISTEST in ArcSDE 8.3 and Oracle 9.2.0.2.

Testing Environment - ArcIMS applications and web services will be tested onGISAIMSBETA1 running ArcIMS 4.0.1 and configured in accordance with the publishedWMS standards referenced above. All data products will be tested on GISTEST,

configuration noted above. Staging Environment - ArcIMS applications and web services will be ported to

GISWEBSTG4, GISMAPSTG4, and GISMAPSTG5 and tested prior to porting to theproduction environment. GISWEBSTG4, GISMAPSTG4, and GISMAPSTG5 run ArcIMS4.0.1 and are configured in accordance with the published WMS standards referenced above.

Production Environment - ArcIMS applications and web services will be ported toGISWEB4, GISMAP4, and GISMAP5 running ArcIMS 4.0.1 and configured in accordancewith the published WMS standards referenced above. All data products will be copied orimported to EPIC31 running ArcSDE 8.3 and Oracle 9.2.0.2.

Middle-Tier Environment

Oracle development tools and application server have been upgraded to the latest version (9i) inorder to remove any bugs that may have been fixed from earlier versions and also to provide themost robust development environment available from Oracle Corporation. This upgradeprovides J2EE 1.3 capabilities needed now for integration of GIS and Oracle Formsfunctionality. It is expected that within the next year DEP will upgrade to the next version (10g)when that software is mature for the previous reasons and to provide J2EE 1.4 capabilities.Oracle upgrades are always planned and carefully managed and they occur with explicitapproval of the CIO.
http://depnet/gis/services/arcims.htmhttp://depnet/gis/services/arcims.htm


11/25

Access & SecurityAccess to DEP systems is done through the use of the Web Access Control Application(WACA). The system is designed to give the authorized end-users control over the access totheir Information Systems. As part of the development process, the user community workswith application development staff to specify and set up the security levels and roles for theapplication. The application is then developed to use this information to limit access in theapplication based upon the role (security level) assigned. Individual access is granted to theseroles through the use of the WACA system.

WORK APPROACH AND DELIVERABLES

Work ApproachThe following methodologies and standards will be taken into account during development foreach phase of this project:

1. DEPs Information Systems Development Methodology (ISDM)2. BIS Productivity Management Standards3. BIS Oracle Designer Naming Standards


12/25

The work approach for the project will be deliverable-based. A collection of pre-determineddeliverables will be completed, as the project proceeds through the seven phases of the DEPInformation Systems Development Methodology (ISDM). Those ISDM phases are Proposal,Strategy, Needs Assessment, System Design, Alpha Development, Beta Testing, andImplementation. The project deliverables and milestones are outlined in the next section, underthe appropriate ISDM phase.

Deliverables (& Milestones)The project deliverables, which will require approval and acceptance from the customer, will beassigned a deliverable number. This number will be used in the project plan, in projectreporting, and in the next section to uniquely identify the particular project deliverable. Adeliverable will have defined acceptance criteria; these criteria will be the basis for approvalwhen the deliverable has been completed. A milestone is a thing of significance to the project.Milestones are different from deliverables in that they do not require approval and they will nothave an assigned number. However, the project milestones will be documented in the followingsection, along with the deliverables, and will be included in project reporting. Milestones willhave Completion Criteria and will often require a reviewer, but a Milestone will not require an

approver.

Strategy PhaseThe purpose of this phase is to produce a project plan and Statement of Work to define and direct theremainder of the project. The following are the deliverables and/or milestones to be produced during theStrategy Phase for this project:

(#1) MS Project Plan

Description:The project plan details all (known) project tasks, work estimates, resource assignments, percentof the project that is complete, proposed task begin and end dates, and proposed start and enddates for the project.

Produced by: Charlotte Gregg

AcceptanceCriteria:

The delivery of the Project Plan and Statement of Work (SOW) will be determined

ACCEPTABLE when the following criteria are met: The team has developed a fair estimate of the time, costs, and schedules; and The team has correctly identified the deliverables for the project; The Project Sponsor/Project Customer agrees the direction of the project accurately aligns

with the needs of the organization; and The Project Plan accurately reflects the schedule, deliverables, and tasks as defined in the

SOW.

Reviewer(s): Terri Rein, Fred Blanton, Robert Rouse, Sesh Paladugu

Approver(s): Kimber Allen

(#2) Statement of Work (SOW)

Description:This document details the agreements between BIS and the customer as to how, when, whereand in what way the project will be carried out.


AcceptanceCriteria:

The delivery of the Statement of Work (SOW) will be determined ACCEPTABLE when thefollowing criteria are met: The project manager and project team understand the problem, opportunity, or need; The Project Sponsor agrees the direction of the project accurately aligns with the needs of

the organization; The Statement of Work accurately reflects the work to be done; and The Project Plan accurately reflects the schedule, estimates and resources as defined in the

SOW.

Reviewer(s): Robert Rouse, Sesh PaladuguApprover(s): Kimber Allen, Terri Rein, Charlotte Gregg, Management Steering Committee (MSC)


13/25

Milestone - Project Kickoff Meeting

Description:The initial meeting of the project participants. The meeting, led by the Project Manager (PM), isthe time during which the customer is first led through the Project Plan and Statement of Work

by the PM.


CompletionCriteria:

The Project Kickoff Meeting will be determined COMPLETE when the following criteria aremet: The PM and project team members meet and review the Project Plan and The PM and project team members meet and review the DRAFT of the Statement of Work

(SOW).

Reviewer(s): N/A

Milestone - Project Notebook Setup

Description: Creation of the physical project notebook and the electronic project directory.


CompletionCriteria:

The setup of the Project Notebook will be determined COMPLETE when the following criteriaare met: The Project Notebook has been created with its particular Project Notebook cover and spine

and

The Electronic Project Directory has been created on a network drive.Reviewer(s): N/A

Needs Assessment PhaseThe customer requirements, functions, and business rules are determined and documented during the NeedsAssessment phase. The information needed to complete the different project deliverables may be obtainedthrough various techniques, including customer interviews, Joint Application Development (JAD) workshops,

prototyping, etc. It is also during this phase that the impacts of the proposed system to the current agencyinfrastructure are discovered and documented. The following are the deliverables and/or milestones to be

produced during the Needs Assessment Phase for this project:

(#3) Candidate Needs

Description:

Document containing needs statements. A statement of need identifies the business/user needs,

independent of how the need will be met. The document should contain clear statements ofeither a particular problem the business/user needs solved or an ability (or capability) that isneeded. A needs statement is "solution neutral".

Produced by: Robert Rouse, Sesh Paladugu

AcceptanceCriteria:

The delivery of the Candidate Needs document will be determined ACCEPTABLE when thefollowing criterion is met: The project sponsor agrees that the document reflects the candidate needs.

Reviewer(s): Charlotte Gregg


(#4) Candidate Requirements

Description:

Document containing requirement statements. A requirement statement is a statement of whata system would have to do in order to meet the business needs. Requirements specify whatwill

be done to satisfy one or more business needs. Contrast with business (or user) need statements

that reflect what the business needs to have solved, independent of the how.Produced by: Robert Rouse, Sesh Paladugu

AcceptanceCriteria:

The delivery of the Candidate Requirements document will be determined ACCEPTABLEwhen the following criteria are met: There is at least one requirement mapping back to every statement of need in the

Candidate Needs document and The Candidate Requirements are detailed to the point that the new form(s) can be created.


Approver(s):Kimber Allen, Management Steering Committee(MSC needs Candidate Requirements document plus an Executive Summary, which details thesolution summary, including impact to the User Community.)


14/25

(#5) Impact Assessment Summary (IAS)

Description:A document that details the impacts (if any) in the following areas: databases, middle tierservers, systems and network servers, help desk and GIS.

Produced by: Sesh Paladugu, Robert Rouse

AcceptanceCriteria:

The delivery of the Impact Assessment Summary (IAS) will be determined ACCEPTABLE

when the following criteria are met: The document explains/considers all potential impacts to the following BIS sections:

Application Development, Database Administration, Geographic Information System, HelpDesk, Middle Tier, and Networking; and

The document details any exceptions to normal operating procedures that this system ormodule will require.


Approver(s): Kimber Allen, Jon Canter, Linc Clay, Barbara Kennedy, Kevin Kerchkoff, Spencer Lepley

System Design PhaseThe deliverable of greatest importance created during the System Design Phase is the Detailed RequirementsSpecification (DRS) document. It is with this document that the programmer is given the details or thespecifics for coding the system. Another product of this phase is the Server Model or physical schema. Thereare no deliverables or milestones to be produced during the System Design Phase for this project. There will

be no changes to the database. Also, it has been elected that the programmer will create the new FIESTA PAform from the Candidate Requirements document, not from a DRS document.

Alpha Development PhaseThe actual system begins to take shape in this phase. Forms or screens and reports or other output are usuallythe two key deliverables. In addition, at the end of this phase, a Beta Test Plan, that will direct the BetaTesting effort during the next phase, is created. The following are the deliverables and/or milestones to be

produced during the Alpha Development Phase for this project:

Milestone - Database and all Database Objects (ALPH)

Description:The creation and/or modification of all development database objects, including tables, views,indexes, triggers, procedures, and roles.

Produced by: Sesh Paladugu

CompletionCriteria:

The delivery of the Database and all Database Objects will be determined COMPLETE whenthe following criteria are met: All database objects needed for development of alpha deliverables (i.e., forms and/or

reports) have been created (and populated, as needed); All appropriate SQL and PL/SQL scripts have been run correctly on the development

database; and All applicable database objects have been compiled without errors on the development

database.

Reviewer(s): Charlotte Gregg, Robert Rouse

(#6) Forms / Screens / Menus

Description:The forms, screens, and menus are what the users see when using the application. The screenscan be of various types, including data entry and query screens.


AcceptanceCriteria:

The delivery of the Forms, Screens, or Menus will be determined ACCEPTABLE when thefollowing criteria are met: Each form or screen is developed according to specifications derived from the Candidate

Requirements document and Each form or screen is developed according to current BIS Oracle Forms Standards.

Reviewer(s): Charlotte Gregg, Donna Gorton, Robert Rouse



15/25

(#7) Beta Test Plan

Description:A plan that defines who will participate in testing (during the next phase), how the testing should

be carried out, where and when beta training will occur, how test results will be recorded andtransmitted back to the developers, and the estimated length of test period.


AcceptanceCriteria:

The delivery of the Beta Test Plan will be determined ACCEPTABLE when the followingcriteria are met: The Beta Test Plan identifies and documents the tests to be run; The Beta Test Plan documents how the tests will be counted as successes or failures; The Beta Test Plan maps each test script (with associated test cases) back to a Requirement

ID; The Beta Test Plan identifies details of how testing will be carried out; The Beta Test Plan identifies the procedure for recording and transmitting test results; and The Beta Test Plan identifies test participants (with potential backups) and a confirmation of

their availability to test and their willingness to test in accordance with the prepared testplan and documented procedures.



(#8) DBA Migration Package (from ALPH to BETA)

Description: Data migrations plan for transferring data from existing applications to the new system. Thisplan identifies specific data to migrate and migration methods.


AcceptanceCriteria:

The delivery of the DBA Migration Package will be determined ACCEPTABLE when thefollowing criteria are met: The number of beta users, with their locations, is detailed; The number and size of tables and the expected growth of the database is described; The package includes a list of the scripts that must be run to create and populate the Beta

database; and The package addresses the Beta environment as well as the DOPPLER (data warehouse)

environment, where necessary.


Approver(s): Spencer Lepley, Kimber Allen

Milestone - Supplement to the PA Users Manual (DRAFT)

Description:DRAFT of the supplement to the current PA Users Manual that describes how to use the newFIESTA PA form.

Produced by: Robert Rouse

CompletionCriteria:

The delivery of the DRAFT Supplement to the PA Users Manual will be determinedCOMPLETE when the following criteria are met: The supplemental information contains screen print(s) of the new form(s); The supplemental information describes any new functionality that has been added to the

PA system with the creation of the FIESTA PA form; and The supplemental information describes the difference between choosing the PA or the

FIESTA PA system from the Oracle main menu.


Beta Testing PhaseFollowing the setup of the BETA environment, User BETA Testing in accordance with the BETA Test Planwill be the major accomplishment/deliverable during this phase. Also, several documents that deal with theimplementation and training for the production system may be produced, such as the Training Plan, theImplementation Plan, and the DBA Migration Package (from BETA to PROD). The following are thedeliverables and/or milestones to be produced during the Beta Testing Phase for this project:

Milestone - BETA Environment Setup

Description: The Setup of the BETA Environment in preparation for User BETA Testing. This may includethe following: e-mail to the UNIX and Middle Tier groups to setup a path for Oracle forms onEPIC227 (BETA), the creation of a web on tlhora5, and the tasks required for the application


16/25

Milestone - BETA Environment Setup

security in WACA.


Completion

Criteria:

The BETA Environment Setup will be determined COMPLETE when the following criteria aremet:

The correct path has been created on EPIC227 (BETA) for Oracle forms; The appropriate web has been created on tlhora5; and The WACA setup for BETA Testing has been completed.


(#9) User BETA Testing

Description:This deliverable represents the time and associated tasks for the user community to BETA testthe new system following the BETA test plan. The BETA Test is carried out in accordance withthe BETA Test Plan.


AcceptanceCriteria:

The User BETA Testing will be determined ACCEPTABLE and COMPLETEwhen thefollowing criteria are met: The new FIESTA PA form is working as expected in the BETA environment; The data in the BETA environment database is accurate and formatted correctly; and All appropriate users were able to test the system and have the correct access and authority

to function as required in the BETA FIESTA PA form.

Reviewer(s): Charlotte Gregg, PA Data Entry team


Milestone - Supplement to the PA Users Manual (FINAL)

Description:FINAL supplement to the current PA Users Manual that describes how to use the new FIESTAPA forms.


Completion

Criteria:

The delivery of the FINAL Supplement to the PA Users Manual will be determinedCOMPLETE when the following criteria are met: The supplemental information contains screen print(s) of the new form(s); The supplemental information describes any new functionality that has been added to the

PA system with the creation of the FIESTA PA form; and The supplemental information describes the difference between choosing the PA or the

FIESTA PA system from the Oracle main menu.Reviewer(s): Charlotte Gregg

Milestone - Training Plan

Description:This plan describes how user training will be conducted when the application is moved into

production.


CompletionCriteria:

The delivery of the Training Plan will be determined COMPLETE when the following criteriaare met: The plan sufficiently details what if any training will be needed for users to use the new

FIESTA PA form and

The plan outlines how and when needed training will occur.Reviewer(s): Charlotte Gregg

(#10) Training Plan Checklist

Description: The Training Plan checklist should address all of the details necessary for training users.


AcceptanceCriteria:

The delivery of the Training Plan Checklist will be determined ACCEPTABLE when thefollowing criterion is met: The training plan checklist is completed and all items pertaining to training have been

identified and planned for in the Training Plan.



17/25

(#10) Training Plan Checklist


(#11) Implementation Plan

Description:The Implementation Plan should include the details necessary for production migration; forexample, dates, file names, and locations of programs which must be run. Coordination with

Database Administration staff and the user community is imperative.Produced by: Sesh Paladugu

AcceptanceCriteria:

The delivery of the Implementation Plan will be determined ACCEPTABLE when the followingcriteria are met: The implementation plan identifies the steps that must be taken before the new system is

implemented in the production environment (excluding those details that will be in the DBAMigration Package) and

The implementation plan identifies all parties that should be notified of the new system tobe implemented.

Reviewer(s): Charlotte Gregg, Robert RouseApprover(s): Kimber Allen

(#12) DBA Migration Package (from BETA to PROD)

Description:

Data migrations plan for transferring data from existing applications to the new system. This

plan identifies specific data to migrate and migration methods.


AcceptanceCriteria:

The delivery of the DBA Migration Package will be determined ACCEPTABLE when thefollowing criteria are met: The number of production users, with their locations, is detailed; The number and size of production tables and the expected growth of the database is

described; The package includes a list of the scripts that must be run to create and populate the

production database; The package addresses the production environment as well as the DOPPLER (data

warehouse) environment, where necessary; and The package lists the forms that must be moved from the beta to the production server(s).


Approver(s): Spencer Lepley, Kimber Allen

Implementation PhaseVerification of the successful production implementation is the key deliverable for this phase. In addition, a

project milestone for this phase can be updates to existing system documentation and/or additional training.The following is the deliverable to be produced during the Implementation Phase for this project:

(#13) Production Move and Verification

Description:

This deliverable involves physically installing the system on the appropriate production platformin accordance to the Implementation Plan. It also includes migrating data and granting access tothe appropriate users. At this point the application belongs to the program area and developersno longer have update access.


AcceptanceCriteria:

The Production Move will be determined ACCEPTABLE when the following criteria are met:

All forms are working as expected in the production system;

All reports are working as expected in the production system;

The data in the production database is correct and formatted correctly; and

All start up users for the system have the correct access and authority to function as requiredin the FIESTA PA system.




18/25

ROLES & RESPONSIBILITIES

Project Organization ChartSee the picture below for the project organization chart. The assigned project role follows the individualor committee name. In most cases, these role names do not correspond to the individuals job titles;

however, they do indicate the position of responsibility to be played within this project.

F I E S T A P A S u b - P r o j e c t O r g a n i z a

K A l l e n , A pS M E - A p p

J C a n t e r , I

L C l a y , GS M E - G

B K e n n e d y ,

S M E - M i d

K K e r c h k o f S M E - N e t

S L e p l e y ,S M E - D B A

S P a l a d u g u /P A S M E , B

D a t a A r c h i t

P e r m i t t i( P A ) D aO r a c l e F

R R o u s e ,B u s i n e s s A n

D G o r t o n , SS M E - O r a

C G r e g gF I E S T A P A

K A l l e nP r o j e c t S

F B l a n t oS M E - P r

T T i z z a r dS M E - P r

T R e i nP r o j e c t M a

M a n a gE x e c u t i v e P r o j e c

Project Roles and Responsibilities TableThe following outlines the roles and responsibilities needed for the successful execution of thisproject:

Project Role Name Project Responsibilities

Note: This chart represents an organization structure only as it pertains to this project.

echnicalgmt. Group

Core SME Group

PM Group


19/25

ExecutiveProjectSponsor

ManagementSteeringCommittee

Approve Statement of Work (SOW) Approve changes in project scope or budget (change

requests) Final project approval


20/25


ProjectCustomer KimberAllen

Approve Project Plan and Statement of Work (SOW) Approve changes in project scope or budget (change

requests) Resolution of escalated issues

Approve Deliverables Monitor project progress monthly Break ties for escalated issues that cannot be resolved by

the project team Project recommendations and guidance Final project approval

ProjectManager

CharlotteGregg

Develop Statement of Work (SOW) Validate critical success factors Develop and manage project to baseline project plan Oversee project status and communications Implement and track Quality Assurance (QA) on project Manage and facilitate resolution of issues Manage and facilitate change requests Manage and facilitate deliverable acceptance Manage risks identified in the SOW Develop and maintain a Project Notebook Archive Project documents when complete Deliver project results on time, within budget, without

surprises

BusinessAnalyst

RobertRouse, SeshPaladugu

Document business processes/rules for the CandidateNeeds

Document business processes/rules for the CandidateRequirements

Create the Impact Assessment Summary (IAS) Create Implementation Plan

Data Architect

SeshPaladugu,Ron Wright

Create/modify all needed database objects, includingtables, views, indexes, triggers, procedures, and/or roles.

ProgrammerSeshPaladugu,Ron Wright

Create forms/screens for data input Meet with users concerning form/screen needs and

preferred layout and style

Testing Lead

RobertRouse, SeshPaladugu

Create and document project BETA Test Plan Define project testers and user testers Lead testing effort

Testers Bob Shaw,CharlotteGregg

Perform tests of the new FIESTA PA form following theBETA Test plan


21/25


Project OfficerTerryTizzard

Perform Project Reviews Assist Project Manager with implementation of BIS

Project Management Standards

SME-

PermittingApplication

Robert

Rouse, SeshPaladugu

Review Project Plan and Statement of Work (SOW)

SME-

Applications

KimberAllen

Review SOW Review Project Plan Review Candidate Needs and Candidate Requirements Review Impact Assessment Summary prior to distribution

to other BIS managers Review the forms Review the Beta Test Plan Provide subject matter expertise on application interfaces Provide testing assistance

SME-OracleForms

Ron Wright,DonnaGorton

Provide assistance to lead programmer with the analysis,design, and development of the new form(s).

Review Oracle forms Provide subject matter expertise on application interfaces

BISManagement

Group

KimberAllen, JonCanter, LincClay,BarbaraKennedy,KevinKerckhoff,

SpencerLepley

Review and approve the Impact Assessment Summary(IAS)

SME-DatabaseAdministratio

n

SpencerLepley

Approve DBA Migration Packages Review impact to database administration Provide subject matter expertise on database

administration issues Testing assistance

SME-Network& Systems

KevinKerckhoff

Provide subject matter expertise on network and systemissues

Testing assistance

SME-Middle

Tier

Barbara

Kennedy

Provide subject matter expertise on middle tier issues

Testing assistancePermittingApplication(PA) DataEntry Team

To bedetermined

Review Statement of Work Review Project Plan Provide subject matter expertise in the appropriate area Assist in the definition of data elements Review the ERD


22/25

PROJECT PLAN

A summarized project plan is presented here showing planned tasks and activities; planned startand finish dates and work estimates. This project was estimated using experienced basedestimating.

RISK MANAGEMENT

Risks exist on every project; however, proactive management can reduce risk occurrence andrisk impact to the project. A structured process serves to monitor, assess, and deal with knownrisks and to uncover new risks as they arise. Risks are communicated to the project team and tothe customer to encourage shared management of the potential risks. Risks are reviewed with the


23/25

customer to create awareness of what we are doing to address risk and also to make the customeraware we may seek their involvement in mitigation.

Risks are formally reviewed during creation of the SOW and each month thereafter. Theprevious risk assessment serves as input to the next risk assessment. However, new risks may beidentified and priorities can/do change. The Project Risk Assessment (PRAM) will be reviewed

and updated on a more frequent basis if warranted.

Project RisksThe following risks have been identified that may have an adverse impact on completion of theproject objectives. Risks are an attempt to predict potential issues that may come up in the lifecycle of the project. For probability (PROB) and consequence (CONSQ), H = High, M =Medium, and L = Low.

RiskID

RiskVariables

PRO

B

CONS

Q

Positive ImpactExpectation orEstimating

Assumption

Negative ImpactMitigation Steps(include mitigation

tasks in project plan)

1ProjectManagerAvailability

M MManagers are availableand complete tasks ontime.

The Project Manager willbe available to manageand complete all assignedtasks.

The Project Manager isimpeded by other

project tasks andassigned tasks aredelayed.

If necessary, shift tasks toother managers so thatthey are completed ontime.

2Vulnerabilityto Change

M M

Additionalneeds/requirements areidentified that clarifyinformation needed tocomplete the project.

The identified needs andrequirements will not beexpanded. It isanticipated that allcurrent business rules willremain unchanged for theFIESTA PA forms.

Additionalneeds/requirements areidentified that requireadditional modificationsto the detailedspecifications.

Request review of needsand requirements byappropriate staff; requestreview of detailedspecifications byappropriate staff; developa prototype and present itto appropriate staff.

3StaffAvailability

L M

The deliverables, dataentry interfaces, andreports will bethoroughly reviewed ortested and delivered ontime.

BIS staff will be availablefor deliverable reviewand testing.

The deliverables anddata entry interfaces arenot thoroughlyreviewed or tested.Forms may containcoding errors thatrequire correction.

Project status reports willidentify any resourceimpacts and requestreassignment of other BISstaff to replace anystaffing deficiencies andmitigate project impact.

4

CustomerParticipationin BetaTesting

M M

Select PA data entryusers are available to

beta test the newform(s); the new form(s)is (are) thoroughlytested.

A sufficient number ofPA data entry users will

be available to beta testthe new form(s).

Insufficient numbers ofPA data entry users areavailable for betatesting; the applicationis not thoroughly tested

prior to production

implementation.

Identify select PA dataentry users and schedule

beta testing sessions earlyin the project. Identifyalternate beta testers.

5 Timeframe M M

The application iscomplete andimplemented/available in

production before theend of September 2004.

The application iscomplete andimplemented/available in

production by the end ofSeptember 2004.

The form(s) logic ismore complex than theestimates provided inthe project plan.

Add an additionalresource, an Oracle Formexpert, to assist the lead

programmer with theanalysis, design anddevelopment of the newform(s).
http://opt/scribd/conversion/tmp/scratch6190/PRAM%20Template.xlshttp://opt/scribd/conversion/tmp/scratch6190/PRAM%20Template.xls


24/25

CHANGE MANAGEMENT

Change ProcedureThe change procedure will be used in any situation where a change occurs to the project asdefined in this Statement of Work. As the project proceeds, there can be occasions when changes

are desired to the scope, approach, processes and procedures that were originally agreed to. Thechange process will also be used when these processes and procedures are violated or when thereis a failure to perform some aspect of the Statement of Work. The Project Manager estimates theimpact of change requests as to the need or benefit, the impact to cost and schedule and thensecures appropriate management approval before adjusting. Note that some changes do notimpact cost or schedule but alters expectations. These are called Informational Change Requestsand will be handled the same as non-informational change requests.

1. Anyone on the project team may request a change. This request is given to the ProjectManager. The Project Manager analyzes the change request and completes the ChangeRequest Form and presents the request to the Project Sponsor and/or Project Customer forreview, discussion, and disposition.

2. The change request must be disposed (approved or rejected) within 3 business days aftersubmittal. This approval/rejection must be in writing. The project will not be adjusted untilthe change request is approved. If no reply is received within the timeframe, the change istreated as an issue.

Change CriteriaThe change procedure will be used for any changes to the accepted Statement of Work,approved deliverables or approved change requests. A change request can adjust somethingprevious agreed to or define something that did not happen as planned. Examples include systemnot being available (lost time), people not performing their duties per the agreed roles andresponsibilities, changes to deliverables or project scope.

ACCEPTANCE MANAGEMENT

Acceptance ProcedureDeliverables are defined throughout the life of the project. These provide the building blocksthat move the project towards final completion. Acceptance of a deliverable means the customerhas given a go to use this deliverable as input to related future deliverables. Acceptance ofdeliverables on a timely basis is critical in order to avoid delays to the project. In order to ensuresmooth delivery and acceptance of all deliverables, the following process will be employed:

1. The Project Manager provides the deliverable to the appropriate and authorized signor for

review, accompanied by an Acceptance Form. The Acceptance Form includes a descriptionof the deliverable and the pre-approved acceptance criteria defined in the Statement of Workfor that deliverable.

2. Acceptance must be in writing (no verbal approvals). E-mail approvals are acceptable if theyare explicit (that is, clear which deliverable is approved). A walkthrough of the deliverablewith the customer is the preferred means of securing approval.

3. Acceptance must occur on a timely basis to avoid delays to the project. For this project,deliverables must be approved within 3 business days after receipt, unless an alternative time
http://opt/scribd/conversion/tmp/scratch6190/Change%20Request%20Form.dochttp://opt/scribd/conversion/tmp/scratch6190/Change%20Request%20Form.dochttp://opt/scribd/conversion/tmp/scratch6190/Deliverable%20Acceptance%20Form.dochttp://opt/scribd/conversion/tmp/scratch6190/Change%20Request%20Form.dochttp://opt/scribd/conversion/tmp/scratch6190/Change%20Request%20Form.dochttp://opt/scribd/conversion/tmp/scratch6190/Deliverable%20Acceptance%20Form.doc


25/25

frame is mutually agreed upon. The Acceptance Form lists the specific due date to eliminateany confusion about when approval is needed to stay on schedule. If approval is not receivedon a timely basis, its lateness is treated as an issue. We never assume default acceptance orrejection. Rejections must specify what is unacceptable.

Final AcceptanceAt the conclusion of the project, after all project deliverables are approved, a Final ProjectAcceptance form will be submitted to acknowledge completion of all work and fulfillment of allobligations under this Statement of Work (and as amended through approved change requests).

APPROVED BY:

Kimber Allen, Project Customer& DEP Applications Section Manager

DATE

Charlotte Gregg, Project Manager DATE

Executive Project Sponsor or Bureau Chief DATE

Fiesta Pa Sow v1.5 Final

Documents

Transcript of Fiesta Pa Sow v1.5 Final