Statement of Work - PMDC

Document Sample
Statement of Work - PMDC Powered By Docstoc
					Performance Measures Data Collection
          STATEMENT OF WORK (SOW)
       Prepared By: Kimber Allen, Charlotte Gregg
                 Creation Date: 03/25/03

                   Final Version 1.9
            Submitted for Approval: 04/22/03
               SOW for Performance Measures Data Collection (PMDC) Project

Revision History
  Date     Description                                                                             Version

03/25/03   Created (draft version) – Kimber Allen and Charlotte Gregg                                1.0
04/10/03   Incorporated Project Teams comments prior to Kickoff Meeting.                             1.1
           Replaced REQUEST and BACKGROUND information with information from Joe
           Young. Removed Myra Williams and Sue Oshesky from the Subject Matter Experts
04/14/03                                                                                             1.2
           (SMEs) – Customer Group in the ROLES AND RESPONSIBILITIES section and from
           the PMDC Project Organization Chart.
04/14/03   Training Plan and Manual reassigned to Melinda Moody to produce.                          1.3
           Added the new resources to the PMDC Project organization Chart and ROLES and
04/18/03                                                                                             1.4
           RESPONSIBILITIES section.
           Changes made to the “In Scope/Out of Scope” section, based on Geof’s comments
04/22/03   from 04/15 meeting (addition of “roles” text) and Melinda’s comments) in 04/15 e-mail     1.5
           (“no historical performance measure values data”).
           Changed the following based on MaryAnn’s suggestions:
            In the Customer Communications section, changed text to reflect weekly meetings.
            Changed Beta Test Plan Acceptance Criteria based on MaryAnn’s suggestions.
            Changed Deliverable #10 to read “Preliminary” DBA Migration Package and
04/22/03                                                                                             1.6
               specified “(from ALPH to BETA)”.
            Made addition to Deliverable #11 definition.
            Changed Deliverable #13 to read “Final” DBA Migration Package and specified
               “(from BETA to PRODUCTION)”.
           Based on Laura’s request, changed the following:
            Changed the User’s Manual and Training Plan Deliverables to read “Produced by:
04/22/03       Melinda Moody, with support from MaryAnn Gunderson.”                                  1.7
            Added a new User Deliverable entitled “User Training Sessions” to be handled by
               MaryAnn.
04/22/03   Inserted an updated PMDC project plan with actual hours entered through 04/17/03.         1.8
           Remove Edwin Levine as Approver for the Detailed Functional Requirements and
04/22/03                                                                                             1.9
           Reports Deliverables; replace with Laura Pasquale as Approver for these deliverables.




             0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 2 >>   8/13/2009 | 5:52 PM
                      SOW for Performance Measures Data Collection (PMDC) Project


                                                 TABLE OF CONTENTS

REQUEST....................................................................................................................................... 4
BACKGROUND ............................................................................................................................ 4
PROJECT SCOPE .......................................................................................................................... 4
  In-Scope ...................................................................................................................................... 4
  Out of Scope ............................................................................................................................... 5
MANAGEMENT APPROACH ..................................................................................................... 5
  Plan Management........................................................................................................................ 5
  Communications Management ................................................................................................... 6
     Team communications. ........................................................................................................... 6
     Customer communications...................................................................................................... 6
     Project Notebook. ................................................................................................................... 6
  Issues Management ..................................................................................................................... 6
QUALITY ASSURANCE .............................................................................................................. 7
TECHNICAL ENVIRONMENT .................................................................................................... 7
WORK APPROACH AND DELIVERABLES .............................................................................. 7
  Strategy Phase – Project Initiation Activities.............................................................................. 8
  Needs Assessment Phase ............................................................................................................ 8
  System Design Phase .................................................................................................................. 9
  Alpha Development Phase ........................................................................................................ 10
  Beta Testing Phase .................................................................................................................... 11
  Implementation Phase ............................................................................................................... 12
ROLES & RESPONSIBILITIES .................................................................................................. 13
PROJECT PLAN .......................................................................................................................... 16
RISK MANAGEMENT................................................................................................................ 16
  Project Risks ............................................................................................................................. 17
CHANGE MANAGEMENT ........................................................................................................ 18
  Change Procedure ..................................................................................................................... 18
  Change Criteria ......................................................................................................................... 18
ACCEPTANCE MANAGEMENT .............................................................................................. 18
  Acceptance Procedure ............................................................................................................... 18
  Final Acceptance ....................................................................................................................... 19
APPROVED BY: .......................................................................................................................... 19




                    0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc                    << Page 3 >>         8/13/2009 | 5:52 PM
                SOW for Performance Measures Data Collection (PMDC) Project


REQUEST
To develop and implement an application to collect in a single database performance data relating
to measures that have been developed by individual programs areas within the department and
approved for use by OPB and the House and Senate. This project will create a database of
performance measurement data that will be updated on a quarterly basis by each program area
inputting their area-specific data. This project will not replace any existing program area systems.
The purpose of this application is to support the activity based accounting, budgeting, and
performance measurement process.

BACKGROUND
The Department has described the current planning and budgeting system in the following way:
“most would agree that the process and systems the state uses today for planning, budgeting and
prioritizing its fiscal resources are cumbersome, antiquated, and in many cases hinder, rather than
help, accountability. While numerous efforts have been made to improve these processes for over
20 years, they have remained in many ways ineffective. We have multiple performance
measurement systems, all intended to aid decision-making and transparency, but which in actuality
are often redundant, duplicative and not mutually supportive. Although a different stakeholder
group requires each system, many are not linked to the statutorily mandated legislative budget
request process, and those that are do not steer the process in the desired manner. Additionally,
none of these systems is uniformly linked to the state’s accounting system, or ultimately to day-to-
day operations.”

There are currently a number of performance measurement business processes and systems in use
in DEP. Each of these has been a stand-alone performance measurement business process in
support of a specific reporting requirement (LRPP), state function, or the legislative budget
request. In 2002, Secretary Struhs met with EOG staff and Legislative Members and staff to
propose that the DEP implement an activity based/ performance measurement system that would,
to the greatest extent possible, streamline and coordinate our disjointed planning, budgeting and
performance measurement activities. The review and revision of DEP’s performance measures
was one element of the proposal; as was the development of an activity based budget and cost
structure. The Department has completed the review and update of the performance measures and
now needs an application to collect, store, process, and share the performance measurement data.

PROJECT SCOPE
In-Scope
This project involves the development of a web-based system to allow for the following highest-
level performance measurement tracking functions:

   1. Input of DEP performance measurement data; and
   2. Output of DEP performance measurement data in the form of standard reports, and a data
      warehouse environment to enable ad hoc query and ad hoc reports.

   Additionally, multiple user roles will be created: a basic data entry role, Division level
   approval/validation role, an administrative role (OSPP), and a general browser role.

              0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 4 >>   8/13/2009 | 5:52 PM
                    SOW for Performance Measures Data Collection (PMDC) Project


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 this phase,
                     the detailed, agreed upon, approved project plan and Statement of Work
                     should comprise the “road map” that is used to navigate the project.
Needs Assessment     The purpose of this phase is to determine the user needs and application
Phase:               specifications.
System Design Phase: The purpose of this phase is to convert all logical requirements (gathered in
                     the previous phase) into physical/technical specifications to be used for
                     developing a working system.
Alpha Development    The purpose of this phase is to create the first working system1 based on the
Phase:               physical/technical specifications.
Beta Testing Phase:  The purpose of this phase is to review the system to ensure it achieves the
                     goals specified during the System Design Phase.
Implementation       The purpose of this phase is to install the system on the appropriate
Phase:               production platform, grant access to users and provide training.

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

Out of Scope
The following items are out of scope for this project:
   1. Analysis to determine the performance measurement data elements. It is assumed that
       these data elements are already known and will be communicated to the project team when
       the project begins;
   2. Electronically importing the performance measurement data from those various DEP
       systems or organizations that currently provide this data; and
   3. Determining the cost and/or ROI of this functionality versus the cost of the extraction of
       this information from the various applications and manual entry into the Performance
       Measures Data Collection System.
   4. The input of any historical performance measure values data into the PMDC database.
       (The collection of performance measure values will begin after the system is
       implemented.)



MANAGEMENT APPROACH
Plan Management
BIS 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 and after that, the baseline will only be
adjusted when the customer approves a change request that affects the schedule.



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

                 0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc         << Page 5 >>    8/13/2009 | 5:52 PM
                SOW for Performance Measures Data Collection (PMDC) Project

The Project Manager will update the project plan weekly with data supplied by all team members
in the progress reporting process. The Project Manager will control potential changes to the
baseline project schedule and/or estimates through the use of the change procedure as described in
this SOW.
Communications Management
Communications Management will focus on providing regular updates on the contributions,
commitments and challenges for the project effort to all project participants as defined in the
project roles and responsibilities and/or project organizational chart. Communications consist of
the following processes:
   Team communications.
   Each project participant will submit to the Project Manager a weekly Individual Project Status
   Report (IPSR) that identifies completed tasks, tasks expected to be completed in the next
   reporting period, lost time, issues, and time reporting by task (including actual effort, effort
   estimates-to-complete, and estimated completion date). The weekly individual reports are
   consolidated into a summarized weekly project report. The project team will communicate
   weekly to share overall project status, to discuss issues, and to provide assignments and goals.
   Customer communications.
   The Project Manager will meet weekly with the customer to review overall project status, to
   review deliverables and discuss issues. A weekly Project Status Report (PSR) will be
   distributed to the customer and all project participants.
   Project Notebook.
   A project notebook is kept as a single repository for all documentation of project management,
   project reporting and control materials. It is accessible to the project team as a reference
   document throughout the project.
Issues Management
An issue is defined as any item adversely affecting execution of the project plan. Issues may
adversely impact the cost, time frame and/or quality of the deliverables of the project. Resolving
issues is an on-going process throughout the life of any project. The keys to effective issue
resolution are early identification, communication and management. Our process is as follows:
Issues are recorded into a Project Issue Log. Every record in the Issue Log contains a description of
the issue, actual or potential impact if not resolved, who raised the issue, when the issue was
raised, updates, and final resolution. Every issue has a target date for resolution after which the
project is impacted. Every issue has an owner responsible for driving resolution and keeping the
Project Manager up to date on progress.
Issues are listed (or the Issues Log is attached) in the weekly Project Status Report (PSR). Issues
are reviewed weekly in team status and customer status meetings. Issues are closed only when the
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. Escalation
       involves bringing the issue to the attention of the Project Sponsor for resolution.




              0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 6 >>   8/13/2009 | 5:52 PM
                SOW for Performance Measures Data Collection (PMDC) Project

QUALITY ASSURANCE
This project will use the standard BIS Control and Reporting Process (BCRP) to monitor project
quality. BCRP deals with “project management” expectations within BIS and sets rigorous, but
minimum standards for quality in project management. Projects within BIS are randomly selected
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 Project
Management Office (PMO), Peer/QA Reviews of project deliverables and the standard quality
processes built into the BIS Information System Development Methodology (ISDM).

TECHNICAL ENVIRONMENT
The 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 Oracle account
   on the appropriate database (on ORABETA for beta testing; on ORAPROD for production).
   Also, a user must have been granted access, in the Web Access Control Application (WACA),
   to the Performance Measures Data Collection (PMDC) System.
 Development environment -The PMDC forms will be created on the development middle tier
   server, EPIC27 (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 PMDC forms will be moved to the Beta region of EPIC27 by one
   of the BIS developers. The changes should be tested by the users in this region by using the
   beta URL: http://depbeta.dep.state.fl.us:7777. The database that will be used for application
   testing is ORABETA.
 Production environment - Once approved, the PMDC forms can be moved to production.
   The items will be moved from EPIC27 (BETA) to the production servers (EPIC29 for network
   users and EPIC28 for delegated county users), by one of BIS’ Database Administrators (DBA),
   at the request of one of the BIS developers. The new system will then be available from this
   URL: http://depapps.dep.state.fl.us:7777/. The production database is ORAPROD.

The report development work for the project will be done on TLHORA4 utilizing ORADEV or
DOPPLER. Testing will be done on TLHORA5 utilizing ORABETA or DOPPLER. Once
approved, the reports will be deployed on TLHORA6 with ORAPROD or DOPPLER as the
supporting database instance.

WORK APPROACH AND DELIVERABLES
The following methodologies and standards will be taken into account during development for
each phase of this project:

    1. DEP’s Information Systems Development Methodology (ISDM)
    2. BIS’ Productivity Management Standards
    3. BIS’ Oracle Designer Naming Standards



              0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 7 >>   8/13/2009 | 5:52 PM
                  SOW for Performance Measures Data Collection (PMDC) Project

Strategy Phase – Project Initiation Activities
The primary objective of this phase is to produce:

                MS Project Plan
          (#1)
                The project plan details all (known) project tasks, work estimates, resource assignments,
   Deliverable
                percent of the project that is complete, proposed task begin and end dates, and proposed
   Description
                start and end dates for the project.
  Produced by: Charlotte Gregg
                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
   Acceptance  The team has correctly identified the deliverables for the project;
      Criteria:  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): Kimber Allen, Edwin Levine
  Approver(s): Edwin Levine, Laura Pasquale

          (#2)   Statement of Work (SOW)
   Deliverable   This document details the agreements between BIS and the customer as to how, when,
   Description   where and in what way the project will be carried out.
  Produced by:   Kimber Allen, Charlotte Gregg
                 The delivery of the Statement of Work (SOW) will be determined ACCEPTABLE when
                 the following criteria are met:
                  The project manager and project team understand the problem, opportunity, or need;
   Acceptance     The Project Sponsor agrees the direction of the project accurately aligns with the
     Criteria:       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):   Kimber Allen, Edwin Levine
  Approver(s):   Edwin Levine, Laura Pasquale

Needs Assessment Phase
The primary objective of this phase is to produce, through information obtained from interviews and data
gathering activities, the following:

          (#3)    Equipment Survey
   Deliverable    An inventory of the hardware and software resources required/available for the users of
   Description    the Performance Measures Data Collection system.
  Produced by:    Charlotte Gregg, Laura Pasquale
                  The delivery of the Equipment Survey will be determined ACCEPTABLE when the
                  following criteria are met:
   Acceptance      The document correctly represents the minimums that are required for the
     Criteria:        Performance Measures Data Collection system; and
                   The document allows for each potential user to document where he or she is below
                      the recommended minimums.
  Reviewer(s):    Lakshmi Paladugu
  Approver(s):    Laura Pasquale


               0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 8 >>   8/13/2009 | 5:52 PM
                 SOW for Performance Measures Data Collection (PMDC) Project


                 Entity Relationship Diagram (ERD) & associated documentation
                 The Entity Relationship Diagram is a graphical representation that shows data entities,
         (#4)
                 the relationships among them, and the nature of those relationships. This diagram also
  Deliverable
                 organizes data items under the appropriate entity. The associated documentation
  Description
                 provides a System Glossary, a report of Entities and their relationships, plus Entities and
                 their Attributes.
 Produced by:    Charlotte Gregg, Lakshmi Paladugu
                 The delivery of the ERD and associated documentation will be determined
                 ACCEPTABLE when the following criteria are met:
                  The diagram correctly represents the data elements communicated during interviews
                     and data gathering activities;
                  The diagram meets BIS’ modeling standards;
   Acceptance
                  The System Glossary report correctly names and defines all entities, according to the
     Criteria:
                     business rules of the sponsor office;
                  The relationships derived from the Entity Definition Report are validated against the
                     business rules of the sponsor office; and
                  The data type and data length detailed in the Entities and their Attributes Report are
                     correct according to the existing or proposed data for the system.
  Reviewer(s):   Kimber Allen, Charlotte Gregg
  Approver(s):   Laura Pasquale

System Design Phase

               Detailed Functional Requirements
         (#5)
               This deliverable identifies the various business rules that dictate the functional
  Deliverable
               requirements. This document also outlines those functions to be automated and the
  Description
               hierarchy of these functions.
 Produced by: Lakshmi Paladugu
               The delivery of the Detailed Functional Requirements will be determined
               ACCEPTABLE when the following criteria are met:
                The diagram correctly details the functionality desired in the system under
  Acceptance
                   development;
     Criteria:
                The business rules are clearly spelled out and their implementation in the system is
                   described; and
                The document makes clear the menu layout for the proposed system.
 Reviewer(s): Kimber Allen, Charlotte Gregg
 Approver(s): Laura Pasquale

         (#6)    Impact Assessment Summary
  Deliverable    A document that details the impacts (if any) in the following areas: databases, middle
  Description    tier servers, systems and network servers, help desk and GIS.
 Produced by:    Lakshmi Paladugu
                 The delivery of the Impact Assessment Summary will be determined ACCEPTABLE
   Acceptance    when the following criteria are met:
     Criteria:    The document explains/considers all potential impacts and
                  The document meets BIS’ standards.
  Reviewer(s):   Kimber Allen, Charlotte Gregg
  Approver(s):   Spencer Lepley, Kevin Kerckhoff, Jon Canter, Barbara Kennedy, Linc Clay



             0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc     << Page 9 >>   8/13/2009 | 5:52 PM
                 SOW for Performance Measures Data Collection (PMDC) Project

Alpha Development Phase

         (#7)    Forms or Screens
  Deliverable    The forms/screens are what the users see when using the application. The screens can be
  Description    of various types, including data entry and query screens.
 Produced by:    Lakshmi Paladugu, Keith Willis
                 The delivery of the Forms or Screens will be determined ACCEPTABLE when the
                 following criteria are met:
   Acceptance
                  Each form or screen is developed according to specifications derived from the
     Criteria:
                     Detailed Functional Requirements/Business Rules document and
                  Each form or screen is developed according to current BIS Forms Standards.
  Reviewer(s):   Kimber Allen, Charlotte Gregg
  Approver(s):   Laura Pasquale

               Reports or Other Output
         (#8)
               A report is information, derived from the performance measures data, describing the
  Deliverable
               findings of some individual or group or the summary information pertaining to a specific
  Description
               item, occurrence, or entity.
 Produced by: Lee Wheeler
               The delivery of the Reports or Other Output will be determined ACCEPTABLE when
               the following criteria are met:
  Acceptance
                Each report (or other output) is developed according to specifications derived from
     Criteria:
                   the Detailed Functional Requirements/Business Rules document and
                Each report is developed according to current BIS Reports Standards.
 Reviewer(s): Kimber Allen and Charlotte Gregg
 Approver(s): Laura Pasquale

               Beta Test Plan
         (#9) A plan that defines who will participate in testing (during the next phase), how the
  Deliverable testing should be carried out, where and when beta training will occur, how test results
  Description will be recorded and transmitted back to the developers, and the estimated length of test
               period.
 Produced by: Lakshmi Paladugu, Keith Willis
               The delivery of the Beta Test Plan will be determined ACCEPTABLE when the
               following criteria 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 meets BIS standards;
  Acceptance
                The Beta Test Plan identifies details of how testing will be carried out;
     Criteria:
                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 test plan and documented procedures.
 Reviewer(s): Kimber Allen, Charlotte Gregg
 Approver(s): Laura Pasquale

        (#10)    Preliminary DBA Migration Package (from ALPH to BETA)
  Deliverable    Data migrations plan for transferring data from existing applications to the new system.
  Description    This plan identifies specific data to migrate and migration methods.
 Produced by:    Lakshmi Paladugu, Keith Willis

             0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc    << Page 10 >>   8/13/2009 | 5:52 PM
                 SOW for Performance Measures Data Collection (PMDC) Project

         (#10) Preliminary DBA Migration Package (from ALPH to BETA)
  Deliverable Data migrations plan for transferring data from existing applications to the new system.
  Description This plan identifies specific data to migrate and migration methods.
                The delivery of the DBA Migration Package will be determined ACCEPTABLE when
                the following criteria are met:
                 The number of beta users, with their locations, is detailed;
   Acceptance  The number and size of tables and the expected growth of the database is described;
      Criteria:  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.
  Reviewer(s): Charlotte Gregg
  Approver(s): Spencer Lepley

Beta Testing Phase

               User BETA Testing
        (#11)
               This deliverable represents the time allowed for the user community to BETA test the
  Deliverable
               new system following the BETA test plan. The Beta Test is carried out in accordance
  Description
               with the Beta Test Plan.
 Produced by: Carried out by the user community, with assistance from the Project Manager as needed.
               The User BETA will be determined ACCEPTABLE and COMPLETE when the
               following criteria are met:
                All forms are working as expected in the BETA environment;
  Acceptance
                All reports are working as expected in the BETA environment;
     Criteria:
                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 PMDC system.
 Reviewer(s): Charlotte Gregg, Lakshmi Paladugu
 Approver(s): Laura Pasquale

       (User)
                 User’s Manual
  Deliverable
                 Manual that describes how to use the new system.
  Description
 Produced by:    Melinda Moody, with support from MaryAnn Gunderson
  Acceptance     The User Community determines acceptance Criteria. This is a user deliverable; BIS
     Criteria:   does not require signoff by the customer.
 Reviewer(s):    Charlotte Gregg
 Approver(s):    This is a user deliverable; BIS does not require signoff by the customer.

       (User)    Training Plan
  Deliverable    This plan describes how user training will be conducted when the application is moved
  Description    into production.
 Produced by:    Melinda Moody, with support from MaryAnn Gunderson.
  Acceptance     The User Community determines acceptance Criteria. This is a user deliverable; BIS
     Criteria:   does not require signoff by the customer.
 Reviewer(s):    Charlotte Gregg
 Approver(s):    This is a user deliverable; BIS does not require signoff by the customer.




             0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 11 >>   8/13/2009 | 5:52 PM
                 SOW for Performance Measures Data Collection (PMDC) Project

       (User)    User Training Session(s)
  Deliverable    These are the actual session(s) during which system users are trained, following the
  Description    training plan.
 Produced by:    MaryAnn Gunderson.
  Acceptance     The User Community determines acceptance Criteria. This is a user deliverable; BIS
     Criteria:   does not require signoff by the customer.
 Reviewer(s):    Laura Pasquale
 Approver(s):    This is a user deliverable; BIS does not require signoff by the customer.

               Implementation Plan
        (#12)
               The Implementation Plan should include the details necessary for production migration;
  Deliverable
               for example, dates, file names, and locations of programs which must be run.
  Description
               Coordination with Database Administration staff and the user community is imperative.
 Produced by: Lakshmi Paladugu
               The delivery of the Implementation Plan will be determined ACCEPTABLE when the
               following criteria are met:
                The implementation plan identifies the steps that must be taken before the new
  Acceptance
                   system is implemented in the production environment (excluding those details that
     Criteria:
                   will be in the DBA Migration Package) and
                The implementation plan identifies all parties that should be notified of the new
                   system to be implemented.
 Reviewer(s): Charlotte Gregg
 Approver(s): Laura Pasquale

        (#13)    Final DBA Migration Package (from BETA to PRODUCTION)
  Deliverable    Produce any additional migration information required by the DBA. This requirement
  Description    complements/finalizes the Migration Package created in the previous phase.
 Produced by:    Lakshmi Paladugu
                 The delivery of the DBA Migration Package will be determined ACCEPTABLE when
                 the following 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;
   Acceptance
                  The package includes a list of the scripts that must be run to create and populate the
     Criteria:
                     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).
  Reviewer(s):   Charlotte Gregg
  Approver(s):   Spencer Lepley

Implementation Phase

              Production Move and Verification
        (#14) This deliverable involves physically installing the system on the appropriate production
  Deliverable platform in accordance to the Implementation Plan. It also includes migrating data and
  Description granting access to the appropriate users. At this point the application belongs to the
              program area and developers no longer have update access.
 Produced by: Lakshmi Paladugu, Keith Willis, and Lee Wheeler
  Acceptance The Production Move will be determined ACCEPTABLE when the following criteria are

             0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 12 >>   8/13/2009 | 5:52 PM
                   SOW for Performance Measures Data Collection (PMDC) Project

                Production Move and Verification
         (#14) This deliverable involves physically installing the system on the appropriate production
  Deliverable platform in accordance to the Implementation Plan. It also includes migrating data and
  Description granting access to the appropriate users. At this point the application belongs to the
                program area and developers no longer have update access.
      Criteria: 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
                    required in the PMDC system.
  Reviewer(s): Charlotte Gregg
  Approver(s): Laura Pasquale




ROLES & RESPONSIBILITIES



                                        PMDC Project Organization Chart



                                                      Edwin Levine                           .
                                                 Executive Project Sponsor


                            Charlotte Gregg                                                  Laura Pasquale
                            Project Manager                                                 Project Customer
                                                                             SME Group
Technical Mgmt. Group
                                                     Business Analyst           Lynda Watson           Mary Ann Gunderson
    Kimber Allen               Terri Rein                                    Subject Matter Expert     Subject Matter Expert
  Mgr. - Applications     Mgr. - Project Mgmt.       Data Architect
                                                     Programmer
                                                     Oracle Forms SME          Melinda Moody                Joe Young
     Jon Canter             Kevin Kerchkoff                                  Subject Matter Expert     Subject Matter Expert
                                                     ASP Reports SME
     Mgr. - ISSC           Network/Systems
                                                                                Linda Frohock             John Hughes
   Spencer Lepley          Barbara Kennedy                                   Subject Matter Expert     Subject Matter Expert
   Mgr. - Databases        Mgr. - Middle Tier
                                                                                  Ingrid King           Geofrey Mansfield
                                                                             Subject Matter Expert     Subject Matter Expert




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



                0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc      << Page 13 >>      8/13/2009 | 5:52 PM
                  SOW for Performance Measures Data Collection (PMDC) Project


The following outlines the roles and responsibilities needed for the successful execution of this
project:

 Project Role      Name            Project Responsibilities
 Executive                          Approve Statement of Work (SOW)
                   Edwin
 Project                            Approve changes in project scope or budget (change requests)
                   Levine
 Sponsor                            Final project approval
                                    Approve Statement of Work (SOW)
                                    Approve changes in project scope or budget (change requests)
                                    Resolution of escalated issues
                                    Approve Deliverables
 Project           Laura
                                    Monitor project progress monthly
 Customer          Pasquale
                                    Break ties for escalated issues that cannot be resolved by the
                                      project team.
                                    Project recommendations and guidance
                                    Final project approval
                                    Develop Statement of Work (SOW)
                                    Validate critical success factors
                                    Develop and manage project to baseline project plan
                                    Develop and manage project budget
                                    Oversee project status and communications
                                    Implement and track Quality Assurance on project
 Project           Charlotte
                                    Manage and facilitate resolution of issues
 Manager           Gregg
                                    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
                   Lakshmi          Document business processes and rules in the Detailed
 Business          Paladugu,          Functional Requirements/Business Rules document
 Analyst           Charlotte        Create the Impact Assessment Summary
                   Gregg            Create Implementation Plan
                   Lakshmi
                                      Create and document the logical data model (ERD)
                   Paladugu,
 Data Architect                       Create physical data model (SMD)
                   Charlotte
                                      Create Equipment Survey
                   Gregg
                                      Develop specifications for forms/screens
                   Lakshmi,           Create forms/screens for data input
 Programmer        Keith Willis,      Meet with users concerning reporting needs and preferred
                   Lee Wheeler         report layout and style
                                      Create reports and other output
                                      Create and document project test plan
                   Lakshmi
 Testing Lead                         Define project testers and user testers
                   Paladugu
                                      Lead testing effort


             0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 14 >>   8/13/2009 | 5:52 PM
               SOW for Performance Measures Data Collection (PMDC) Project

Project Role    Name             Project Responsibilities
                                  Perform Project Reviews
Project Officer Terri Rein        Assist Project Manager with implementation of BIS Project
                                    Management standards
                                  Create/Review SOW
                                  Review Project Plan
                                  Review the Entity Relationship Diagram and Server Model
                                    Diagrams
                                  Review the business processes and rules in the Detailed
SME-
                Kimber              Functional Requirements/Business Rules document
Applications
                Allen             Review Impact Assessment Summary prior to distribution to
                                    other Technical managers group
                                  Review the forms and reports
                                  Review the Beta Test Plan
                                  Provide subject matter expertise on applications interfaces
                                  Testing assistance
                Kimber
                Allen,
                Spencer
Technical       Lepley,
Management      Kevin               Review and approval of the Impact Assessment Summary
Group           Kerckhoff,
                Jon Canter,
                Barbara
                Kennedy
                                    Review impact to database administration
SME-Database
               Spencer              Provide subject matter expertise on database administration
administration
               Lepley                issues
                                    Testing assistance
                Kevin
SME-Network
                Kerckhoff,          Provide subject matter expertise on network and system issues
& Systems
                Brian               Testing assistance
                Narkinsky
SME-Middle      Barbara             Provide subject matter expertise on middle tier issues
Tier            Kennedy             Testing assistance




           0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 15 >>   8/13/2009 | 5:52 PM
                SOW for Performance Measures Data Collection (PMDC) Project

 Project Role     Name             Project Responsibilities
                  Lynda
                  Watson, Joe
                  Young,
                  Melinda
                  Moody,              Review Statement of Work
 SMEs-            Mary Ann            Review Project Plan
 Customer         Gunderson,          Provide subject matter expertise in the appropriate area
 Group            Linda               Assist in the definition of data elements
                  Frohock,            Review the ERD
                  John Hughes,
                  Ingrid King,
                  Geoffrey
                  Mansfield

PROJECT PLAN
A summarized project plan is presented here showing planned tasks and activities; planned start
and finish dates and work estimates. This project was estimated using experienced based
estimating.




RISK MANAGEMENT
Risks exist on every project; however, proactive management can reduce project risk occurrence
and risk impact. A structured process serves to monitor, assess, and deal with known risks and to
uncover new risks as they arise. Risks are communicated to the project team and to the customer
to encourage shared management of the potential risks. Risks are reviewed with the customer to
create awareness of what we are doing to address risk and also to make the customer aware we
may seek their involvement in mitigation.
Risks are formally reviewed during creation of the SOW and each month thereafter. The previous
risk assessment serves as input to the next risk assessment. However, new risks may be identified
and priorities can/do change. The Project Risk Assessment (PRAM) will be reviewed and updated
on a more frequent basis if warranted.




             0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 16 >>   8/13/2009 | 5:52 PM
                        SOW for Performance Measures Data Collection (PMDC) Project

Project Risks
                                                                                                                            Mitigation Steps
                                                                           Expectation or
     Risk                                                                                              Negative                 (include
ID                             Prob   Consq    Positive Impact              Estimating
     Variables                                                                                          Impact              mitigation tasks
                                                                            Assumption
                                                                                                                            in project plan)

                                               It is unlikely that key                               If key personnel
                                               personnel will leave the                              leave the              Project briefings will be
     Turnover of Key                                                        The project assumes
                                               organization during the                               organization           done for various
     Personnel - The                                                        key personnel will
                                               time period the project                               during the project,    members of the
     project is dependent                                                   be available for the
                                               is taking place. If these                             it will be necessary   organization, so that if
     upon key personnel                                                     length of the project,
1                              Low     High    key resources are re-                                 to delay the project   we do need to replace a
     being available to                                                     namely, Ed Levine,
                                               allocated to other work                               while we look for a    resource on the project
     complete in a timely                                                   Charlotte Gregg,
                                               within DEP, they will                                 replacement            we can possibly use an
     manner and to meet                                                     Lakshmi Paladugu,
                                               still be available to                                 resource and bring     internal resource and
     the commitments.                                                       and Kimber Allen.
                                               provide subject matter                                that resource up to    reduce ramp up time.
                                               expertise.                                            speed.


                                                                            The schedule is          If the customer is
                                                                            estimated based on       not able to test in    Keep customer
                                               If the customer is able
     Customer is not able                                                   the customer being       the agreed to time     informed of pending
                                               to test faster than
     to have sufficient                                                     able to provide quick    frames deliverable     delivery of items to be
2                              Low    Medium   anticipated deliverables
     resources available                                                    turnaround times for     dates will be re-      tested in weekly status
                                               may be delivered ahead
     for user testing.                                                      enhancements being       estimated and time     meetings so they can be
                                               of schedule.
                                                                            delivered to them for    will be lost in re-    prepared.
                                                                            testing.                 planning.


                                               It is possible that the
                                                                                                     If the Customer
                                               Customer will decide         Estimating
                                                                                                     needs to change
                                               something scheduled is       assumptions are
                                                                                                     priorities or add      Conduct weekly
                                               no longer important in       based upon the
     Customer changes                                                                                additional items to    progress meetings with
                                               this phase or reduce the     customer sticking
3    priorities or has         Low    Medium                                                         the enhancement        the customer; review
                                               scope of an effort           with the schedule
     conflicting priorities.                                                                         list time will be      issues and priorities on
                                               allowing us to               and not changing the
                                                                                                     lost while the         a continuing basis.
                                               potentially deliverable      deliverables and
                                                                                                     project schedule is
                                               some other items ahead       acceptance criteria.
                                                                                                     re-planned.
                                               of schedule.

                                                                            Due the projected
                                               Training room is                                      Training cannot
                                                                            timeframe, the
     Training Room                             scheduled in advance                                  occur during the       Reserve room early in
4                              Low     High                                 training room has
     availability                              and appropriate                                       projected              the project.
                                                                            available open
                                               training occurs.                                      timeframes.
                                                                            windows.

                                                                                                     Schedule is            Ensure necessary
     Data elements are                         Data elements are                                     adversely affected,    analysis and
                                                                            During analysis the
     not clearly defined                       predefined and static                                 causing re-            specifications are
5                              Low     High                                 data elements can be
     or are 'moving                            allowing project to                                   estimation and lost    complete prior to
                                                                            clearly defined
     targets'                                  finish on time.                                       time to do re-         proceeding with other
                                                                                                     planning.              phases of the project.


     User workstation                                                                                                       Equipment Survey is
                                               Necessary upgrades           All users conform to     Affected users
     does not meet                                                                                                          done early in the project
6                              Low    Medium   will be implemented          current BIS              cannot run the new
     recommended                                                                                                            to allow for upgrades as
                                               for DEP staff.               minimum standards.       PMDC system.
     minimum standards.                                                                                                     necessary.




                    0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc               << Page 17 >>        8/13/2009 | 5:52 PM
                 SOW for Performance Measures Data Collection (PMDC) Project

CHANGE MANAGEMENT
Change Procedure
The change procedure will be used in any situation where a change occurs to the project as defined
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. The
change process will also be used when these processes and procedures are violated or when there
is a failure to perform some aspect of the Statement of Work. The Project Manager estimates the
impact of change requests as to the need or benefit, the impact to cost and schedule and then
secures appropriate management approval before adjusting. Note that some changes do not impact
cost or schedule but alter expectations. These are called Informational Change Requests and will
be handled the same as non-informational change requests.
1. Anyone on the project team may request a change. The request for change is given to the
   Project Manager. The Project Manager analyzes the change request and completes the Change
   Request Form and presents the request to the Project Sponsor and/or Project Customer for
   review, discussion, and disposition.
2. The change request must be disposed (approved or rejected) within 3 business days after
   submittal. This approval/rejection must be in writing. The project will not be adjusted until the
   change request is approved. If no reply is received within the timeframe, the change is treated
   as an issue.
Change Criteria
The 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 something previous agreed
to or define something that did not happen as planned. Examples include system not being
available (lost time), people not performing their duties per the agreed roles and responsibilities,
changes to deliverables or project scope.

ACCEPTANCE MANAGEMENT
Acceptance Procedure
Deliverables are defined throughout the life of the project. These provide the building blocks that
move the project towards final completion. Acceptance of a deliverable means the customer has
given a “go” to use this deliverable as input to related future deliverables. Acceptance of
deliverables on a timely basis is critical in order to avoid delays to the project. In order to ensure
smooth 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 description of
   the deliverable and the pre-approved acceptance criteria defined in the Statement of Work for
   that deliverable.
2. Acceptance must be in writing (no verbal approvals). E-mail approvals are acceptable if they
   are explicit (that is, clear which deliverable is approved). A walkthrough of the deliverable
   with 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
   frame is mutually agreed upon. The Acceptance Form lists the specific due date to eliminate

              0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 18 >>   8/13/2009 | 5:52 PM
                SOW for Performance Measures Data Collection (PMDC) Project

   any confusion about when approval is needed to stay on schedule. If approval is not received
   on a timely basis, its lateness is treated as an issue. We never assume default acceptance or
   rejection. Rejections must specify what is unacceptable.


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


APPROVED BY:

________________________________________          __________
 Executive Project Sponsor                           Date


________________________________________          __________
Project Customer                                     Date


_______________________________________          __________
 DEP Applications Section Manager                    Date


_______________________________________          __________
Project Manager                                      Date




             0387f6dc-a03f-4757-bd40-ccf79dc9092e.doc   << Page 19 >>   8/13/2009 | 5:52 PM

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:11
posted:8/14/2009
language:English
pages:19