USA: +1(669)289-8683 
Sign in
week3 – week5
week3 due monday 6/10/2013
Week4-Week5 due 6/15/2013
SCG
LAN
SCG
WAN
H
R
M
S
Database
Server
ABRA
Administrator
ABRA
Database
Server
HRMS
Database
(Partial Update
Capability)
ABRA
Full Access
Business Center
HR Reps
Note: Exporting Data from HRMS to
ABRA will not be attempted. There
will be no fall back plan to use the
ABRA Database once HRMS has
been tested and implemented.
HRMS
Database
Full Access
E-mailed HRMS Updates From Business
Center Rep to
ABRA Administrator
Sarasota County Government
Project
Plan
SCG LAN
SCG
WAN
HRMS
Database
Server
ABRA Administrator
ABRA
Database
Server
HRMS
Database
(Partial Update
Capability)
ABRA
Full Access
Business Center
HR Reps
Note: Exporting Data from HRMS to
ABRA will not be attempted. There
will be no fall back plan to use the
ABRA Database once HRMS has
been tested and implemented.
HRMS
Database
Full Access
E-mailed HRMS Updates From Business
Center Rep to ABRA Administrator
Project Plan
for the
Project
Version:
1
.0.0
June
9
,
2
01
3
Sarasota County Government
Project Management Office
Document Control
Document Approval
|
Approvals |
Signature |
Date |
|
Document History
|
Revision |
Author/Reviser |
Comments |
Document Storage
This document is created in Microsoft Word
20
00 and is maintained in the
Project Contact
The contact for this document is:
Phone:
E-mail:
Sarasota County Government
Project Management Office (
PM
O)
Preface
This Project Plan defines the activities to be performed, the products to be developed, the project schedule, and the resources required to develop the
Table 1 Initial Distribution List
|
Name |
Project Role |
Delivery Information |
||||||
|
Name |
Sponsor, Tester, etc |
E-mail, Web, etc. |
After Initial Distribution the lastest version of the project plan will be located on the EIT Project Page located at
Table of Contents
iiApprovals
1
Introduction
5
1.1
Project Plan Purpose
5
1.2
Evolution of the Project Plan
5
2
Project Overview
7
2.1
Project Scope
7
2.2
Project Modules
7
2.3
Project Assumptions and Constraints
8
2.
4
Software Life Cycle
8
2.5
Project Issues
8
2.
6
Course Corrections
8
2.7
Testing
9
2.8
Training
9
3
Project Management
10
3.1
Project Management Objectives and Priorities
10
3.2
Procedures, Methods and Standards
10
3.3
Quality Assurance Plan
11
4
System Overview
12
4.1
Figure 1 – System Connectivity
12
5
Critical Computer Resources
14
5.1
Critical Computer Resource Assumptions
14
6
Project Schedule and Level of Effort Estimates
14
Risk Management
16
External Dependencies
17
Appendix A – Major Milestone and Schedule Summary
18
Appendix B – Initial Work Breakdown Structure
19
Index of Tables
6
Table 1 Reference Materials
Table 2 Vendor Developed Modules
7
Table 3 EIT Developed Modules
7
Table 4 Project Roles
11
Table 5 Project Contact List
11
Table 6 Summary of Critical Computer Resources for the Project
14
Table 7 Risk Management
16
Table 8 Major Milestone LOE and Schedule Summary
18
1 Introduction
1.1 Project Plan Purpose
The purpose of this document is to provide a mechanism to communicate the project scope, assumptions, constraints, project issues, risks, and Project Management objectives as well as other pertinent project information. Project details relating to work at the task level is in the Work Breakdown Structure (Appendix B).
This project plan will be used to manage tasks, milestones, the project schedule, project issues, risks, and resource assignments for the
The Project Major Milestone and Schedule Summary can be found in Appendix A. The Work Breakdown Structure, Schedule, and link to the Microsoft Project Plan are contained in Appendix B. Appendix C contains the latest version of the Project Issues Log.
1.2 Evolution of the Project Plan
This Project Plan will be reviewed and updated if necessary at the end of each life cycle phase to ensure that it accurately reflects the status of the project. The Project Plan will also be reviewed in the Weekly Project Status meeting and modifications will be made if required.
If changes to the Project Plan’s Schedule Baseline are required, they will be made once an approved Scope Change Request has been completed and approved.
Table 1 Reference Materials
|
Document Overview |
Created By |
Document File Location and/or Name |
2 Project Overview
2.1 Project Scope
This project will allow for planning, design, development, testing, and implementation of a
2.2 Project Modules
Table 2 Vendor Developed Modules
|
Vendor |
Module(s) |
Table 3 Internally Developed Modules
|
Group |
Project Assumptions and Constraints
2.2.1 Assumptions
2.3.2
Constraints
2.3 Software Life Cycle (If applicable, remove if not)
Example: The software life cycle chosen for this project is Rapid Application Development (RAD). This life cycle was chosen because this project is on a fast track and as such must be developed in the shortest amount of time.
2.4 Project Issues
Issues and problems will be tracked in the Project Issues Log as they arise. (Appendix C). The issues log will be uploaded to the
> every Course corrections will be made throughout the project. These course corrections will be discussed in the Weekly Project Status Meetings.
Testing
1. Component One
2. Component Two
3. etc.
Example: Business Center and PMO personnel will be responsible for the development and implementation of the user acceptance test. The User Acceptance Test (UAT) will ensure the primary sponsor and stakeholders are satisfied that the requirements have been me. A signoff of the UAT by the project sponsor is required prior to implementation.
Example: The User Acceptance Test will test at a minimum the following:
1. All GUIs and backend functionality
2. Manager Portal, GUIs, and backend functionality
3. Administration Portal, GUIs and backend functionality
4. Merit Increase Process Functionality
5. Performance Review Process
6. Performance Review Process – Multi-Rater Feedback
7. Employee Information Update Process A training plan will be developed outlining the roles and responsibilities of the Project Management
Example
1. Ensure the project completes on the targeted implementation date.
2. Assist in obtaining needed development and support tools to support EIT development.
3. Assist (as needed) the development manager in identifying and distributing responsibilities to development resources by components.
4. Coordinate external issues through the appropriate departments.
5. Conduct and lead weekly Project Management status meetings to gather and report accurate status.
6. Report project progress through the creation of weekly status reporting.
Example
1. Project status will be reported weekly. Status reports will be available on the
EIT Project Web Site
every Wednesday.
2. Changes to milestone dates, risks, or resources, which have the potential to result in a Scope Change Request (SCR), will be communicated to the project stakeholders in the weekly status report.
3. Project Schedule issues will be tracked and controlled by the project manager and the project team.
4. Project Schedule actuals in regards to Milestone Actual Start and Finished dates will be reported via the Project Status Report
5. Risk Management will be performed throughout this project.
6. Weekly Status meetings will be held with select members of the project team.
Table 4 Project Roles
Example- Delete and add applicable project information
Project Role
Name
Responsibilities
XXX General Manager
Name
Oversee EIT and External Development Efforts
Development Manager
Name
Development responsibilities
Project Manager
Name
Day-To-Day Project Oversight
Department Manager
Name
Manage Development Resources
Analysis
Name, Resource 2 Gustafson , Resource 1
Gather and document project requirements
Development
Developer/Vendor names
Develop application processes, reports, custom modules and GUIs
Database Administration
DBA
Design, develop, and support the Database
Quality
Team Members
Names
Quality Team
Table 5 Project Contact List
Example
Department
Phone #
E-mail Address
Location
Diana Allen Human Resources/Payroll 31 6- 120 6
dallen@co.sarasota.fl.us 67 00 Clark Rd. Brian Darley Enterprise Information Technology 8 61 -5 41 8
bdarley@co.sarasota.fl.us SCTC Barbara Thibault Human Resources/Personnel 86 1- 53 26
bthibaul@co.sarasota.fl.us 1 60 0 Ringling Eleanor Zoppe Enterprise Information Technology 6 50 -9 48 9
ezoppe@scgov.net SCTC Enterprise Information Technology 65 0- 91 96
egustaf@co.sarasota.fl.us SCTC Fred Dunayer Enterprise Information Technology 650-2 21 6
fdunayer@co.sarasota.fl.us SCTC Gayle Gursky Finance and Administration 861-61 76
ggursky@co.sarasota.fl.us 13 01 Cattlemen Nancy Fisher Administrative & Financial Services 861-67 15
nfisher@co.sarasota.fl.us 28 17 Cattleman Nikki Snyder Payroll (Finance – Clerk) 861- 51 59
nsnyder@co.sarasota.fl.us 1 66 0 Ringling
Example Only
Example High-Level Planning Milestones
Task
Status
Conduct a Database Model Review with the Database Architect Complete – 02/07/03 Initial meeting with Web developers to discuss details surrounding the GUIs Scheduled – 02/10/03 Meet with developers and Database Architect to map GUI fields to database tables/fields Not scheduled. No resources identified as of 02/10/03. Developers and Core team to meet to define data constraints Not started Define error processing for all GUIs Not started
Example High-Level Planning Milestones
Task Status Check for dates and numbers outside of normal ranges Not started Payroll/HR comparison (pay, classification, position from standard download) Not started Classification and Transaction updates Not started Other Maintenance reports Not started Entry of employee change transactions through last full pay period prior to implementation. Not started
Example High-Level Estimate (optional)
Resource 1 – Run Exception Reports and Comparisons; update code tables
40 hours
Critical Computer Resources The following table summarizes the list of the critical computer resources required for this project for all impacted systems:
Table 6 Summary of Critical Computer Resources for the Project Example
Resource
New/Additional
Type and/or
Application
Source
Workstations (development, testing, training, production, user)
N/A
N/A N/A
Servers (Production, Test, Development, and Training)
2 (Production)
Microsoft IIS
Microsoft SQL Server 2000
EIT
Direct Access Storage Device (DASD)
N/A N/A
Communications requirements
Connectivity from all SCG County Offices to the Suncoast Technology Center
Connectivity to SCG iNet
EIT
System Software, Utilities, Software Tools
Development
Test
Production
Identitech Components
SQL Server 2000 Software
Microsoft IIS Software
EIT Example 1. The critical computer resources requirements as outlined above will be required to complete Phase I of the HRMS project.
2. The EIT/Network Applications group created the above Critical Computer Resource requirements.
Example · Level of effort (LOE) information would normally be documented in the Milestone and Schedule Summary in the table of Appendix B. Since this project follows a RAD approach, LOE information by Milestone will not be supplied.
· Schedule estimates would normally be derived by estimating the project at a task level, using task decomposition techniques, and by interviewing the resources on the development team. Since this project will utilize a RAD approach, the schedule has been built using the project completion date and backing into a schedule from there.
· Estimates and timeframes noted in the Microsoft Project Plan (MPP) contain our best guesses as to when certain tasks will be complete. The MPP will evolve over time and be adjusted as needed. Milestone information is documented in Appendix B at a summary level and the schedule is documented in detail in the Work Breakdown Structure referenced in Appendix C.
Risk Management
Example 1. Risks will be identified throughout the project and reviewed in weekly project status meetings.
2. Risks that are discovered externally will be evaluated by the project lead/development team and considered for inclusion, then prioritized and addressed if necessary in the Risk Statement Table (below).
3. All action items resulting from the Risk assessments will be noted in the Project Issues log and reviewed in the Weekly Project Status meeting.
Table 7 Risk Management (Example)
#
Risk
Risk
Consequence
Priority High, Medium, Low
Risk resolution progress
Creeping requirements
Delayed
Implementation
Increased Scope
High
· User interface prototype used to gather high-quality requirements.
· Staged delivery approach will be employed to provide some ability to change features if needed.
Requirements or developer gold-plating
Delayed Implementation
Increased Scope
High · Project Status Meetings will check for suspected “gold-plating” concerns or evidence.
Unstable tools delay schedule
Delayed Implementation
High · New tools are used on this project.
NOTE: No resolution known
Released software has low quality
Low Customer Satisfaction
Medium
· User interface prototype developed to assure users would accept software.
· Internal Technical reviews will be conducted in the EIT Network Applications group for requirements, designs, and code.
· Test planning assures system testing will cover all functionality.
· Independent testers perform system tests.
Unachievable schedule
Sponsor dissatisfaction
Customer dissatisfaction
Medium · Schedule is re-estimated several times over the course of the project.
· Active project tracking assures that schedule slips have better chance of being recognized.
· Staged delivery allows for delivery of partial functionality even if whole project takes longer than expected.
Friction between developers and customers
Project Failure
Low
· User interface prototype aligns developers and customers on same vision.
· Staged deliveries provide customers with evidence of steady progress.
Appendix A – Major Milestone and Schedule Summary
Example: The following high-level milestones will be tracked for this project. The detailed schedule and resources can be found in the Work Breakdown Structure referenced in Appendix C.
Table 8 Major Milestone LOE and Schedule Summary
Phase
Scheduled
Start Date
Actual Start Date Scheduled
End
Actual End
Complete Draft RS/HLA
01/21/03
01/21/03
02/04/03
Complete Draft Project Plan
01/ 24 /03
01/ 23 /03
02/07/03
Coding and Testing
02/18/03
02/18/03
05/24/02
Establish User Acceptance Test (UAT) Environment
Promote Code/Tables to Production
05/26/03
05/28/03
Execute UAT
05/28/03
06/21/03
Production Implementation
06/ 25 /03
06/26/03
Warranty
06/26/03
07/26/03
Project Close-out
07/28/03
07/ 30 /03
Example Only – Delete
ID
Task Name
Duration
Start Date
Finish Date
Pred.
Resource Names
HRMS Phase I WBS and Schedule
16 4 days ?
Fri 12/13/02 Thu 7/31/03
Analysis 57 days? Fri 12/13/02 Tue 3/4/03
Finalize Module Process Flows
27 days Fri 12/13/02
Tue 1/21/03
0 days Fri 12/13/02 Fri 12/13/02 Resource 1, Resource 2 0 days Fri 12/13/02 Fri 12/13/02 Resource 1, Resource 2 Review Process Flow with EIT 0 days Fri 12/13/02 Fri 12/13/02 Resource 1, Resource 2 Performance Review (Multi-Rater Feedback Sub-Process) 0 days Fri 12/13/02 Fri 12/13/02 Resource 1, Resource 2 Employee Update 0 days Fri 12/13/02 Fri 12/13/02 Resource 1, Resource 2 Process Flows Complete 0 days Tue 1/21/03 Tue 1/21/03
Initial GUI Design
11.
1 day s Tue 1/21/03
Wed 2/5/03 Design HR Admin Screens 10 days Tue 1/21/03 Mon 2/3/03 Send out HR Admin Screens and Business Center Data Cleanup Screens for Review 0.1 days Wed 2/5/03 Wed 2/5/03 Steve Design HR/Business Center Data Cleanup Screens for review 0.1 days Wed 2/5/03 Wed 2/5/03 Resource 1 Design Portal Screens 10 days Tue 1/21/03 Mon 2/3/03 Send Portal Screens out for review 0.1 days Wed 2/5/03 Wed 2/5/03 Resource 2 Portal Design Complete 0 days Wed 2/5/03 Wed 2/5/03 16
Initial Requirements Definition
18.
2 days Tue 1/21/03 Fri 2/14/03 Develop HRMS RS/HLA Document – First Cut 11 days Tue 1/21/03
Tue 2/4/03 Steve Send out RS/HLA (ver.0.6) document for review 0.1 days Tue 2/4/03 Tue 2/4/03 20 Steve 22 Meet with Identitech to clarify project scope and objectives 0.2 days Tue 2/4/03 Tue 2/4/03 Steve, Resource 1, Resource 2 Send out meeting minutes from Identitech meeting 0.2 days Tue 2/4/03 Tue 2/4/03 Steve Setup Kick-off Meeting 0.1 days Tue 2/4/03 Tue 2/4/03 Steve Conduct Kick-off Meeting 0.2 days Thu 2/13/03 Thu 2/13/03 24 Steve Update/Changes to RS/HLA document based on feedback from Kick-off Meeting Thu 2/13/03 Fri 2/14/03 25 Steve Baseline RS/HLA document established (the document is still a work in progress) 0 days Fri 2/14/03 Fri 2/14/03 26 Steve 29
HRMS Database
30 days ? Tue 1/21/03 Tue 3/4/03 Initial meeting to discuss HRMS Database requirements 0.2 days Thu 1/23/03 Thu 1/23/03 Resource 2, Resource 1 , Steve, Jim Create Initial Design of Database Model 3 days Thu 1/23/03 Tue 1/28/03 30 32 Review Database Model with Analysis Team 0.2 days Tue 1/28/03 Tue 1/28/03 31 Resource 1, Jim 33 Create HRMS Database 13 days Tue 1/28/03 Fri 2/14/03 32 Jim 34 Populate new database with a few test records 1 day? Fri 2/14/03 Tue 2/18/03 33 Jim 35 Import ABRA data into HRMS Database 0 days Tue 1/21/03 Tue 1/21/03 34 Jim 36 HRMS Test Database Ready Tue 1/21/03 Tue 3/4/03 35 Jim, Resource 2, Resource 1 37 38
Coding
94 days? Tue 1/21/03 Mon 6/2/03 39
HR Standalone Database Admin GUIs
50 days? Tue 1/21/03
Tue 4/1/03
HR Business Center Cleanup GUIs
4 8 days ? Tue 1/21/03 Fri 3/28/03 Build Screens 18 days Mon 3/3/03 Wed 3/26/03 MethodFactory 42 Test Screens Thu 3/27/03 Fri 3/28/03 41 43 Screens Ready to Deploy 0 days Fri 3/28/03 Fri 3/28/03 42 44 45 Test Screens 1 day? Tue 1/21/03 Tue 1/21/03 46
HR Administration GUIs
22 days Mon 3/3/03 Tue 4/1/03 47 Build Screens 18 days Mon 3/3/03 Wed 3/26/03 MethodFactory Test Screens Thu 3/27/03 Tue 4/1/03 47 Resource 2, Resource 1 49 Screens Ready to Deploy 0 days Tue 4/1/03 Tue 4/1/03 48
LDAP Functionality
28.2 days Tue 4/15/03 Fri 5/23/03 52 Receive LDAP Module From Identitech 0.2 days Tue 4/15/03 Tue 4/15/03 LDAP Testing with E-directory 10 days Tue 4/15/03 Tue 4/29/03 52 Team 54 Beta Testing with select users Tue 4/29/03 Fri 5/9/03 53 Beta Users 55 Testing with Large Test Group ( 100 plus users) 10 days Fri 5/9/03 Fri 5/23/03 54 Release Users 56 LDAP Module Ready 0 days Fri 5/23/03 Fri 5/23/03 55 58
NetFYI Modules
55.2 days? Tue 1/21/03 Wed 4/9/03
Merit Increase Process
32.2 days? Tue 1/21/03 Fri 3/7/03
Develop Detailed Requirements for Merit Increase Process
22.9 days? Tue 1/21/03 Fri 2/21/03 Clarify and nail down exact process steps and included functionality
0. 5 days Tue 2/18/03 Tue 2/18/03 34 Team 62 Identify Data Types used in process steps 1 day Tue 2/18/03 Wed 2/19/03 61 Team 63 Identify data elements to be read from/written to the HRMS Database 1 day Wed 2/19/03 Thu 2/20/03 62 Team 64 Document operations on specific fields 1 day Wed 2/19/03 Fri 2/21/03 63 Team Define IFAS data requirements 0.5 days Fri 2/21/03 Fri 2/21/03 64 Resource 1, Resource 2 Define flat file format for IFAS 1 day? Tue 1/21/03 Tue 1/21/03 Data Management Coding 2. 75 days Fri 2/21/03 Wed 2/26/03 68 Build Search Classes 0.5 days Fri 2/21/03 Mon 2/24/03 65 Team 69 Build database indexes 0.5 days Mon 2/24/03 Mon 2/24/03 68 Team 70 Build Work Flow 0.5 days Tue 2/25/03 Tue 2/25/03 69 Team 71 Build other required sub processes and modules? 0.5 days Mon 2/24/03 Wed 2/26/03 70 Team 72 Build Prototype of Merit Increase Process 0.5 days Wed 2/26/03 Wed 2/26/03 71 Team 73 Test 32.2 days? Tue 1/21/03 Fri 3/7/03 74 Test Prototype Process Flow utilizing test users in Roles database 0.5 days Wed 2/26/03 Thu 2/27/03 72 Team Unit test of Merit Increase Process utilizing live Data in HRMS Database 0.5 days Thu 2/27/03 Thu 2/27/03 74 Team Test Prototype in Development Environment 0.5 days Thu 2/27/03 Fri 2/28/03 75 Team 77 Review Prototype and Functionality with Red Team 0.2 days Mon 3/3/03 Mon 3/3/03 76 78 Rework Prototype into final Process/Workflow 4 days Mon 3/3/03 Fri 3/7/03 77 79 Workflow ready for Testing 0 days Fri 3/7/03 Fri 3/7/03 78 80 81
Performance Management Process
23 days Fri 3/7/03 Wed 4/9/03 82
Develop Detailed Requirements for Performance Management Process
12 days Fri 3/7/03 Tue 3/25/03 83 Clarify and nail down exact process steps and included functionality 2 days Fri 3/7/03 Tue 3/11/03 79 Team 84 Identify Data Types used in process steps 2 days Tue 3/11/03 Thu 3/13/03 83 Team 85 Document operations on specific fields 2 days Thu 3/13/03 Mon 3/17/03 84 Team Identify data elements to be read from/written to the HRMS Database 2 days Mon 3/17/03 Wed 3/19/03 85 Team 87 Define IFAS data requirements 2 days Wed 3/19/03 Fri 3/21/03 86 Team 88 Define/Update flat file format for IFAS 2 days Fri 3/21/03 Tue 3/25/03 87 Team 89
Code
6 days Tue 3/25/03 Wed 4/2/03 90 Build Search Classes 1 day Tue 3/25/03 Wed 3/26/03 88 Team Build database indexes 1 day Wed 3/26/03 Thu 3/27/03 90 Team 92 Build other required sub processes and modules? 1 day Thu 3/27/03 Fri 3/28/03 91 Team 93 Cleanup Efforts and final 1 day Fri 3/28/03 Mon 3/31/03 92 Team Build Work Flow 1 day Mon 3/31/03 Tue 4/1/03 93 Team 95 Build Prototype of Performance Management Process 1 day Tue 4/1/03 Wed 4/2/03 94 Team Test Wed 4/2/03 Wed 4/9/03 97 Test Prototype Process Flow utilizing test users in Roles database 1 day Wed 4/2/03 Thu 4/3/03 95 Team 98 Unit test of Merit Increase Process utilizing live Data in HRMS Database 1 day Thu 4/3/03 Fri 4/4/03 97 Team 99 Test Prototype in Development Environment 1 day Fri 4/4/03 Mon 4/7/03 98 Team Review Prototype and Functionality with Management 1 day Mon 4/7/03
Tue 4/8/03 99 Team 101 Rework Prototype into final Process/Workflow 1 day Tue 4/8/03 Wed 4/9/03 100 Team 102 Workflow ready for System Testing 0 days Wed 4/9/03 Wed 4/9/03 101 Team 103 104
Employee Information Update Process
45 days Tue 4/1/03 Mon 6/2/03 105
Develop Detailed Requirements for Employee Information Update Process
6 days Tue 4/1/03 Tue 4/8/03 106 Clarify and nail down included functionality 1 day Tue 4/1/03 Tue 4/1/03
Web1 107 1 day Wed 4/2/03 Wed 4/2/03 106 Web1 108 Document operations on specific fields 1 day Thu 4/3/03 Thu 4/3/03 107 Web1 109 Identify data elements to be read from/written to the HRMS Database 1 day Fri 4/4/03 Fri 4/4/03 108 Web1 110 Define IFAS data requirements 1 day Mon 4/7/03 Mon 4/7/03 109 Web1 111 Define/Update flat file format for IFAS 1 day Tue 4/8/03 Tue 4/8/03 110 Web1 112 Code 34 days Wed 4/9/03 Mon 5/26/03 113 Build Search Classes 2 days Wed 4/9/03 Thu 4/10/03 111 Web1 114 Build database indexes 2 days Fri 4/11/03 Mon 4/14/03 113 Web1 115 Build other required sub processes and modules? 2 days Tue 4/15/03 Wed 4/16/03 114 Web1 116 Cleanup Efforts and final 2 days Thu 4/17/03 Fri 4/18/03 115 Web1 117
Employee Portal
26 days Mon 4/21/03 Mon 5/26/03 118 Develop Prototype Screen(s) 3 days Mon 4/21/03 Wed 4/23/03 116 Web1 119 Route to HR Subject Matter Experts for Feedback/Approval 1 day Thu 4/24/03 Thu 4/24/03 118 Web1 Build Screens 10 days Fri 4/25/03 Thu 5/8/03 119 Web1 121 Integrate into Identitech Processes and HRMS Structure 12 days Fri 5/9/03 Mon 5/26/03 120 Web1 122 Test 5 days Tue 5/27/03 Mon 6/2/03 123 Test of GUI and Employee Read/Update Processes 5 days Tue 5/27/03 Mon 6/2/03 121 Web1 124 Process ready for Testing 0 days Mon 6/2/03 Mon 6/2/03 123 125 126
Portal Development
30.5 days Tue 4/1/03
Tue 5/13/03 127
Manager Portal
30.5 days Tue 4/1/03 Tue 5/13/03 128 Develop Prototype Screen(s) 5 days Tue 4/1/03 Mon 4/7/03 Web2 129 Route to HR Subject Matter Experts for Feedback/Approval 0.5 days Tue 4/8/03 Tue 4/8/03 128 Web2 130 Build Screens 10 days Tue 4/8/03 Tue 4/22/03 129 Web2 131 15 days Tue 4/22/03 Tue 5/13/03 130 Web2 132 Ready for Testing 0 days Tue 5/13/03 Tue 5/13/03 131 133 134
HR Administration Portal
30.5 days Tue 4/1/03 Tue 5/13/03 135 Develop Prototype Screen(s) 5 days Tue 4/1/03 Mon 4/7/03 Web3 136 Route to HR Subject Matter Experts for Feedback/Approval 0.5 days Tue 4/8/03 Tue 4/8/03 135 Web3 137 Build Screens 10 days Tue 4/8/03 Tue 4/22/03 136 Web3 138 Integrate into Identitech Processes 15 days Tue 4/22/03 Tue 5/13/03 137 Web3 139 Ready for Testing 0 days Tue 5/13/03 Tue 5/13/03 138 140 141
User Acceptance Testing (UAT)/System Test
22 days Mon 5/26/03 Tue 6/24/03 142 Obtain/Create System test data 2 days Mon 5/26/03 Tue 5/27/03 Team 143 Performance Review 5 days Wed 5/28/03 Tue 6/3/03 142 144 Performance Review (Multi-Rater Feedback Sub-Process) 4 days Wed 6/4/03 Mon 6/9/03 143 Users 145 Merit Increase 2 days Tue 6/10/03 Wed 6/11/03 144 Users 146 Employee Information Update Process 3 days Thu 6/12/03 Mon 6/16/03 145 Users 147 HR Administrators Portal 15 days Mon 5/26/03 Fri 6/13/03 Resource 2, Resource 1 148 Manager’s Portal 4 days Tue 6/17/03 Fri 6/20/03 146 Users 149 Employee’s Portal 2 days Mon 6/23/03 Tue 6/24/03 148 Users 150 User Acceptance Testing Complete 0 days Tue 6/24/03 Tue 6/24/03 149 151 152 Implementation 2 days Wed 6/25/03 Thu 6/26/03 153 Load Code in Production Environment 2 days Wed 6/25/03 Thu 6/26/03 150 Team 154 Load Production Data into Production Database 2 days Wed 6/25/03 Thu 6/26/03 150 Team 155 System Live in Production 0 days Thu 6/26/03 Thu 6/26/03 154,153 Team 156 157
Project Closeout Activities
2 days Fri 6/27/03 Mon 6/30/03 158 Archive all Project Documentation 2 days Fri 6/27/03 Mon 6/30/03 155 Team, PM 159 Place all code in Source Safe 1 day Fri 6/27/03 Fri 6/27/03 155 Team 160 Conduct Lesson’s Learned and Project Close-out Meeting with Stakeholders 0.5 days Mon 6/30/03 Mon 6/30/03 159 161 Close-Out Activities Complete 0 days Mon 6/30/03 Mon 6/30/03 160 162 163 Warranty 24 days? Mon 6/30/03 Thu 7/31/03 164 Warranty Period for Phase I 23 days Mon 6/30/03 Wed 7/30/03 Team 165 Warranty Period Complete 1 day? Thu 7/31/03 Thu 7/31/03 164 166 167 Project Complete – Warranty and Project Closeout Activities Complete 0 days Thu 7/31/03 Thu 7/31/03 165
Project Issues Log –
Issue #
Issue Type, Description and
Impact to Project
Priority
(M/H/L)
Date Reported
Reported By
Assigned To
Resolved
Status
Resolution/Comments
Issue Type: Resource
Description (revised) Need resource commitments to fully staff the “Red”, “Blue”, and “Quality” teams
Impact: If the resources that have been identified aren’t assigned to this project, quality will suffer.
02/25/03 Jack Bill Open
02/25 – Will forward the list of requested resources to EIT management by COB on 02/28.
03/03 – Have resource commitments for Red Team, part of Blue Team, and we are working on the rest of the list. Resources that are needed that can’t be obtained will be escalated to EIT management.
Description: No resource commitments from development for GUI development.
Impact: The project requires an Internet Presence resource now to review GUI requirements and estimate resources and Level of Effort (LOE).
02/26/02 Jack PMO Manager Open
02/25 – Will forward this issue to the PMO Manager for action
� EMBED Word.Picture.8 ���
� EMBED Visio.Drawing.6 ���
PMO 19
Risk Management Plan
· Introduction 3.3 Risk management
Miscommunication
Probability: High
Impact: High
Misinterpretations of what other team members say and write might stand in the way of a common understanding of what to do and how to do it. This might lead to delays, unwanted results and double work. Prevention: Throughout the project, and especially during weekly meetings, the PM has to make sure every team member understands the task given to him, by having frequent talks with each group member about their task. It is important that the minutes of the meeting are correct and complete, and they should be read by everyone with care. Correction: When a problem occurs, the PM arranges a meeting with all involved people to come to a common understanding of the situation. After this meeting, its results are briefed to all team members.
Too many planned features lead to infeasible design
Probability: Medium
Impact: Medium
Prevention: The technical advisor should be consulted on whether the delivery of the planned product can be done within the time budget. Every item should have a priority. Correction: By closely monitoring progress the decision to drop certain requirements can be made in time. Note: Due to the incremental coding approach, this is less of a problem than it otherwise might have been.
Illness or absence of team members or the PM
Probability: Medium Impact: High Prevention: Team members should warn their team leader or the PM timely before a planned period of absence. The PM should make planned absence a point on the first meeting to make sure that absence that is known at that time is taken into account in the schedule. Correction: Every role has a person to replace him. Communication between these two people is very important. The “vice” person should be actively involved in all work in order to be able to replace his counterpart. All important information and design decision should be documented in documents or minutes, to make sure that as little information as possible is lost.
Loss of critical information, documents or code
Probability: Medium Impact: High Prevention: The SCMP should be written and used with care. The base assumption should be that there is a backup of every single piece of information at any single time. Correction: Use the latest backups to recover the most recent version. If the missing parts are necessary, replace these as soon as possible.
The customer changes his mind about the requirements, or there is disagreement about the requirements interpretation. Probability: High Impact: Medium Prevention: It should be made very clear to the customer that after a certain date the requirements can’t change anymore Correction: If the customer changes his mind during the UR phase his new requirements can be incorporated in the URD . Procedures in SQAP detail if the URD may be changed after approval, and (if so) how to implement changes.
The customer is not available when needed
Probability: Medium Impact: Medium Prevention: Meetings with the customer should be planned well in advance. The customer has been given room in his schedule for his Software Engineering related work. Holidays and other travel plans of all people involved should be put in this document in section 5.5.3. Correction: When the customer is not available, meetings may have to be rescheduled.
Imbalance in work load
Probability: Low
Impact: Medium Prevention: Keep track of the work done by individuals by using logs. Correction: Redistribute the work when large differences appear.
Time shortage
Probability: High Impact: Medium Prevention: Care is taken to plan enough spare time. For every external review two dates are planned in case the first review fails to lead to acceptance. Planning is based on experience from previous projects. Correction: When tasks fail to be finished in time or when they are finished earlier than planned the project planning is adjusted. If time shortage occurs, several user requirements, which have lower priority, can be dropped after consultation with the client. Only those of highest priority are mandatory. Implementation of the lowest priority requirements is not expected to be reached.
Design Errors
Probability: Medium Impact: High Prevention: The design should be reviewed very critically. An advisor should be consulted frequently on his opinion about the feasibility and the correctness of certain design decisions. The external reviews of the systems design will also ensure that the team will not commence with an erroneous design. Correction: When errors in the design are noticed an advisor should be consulted to help correct the design errors as soon as possible. Also all work, which depends on the faulty design, should be halted until the error is corrected.
Personal conflicts between team members
Probability: Low Impact: Medium Prevention: By stimulating the communication between team members, conflicts may be avoided. Also team-building activities should be held. Correction: Team members who are known to have had conflicts between them will not be assigned to the same team. Furthermore, the PM will discuss the situation with the team members in an effort to clear the air.
Lack of expertise to fulfill certain tasks
Probability: High
Impact: Low
Prevention: By focusing on solutions for which the necessary expertise is available and sharing expertise available within the team this risk may be reduced. Correction: In SQAP, methods for acquiring skills are detailed. 3.4 Monitoring and controlling mechanisms The monitoring of progress is done by the PM using the following means: Weekly Project Group Meetings The project group meetings take place in the project room, HG10.56. Project group meetings usually take place on Tuesday at 12.45, although this time may be subject to change. Emails will be send about the time if it changes. These meetings are meant to inform each other of the progress made on various tasks. New tasks are assigned by the PM on these meetings. Before the meeting, all members read minutes of previous meeting. The PM takes care of the agenda and presides the meeting. Note that much of the content of these meetings can also be discussed informally. These meetings are primarily used to bring everybody up to speed with the current status. Weekly increment delivery Week 10 of the project the first increment is started. From this moment till end of coding every Monday at 13:00 a group member together with PM and QM visits the SM to show the progress of the past week. On the weeks that also the progress meeting is it is after this meeting with the same group member. A couple of items have to be delivered at this meeting: · List of functionality realized this week that can be checked as well as the lists of previous weeks. This list includes referenced to the implemented requirement. · A printed version of the URD · Url of the increment to review and of the 2 previous increments. At this meeting the SM checks the new items and a few random checks of existing functionality to confirm nothing has been broken. Progress Meetings These meetings are scheduled biweekly at Monday 13:00 in room 5.36. On these meetings the PM, a team member and if available QM meet with the SM. Before progress meetings the following things need to be done: · Write a progress report after the example of the previous reports. · Read the minutes of the previous meeting. · Deliver the report to the SM half an hour before the start of the first meeting on that day. Project metrics Every week, the work done by the members, needs to be administrated. Each team member has to _ll in their hours on a web-based log. This log needs to be filled in as soon as possible but at the latest Sunday 18:00 and then also be filled with non- project related to complete 40 hours. A week starts at Monday and ends at Sunday. Every entry in a log has to belong to one of the following work-packages: SPMP, Software Verification and Validation Plan, Acceptance Test Plan, Software Configuration Management Plan, Software Quality Assurance Plan, User Requirements Document, SRD, Prototype, Research, Architectural Design phase, Detailed Design Document, Code, IT,ST, Acceptance Test, Software Transfer Document (STD), Formal reviews, Meetings or Presentations. The PM sends an email to the Senior Management (SM) every week, containing the hours spend on the different work packages and the hours spend on following categories: Non project related, General project related, Documentation, specification, design, Source code, Testing, verification, consolidation and rework. Further, for every work package, an estimation of remaining hours is added.
I will do it as the bellow Table.
1.0 Error! Unknown document property name.
Version Number: 1.0 Version Date:
[This document is a template of a Risk Management Plan document for a project. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the project.
· Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.
· Blue italicized text enclosed in angle brackets ( · Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.
1. Replace all text enclosed in angle brackets (e.g.,
After clicking OK to close the dialog box, update all fields throughout the document selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking on it and pressing F9.
These actions must be done separately for any fields contained with the document’s Header and Footer.
2. Modify boilerplate text as appropriate for the specific project.
3. To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.
4. To update the Table of Contents, right-click on it and select “Update field” and choose the option – “Update entire table”.
5. Before submission of the first draft of this document, delete this instruction section “Notes to the Author” and all instructions to the author throughout the entire document.
[Provide information on how the development and distribution of the Risk Management Plan will be controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.]
Version
Implemented
By
Revision
Date
Approved
By
Approval
Date
Description of
4
1.0 4
1.1
4
4
2.1 4
2.2 5
2.3 5
2.3.1 6
2.4 6
2.4.1 6
2.4.2 6
2.5 7
2.6 8
8
8
9
10
Appendix A: Risk Management Plan Approval
11 APPENDIX B: REFERENCES
12 APPENDIX C: KEY TERMS
A risk is an event or condition that, if it occurs, could have a positive or negative effect on a project’s objectives. Risk Management is the process of identifying, assessing, responding to, monitoring and controlling, and reporting risks. This Risk Management Plan defines how risks associated with the Risks related to IT systems or applications must be identified and documented based on the methodology in NIST SP 800-30, Risk Management Guide for Information Technology Systems. IT system or application weaknesses must be identified on an associated plan of action and milestones (POA&M) and tracked in accordance with HHS POA&M guidelines. Appropriate protective measures must be taken to safeguard sensitive IT system or application weaknesses or vulnerabilities from unauthorized disclosure.
[Summarize the steps necessary for responding to project risk.]
The project manager working with the project team and project sponsors will ensure that risks are actively identified, analyzed, and managed throughout the life of the project. Risks will be identified as early as possible in the project so as to minimize their impact. The steps for accomplishing this are outlined in the following sections. The A distinction may need to be made between overall project risk management and IT system or application risk management. Risks related to IT systems or applications must be identified and documented based on the methodology in NIST SP 800-30, Risk Management Guide for Information Technology Systems.
Role
Responsibilities
Business SME (BSME) The BSME assists in identifying and determining the context, consequence, impact, timing, and priority of the risk. Risk Manager or Project Manager (PM) The Risk Manager or PM is a member of the Integrated Project Team (IPT). The Risk Manager or PM determines if the Risk is unique, identifies risk interdependencies across projects, verifies if risk is internal or external to project, assigns risk classification and tracking number. During the life of the project, they continually monitor the projects for potential risks. The IPT is responsible for identifying the risks, the dependencies of the risk within the project, the context and consequence of the risk. They are also responsible for determining the impact, timing, and priority of the risk as well as formulating the risk statements. Risk Owner(s) The risk owner determines which risks require mitigation and contingency plans, he/she generates the risk mitigation and contingency strategies and performs a cost benefit analysis of the proposed strategies. The risk owner is responsible for monitoring and controlling and updating the status of the risk throughout the project lifecycle. The risk owner can be a member of the project team. Other Key Stakeholders The other stakeholders assist in identifying and determining the context, consequence, impact, timing, and priority of the risk. Risk identification will involve the project team, appropriate stakeholders, and will include an evaluation of environmental factors, organizational culture and the project management plan including the project scope, schedule, cost, or quality. Careful attention will be given to the project deliverables, assumptions, constraints, WBS, cost/effort estimates, resource plan, and other key project documents. The following methods will be used to assist in the identification of risks associated with · Brainstorming
· Interviewing
· SWOT (Strengths, Weaknesses, Opportunities and Threats)
· Diagramming
· Etc.
A Risk Management Log will be generated and updated as needed and will be stored electronically in the project library located at All risks identified will be assessed to identify the range of possible project outcomes. Risks will be prioritized by their level of importance. The probability and impact of occurrence for each identified risk will be assessed by the project manager, with input from the project team using the following approach:
Probability · High – Greater than <70%> probability of occurrence
· Medium – Between <30%> and <70%> probability of occurrence
· Low – Below <30%> probability of occurrence
Impact
Impact
H
M
L
L M H
Probability
· High – Risk that has the potential to greatly impact project cost, project schedule or performance
· Medium – Risk that has the potential to slightly impact project cost, project schedule or performance
· Low – Risk that has relatively little impact on cost, schedule or performance
Risks that fall within the RED and YELLOW zones will have risk response plan which may include both a risk response strategy and a risk contingency plan.
Analysis of risk events that have been prioritized using the qualitative risk analysis process and their affect on project activities will be estimated, a numerical rating is applied to each risk based on quantitative analysis, and then documented in this section of the risk management plan. Each major risk (those falling in the Red & Yellow zones) will be assigned to a risk owner for monitoring and controlling purposes to ensure that the risk will not “fall through the cracks”. For each major risk, one of the following approaches will be selected to address it:
· Avoid – Eliminate the threat or condition or to protect the project objectives from its impact by eliminating the cause
· Mitigate – Identify ways to reduce the probability or the impact of the risk · Accept – Nothing will be done · Contingency –Define actions to be taken in response to risks · Transfer – Shift the consequence of a risk to a third party together with ownership of the response by making another party responsible for the risk (buy insurance, outsourcing, etc.) For each risk that will be mitigated, the project team will identify ways to prevent the risk from occurring or reduce its impact or probability of occurring. This may include prototyping, adding tasks to the project schedule, adding resources, etc. Any secondary risks that result from risk mitigation response will be documented and follow the risk management protocol as the primary risks. For each major risk that is to be mitigated or that is accepted, a course of action will be outlined in the event that the risk does materialize in order to minimize its impact. The level of risk on a project will be tracked, monitored and controlled and reported throughout the project lifecycle. [Describe the methods and metrics that will be used to track the project’s risk status throughout the lifecycle as well as how this status will be reported to the stakeholders/ management.] Risks will be assigned a risk owner(s) who will track, monitor and control and report on the status and effectiveness of each risk response action to the Project Manager and Risk Management Team on a A “Top 10 Risk List” will be maintained by the PM/Risk Manager or IPT and will be reported as a component of the project status reporting process for this project. All project change requests will be analyzed for their possible impact to the project risks. As Risk Events occur, the list will be re-prioritized during weekly reviews and risk management plan will reflect any and all changes to the risk lists including secondary and residual risks.
Management will be notified of important changes to risk status as a component to the Executive Project Status Report. [State timeframe, i.e., every two weeks]
The Risk Manager (PM) will:
· Review, reevaluate, and modify the probability and impact for each risk item [timeframe, as needed, every two weeks, etc.]
· Analyze any new risks that are identified and add these items to the risk list (or risk database).
· Monitor and control risks that have been identified
· Review and update the top ten risk list [timeframe, as needed, every two weeks, etc.]
· Escalate issues/ problems to management [List factors that would need to be escalated to management. Examples: documented mitigation actions are not effective or producing the desired results; the overall level of risk is rising.]
The Risk Owner will: · Help develop the risk response and risk trigger and carry out the execution of the risk response, if a risk event occurs.
· Participate in the review, re-evaluation, and modification of the probability and impact for each risk item on a weekly basis.
· Identify and participate in the analysis of any new risks that occur.
· Escalate issues/problems to PM that,
· Significantly impact the projects triple constraint or trigger another risk event to occur.
· Require action prior to the next weekly review
· Risk strategy is not effective or productive causing the need to execute the contingency plan.
Risk activities will be recorded in the A risk contingency budget can be established to prepare in advance for the possibility that some risks will not be managed successfully. The risk contingency budget will contain funds that can be tapped so that your project doesn’t go over budget.
There is a total of <$X> in the
[Above is only an example of text that could be used. Enter whatever information is appropriate to outline/ define the budget associated with the Risk Management activities on the project.]
A Risk Management Log will be maintained by the project manager and will be reviewed as a standing agenda item for project team meetings. Risk activities will be recorded in the A risk will be considered closed when it meets the following criteria:
· · Examples:
· Risk is no longer valid · Risk Event has occurred · Risk is no longer considered a risk · Risk closure at the direction of the Project Manager
The lessons learned will be captured and recorded in the
The undersigned acknowledge that they have reviewed the
[List the individuals whose signatures are desired. Examples of such individuals are Business Owner, Project Manager (if identified), and any appropriate stakeholders. Add additional lines for signature as necessary.]
Signature: Print Name: Title: Role: Signature: Date: Print Name: Title: Role: Signature: Date: Print Name: Title: Role:
[Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.]
The following table summarizes the documents referenced in this document.
Document Name
Description
Location
The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.
Term
Definition
[Insert Term]
[Insert appropriate disclaimer(s)]
PAGE
2.5 Course Corrections
2.5.1 Testing
2.5.2 User Acceptance Testing
2.6 Training
2.7 Project Management Objectives and Priorities
2.8 Procedures, Methods and Standards
Name
Resource 2 Gustafson
2.9 Quality Assurance Plan
3 System Overview
3.1 Figure 1 – System Connectivity
3.1.1 PLANNING
3.1.2 DATABASE CLEANUP ACTIVITIES
Staff:
Tom – Entry of Corrections; Entry of change transactions.
Time:
3.2 Critical Computer Resource Assumptions
4 Project Schedule and Level of Effort Estimates
1
2
3
4
Delayed Implementation
5
6
Customer dissatisfaction
5 External Dependencies
5.1.1 This project is dependent upon …
1
Appendix B – Initial Work Breakdown Structure
1
2
3
4
Merit Increase
5
Performance Review
6
7
8
9
10
11
12
Resource 1
13
14
15
Resource 2
16
17
18
19
20
21
23
24
25
26
1 day
27
28
30
31
Jim
30 days
40
41
2 days
Resource 2, Resource 1
48
4 days
50
51
Team
53
8 days
57
59
60
61
65
66
67
75
76
86
91
94
96
5 days
100
Identify Data Types
120
Integrate into Identitech Processes
Users
PM
APPENDIX C – PROJECT ISSUES LOG
Examples – Delete
Date
1
M
2
Issue Type: Resource
H
Ver. 1.0.0_1104757865
_1106389030.vsd
· Risk Management Procedure
· Process
· Role and Responsiblities
· Risk Identification
· Method for Risk Identification
· Risk Analysis
· Qualitative Analysis
· Quantitative Analysis
· Risk Response Planning
· Risk Monitoring, Controlling, and ReportingRisk Management Plan
Version:
Risk Management Plan
Notes to the Author
When using this template, the following steps are recommended:
VERSION HISTORY
Number
Change
1.0
TABLE OF CONTENTS
INTRODUCTION
Purpose Of The Risk Management Plan
2.0
risk management Procedure
Process
ROLES AND RESPONSIBILITIES
Risk Identification
Methods for Risk Identification
Risk Analysis
Qualitative Risk Analysis
Quantitative Risk Analysis
Risk Response Planning
Risk Monitoring, Controlling, And Reporting
2.7
Risk Contingency Budgeting
3.0
Tools And Practices
4.0
Closing a Risk
5.0
Lessons Learned
1.0 INTRODUCTION
1.1 Purpose Of The Risk Management Plan
2.0 risk management Procedure
2.1 Process
2.2 ROLES AND RESPONSIBILITIES
Integrated Project Team
2.3 Risk Identification
2.3.1 Methods for Risk Identification
2.4 Risk Analysis
2.4.1 Qualitative Risk Analysis
2.4.2 Quantitative Risk Analysis
2.5 Risk Response Planning
2.6 Risk Monitoring, Controlling, And Reporting
2.7 Risk Contingency Budgeting
3.0 Tools And Practices
4.0 Closing a Risk
5.0 Lessons Learned
Appendix A: Risk Management Plan Approval
Date:
APPENDIX B: REFERENCES
APPENDIX C: KEY TERMS
Revision Date:
Error! Unknown document property name.
Page 2 of 8
EPLC_Risk_Management_Plan_TemplateT
