pre-design, development and implementation (ddi) project management plan · pdf...

Department of Financial Services

Date: 02-19-2016

Revision: Final 2.1

Pre-Design, Development and Implementation (DDI) Project Management Plan

(PMP)

Department of Financial Services Pre-DDI Project Management Plan

of 66 02/19/2016

Revision History

Version Date Author Revision Notes

Draft 12/02/2014 Terry Owen Original draft

Draft 03/5/2015 Danielle Kosberg, Brendan Jones

Updates to original draft

Draft 04/9/2015 Melissa Turner, Danielle Kosberg, Brendan Jones

Updates to revise draft in preparation for PMO Support Contractor

Draft 05/18/2015 Phil Harman Updated the draft PMP created by Brendan and Danielle

Draft 06/23/2015 Phil Harman Updates made as a result of several review and feedback sessions with Danielle, Melissa, and Brendan.

1 06/26/2015 Melissa Turner, Danielle Kosberg

Updates made as a result of review

1 07/06/2015 Paul Whitfield, Charles Ghini, Christina Smith, Bert Wilkerson, Melissa Turner, Danielle Kosberg

Updates made as a result of sponsor review

Draft 2.0

10/19/2015 Phil Harman and Melissa Turner

Identify edits for Governance Charter and subset of items identified on Florida PALM “consideration log”

Draft 2.0

11/04/2015 Melissa Turner Updates made as a result of internal Project team review

Draft 2.0

11/10/2015 Sean Cooley and Melissa Turner

Updates made for Style Guide

2.0 11/20/2015 Paul Whitfield, Charles Ghini, Christina Smith, Bert Wilkerson, Melissa Turner, Danielle Kosberg

Updates made as a result of schedule management changes and sponsor review

2.1 02/19/2016 Melissa Turner Updates based on discussions with House


of 66 02/19/2016

Table of Contents

Document Overview ................................................................................................................... 4

Document Scope ....................................................................................................................... 4

Out of Scope .............................................................................................................................. 5

Assumptions .............................................................................................................................. 5

Project Life Cycle ....................................................................................................................... 5

Project Management Processes ................................................................................................ 8

Project Management Sub-processes ........................................................................................10

Risk, Issue, Deliverable and Action Item Responsibilities ..........................................................10

Appendices ...............................................................................................................................12

Appendix 1 - Performance Management ...................................................................................12

Appendix 2 - Cost Management ................................................................................................15

Appendix 3 - Schedule Management ........................................................................................16

Appendix 4 - Quality Management ............................................................................................22

Appendix 5 - Procurement Management ...................................................................................27

Appendix 6 - Staffing Management ...........................................................................................28

Appendix 7 - Collaboration Management ..................................................................................31

Appendix 8 - Project Scope and Change Management .............................................................32

Appendix 9 - Risk Management ................................................................................................35

Appendix 10 - Communications Management ...........................................................................41

Appendix 11 - Issue Management .............................................................................................50

Appendix 12 - Decision Management ........................................................................................52

Appendix 13 - Deliverable Management ...................................................................................54

Appendix 14 - Action Item Management....................................................................................57

Appendix 15 - Content Management .........................................................................................59

Appendix 16 - Lessons Learned Management ..........................................................................62

References ...............................................................................................................................65

Project Approvals ......................................................................................................................66


of 66 02/19/2016

Document Overview The Florida PALM Project will ensure it meets its cost, schedule, scope and quality objectives by employing a set of defined and repeatable project management processes. This document details the processes to be used during the Pre-DDI phase for all work identified in the Project Charter and supporting Strategy, Plans, Contracts, and Scope documents. Compliance with these repeatable processes will help expedite the successful, on-time completion of the work.

Document Scope This document communicates the complete lifecycle of project management as it relates to delivery of the Florida PALM Pre-DDI phase. This document communicates the purpose, scope and process for the following project management processes:

1. Performance 2. Cost 3. Schedule 4. Quality 5. Procurements 6. Staffing 7. Collaboration 8. Project Scope and Changes 9. Risks 10. Communications 11. Issues 12. Decisions 13. Deliverables 14. Action Items 15. Content 16. Lessons Learned

Who Should Use This Document? The Project staff members should use this document for guidance on Project procedures associated with the above identified Project processes across all work completed in various “Tracks.”

Interdependence and Related Documents This document shall be used in conjunction with the following Project documents to govern and manage the Florida PALM Project.

The Project Charter

The Project Governance Charter

Procurement documents and contracts associated with the support of this Project as they are developed and executed, namely:

o Business Process Standardization Support Services Contract o Project Management Office Support Services Contracts o Software and System Integrator (SSI) Procurement Support Services Contract o Outside Counsel Support Services Contracts o Independent Verification and Validation (IV&V) Services Contract


of 66 02/19/2016

o Organizational Change Management Support Services Contract o System and Data Strategy Support Services Contracts

Distribution of Document This document shall be distributed to Project staff members, the Project Steering Committee, and any other personnel as required or otherwise authorized by the Project Director. This document will also be submitted along with a budget amendment in accordance with 2015-2016 GAA Proviso Line 2331A. Notifications of changes to this document will be circulated by the PMO Manager.

Out of Scope This document does not include specific Project delivery methodologies associated with a specific discipline or business area. This document will not include a comprehensive listing of project management tool(s) used for each process area.

Assumptions In order to fully understand this document, the reader has a general working knowledge of the project management processes and has read/understands the Project Management Body of Knowledge (PMBOK). In addition, updates to the PMP (after initial approval) will follow the processes defined in Appendix 8 - Project Scope and Change Management.

Project Life Cycle Traditionally, project management includes a number of elements, four to five stage, and a control system. Regardless of the methodology or terminology used, the same basic project management processes will be used. Major project management stages generally include and will be applied for the Pre-DDI phase of the Florida PALM Project:

1. Initiating 2. Planning 3. Execution 4. Monitoring and Controlling 5. Closing

The Project initiating stage determine the nature and scope of the Project as well as initiating the Florida PALM Project. This phase/event is complete for Florida PALM Project. The Project will have multiple “tracks” staffed to simultaneously support the Project across the four critical dimensions: people, process, technology, and project management. The Tracks for Pre-DDI are listed below:

1. BPS – Business Process Standardization – responsible for business process standardization activities and creating functional requirements for the ERP.

2. OCM – Organizational Change Management – responsible for developing and executing change management strategies (the people-side of change) for the new ERP.

3. SDS – Systems and Data Strategy - responsible for developing and executing technical strategies for the new ERP.


of 66 02/19/2016

4. PMO – Project Management Office responsible for developing and executing project management strategies for all Project phases. PMO will also be responsible for the procurement activities for the new ERP and System Integrator.

For work associated with Project tracks, outsourced work or other initiatives within Florida PALM, Project initiation will be accomplished by creating one or all of the following.

1. Vision and Scope Document for the Project 2. Strategy Document for each Track

The above documents are described in detail in Appendix 14 – Content Management. After the initiation stage, the Project will be planned to the appropriate level of detail. The main outcome is to create content that describes the schedule, time commitments, cost and resources adequate to estimate the work and to effectively manage risks during Project execution. The Project planning documents are described in Appendix 14 – Content Management. The majority of the content in this document is focused on what our approach is to fulfill the Project executing, monitoring, and controlling stages so we can successfully execute/deliver the Pre-DDI outcomes defined in the approved scope documents. The exhibit below illustrates the PMP content elements and their relationships to each other.

Figure 1: Project Execute, Monitor, and Control Processes

There are five icons depicted in the diagram above exhibit. Those five icons are: Table 1: Icon Definitions

Symbol Definition

Realized Benefits will be achieved after the Project is completed or after specific phases/implementations have been accomplished.

Implement consisting of Technology, Business Process Standardization, and Training.


of 66 02/19/2016

Symbol Definition

Organization Change Management, which is critical for the Project success as it relates to the adoption of the technology and new processes.

Project management execute, monitor and control stages: Cost, Time/Schedule, Quality, Scope, Staff, Procurement, Risks, Communication, and Integration.

Supporting project management sub-processes vital to be controlled and effective in support of the traditional project management processes. These are: Issue, Deliverable Approvals, Decisions, Action Items, and Project Change Requests (PCRs).

This document will not describe the Project approach to Implement, Realized Benefits or Organizational Change Management (Org Chg Mgmt). The Realized Benefits, Implement for technology (Tech) and Implement for training will be defined during the Project DDI phase. The Implement for Business Process Standards (BusProcStd) Strategy has been defined and approved in the Pre-DDI BPS track. The Organizational Change Management (Org Chg Mgmt) will be defined as a part of the Organization Change Management Strategy created by the Pre-DDI OCM track and modified during the DDI phase. After the execution stage, the Project will be closed for the Pre-DDI phase. A strong Project close process enables future benefits to be received by the organization. Significant knowledge capital is developed over the course of a Project and it needs to be captured in a manner that allows it to be leveraged in the future. The key components of Project Closeout are illustrated in the exhibit below:

Figure 2: Project Closeout Components

Archive Project Artifacts Significant documentation will be developed over the course of the Project. Project artifacts, which are defined as Project Management documents, Project deliverables, supporting documents and data, interview notes, etc., need to be organized and archived for future reference and use. Project team members will place Project artifacts on the dedicated Florida PALM Pre-DDI SharePoint site in adherence with the prescribed file structure. Each Contract Manager is responsible for establishing a final version in PDF and original format for all contract deliverables in SharePoint. These documents provide historical knowledge and will be critical to answering future questions that arise.

Finalize Lessons Learned Over the course of the Project, the Project staff will identify areas for improvement as well as strong practices that should be propagated in the future. Lessons Learned will be documented


of 66 02/19/2016

in the Lessons Learned log over the course of the Project as they are identified. See additional information in Appendix 16 – Lessons Learned Management.

Project Signoff Upon conclusion of the Pre-DDI phase of the Project, the Project Director will request signoff by the Executive Sponsor to confirm they agree the Project has been completed.

Contract Close Out Each Contract Manager has the responsibility to conduct the Contract Close Out Checklist and complete the Contractor Evaluation Form identified in the DFS Contract Management Lifecycle Guide at the conclusion of assigned contracts.

Project Management Processes In order to effectively deliver the Project’s plan, execute, control, monitor, and close stages, a set of Project processes are documented in order to communicate the procedures as well as the roles and responsibilities in the process.

Integration Management The purpose of Integration Management is to coordinate all Project activities to accomplish timely and successful Project completion. The major elements that require integration management are:

1. Resources (people, equipment, facilities, IT assets, etc.) See additional information in Appendix 2 – Cost Management, Appendix 5 – Procurement Management and Appendix 6 – Staffing Management

2. Schedule (phases, milestones, work effort and duration) See additional information in Appendix 3 – Schedule Management

3. Project Deliverables (artifacts [documents], equipment, technology, processes, etc.) See additional information in Appendix 12 – Deliverable Management

4. Project Performance Reporting See additional information in Appendix 1 – Performance Management

A defined Communications Management approach can ensure coordination of the activities described above.

Performance Measures Reporting on performance measures is critical to monitoring and controlling the outcomes of our Projects. The Project Management Team (Project Director and Track Leads/Managers) and staff members shall report progress on defined Project performance metrics. See additional information in Appendix 1 - Performance Measures.

Cost Management The purpose of Cost Management is to ensure the Project will be completed within the approved budget. This includes managing planned and actual expenditures to the appropriated budget categories. See additional information in Appendix 2 - Cost Management.

Schedule Management


of 66 02/19/2016

The purpose of Schedule Management is to build processes to track time with controls to accomplish timely Project completion. See additional information in Appendix 3 -Schedule Management.

Quality Management The purpose of Quality Management is to confirm the work performed meets expected results, the terms of the contracts statement of work (SOW) as well as the Project quality standards and client expectations for service quality. See additional information in Appendix 4 -Quality Management.

Procurement Management The purpose of Procurement Management is to leverage existing processes to identify goods or services needed to successfully complete the Project objectives and scope, solicitation approach and contract administration. The procurement of all goods and services will follow State procurement law. See additional information in Appendix 5 - Procurement Management.

Staffing Management The purpose of Staffing Management is to define a process of obtaining the human resources with desired skills necessary as well as the onboarding and management related activities of Project staff. See additional information in Appendix 6 - Staffing Management.

Collaboration Management The purpose of Collaboration Management is to define an approach for engaging appropriate Project stakeholders and developing relationships with other entities with ERP experience. See additional information in Appendix 7 - Collaboration Management.

Project Scope and Change Management The purpose of Project Scope and Change Management is the process of requesting, determining attainability, planning, implementing, and evaluating of Project changes (which may include scope, schedule or cost). All necessary parties will need to be made aware of an approved Project change and the change will be appropriately managed to ensure the successful, on-time completion of the Project. See additional information in Appendix 8 - Project Scope and Change Management.

Risk Management The purpose of Risk Management is to define processes to identify, track and mitigate risks. Additionally, proper risk management should maximize the probability and consequences of positive events and minimize the probability and consequences of events adverse to Project objectives. See additional information in Appendix 9 - Risk Management.

Communications Management The purpose of Communications Management is to provide the critical links among people, ideas, and information that are necessary for the successful, on-time completion of the Project. Disseminating status reports, postings information to the Project website and holding recurring meetings with Project staff and stakeholders provide transparency to Project activities. See additional information in Appendix 10 - Communications Management.


of 66 02/19/2016

Project Management Sub-processes To deliver the Project successfully, this Project team will employ sub-processes that are widely known and accepted “must haves” in the project management domain. These sub-processes (also identified in Figure 1) are:

Issue Management The purpose of Issue Management is to minimize the impediments to the successful, on-time completion of the Project. The process involves the identification, tracking, and resolution of issues. See additional information in Appendix 11 - Issue Management.

Decision Management The purpose of Decision Management is to record what decisions are needed, who needs to make them, and when they are needed. The process involves the identification, tracking, and documenting decision. See additional information in Appendix 12 - Decision Management.

Deliverable Management The purpose of Deliverable Management is to describe the process of creating, reviewing and accepting deliverables. Deliverable acceptance is a key process to Project success given these are the tangible outcomes specified by the Project. See additional information in Appendix 13 - Deliverable Management.

Action Item Management The purpose of Action Item Management is to describe the process for identified needs by the Project staff to accomplish outcomes that are not on the Project schedule or in risks, issues, or decision logs. Action Items should not be extensions or child activities to risk, issues, decisions, and deliverable approvals. See additional information in Appendix 14 - Action Item Management.

Content Management The purpose of Content Management is to describe document types to be created for the Project as well as revision, team collaboration, version control, and retention guidelines. See additional information in Appendix 15 - Content Management.

Lessons Learned Management The purpose of Lessons Learned is to document both positive and negative outcomes the Project would like to repeat or avoid in the future, respectively. The main goal is to capture problem-solving techniques to be used in the future work in order to “not repeat undesired outcomes”. See additional information in Appendix 16 - Lesson Learned Management.

Risk, Issue, Deliverable and Action Item Responsibilities The exhibit below illustrates staff roles and their ownership for Risks, Issues, Deliverable Acceptance and Action Items (RIDA).


of 66 02/19/2016

Figure 3: Project RIDA Ownership Matrix

Mngs (Manages) has two variations: Exclusively (Mng Excl) and Across Multiple Tracks (Mng Multi-Track). Mng Excl means a RIDA item is assigned exclusively to a Project Track Lead (he or she owns the process for completing that request). Mng Multi-Track means a RIDA item is assigned to the PMO because it needs to be managed across multiple tracks. ODO means a RIDA item is assigned to a staff member (that staff member will own the content and process of the RIDA item). The PMO will monitor and report progress for all RIDA.


of 66 02/19/2016

Appendices

Appendix 1 - Performance Management

Overview of Performance Management The purpose of Performance Management is to drive and track the right outcomes in order to fulfill the Project goals and objectives. For project management, performance metrics are used to assess the health of the Project. Performance metrics typically define criteria for time, cost, resources, scope, quality, and decision-making. In order to achieve the data capturing and reporting on the Project performance metrics identified in this Appendix, the Project plans to employ a web-based project management support tool (PST). Without this capability, the metrics below will require significant manual process overhead and staff resources.

Performance Management Definitions Key Performance Measures (KPMs) - Measures of success for a Project. For most Projects, it is cost and realized benefits. Key Performance Indicators (KPIs) - Elements that can be measured and will influence Project outcomes. As a result, KPIs have a direct relationship to the KPMs. For every KPM, there is typically a one-to-many relationship to a KPI. KPIs should be:

1. Measurable (Quantifiable and Qualitative) 2. Comparable to industry established benchmarks or baselines 3. Measured over time, to see trending

Performance Measures (PerfMs) - Additional process or sub-process measures that can influence KPMs and KPIs.

Performance Management Process The Project performance metrics are shown in the exhibit below. Some of these metrics will be derived over a time period which coincides with the implementation of data gathering and reporting project management tools. As a result, some of the metrics identified below be reported FY2014-15 and expanded in the future. The Project will develop and publish a performance metrics adoption schedule.


of 66 02/19/2016

Figure 1-1: Performance Metrics

Project Performance Measures

Item #Measurement Adoption

Schedule

Cost Definitions/Notes

1 KPM - Cost Performance Index (CPI)

CPI is a measure of cost efficiency of budgeted resources for the

work completed. CPI is expressed as a ratio of Earned Value

(EV) to Actual Cost (AC): CPI = EV/AC

When PST Implemented

2 KPM - Cost Variance (CV) Planned versus Actual over time, Accumulative total to dateNow, by contract milestone

payment

3 KPI - Contract Payment $ variance Planned versus Actual over time, Accumulative total to date Now

4 KPI - Planned versus Forecast versus Actual

Planned (original appropriation) versus Foreccast (estimate to

complete the work which would include CRs) versus Actual over

time


5 KPI - Change Requests impacting cost Planned spend impacted by Change Requests over time Now, by contract

6 KPI - Earned Value (EV)

Earned Value is the measure of work performed expressed in

terms of the budget/planned amount authorized for that work,

and Actual Cost is the realized cost incurred for the work

performed on an activity or set of activities during a specific

time period.


Schedule Definitions/Notes

7 KPI - Schedule Performance Index (SPI)SPI is a measure of schedule efficiency expressed as a ratio of

Earned Value (EV) to Planned Value (PV): SPI = EV/PVWhen PST Implemented

8KPI - Milestone/Deliverable Critical Path

Schedule Variance (SV)

Planned versus Actual over time. Running count over time and

aggregated, number of met versus not met due datesNow

9 KPI - Deliverable approval variance Planned versus Actual Now

10 KPI - Contract Payment variance Planned versus Actual Now

11KPI - Open versus Close Rate on Risks,

Issues, Decision, and Change Request# completed by Due Date, # of late, Late versus Met over time Now

12KPI - Due Date completion varaince for

Risks, Issues, Decisions, and Change Request

Running count over time and aggregated, number of met versus

not met due datesNow

13 KPI - Change Requests impacting schedule Days impacted by Change Requests over time Now

Risks Definitions/Notes

14 PerfM - # of Risk transitioned into Issues Risk to Issue Count Now

15PerfM - Managed versus unmanaged

cost/schedulePie chart to illustrate ratio of cost of managed versus do nothing When PST Implemented

Issue Definitions/Notes

16 PerfM - Issues ImpactsThis should be a forecast of schedule and cost impacts if not

resolvedWhen PST Implemented

Scope Definitions/Notes

17 PerfM - # of CR for missed needs Count Now

18PerfM - Cost and schedule expansion graph

tied to CRsGraph line over time Now

19

PerfM - Total Number of requirements by

Agency Function or Project Track (ex: SOW

Items, P2P, A2R, O2C, R2R Infrastructure,

Network, Servers, )

Count Now

20

PerfM - # of Fulfilled versus Unfilled

Requirements over time, planned versus

actual tied to due dates

Count Graph line over time When PST Implemented

Acronyms:

PerfM = Performance Measures

KPM = Key Performance Measure, the elements that effect Cost, Planned versus Actual

KPI = Key Performance Indicator, the elements to be monitored that will have impact to KPM

PST = Project Support Tool


of 66 02/19/2016

Figure 1-1: Performance Metrics (continued)

Project Performance Measures

Item #Measurement Adoption

Schedule

Qual ity Definitions/Notes

21 KPI - Service Quality Mgmt >> Surveys Satisfaction graph over time by function area and by questionWhen IV&V/QMS

implemented

22KPI - Service Quality Mgmt >> Action Plan

close rateMeasure Close Rate

When IV&V/QMS

implemented

23

KPI - Technology Quality Mgmt >> Defect

tracking and measure of Artifacts and

Technology

Items tracked over time:

1) Planned versus actional review/test cycles

2) Sum Total Defects and Closed Defects.

3) Open and New defects in the reporting cycle.

4) Sum of Defect types over time.

When IV&V/QMS

implemented

24 KPI - Recording and Applying Lessons

LearnedNumber of created versus number of applied.

When IV&V/QMS

implemented

Org Chg Mgmt Definitions/Notes25 KPI - Resistance to Change "Risks" # of OCM Risks Now26 KPI - Awareness Rating Data captured through Surveys Now

27KPI - Awareness Rating over time by

Functional AreaSurvey results over time Now

Staffing Management Definitions/Notes

28 PerfM - # of resources by categoryPlanned versus Actual by Month Graph. Impact statement on

schedule variance, if any.Now

29 PerfM - Resource Staffing Graph Month Graph. Impact statement on schedule varaince, if any. Now

Acronyms:

PerfM = Performance Measures

KPM = Key Performance Measure, the elements that effect Cost, Planned versus Actual


of 66 02/19/2016

Appendix 2 - Cost Management

Overview of Cost Management The purpose of Cost Management is to ensure the Project will be completed within the approved budget. This includes managing a spend plan which includes planned and actual expenditures to the appropriated budget categories.

Cost Management Definitions Cost Management is primarily concerned with the cost of the resources (staff, equipment, hardware, software, facilities, and expenses) needed to complete Project activities. Cost Management should also consider the effect of Project decisions on the cost of completing the entire Project, like scope changes as well as strategy, requirements, and decisions.

Cost Management Process The Cost Management process can be found in the exhibit below.

Figure 2: Cost Management Process

1. Resource planning involves determining what physical resources (people, equipment, materials, travel, facilities, etc.) and what quantities of each should be used to perform activities. The Project Director is responsible for coordinating with Track Leads to determine what resources will be needed.

2. Cost estimating involves developing a cost estimate for the resources needed to complete Project activities. The Project Director is responsible for coordinating with Track Leads to develop cost estimates.

3. Budget Approval is obtained through the State of Florida Legislative Budget Request process. The Project Director works with the Track Leads, Executive Sponsor and Budget Officer to request and obtain budget approval.

4. The Spend Plan is a tool used to monitor what has or will be expended to acquire identified staff, goods, services, and technology. Items will not be added to the Spend Plan until the resource planning activities are complete. The Spend Plan amounts and variances will be used for reporting.

5. Spend Baseline involves allocating the overall spend estimates to individual work items in order to establish a spend baseline for measuring Project cost performance. The Project Director is responsible for establishing a monthly spend plan to be measured against a spend baseline.

6. Spend Control is concerned with determining whether the current cost performance has changed against the baseline (variance), controlling the factors which create changes to cost performance to ensure that changes are beneficial, managing actual changes when they occur, and informing appropriate stakeholders of authorized changes to the baseline.


of 66 02/19/2016

Appendix 3 - Schedule Management

Overview of Schedule Management The purpose of Project schedule management is to create and agree to a listing of a Project's milestones, outcomes, deliverables, reviews, and supporting tasks usually with intended start and finish dates. Those items are often estimated in terms of resource allocation, budget and task time needed (duration), linked by dependencies. A schedule is commonly used in Project planning and Project portfolio management. Before a Project schedule can be created, a work breakdown structure (WBS), an effort estimate for each task, and a resource list with availability for each resource is needed. To control the schedule, dedicated resources will be committed to the development and maintenance of the Project schedule.

Schedule Management Definitions Work Breakdown Structure (WBS) - in project management, a deliverable-oriented decomposition of a Project into smaller components. A WBS element may be a product, data, service, or any combination thereof. A WBS also provides the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control. Baselined Schedule - An organization’s approved Project schedule that can be changed only through formal change control procedures unless it is a minor adjustment. The Project schedule can be used as a basis for Earned Value Analysis. Critical Path - Calculates the longest path of planned activities to logical end points or to the end of the Project, and the earliest and latest that each activity can start and finish without making the Project longer. This process determines which activities are "critical" (i.e., on the longest path) and which have "float" (i.e., can be delayed without making the Project longer).

Schedule Management Process The Project will use a Project schedule, created in Microsoft Project, to establish and baseline the due dates for milestones, deliverables, and key events. The Project team will follow the PMBOK® Project Management guidelines of developing a schedule, managing the change, and reporting progress. The PMO will monitor progress proactively to anticipate challenges and provide support to team members. It is not always feasible to create accurate estimates through the end of long Projects. Beyond a certain period, work plans and schedules become unrealistic due to the ever-increasing uncertainty of the future. To avoid in investing resources and time in creating plans with unrealistic detail, the concept of rolling-wave planning is employed in developing the schedule. In rolling-wave planning, a top down approach is used to assign WBS responsibility to the key Project Tracks, but the detail is not created until the track strategy is approved and any contractual deliverables are agreed upon. The Schedule Management process can be found in the exhibit below.

http://en.wikipedia.org/wiki/Longest_path


of 66 02/19/2016

Figure 3-1: Schedule Management Process

Approve Track Strategy Due to the limited resources at the onset of the Project and the significant onboarding needed in the first year, the Project staff has prioritized the Project Tracks, by criticality to the Pre-DDI objectives. The following is a list of work that will utilize a rolling wave planning approach for the Project.

1. PMO – SSI Procurement Support activities 2. PMO – Project Management Office Support activities 3. PMO – Independent Verification and Validation (IV&V) 4. PMO – Outside Legal Counsel 5. OCM – Organizational Change Management Support activities 6. SDS – Systems and Data Strategy activities

Business Process Standardization (BPS) activities and all outsourced work with contractual date commitments will not use “rolling wave planning approach”. The Project will utilize a master Project schedule as well as track schedules. The Project approach to establishing a master schedule is to first create a strategy document for each Project Track to record the proposed approach for each Track. Once the strategy is reviewed by the Steering Committee the Project will begin drafting a solicitation document as needed, related deliverables and draft due dates. These draft deliverable due dates will not be included in the master Project schedule, rather the activities and dates for finalizing the corresponding contracts will be included. The dates associated with submitting and reviewing deliverables will be included in the master schedule. During the Pre-DDI phase, a key objective for the Project staff is to create, finalize, and communicate the Project’s scope and schedule. Since the Project is leveraging Contractor staff to complete Project deliverables, a baseline track schedule cannot be established until the contracts for each of those services and deliverables are finalized. Each Contractor, as a component of their response to the solicitation, is required to confirm the deliverables and due dates or propose alternatives. Once a contract is finalized to support the Track activities, the deliverables and corresponding due dates for the contract will be included in the master schedule.

Finalize and Baseline Track Schedule A required contractual activity for each Contractor is to create and maintain a Microsoft Project Schedule of activities, with resources and dependencies assigned, to the agreed upon Work Breakdown Structure (“WBS”) for the track.


of 66 02/19/2016

The steps that constitute the Finalize and Baseline Schedule activity are:

Review existing draft schedules and plans

Review and finalize the Work Breakdown Structure (WBS)

Review and finalize the activity durations

Review and finalize activity dependencies including the creation of milestones

Review the overall schedule and integration of tasks between teams including incorporating external dependencies

Approve and baseline the schedule A schedule baseline is a version of the schedule that is the standard against which future schedule performance will be measured. This comparison can identify areas of schedule slippage requiring corrective action to ensure the Project remains on schedule. Because the track schedule baseline will be used throughout the Project for measuring actual performance against planned tasks, the Project staff must review all aspects of the track schedule before the baseline is finalized. This final examination of the track schedule may take several iterations as activities, their sequencing and duration, inter-Project dependencies, and resource requirements are reviewed and adjusted to achieve a baseline that is optimized for the Project.

Track Progress Track progress against the schedules is a continuous process that occurs at least weekly or as needed in order to collect and report accurate information in a timely manner. The PMO and Track Leads will utilize the status meetings, status reports and four-week look ahead reports to track and communicate progress against the schedules. This process consists of the following steps:

Review the schedules weekly or as needed

Conduct bi-weekly meetings with the Project Director and Track Leads to review the master schedules

Analyze, determine and document corrective actions, if needed (e.g. change request)

Obtain approval to implement schedule changes, if needed

Update the schedules as needed to reflect changes

Document progress updates on status reports

To build consistency in how progress is reflected in the schedules and weekly status reports, tasks will be reported using the following Percent Complete definitions in the exhibit below as weekly tracking occurs. Table 3-2: Task Percent Complete Definitions

Percent Complete Definition

0% Task/work product not started

25% Task started and in-progress

50% Staff assigned to work communicate half of the work is completed

75% Work product has been submitted for initial review/approval

90% Work product has been submitted for final approval

100% Task/work product is complete

The schedules also reflect milestones (tasks with a duration of zero days). Milestones are binary – they are either not complete or complete. A completed milestone will be reflected as 100%. Otherwise, a milestone will be reflected as 0%.


of 66 02/19/2016

Revise Schedule The PMO will be responsible for managing changes to the master Project schedule following the Project Scope and Change Management Process (defined in Appendix 8). Any approved changes to the approved/baselined Track schedules will follow the defined process and will be made by the Contractor in that Track or the Track Lead.

Schedule Standards and Assumptions Throughout the Project, certain standards will be maintained concerning the schedule and processes tied to the schedule management. The exhibit below presents a scheduling best practices checklist for use on the Project. It is a tool for use in schedule creation, schedule reviews and monitoring activities. Table 3-3: Schedule Management Best Practice Checklist

Item # Review Item

1 General

1.1 Is the schedule being regularly updated with actual values of task performance including (at a minimum) planned start, planned finish, actual finish, and percent complete?

1.2 Are there inter-related Projects that are dependent upon this Project (either for inputs, outputs, or resources)? This should be noted in the Project schedule.

1.3

Are “High Risk” mitigation tasks included in the schedule and connected to correct WBS items?

1.4 Are milestones, contract payments, and contract deliverable due dates clearly identifiable?

2 Resources and Calendars

2.1 Are the non-working holidays entered in the Project calendar?

2.2 Are there conflicts in resource allocation among tasks?

2.3 Are the appropriate resources allocated to all relevant tasks?

2.4 Are there duplicate resources entered in the Resource Sheet?

3 Structural

3.1 Are tasks named in a unique manner, associated to the appropriate track and have a duration estimate?

3.2 Are any tasks with duration > a month?

3.3 Are there summary tasks with predecessors?

3.4 Are there summary tasks with successors?

3.5 Do all summary tasks have at least two subtasks?

3.6 Are there summary tasks with resources?

3.7 Are there milestone tasks with durations > 0 days?

3.8 Are there milestone tasks with resources?

3.9 Are there milestone tasks without a predecessor?

3.10 Are there detailed tasks without a predecessor?

3.11 Are there detailed tasks without a successor?

3.12 Are there detailed tasks with constraints other than “As soon as Possible”?

3.13 Are there detailed tasks that are manually scheduled?

3.14 Are there “fixed dates” outside of the “critical path” or timeline markers?

3.15 Is there a logical hierarchy of tasks?

4 Baselines


of 66 02/19/2016

Item # Review Item

4.1 Did modified Baseline Start date or Baseline Finish dates go through authorization?

4.2 Are any newly added tasks baselined selectively?

5 Weekly Updates and Metrics

5.1 Has the schedule been updated in the past week?

5.2 Are there incomplete tasks with a Planned Finish Date earlier than or equal to the last modified date of the schedule?

5.3 Are there un-started tasks with a Planned Start Date earlier than or equal to the last modified date of the schedule?

5.4 Have you reviewed the Critical Path?

5.5 Are there Actual Finish dates that were entered as future dates?

5.6 Are the tasks for deliverable review cycles reflective of the agreed number of reviews, durations, and dates?

5.7 Are the tasks for deliverable approval included for all defined deliverables?

5.8 Are the detailed tasks defined at the appropriate level of detail given the current progress of the Track?

5.9 Are there changes to Planned Finish Dates for major milestones that negatively impact the critical path?

The exhibit below reflects the Projects schedule standards. Table 3-4: Schedule Standards

Standard Activity

Resource Naming

Individual resources will be displayed by first and last name and a group of individuals will referenced collectively (i.e. Vendor, BPS Support Contractor, and BPS Team).

Non-working Time

State holidays and weekends are marked as “non-working time” in the Project schedule. This means that Microsoft Project will skip over these dates when scheduling work.

Hours of productivity

The Project schedule assumes that team members will be productive on Project tasks 8 hours/day.

Meetings

The Project schedule will not track Project meetings. The Project maintains a meeting log to record all Project meetings that occur with one or more person outside of the Project staff. Weekly status meetings, team meetings and impromptu meetings between team members are recorded through Microsoft Outlook Calendar features and not the meeting log.

Schedule Updating

Updates to the Master Project Schedule will be made at least weekly by the PMO Manager or designee. Updates to the Track Schedules (% complete only) will be made weekly by the Contractor or staff supporting the Track.

Columns Displayed

The standard columns to display are:

Task Name

Percent Complete

Duration

Start

(Planned) Finish

Actual Finish

Predecessors


of 66 02/19/2016

Standard Activity

Successors

Resource Names

Work

Schedule Backup

The schedule will be saved as a backup copy on a weekly basis. This includes a PDF of the schedule uploaded to the SharePoint site.

Tasks The tasks in the schedule will be set to “fixed duration”.


of 66 02/19/2016

Appendix 4 - Quality Management

Overview of Quality Management Quality Management (QM) will provide processes and tools for management to have visibility into the services and technical quality of the Project to meet expected results. Project QM also involves quality assurance activities by employing independent verification and validation activities to confirm that Project procedures, instructions, deliverables and practices are properly implemented per organization policy, standards, and rules.

Quality Management Definitions Quality Management System (QMS) - “The Project Quality Program”. QMS refers to management methods used to enhance quality and productivity on the Project. QMS is a comprehensive approach that works horizontally across Project tracks and extending backward and forward to include both Contractors, Project team members, and agency stakeholders. Quality Planning (QP) - “The QMS Project QC Plan”. Quality planning will identify the who, what, when, where, and how for quality elements. Quality Assurance (QA) - “The QMS Prevention Element”. The standards, procedures, and planned systematic activities (ex: training, Project tools, Project support personnel) necessary to ensure that quality standards and procedures are adhered to and that delivered products or services meet contract and quality requirements. Quality Control (QC) - “The QMS Inspection and Fix Element”. Quality control requires the Project manager(s), Track Leads, and the Project team to inspect the accomplished work to ensure its alignment with the Project scope and requirements. Quality of Service Evaluations (QSE) - Service compliance evaluations that are concerned with how well Contractor staff professionalism is being perceived by Project team members. This data will be gathered through periodic surveys as well as assessed, measured and, reported by the Project Management Office. Technical Quality Evaluations (TQE) - Process and standards compliance evaluations that are concerned with technical deliverables. The elements for technical quality are:

1. Project artifacts (i.e. document deliverables) are reviewed, and quality feedback is provided by the designated group of employees prior to initial delivery to the customer. Approvers must not see Project team produced artifacts before they go through a quality-control review.

2. Technology installation deliverables are evaluated per the test strategy and supporting test plan.

Independent Verification and Validation (IV&V) - Verification and validation are independent procedures performed by a third party that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose.

QMS Component Relationship Map There are many parts to a QMS system. The below exhibit identifies and illustrates the relationship between those parts.


of 66 02/19/2016

Figure 4-1: QMS Component Relationship Map

The standards and measures identify what is to be performed and measured. The quality planning ties together the “who, what (outcomes), when, where, and resources” needed to implement the standards and measures. The procedures describe the processes for evaluating and measuring quality as well as who has ownership for each step in the process. “Deliverable Acceptance” is a process that enables the “Quality Control” processes inside the QMS system to evaluate and arrive an acceptable product. The remaining components in the illustration above are described in the “Definition” section of this appendix.

Quality Evaluation Processes This section explains the processes for service quality, technical quality, and IV&V activities.

Service Quality Evaluation (SQE) To evaluate the quality of services provided by Contractors, the Project shall employ a “quality of service” satisfaction survey. This survey is delivered electronically or gathered through interviews. The survey is performed more than once. These surveys are a monitored and tracked event on the Project schedule. The Project team may choose to employ a survey application to gather service quality information. The PMO track will manage, gather, analyze, and report the SQE results to Project leadership. PMO will also provide this feedback to the Contractor with the Track Lead participation. For contractor staff augmentation work, SQE results are recorded by the Contract Manager on a monthly basis inside the Project provided timesheet recording sheet. The rating is “Pass” or “Fail” for Quality of Work Products, Timely Completion of Assigned Tasks, and Communications.

Technical Quality Evaluations (TQEs) This section describes the expectations for “Quality Control” associated with deliverables and


of 66 02/19/2016

supporting technologies identified in scope or statements of works. There will be two technical evaluation processes.

1. Non-Contractual documents that shall be shared and stored for future use or be presented to Project Director or Project sponsors will go through a peer review process. This peer review process consists of:

a. Work Product Owner (WPO) creates document. b. WPO schedules and coordinates peer review, records feedback using “track

changes” and insert comments as appropriate. c. WPO updates the document using version history to communicate the summary

of changes. d. WPO conducts additional reviews with the peer reviewer(s) until all concerns or

defects have been resolved to satisfaction. e. WPO stores the document(s) in an agreed to SharePoint location.

2. Contractual accepted documents require a formal quality evaluation. Typical document

review cycles are: a. WPO confirms document’s content, format and transmission method per SOW

and/or Deliverable Expectation Document. b. WPO will coordinate with Contractor QA to perform quality reviews prior to

submission using QA inspection points defined in the “Document Quality Checklist”.

c. Cycle 1 Review - WPO reviews document with identified reviewers and correct defects.

d. Cycle 2 Review - WPO reviews document with identified reviewers and correct defects in preparation for final approval submission.

The above review cycle will be dictated in the contract document or approved Project schedule.

Independent Verification and Validation (IV&V) This Project will also leverage IV&V services to evaluate QMS processes compliance and PMP process effectiveness and efficiency. IV&V services are critical components of a quality management system. IV&V inspections are performed at scheduled time intervals to confirm the Project complies with the pre-defined quality standards and processes. The IV&V function will provide the IV&V evaluation report to the Project designated audience and defined frequency per the approved “Pre-SSI IV&V Implementation Strategy” produced as part of the IV&V contract.

Quality Measurement High-quality work products are considered critical to the Florida PALM Project to provide outstanding service to its customers. This section identifies the qualified and quantified quality measurements for the Project. The following Technical Quality Defects Classification will be used to classify and report defects found in documents after submission for acceptance review:

Severity 1: Major Material Issue – Contract or Deliverable Expectation Document specified content is absent in document.

Severity 2: Quality Issue - Missed data previously communicated in acceptance review cycle #1, major grammatical errors (basic spellcheck must be performed).

Severity 3: Immaterial Issue - Consistency in fonts, punctuation, elimination minor


of 66 02/19/2016

grammar errors.

When conducting a document review, the TQE results are documented electronically containing content in the “Document Quality Checklist” attached below and posted to the designated location. The attached sheet also contains an example “Quality Trend Report” that will be used to see quality progress over time.

Doc QA Checklist

TQE ratings will be defined as follows:

1. First review submission, if “Severity 1” defects exists, rating is “Unacceptable”, otherwise it is ready for further review.

2. Second review submission, a. If “Severity 1” defects exist, rating is “Unacceptable”. b. If “Severity 2 or 3” defects exists, rating is “Dissatisfied”, proceed with review.

3. Third review submission, a. If “Severity 2” defects exist, rating is “Extremely Dissatisfied”. b. If “Severity 3” defects exist, rating is “Conditional Accept”.

IV&V Evaluation Ratings shall be defined as part of the Pre-SSI IV&V Implementation Strategy.

Quality of Service Measurement Contractor staff are measured and evaluated on their service quality brought to the Project. Customer satisfaction rating (via the customer satisfaction survey) will be rated as, “met”, or “did not meet” expectations by category. The survey consists of standard questions gathered through one or more electronic delivered content or face-to-face interview cycles. The results from the survey are reported into the Project Performance Measures. Less than “met” ratings/comments require follow-up with the Project Director by the Contractor QA to understand the issues/concerns, develop remediation action plans, and resolve these issues/concerns in a timely manner.

Quality Management Roles and Responsibilities Specific roles and responsibilities for quality are summarized in the below exhibit: Table 4-5: Quality Management Roles and Responsibilities

Role Responsibilities

Track Lead or Contractor Project Manager

Confirm deliverables are prepared in conformity with organization standards, methodologies and deliverable expectations.

Confirm that quality control is implemented through evaluation and feedback by staff who did not author the documents or perform work on the deliverables.

Responsible for ensuring TQE data is gathered.


of 66 02/19/2016


Note: The above responsibilities may be delegated/assigned to another team or entity. By doing this, this does not remove the responsibility from the leaders to ensure these functions are being performed.

Project Management Office

Provides overall guidance and manages the Quality Management System.

Responsible for maintaining the SQE and TQE reports/dashboards.

Work Product Owner

Owns and prepares deliverables to conform with established Project standards and methodologies.

Schedules and conducts TQE reviews.

Owns remediation of all deliverable defects associated with the assigned work product.

Contractor QA

Participates in the deliverable review process using the Document Quality Checklist.

Participates in discussions related to Quality of Service issues.

Project QA (IV&V)

Validate and verify Project QMS

Maintain an IV&V dashboard to comply with the Project performance reporting requirements.

Documents and reports IV&V remediation progress monthly.

Generate and coordinate customer satisfaction surveys and produce reports.

Perform IV&V inspections.


of 66 02/19/2016

Appendix 5 - Procurement Management

Overview of Procurement Management The purpose of Procurement Management is to leverage existing processes to identify goods (products) or services needed to successfully complete the Project objectives and scope, solicitation approach and contract administration. The Project will procure support services for each track. For these services, the Project will follow the DFS Agency Policy and Procedures (AP&P) #2-02 (Purchase of Commodities/Contractual Services) which references relevant Florida procurement laws (F.S. 287) and rules for all products and services needed to support the Project.

Procurement Management Definition Procurement Management Process, or Procurement Process, is a method by which goods and services are purchased. The procurement management process involves managing the ordering, receipt, review and approval of goods and services from Contractors. A procurement process also specifies how the Contractor relationships will be managed, to ensure a high level of service is received.

Procurement Management Process Procurements will be managed through the PMO. The Project will have designated procurement professionals that will work through the procurements from the initial strategy, contract execution and through the contract closeout. Every Project Track will develop a Track Strategy that includes the identification the services required. Procurements will follow the DFS Contract Management Lifecycle Guide procedures which define the solicitation approach and contracting administration. For these type of procurements, each will require these items to be documented an approved:

1. Business Needs Analysis 2. Purchasing Methods 3. Identify Rules and Statues affected by the activities

The Project will review and forecast future products and services needed in the monthly Project spend plan.

Purchase Authority The Project Director has the authority to purchase the necessary goods and services to achieve the outcomes of the Project within budget constraints.


of 66 02/19/2016

Appendix 6 - Staffing Management

Overview of Staff Management The Staff Management section describes the onboarding and management related activities concerning state employees and contracted staff (Contractor staff). A Project staff guidelines document was created to provide helpful information and expectations for all Project staff on key topics. Project staff include both Department of Financial Services (DFS) and Contractor staff who perform work as a member of the Florida PALM Project (the Project).

State Staff Employees Effective Project oversight and collaboration among the all Project staff are critical to Project success. At appropriation of state full-time employees (FTEs), the Project established positions to identify the human resources with desired knowledge, skills and abilities (KSAs) needed to achieve Project success. When considering potential Project staff members, candidates are evaluated against the established KSAs. The Project Charter describes the Project staff needed to effectively administer the Project through the Pre-DDI Phase. It also describes the roles and responsibilities of each Project staff member. The Track Leads are ultimately responsible for the performance and staff management within their Track. All Project staff members are evaluated annually based on performance expectations. The evaluation of whether each performance measure is met is based upon a combination of visual observation, logs or notes kept by the supervisor, written activity or work logs kept by the employee, periodic meetings with the employee, customer or colleague feedback, written progress reports, and meeting of Project milestones and deadlines. The Project staff will follow all DFS’ Human Resources (HR) policies and procedures. DFS policies are maintained on the DFS intranet site and can be accessed at http://dfsintranet/APP/Forms/AllItems.aspx.

State Staff Onboarding When hiring full time state employees, the Track Leads will need to monitor the steps to ensure a smooth transition for the newly acquired staff. This process can take several weeks and stretches across various divisions within DFS. The steps/requirements below would take place after the applicant has accepted the verbal offer from the appropriate manager. The steps/requirements for staff onboarding are:

1. The Track Lead/Hiring Manager will: a. Complete Employer Reference Checks – it is suggested the Track Lead complete

reference checks with the candidate’s previous employers over 10 years (at a minimum) i. If the candidate was ever a state employee, review the personnel and employee

relations file at appropriate State agency, and document the reference checks in an email or word document.

ii. Complete the Employer Reference Check Form (DFS-C2-644) b. Request a signed State of Florida application c. Request a signed Appointment Processing Form (DFS-C2-2069) d. Send the Project Office Manager the following:

http://dfsintranet/APP/Forms/AllItems.aspx


of 66 02/19/2016

i. The completed reference check forms ii. The signed state of Florida application iii. The signed Appointment Processing Form (Track Lead and candidate signatures)

2. The Project Office Manager will prepare New Hire Package including: a. Appointment Request Form (DFS-C2-648) (signed by the Project Director) b. Signed Application c. Completed reference check forms d. Position Description e. Appointment Processing Form (DFS-C2-2069) f. Personnel Action Memo (signed by the Project Director)

3. HR reviews the New Hire Package and sends notification of receipt and once the package is reviewed and process them. They will send a notification of approval to process with fingerprinting.

4. The candidate is required to contact the HR representative to schedule fingerprinting appointment at DFS. HR will complete the background screening and notify the Project Office Manager and hiring Track Lead when screening is cleared and approved.

5. The hiring Track Lead contacts the candidate for a start date. 6. The Project Office Manager will notify HR and HR will generate the offer letter. 7. Once the offer letter is generated the Project Office Manager completes:

a. DFS Form 1820 b. Building Access Form(s) c. Parking

8. Once complete, the new team member receives a “Day 0” welcome email including the Project guidelines and information first their first day at the email address provided.

Once onsite, the OCM team conducts New Employee Orientation (NEO) training for new State team members.

Contractor Staffing Every Project Track will develop a Track Strategy that includes the identification the contractual services needed and the Contractor’s desired knowledge, skills and abilities (KSAs). Each contract defines the minimum and preferred qualifications of staff assigned to work on the Project. The Project staff is ultimately responsible for managing the Contractor staff on the Project. In order to ensure the timely delivery and high quality of work products from Contractor staff, the Track Lead, or his/her designee, will meet weekly with the Contractor to discuss the progress for the procured services. The meetings will be primarily in person or for exceptions, by teleconference. The purpose of these meetings will be to:

1. Review significant activities that have been conducted or are underway. 2. Discuss any tasks/activities that are behind schedule and a plan to bring them current 3. Discuss any problems that have been encountered and their resolution or plan for future

resolution. 4. Review goals or upcoming deadlines.

The weekly meetings serve as an opportunity to ask questions ahead of time in order to prevent delays in delivery and schedule. All Contractor staff are to operate as a partner and work in good faith to provide professional services based on best practices and industry standards


of 66 02/19/2016

For staff augmentation contractors, the Project staff will provide a monthly performance assessment (quality, communication, timely completion of tasks) on the contractor time report provided by the Project.

Contractor Staff Onboarding When executing contracts and bringing Contractor staff to the Project, the Track Leads/Contract Managers will need to monitor the steps to ensure a smooth transition. This process can take several weeks and stretches across various divisions within DFS. The steps/requirements below would take place after the contract is executed. The steps/requirements for Contractor onboarding are:

1. Acquire Start Date of Contractor(s) 2. Contractor(s) submit signed Non-Disclosure Agreement (NDA) 3. Fingerprinting and Background Screening

a. Contractor to register/make appointment for fingerprinting i. Local: Fingerprinting will take place at the UPS store next to the Lake Ella Publix.

(processing time is on average 24-48 hours) ii. Non-Local: For staff that does not reside in the State of Florida, they must register

at the site http://www.l1enrollment.com/ and request and mail in complete fingerprint cards according to the instructions (processing time is on average 5-7 days). The register may also call MorphoTust at 1-800-528-1358 and complete the registration process.

b. Regardless of location, the Contractor will notify the Project Office Manager and appropriate HR contact with the date/time of their fingerprint appointment so the results can be tracked.

4. Once background screening complete, Project Office Manager completes: a. DFS Form 1820 b. Building Access Form(s) c. Parking – send vendor contact information for parking

i. Monthly parking reservations are handled by Republic Parking, at 850-561-3066. Check or cash only and have to visit office to obtain tags

ii. Duval lot is paved - $30 per month iii. Bronough lot is unpaved - $20 per month

5. Once complete, Contractor(s) receives “Day 0” welcome email including the Project guidelines and Day 1 information at their provided email address.

State and Contractor Staff Roll-Off To facilitate the roll-off of State or Contractor Staff, the PMO Team leverages a roll-off checklist to ensure the appropriate transfer of knowledge, final acceptance of work and removal of access is complete.

http://www.l1enrollment.com/


of 66 02/19/2016

Appendix 7 - Collaboration Management The purpose of Collaboration Management is to define an approach for the involvement of Project stakeholders and other entities with ERP experience.

Collaboration with State Agencies As part of the BPS Track, specific activities were identified in the BPS Strategic Plan to engage agencies to review and confirm standardized business processes which include relevant statutes/rules, key policy items for consideration, reporting needs and data exchanges (interfaces). This included facilitation of Workgroups (with subsets of agencies) and Workshops (with all agencies) and concluded with an activity to obtain feedback through surveys and a process questionnaire from agencies regarding the proposed standard business processes. The BPS Strategic Plan also identified the use of focus groups (as needed) composed of a select number of agency SMEs to review applicable areas of requirements in order to validate requirements gathered from other data sources (such as Aspire, Contractor “KnowledgePacks” developed from other state ERP implementations and industry best practices).

Collaboration with FFMIS Entities The Project understands that each FFMIS entity and its accompanying subsystem(s) are critical to the State of Florida and should be considered by the Florida PALM Project for future potential impacts. Clear communication and engagement with the appropriate level of leadership at each FFMIS entity is necessary throughout the Pre-DDI phase to inform and align FFMIS entities with objectives of the Project. In addition to including FFMIS agency owners in the business process standardization activities, the Project anticipates that each Project Track will engage each FFMIS entity to one degree or another, either in parallel or jointly as the situation dictates. The approach for engaging each FFMIS entity is outlined a FFMIS Pre-DDI Engagement Strategy.

Collaboration with Public Sector ERP Implementations

In order to leverage best practices developed by other public sector ERP implementers, the Project created a Collaboration Strategy within the OCM Track. The Collaboration Strategy includes activities to coordinate with other states, cities and universities that have implemented an ERP to share planned activities for the Florida PALM Project and discuss lessons learned from their implementation.

Communication/Meeting Log Having a defined Communications Management approach can ensure the distribution of timely information to Project stakeholders (see additional information in Appendix 10 - Communications Management). The Communications Log (managed by the OCM team) is intended to capture major communication events regarding the Florida PALM Project to outside entities. Outside entities include any person or organization not within the Project team. Communication events include newsletters, notifications, memos, speeches, media coverage, presentations, letters, emails, publications, et cetera. This log is managed on the Project’s Organization Change Management SharePoint site. The Meeting Log (managed by the OCM team) is intended to capture details of planned and completed meetings between Project staff and at least one other participant outside of the Project. Details include participants, attached documents (such as agendas) meeting times, dates and locations, and meeting notes. Together, both logs provide a good assessment of who is being contacted, how frequently, and the amount of time being requested, and the message being transmitted.


of 66 02/19/2016

Appendix 8 - Project Scope and Change Management

Overview of Project Scope and Change Management Project Change Management describes the change control process for tracking and gaining approval on Project changes. The process exists to communicate to all necessary parties that a change is needed and will be managed to ensure the Project is protected against unauthorized work activities. Once Project change is identified, an analysis is conducted to determine impacts to cost, schedule, scope and quality. All Project changes related to scope, cost, or schedule are managed through the Project Scope and Change Management Process and the Project Governance Charter. A Project change is an addition, modification or deletion to any element within the established Project charter, supporting strategies, or plans. Anyone internal or external to the Project may request a Project change by submitting a Project Change Request (PCR). An effective Project Change control procedure should:

1. Provide a mechanism to allow individuals to request Project changes. 2. Document a process for formally assessing the impact of a requested Project change

(effort, schedule, cost, and/or functionality). 3. Identify the roles and responsibilities of various team members to review Project

changes, disposition considerations, and formally approve Project changes, including escalation, as appropriate.

4. Document how the disposition of a requested Project change is communicated back to the requester and other interested parties.

5. Manage the impact of approved Project changes on deliverables, schedule, and/or cost. 6. Allow Project changes to accepted work products to be proposed and evaluated,

schedule and quality impact assessed, and approved or rejected into work products in a controlled manner.

Once a Project change has been identified, the processes described below is used to determine if the requested change needs to enter the formal change control process.

Minor Project Adjustments As a basic guideline, any Project change that requires less than eight hours of work or is not an addition or deletion of scope will be classified as a minor adjustment and does not require the formal Project change request process. Changes to meeting schedules, is an example of a minor adjustment, as long as the overall timeline or deliverable schedule is not impacted. Each Track Lead is responsible for determining if it is a minor adjustment or a significant change. Any minor adjustment can be moved to the Project Change Process if it is determined to be a substantial change or if it occurs so late in the Project that it presents an unacceptable risk. The minor adjustment process is listed below:

The Project change is identified by a member of the Project staff to the Track Lead.

The Project change is vetted by the Track team to make sure it is reasonable.


of 66 02/19/2016

The Project change is reviewed by the track team to see if it is a major change or requires a large number of hours to complete. If not, the change is made and the Project Director is notified, if applicable.

Project Change Process The Project Change Process is crucial to Project completion and successfully managing expectations. It entails making choices about resource allocation, making trade-offs among competing objectives and alternatives, and managing the interdependencies among project management processes (i.e. cost management, scope management). Planning and management of scope, human resources, schedule, risks, quality, or costs cannot be done in a vacuum. Changes in scope can affect the schedule. Changes in staffing can affect costs. Change management is an ongoing process. Identifying and qualifying changes in a timely manner is a critical success factor for the Project. Both Project and Contractor staff will apply appropriate effort to support timely Project change request process. Change requests are often the result of a Project risk or issue that has been evaluated to determine that a change is required. Change requests can come from newly identified or changing needs or external factors having an impact on the Project. The Requester submits a Project Change Request form containing a request for additional resources, additional funding, a change in schedule, or other change identified as necessary for Project success. Change requests can occur throughout the life of the Project. Changes that affect the scope, budget, schedule, and/or effort of the Project are formally documented, prioritized, analyzed, reviewed, and approved before implementation. Prior to bringing a completed PCR form to the Change Control Board (CCB), the Track Lead reviews and evaluates the completed documentation. Any questions or issues regarding the PCR should be addressed, to make sure the documentation is complete, clear, and accurate. Once the SCR documentation is complete, the Track Lead schedules the PCR for the next CCB meeting. The evaluation will use the “Change Management Checklist” identified below. This checklist enables Project team and/or a Track Lead to evaluate the effectiveness of the PCR process and how to revise the specific documents. The checklist contains items to consider for documenting PCRs, handling them according to process, and ensuring any approved changes are reflected in the Project deliverables. The Change Management Checklist is available here.

Change Management

Checklist

The approval path for change requests is determined by the impact to scope, cost, and schedule. Once approved or rejected, a change request will be closed.

Change Request Log


of 66 02/19/2016

A Change Request Log will be used to document and track change requests. The change request log will be located on the Project’s SharePoint site and include all the information contained in the change request form. The Track Lead or PMO is responsible for maintenance of items in the Change Request Log. The change request progress will be tracked by the PMO.

Project Scope and Change Management Roles and Responsibilities The below exhibit summarizes the roles and responsibilities associated with Change Management.

Roles Responsibility

Steering Committee, Executive Sponsor and Chief Financial Officer

Reviews changes that meet the criteria defined in the Project Governance Charter

Project Director

Reviews PCR’s prior to CCB submission

Approves or rejects PCR that meets the criteria defined in the Project Governance Charter

Escalates changes that meet the criteria to the Steering Committee and involve others as needed

Communicates PCR status to CCB

Change Control Board

Members will include PMO Manager, Track Leads, Project Risk Lead and designated PMO Staff

Reviews and provides considerations for changes requested consistent with escalation criteria

Participates as needed in determination of whether change is required

If change request is rejected, determine appropriate course of action

Track Lead

Identify and document changes based on evaluation of issues or risks and communicates need for incorporation to the Change Request Log

Update Project artifacts (scope, schedule, resource plan, etc.) as needed and assigned by work stream lead

Logs change requests, posts to SharePoint and ensures signatures are captured as needed

Manage process to ensure that steps are followed as defined

Ensures signatures are captured as needed

Track communication and approvals within the Project staff, internal stakeholders

Facilitates discussions on identifying change request impacts

PMO

Reviews all PCRs for completeness and impact quantification (schedule, cost) prior to review by Project Director and Change Control Board

Owns PCR process and has same responsibilities as Track Leads when it affects multiple tracks

Tracks and reports all PCR decisions escalated to Change Control Board

Requester Document and submit PCR based on need identified


of 66 02/19/2016

Scope of the Software and System Integrator (SSI)

The table below identifies the System/Business functions that have been designated for replacement by the Florida PALM Project.

Current System/Business Function Target System

FLAIR Central: Budget Ledger Florida PALM – Phase 1

FLAIR Central: Cash Ledger Florida PALM – Phase 1

FLAIR Central: W9 Florida PALM – Phase 1

FLAIR Central: EFT Florida PALM – Phase 1

FLAIR Central: 1099 Florida PALM – Phase 1

FLAIR Central: Warrants Florida PALM – Phase 1

FLAIR Departmental: Accounts Receivable Florida PALM – Phase 1

FLAIR Departmental: Accounts Payable Florida PALM – Phase 1

FLAIR Departmental: General Ledger Florida PALM – Phase 1

FLAIR Departmental: Project Accounting Florida PALM – Phase 1

FLAIR Departmental: Asset Accounting Florida PALM – Phase 1

FLAIR Departmental: Grants Accounting Florida PALM – Phase 1

FLAIR IW: Information Warehouse / Reporting Florida PALM – Phase 1

FLAIR Payroll: Payroll Florida PALM or another solution integrated with Florida PALM proposed by SSI and accepted by the State

Unknown: Grants Management Florida PALM – Phase 2

Unknown: Contract Management Florida PALM – Phase 2

Unknown: Project Management Florida PALM – Phase 2

Unknown: Asset Management Florida PALM – Phase 2

CMS: Receipts Florida PALM – Phase 1

CMS: Verifies Florida PALM – Phase 1

CMS: Chargebacks Florida PALM – Phase 1

CMS: Trust Fund Accounting Florida PALM – Phase 1

CMS: Investment Accounting Florida PALM – Phase 1

CMS: Disinvestments Florida PALM – Phase 1

CMS: Bank Accounting Florida PALM – Phase 1

CMS: State Accounts Florida PALM – Phase 1

CMS: CRA Florida PALM – Phase 1

CMS: Agency Repository (Doc Mgmt.) Florida PALM – Phase 1

CMS: Warrant Processing Florida PALM – Phase 1

CMS: Investments (Trading) CMS interfaced with Florida PALM

CMS: SPIA CMS interfaced with Florida PALM

CMS: Archive CMS interfaced with Florida PALM

MFMP: Purchasing MFMP interfaced with Florida PALM

MFMP: Receiving MFMP interfaced with Florida PALM

People First: Human Resources People First interfaced with Florida PALM

LAS / PBS: Budgeting LAS/PBS interfaced with Florida PALM

FACTS: Grants Administration Florida PALM – Phase 2

FACTS: Contract Administration Florida PALM – Phase 2

Agency Business Systems: Multiple Florida PALM or Agency Business Systems interfaced with Florida PALM


of 66 02/19/2016

Appendix 9 - Risk Management

Overview of Risk Management Risk management is the process of proactively identifying events or situations that can adversely affect a Project’s ability to achieve stated goals or objectives and the development of mitigation strategies to avoid or minimize potential negative outcomes. The tracking of risks is considered to be a critical component of project management. A Project risk is a possible event or condition that may impact the Project’s ability to meet stakeholder expectations, or a general uncertainty (either positive or negative) which pertains to the Project. A risk can also be described as an “unborn issue”. Ad Hoc risks are risks identified during events not associated with a formal or planned “risks assessment” event. They are most often discovered and recorded during Project risk status or schedule reviews. Risk Assessments are scheduled and formalized events for identifying risks on a Project. Risk Management Methods Risk management methods consists of two primary processes: Risk Assessment and Risk Control. Each process includes three components. Risk Assessment involves risk identification, risk analysis (evaluation), and risk prioritization. Risk Control involves risk management planning, risk resolution, and risk monitoring. The exhibit below illustrates the relationship between the risk management elements.

Figure 9-1: Risk Management Elements

Risk Management Process The exhibit below communicates the risk management process. The exhibit depicts the process for identifying, assessing, managing and closing as well as the identification of the individual or team responsible for each process step.


of 66 02/19/2016

Figure9-2: High-Level Risk Management Process

Risk Assessment Components

Risk Identification produces a list of Project-specific risk items likely to compromise a Project's satisfactory outcome. Risks can be identified through risk surveys, interviews, assessment meetings, and personal experience.

Risk Analysis Qualitative Risk Analysis assesses the probability and potential magnitude associated with each identified risk item. Each identified Project risk will be qualified by the Risk Management Team (RMT) by probability of occurrence. These values will be recorded in a risk log and managed by the PMO, Track Lead, and PMO Risk Lead. Quantitative Risk Analysis is the process of quantifying the impact of moderate to critical risks to determine their likely impact upon Project outcomes. Risk Prioritization assigns a priority value to each identified risk based on the result of the foregoing risk analysis, identifying those risks likely to have the greatest probability and impact. At this point, the Risk Management Team will determine whether each individual risk will be mitigated, transferred, resolved, or monitored.

Risk Log A Risk Item Log will be utilized to document and track risks. The log serves the purpose of tracking progress and the risk response. The PMO Risk Lead add items to the Risk Log during risk assessments. Requesters add adhoc risks to the Risk Log as identified. The PMO Risk Lead monitors the Risk Log to ensure risks (including status) are updated appropriately.

Risk Control Components Risk Management Planning determines how overall risk identification, evaluation, and response activities will be structured and performed. During the initial risk assessment meeting, the RMT identifies which ongoing risk management activities are appropriate for the Project, and the Risk Owner or delegate will document those decisions within the Risk Log.


of 66 02/19/2016

Risk Resolution provides for responsive actions which either transfer a given risk to a third party or mitigate the probability of occurrence or financial impact. Typical resolution techniques include use of contractual agreements, expert judgment, and lessons learned on previous projects. Executing preventive actions involves an investment of finances and human capital to mitigate the threat of negative events to Project objectives. A resolution strategy or response action plan consists of a set of steps to achieve resolution. The risk owner records these steps in the risk log. The data collected is:

1. Sequence of actions to be taken. 2. Resources who take the actions. 3. Expected dates for the actions. 4. Contingency or escalation actions, if first actions fail. 5. Impact if the team does nothing to mitigate the risk. The impact should be quantified in

terms schedule, cost, resources, quality or any combination thereof. Risk Monitoring involves tracking the risk resolution progress, taking corrective action as appropriate, and identifying new risks during Project execution. To stay vigilant, the RMT also performs a risk re-assessment at the inception of each phase of the Project, recording newly discovered risks in the Risk Log.

Risk Analysis When a new risk is identified, it is added to the Risk Log and the RMT conducts a risk impact analysis to document the qualitative and quantitative values. The exhibit below displays the “Impact Value” across multiple areas.

Figure 9-3: Risk Impacts

Given risks are a forecast of potential issues, a probability value must be derived. The exhibit below provides the values for risk probability.


of 66 02/19/2016

Figure 9-4: Risk Probability

The product of the impact and probability values will generate a risk priority score to give a prioritization of the identified risks. These risk priority scores are recorded in the Risk Log. The exhibit below illustrates the derived calculations.

Figure 9-5: Risk Priority Score Calculation

The risk priority score aids in the depth of response planning and the frequency the risk monitoring receives. A Risk Owner is assigned responsibility for planning the risk response and managing the risk. The Risk Owner may update his/her assigned risk(s) on the Risk Log.

Risk Management Roles and Responsibilities Decisions and escalations for risk management are defined in Appendix 12 - Decision Management. The roles and responsibilities relating to Risk Management are presented in the below exhibit. Table9-6: Risk Management Role and Responsibilities


Requester (anyone) The risk originator is a team member or any stakeholder who

identifies risk to the PMO Risk Lead or a Track Lead

Completes ad submits the initial risk information

Track Lead

Responsible for ensuring that Project risks are addressed in a timely manner to avoid escalation to issues

Presents risks to the Risk Management Team

Calls and facilitates meetings of the Risk Management Team

Manages and facilitates risk mitigation acceptance and resolution

Maintains the Risk Log on a weekly basis—at a minimum

Provides content on the Risk section of Project status reports

May present Risk updates and facilitate risk-related discussions at Project staff meetings

Probability Rating Possibility of Occurrence

High = 5 > or = 50%

Low = 1 < 50%

Risk Probability


of 66 02/19/2016


Formulates and executes risk response plan

Main objective is to preclude “Risks” turning into “Issues”

PMO Risk Lead

Eliminates duplicate Risks as identified

Manages the process, mitigation plans, and reports progress for all identified “HIGH or Major IMPACT Risk”

This person has the same responsibilities as the Track Leads

Risk Management Team (Project Director, Track Leads or designees)

Approves risk response plans

Monitors risk mitigation plans

Approves closure of risk


of 66 02/19/2016

Appendix 10 - Communications Management

Overview of Communication Management Efficient and effective project communications management is critical to overall Project success. Both Project leadership and Project staff members benefit greatly from timely, accurate and predictable communications. Project communication management includes the generation, collection, storage, dissemination, and disposition of Project information. Good communication management ensures Project leadership and team members are kept in sync and progress of project activities are transparent to stakeholders. This will support stakeholder alignment to the Project goals, objectives, status, and upcoming events. Project status communication is focused on internal communications with Project sponsors, leadership, and stakeholders, managed by the PMO. The Organizational Change Management (OCM) Track will develop a change communications strategy to facilitate awareness and support among the Project’s external stakeholders. Open, on-going, and transparent communication between Project sponsors, Project staff members, and stakeholders is vital to the success of the Project. This strategy defines:

What needs to be communicated on the Project,

Who is responsible for communicating with what audience,

When the communication needs to take place, and

How information will be communicated. The scope of this process includes identifying the requirements for each communication type, the frequency of communication, the medium of communication, and the team member or members responsible for the communication.

Content and Event Map To gain a better appreciation for the ins and out of communication, it helps to understand what content is gathered and its relationship to a specific communication event. The exhibit below illustrates this relationship.


of 66 02/19/2016

Figure10-1: Communication Content and Event Map

The above illustration has two key communication elements. These are content categories and event frequencies. There are three identified event frequencies: Weekly, As Needed, and Monthly. There are two content categories identified Figure 1:

1. “KPMs and KPIs” consist of risks, issues, decisions, schedule, cost, quality, and organizational change management. These performance measures are listed and explained Appendix 1 – Performance Management.

2. Project “Key Support Elements” are lessons learned and action items.


of 66 02/19/2016

Project Communication Events The content of this process is strictly focused on communications within the Project staff and Project sponsorship. Communications will be developed by the Project staff and then flow to the target audience.

Communication Event/Type

Audience/ Stakeholders

Topic(s) Communication

Objective Medium

Event Frequency

Author/ Communicator

Track Status Report

Project Director

Track Leads

Tasks completed previous week

Tasks planned for next week

Listing of key Risks, Issues, Action Items, Lessons Learned, Changes requested

Keep Track Lead apprised of project status

Email and Meeting

Weekly Project State Staff or Contractor Staff

Project Status Report

Executive Sponsors

Project Sponsors

Track Leads

Designated DFS Division Staff

Project Staff

Tasks completed previous week

Tasks planned for next week

Listing of key Risks, Issues, Action Items, Lessons Learned, Changes requested

Keep Project leadership (sponsors and Track Leads) apprised of project status

Email Weekly Project Director

Project Monthly Report

Chair of Senate Committee on Appropriation and designated staff

Chair of the House

Milestones achieved to date

Upcoming milestones

Significant changes to plans

Required by proviso to report status and activities quarterly

Email and possibly Meeting

Monthly Project Director


of 66 02/19/2016




Objective Medium

Event Frequency


Appropriations Committee and designated staff

Executive Office of the Governor’s Office of Policy & Budget and designated staff

Agency for State Technology

Managers’ Meeting

Project Director

Track Leads

Updates from the Project Director

Status updates from Track Leads

Follow-up on outstanding action items

Integration and coordinate priorities across Tracks

Meeting Weekly Project Director

Change Control Board

Project Director

PMO Manager

Appropriate Track Lead(s)

Appropriate SMEs

Project Risk Lead

Review change requests that have been escalated to the Change Control Board in accordance with the Project Scope Change Request process

Evaluate requests for change that have been escalated to both Project Director and Change Control Board

Provides considerations information that will aid the Project

Meeting As Needed PMO Staff


of 66 02/19/2016




Objective Medium

Event Frequency


Director or Executive Sponsor to accept or reject the project scope change,

Project Risk Management Review

Risk Management Team (Project Director and Track Leads)

Review status progress on “Open Risks” items

Add “new” identified risks

Communicate mitigation plans and progress status

Monetize the risk impacts

Ensure there is a clear association between the identified risk and a project outcomes or contract deliverable

Establish clear close criteria

Meeting Monthly PMO Risk Lead

Track RIDAPL (Risks, Issues, Decisions, Action Items, Project Change and Lessons Learned) Review

PMO Manager

Add or Update Risks, Issues, Decisions, Action Items, Project Change and Lessons Learned (RIDAPL) status

Add “New” RIDAPL items

Change RIDAPL ownership, when applicable

Share RAIDL status across staff

Meeting Weekly Track Lead


of 66 02/19/2016




Objective Medium

Event Frequency


“Contractor” Quality of Service Evaluation (QSE) Progress Review

Project Director

Track Leads

State Contract Manager

Contractor Project Manager

Review results from Quality of Service Evaluations (QSE) surveys

Communicate progress on Corrective Action Plans associated with QSE.

Alignment expectations between State Of Florida and Contractors in terms of Quality of Service.

Meeting Monthly

Contractor Engagement or Quality Assurance Lead

Steering Committee Meeting

Steering Committee Members

Communicate project status, spend plan, and impacts

Brief and obtain direction from Project sponsorship

Meeting Monthly Project Director

Executive Sponsor Meeting

DFS Chief of Staff

Deputy CFO

Varies

Brief and obtain direction from executive sponsorship

Meeting Bi-Weekly Project Director

Team Meetings Track Lead

and team

Updates from the Track Lead

Status updates from team members

Follow-up on outstanding action items

Integration of activities within track

Meeting Daily or Weekly

Track Lead


of 66 02/19/2016




Objective Medium

Event Frequency


Sponsor Working Meetings

Project Sponsors and Track Leads

Varies

Group collaboration on a Strategy and Deliverables

Meeting As Needed Project Director

Four Week Look-Ahead Report

Project Director

Track Leads

List of tasks scheduled for completion within the next four weeks and the status of these tasks.

For PMO to provide the Project Director and Track Leads with status of activities scheduled for the next four weeks—according to the approved project schedule and for PMO to obtain status updates on near-term tasks

Email Weekly PMO Staff

Project Track Kickoff Meetings

Sponsors

Project staff

Key DFS Staff

Track Project Scope

Track Project Leadership and Team Members

Track Project Objectives, Approach, Timeline, Deliverables, and Guiding Principles

Define Stakeholder

Set expectations for the Project and stakeholder involvement

Meeting Per agreed to calendar event

Track Lead


of 66 02/19/2016




Objective Medium

Event Frequency


Roles & Responsibilities

Status Report to Agency for State Technology

Designated AST Project Manager

Milestones achieved to date

Upcoming milestones

Significant changes to plans

Provide documentation to support AST oversight responsibilities

Email and possibly Meeting

Monthly Project Director

Administrative Services Meeting

Agencies Administrative Services Directors

Project status updates

Provide status updates and upcoming expectations for stakeholder involvement

Meeting Monthly Project Director and BPS Manager

Chief Information Officers (CIOs) Council

Agencies CIOs

Project status updates

Provide status updates and upcoming expectations for stakeholder involvement

Meeting Monthly Project Director and SDS Manager


of 66 02/19/2016




Objective Medium

Event Frequency


Project Track/Phase Close-out Meeting

Sponsors

Project staff

Key DFS Staff

Express appreciation for their support during the Project

Conduct and record lessons learned

Closeout Track/Phase

Meeting Per agreed to calendar event

Project Director

Independent Verification and Validation Review

PMO Director

PMO Lead

Project Risk Lead

To Be Determined post IV&V contract award


Meeting


IV&V Contractor Lead


of 66 02/19/2016

Appendix 11 - Issue Management

Overview of Issue Management The purpose of Issue Management is to minimize the risk of not meeting the objectives of the Project due to unresolved problems that arise. The process involves the identification, evaluation, management, and resolution of issues.

Issue Management Definitions A Project issue is “any unresolved situation that most often negatively impact the Project.” Issues typically arise due to unplanned or unexpected events.

Issue Management Process The exhibit below communicates the issue management process. The exhibit depicts the process for identifying, assessing, managing and closing as well as the identification of the individual or team responsible for each process step.

Figure11-1: High-Level Issue Management Process

The first step in the process starts with the identification and submission of an issue by the requester. The requester contacts the appropriate Track Lead or PMO to discuss the concern. The requester must describe the issue and associated impact to the Project. Once identified, issues are evaluated and ranked by priority according to impact:

Critical = Work has or will come to (in next twenty-four hours) a complete standstill.

High = Impacts either cost, schedule, contract deliverable, contract payment or any combination thereof.

Low = All impacts not listed in the “High or Critical”.

Issue Resolution Strategy Issues must be managed to resolution. A resolution strategy consists of a set of steps to achieve resolution. The Issue owner (Track Lead or PMO) records these steps in the ‘Action Plan’ field of the Issue Log. The field must contain these components:


of 66 02/19/2016

1. Sequence of actions to be taken 2. Which resources take the actions 3. Expected dates for the actions 4. Contingency or escalation actions, if first actions fail

Issue Response Time If an issue is determined to be “Critical” by either the Track or PMO lead, the response time to publish and communicate the action plan is within 8 hours of the issue being identified. At a minimum, progress on the action plan will be communicated each day via email to designated stakeholders until resolved. The Project Director or Track Lead has authority to specify more frequent and different communication mechanisms (phone, in person, meetings) for “Critical Issues”.

Issue Monitor and Escalation Process

In the event an issues remains unresolved at a certain Issue Escalation Level, an escalation process is to be used. The issue escalation levels are shown in the following table:

Level Florida PALM Pre-DDI

1 CFO or designee

2 Steering Committee, Chaired by Executive Sponsor

3 Project Director

4 Project Track Lead

“High” priority Issues that cannot be resolved by the “agreed to due date”, the issue will be escalated to the next level in the governance structure. The Levels identified in the above exhibit will use the following escalation trigger timeframes when an issue is not resolved by the due date:

Level 4 to Level 3 – within 3 business days after due date

Level 3 to Level 2 - within 4 to 10 business days after due date for issues impacting schedule or cost

Level 2 to Level 1 - greater than 10 business days after due date for issues impacting cost

Issue Log The Project staff will utilize an Issue Log to document and track issues including steps for resolution. The issue resolution steps will focus on speedy closure of issues in order to maintain the Project schedule and quality of deliverables. The issue progress will be reviewed by the PMO at the Project and track level on a periodic basis.


of 66 02/19/2016

Appendix 12 - Decision Management

Overview of Decision Management Decision management, in the context of running the day-to-day operations of the project, is to establish and implement a defined structure that will improve the decision making process by using all available information to increase the precision, consistency and agility of decisions. Additionally, good decision making is about making good choices while considering risks and scope/schedule/budget constraints. Decision management should make use of tools such as business rules, business intelligence (BI), continuous improvement (kaizen), and predictive analytics. Project Governance and the associated decision making authority for this function is defined in the Project Governance Charter.

Decision Management Definitions Decisions will be made on regular basis (hourly, daily, weekly, etc.) that do not require the project staff to submit a request for decision. Decisions that require a formal process are ones that have these characteristics: 1. Impact to the project objectives or the functional/technical direction of the project. These

type of decisions require collaboration and agreement across multiple tracks and project sponsors.

2. Some decisions will impact cost, schedule, or quality. If this occurs, the decision will follow the decision management process to formally document it in the decision log. A project change request (PCR) shall be spawned or created as a result of the decision. These types of decisions and resulting PCRs will be escalated through the defined governance included in the Project Governance Charter and will follow the Project Scope and Change Management processed described in Appendix 8.

3. If the decision made does not impact cost and schedule, then it will be recorded exclusively in the project decision log.

Decision Management Process Anyone, i.e. “Requester”, can make a request for a decision by the decision authority. The decision is evaluated by the appropriate Track Lead to determine relevance and completeness of the request data. The first outcome in the process is to disposition whether the decision is to be managed by the Track lead (OCM, SDS, and BPS) or the PMO. If a decision impacts multiple tracks or requires a decision by the Executive Sponsor or Project Director, the PMO track will manage the decision process. When a decision is requested, it is recorded in the decision log. The decision process owner communicates status and decision outcome to the requester and individuals affected, and once resolved then closes the item in the decision log.

Project Decision Log The decision log will be used to capture questions that need to be answered and may have an impact on the Project’s scope, schedule, budget and/or quality depending on the answer. These questions will be recorded in the Decision Log and documented on the weekly status report, assuming they remain unanswered or open. Questions that have been answered (i.e., decision made) will be removed from the Status Report but retained on the Decision Log with the answer


of 66 02/19/2016

documented and a reference to who provided the answer so the information is available for future reference if needed.

Potential Law Changes Throughout the Project lifecycle, there may be impacts to current rules, and statute or the need for new laws. The Project’s responsibilities is to record and report the need for a law change. The policy owner is responsible for facilitating the review of the policy issue, identify potential law changes, and facilitating the law change request to closure. The Project Sponsors are responsible for reviewing policy issues and determining recommended solutions for a law change. The Project sponsors will act as the liaison with the state agencies, Executive Office of the Governor and the Legislature to ensure all policy issues are addressed and any potential law changes are processed to closure. The exhibit below is a graphical representation of the policy decision process involving law changes. The exhibit depicts the various steps that a policy issue will proceed through in the process as well as the identification of the individual or team responsible for the process step.

Figure12-4: Policy Decision Process


of 66 02/19/2016

Appendix 13 - Deliverable Management

Overview of Deliverable Management Deliverable management is a key process to Project success and will be integrated into the Project quality management approach. To achieve a positive outcome, this process needs to be carried out over the life of a Project to make sure that expectations are aligned and met. The exhibit below illustrates the high-level process for deliverable acceptance.

Figure 13-1: Deliverable Management

Project deliverables will be identified throughout the lifecycle of the Project. The way in which each deliverable is to be developed will vary depending on the type of deliverable to be completed. Deliverables that are defined as part of a contract will be routed through the assigned Contract Manager and the Track Lead. Deliverables will be developed using tools and techniques appropriate to their form. This may include the use of Microsoft Office software (for written or other hard-copy deliverables), Commercial of the Shelf (COTS) or custom software, or other tools. Each deliverable will be defined using a standard template that is approved during the Deliverable Expectations Document (DED) process.

Deliverable Management Definitions Deliverable - Any tangible outcome specified in the contract, statement or scope of work, strategy, or plan document. Deliverables are classified as artifacts, technology implementations, events or qualified and quantified benefits. Deliverable Schedule - A list of all deliverables identified in all contractual documents recorded and progress tracked in the “Master Project Schedule”. Deliverable Expectation Document (DED) - used to record a mutually agreed upon acceptance criteria in addition to or already communicated in the contract document(s). The DED also records the vendor’s general development approach to meeting the deliverable requirements. The deliverable acceptance criteria recorded in the DED must be clearly defined and absent of subjectivity and ambiguity wherever practical. The DED will identify the specifics criteria for acceptance, and any comments pertinent to further clarifying the criteria. Artifacts - Documents in any medium, electronic or hard copy, and MSOffice format such as Word, Excel, PowerPoint, Project, Visio, etc. Technology - Hardware or software tangibles. Events - Training, workshops, knowledge transfer, interviews, or surveys. Deliverable Quality Control (QC) - Defined and explained in Appendix 4 – Quality Management.


of 66 02/19/2016

Deliverable Creation, Review, and Approval Process To minimize surprises or delays during the deliverable review process, the Project staff should be involved throughout the deliverable development process. Sharing working drafts of deliverables in a collaborative manner throughout the creation process facilitates the identification of issues, differences of opinions, and misunderstandings. The exhibit below illustrates the deliverable development, review, and approval process.

Figure13-2: Deliverable Management Process

Deliverable Schedule Deliverables defined by a contract will be entered into a Deliverable Schedule, i.e. Project Master Schedule. The Deliverable Schedule records the progress of each deliverable including information such as reference number, deliverable name, scheduled submission date, actual submission date, deliverable approval date, and approver name.

Deliverable Expectation Document Once the Project Staff establishes agreed upon expectations and acceptance criteria, the Deliverable Owner will finalize the draft and submit the DED to the Contract Manager and/or Track Lead for review and approval. The approval will be captured in the Revision History of each DED.

Deliverable Quality Control The Quality Control process is explained in detail in the “Technical Quality Evaluations” section of Appendix 4 – Quality Management.

Deliverable Management Roles and Responsibilities The exhibit below describes the deliverable management roles and responsibilities for the process illustrated in the above exhibit.


of 66 02/19/2016

Table 13-3: Deliverable Management Responsibilities

Role Responsibility

Contract Manager/Track Lead

This person is designated by the Contract or Project Director

Tracks deliverable status

First step in hand off process between Contractor and State of Florida

Facilitates the approval process

Performs review of deliverable(s) to ensure they meet contract requirements and basic quality standards

Sends comments and a deliverable recommendation to Approvers and Deliverable Owners

Deliverable Owner

This is the primary owner of the deliverable

Monitors the review process

If the deliverable is a document, this person could also be the primary author

Completes initial criteria for Deliverable Feedback Form (if applicable) and submits with deliverable

Updates deliverable if comments are returned as a result of the review process

Identifies and notifies deliverable reviewers prior to deliverable submission date (applies to Track Lead only, if not contractual deliverable)

Contractor or Staff QA

Designated by the contractor firm or Project Director (if not related to contract)

Reviews deliverable(s) to ensure they meet contract requirements and quality standards

Ensure Deliverable has no “Severity 1 or 2” defects prior the first submission (Severity 1 and 2 are described in Appendix 4 – Quality Management).

Project Team

These are team staff members contributing to the solution and content of the deliverable

They are typically subject matter professionals

They can be assigned work to be completed for the deliverable

They can be assigned to be a reviewer

Approvers

Reviews deliverable to ensure compliance with contract and Project requirements

Recommends deliverable acceptance or rejection based on input from the Project team

Records comments/changes to deliverable or deliverable component

Coordinates with Project Sponsors to review major deliverables and includes sponsor comments as part of feedback (applies to Track Lead)

While the Project Director is responsible for accepting all deliverables, the Steering Committee members will be responsible for reviewing and providing feedback on key project deliverables

Project Director accepts or rejects the deliverable and communicate the disposition to the Contract Manager

Project Sponsors

Reviews and provides comments to Track Lead on specified deliverables


of 66 02/19/2016

Appendix 14 - Action Item Management

Overview of Action Item Management Disciplined management of Action Items enables a Project staff to effectively complete work in a timely manner in order to keep a Project on track. Action Item Management process provides the mechanism throughout the life cycle of the Project to bring action items to closure.

Action Item Management Definition Action item - An Action Item is a proactive task identified by the Project staff to address a specific need in order to provide an outcome that is not on the Project schedule or in other risks, issues, or decision logs. Action Items should not be extensions or child activities to risk, issues, decisions, and deliverable approvals. Action Items are unique needs created out of discussions that are recorded and need follow up.

Action Item Management Process The exhibit below shows the various stages of the Action Item management process.

Figure 14-4: Action Item Process

The first step in the process starts with the identification and submission of an action by the requester. The requester contacts the owner to discuss the need/outcome and gains agreement for ownership. The requester must describe the need or desired outcome and include any other information that could be helpful to whoever is assigned the action item to resolve. The owner will evaluate and formulate the plan to close the action item.

Action Item Log An Action Item Log will be utilized to document and track action items. The log serves the purpose of tracking progress to a specified due date, owners of the steps in the action plan, and aides in associating the action to a significant outcome. Updates to action items already captured in the Action Log can be made by Project staff members or named owners; and, the


of 66 02/19/2016

owner is responsible for maintenance of items in the Action Item Log. The action item progress will be reviewed by the PMO at the Project and track level on a periodic basis.

Roles and Responsibilities in the Action Item Management Process The following exhibit describes the Project staff’s roles and responsibilities for action items:

Table 14-2: Action Item Roles and Responsibilities


Requester

Identifying action items to be performed in support of a Project objective

Logging action items identified

Defining the outcome desired

Reviewing and approving action plan to ensure request as originally defined will be resolved

Owner

Participating in discussions with the Action Item requester to fully understand the need

Researching and drafting the Action steps to be executed

Driving the action items to resolution and closure

Ownership of Action Item Tracking Logs

Monitoring and management of assigned action items

Reviewing action items to prevent duplication


of 66 02/19/2016

Appendix 15 - Content Management

Overview of Content Management The Content Management process describes the documentation practices for this Project. Content Management includes document creation, document revision, version control, and retention. A standard process will be used for Project related documents; the standard will apply to the creation and management of documentation including minutes, notes, deliverables and other outputs for this phase of the Project. The goal of Content Management is to ensure quality consistency in Project documents. To support this goal, an internal SharePoint site has been created to manage and maintain working documents for this phase of the Project. PMO staff will maintain this site and grant users the ability to add and update folders, documents, and sites. SharePoint helps to organize large, complex information sources and manage documents with multiple authors and approvers. SharePoint provides for versioning, check-in and check-out to ensure that only one person works on a document at a time, controlled document access based on user roles.

Documentation Strategy To derive a content management strategy, it is important to identify all content that will we created and maintained on the Project. The below exhibits illustrate the type of artifacts and the relationship to each other that will be created for this Project.

Figure15-8: Document Strategy

The exhibit below communicates “What” and “Where” content is stored now and planned for the future.


of 66 02/19/2016

Figure15-2: Content Storage Technology Strategy

Saving and Distributing Documents Upon saving documents, prepare the document for distribution. Review the properties; under advanced properties, add the title, category, keywords, and verify the author name is correct. This will facilitate searches to find the document. If the document is a final document, mark as final, which will make the document read-only. Also, restrict permissions or encrypt where appropriate. For instructions on viewing or changing properties in an office document, go to http://office.microsoft.com/en-us/word-help/view-or-change-the-properties-for-an-office-document-HA010047524.aspx. As relevant Project documentation is gathered, documents will be stored on SharePoint following standards and processes defined in this process. SharePoint tutorials are posted on the main Project SharePoint page at the following link:

http://office.microsoft.com/en-us/word-help/view-or-change-the-properties-for-an-office-document-HA010047524.aspx

http://office.microsoft.com/en-us/word-help/view-or-change-the-properties-for-an-office-document-HA010047524.aspx


of 66 02/19/2016

http://dfsintranet.fldoi.gov/capitol/osp/pmoffice/FCR-PreDDI/SharePoint%20Resources/Forms/AllItems.aspx

Document Version Control Version control of documents will be managed by established SharePoint features. There will be no pre-determined limit set on the number of versions SharePoint will maintain. For larger more complex documents, Project staff will break the documents into smaller more manageable components. These smaller components will be merged later to form the complete document.

Website Content Management The Florida PALM Project has an external facing website at: http://www.myfloridacfo.com/floridapalm/default.htm. The site contains information such as important meetings, links to Project related procurements, reference sites, and contact information.

Figure 15-3: Website Content Management Process

The PMO manages the content and any changes to the Project website. If a change is needed on the site, the requester would make the suggestion to the PMO for consideration/implementation. The PMO will work with the Project Director and Track Leads during the process to ensure all tracks are aware of the changes. In addition, the OCM group will assist in ensuring the website obtains the desired level of effective communication. The Exhibit below illustrates the Website Content Management process.

PMO Notified of Potential Website

Change

PMO Works with OCM to Finalize

Change

Review Process Including Project Director Approval

Website Content Manager

Implements Change on Website



http://www.myfloridacfo.com/floridapalm/default.htm


of 66 02/19/2016

Appendix 16 - Lessons Learned Management

Overview of Lessons Learned Management A lesson learned is useful information gained through experience that an organization should retain for future use and that can be relevant to other organizations or this Project in future phases. Depending on the lesson, it could be a valuable technique or an outcome that we wish to repeat or it could be an undesirable result we wish to avoid. Often, identifying our lessons learned is as simple as asking the question, “What worked well or what didn’t work so well?”

Categories of Lessons Learned

Lessons learned will be organized and captured for sorting by “strength” or “improvement”. Lessons learned should be:

Something learned from experience,

An adverse experience that is captured and shared to avoid a recurrence,

An innovative approach that is captured and shared to promote repeat application, or

The knowledge acquired from an innovation or an adverse experience that leads to a process improvement.

Importance of Lessons Learned Ultimately, lessons learned are a matter of improving the productivity and efficiency of a process. Individuals or teams can benefit from the knowledge gained through the experience of those who have gone before them. Many organizations that label themselves as “learning organizations” often overlook their own experiences as a platform for learning. They assume their collective experiences are passed along to the next person or group. To be considered a learning organization we must be proactive, capture lessons learned, and “cross-pollinate” the concepts through training or other techniques that expose the information to others who may benefit from it. The application of lessons learned helps produce Project teams, which operate with less risk of failure, increased efficiency, and more awareness of their surroundings.

Attributes of Lessons Learned Documenting a useful lesson-learned requires a clear understanding of the purpose and importance of documenting the successes and/or failures of a Project. Because lessons learned serve as an important management tool in retaining organizational knowledge, reducing Project risk, and improving Project performance, they must have relevance to future Projects. To build relevance into your lesson-learned and make them of value to others in addressing similar situations, you must:

Identify the process or element in which the situation arose,

Describe how the situation arose and define the problem or positive development encountered, and,

Provide concrete, practical solutions or recommendations based on this experience.


of 66 02/19/2016

In order to be easily accessible and beneficial across the Project, lessons learned should have the same look and feel. Just as it is important that managers have a common understanding of the practices and terminology employed in their profession, it is equally important the lessons learned they contribute be presented in a manner that is easily understood by their peers.

Lessons Learned Management Process The below exhibits will be used guiding the lessons learned process for the Project.

Figure 16-1: Lessons Learned Process

At the conclusion of each contract, the Track Lead will initiate a lessons learned session including the PMO/Contract manager, the Contract Manager, and the state staff involved in the contract. A formal Lessons Learned session will be conducted with the Steering Committee and key Stakeholders prior to the Pre-DDI phase of the Project closing. The Lessons Learned session will be facilitated by the PMO Manager, and the results of the session will be documented and submitted as a Project work product to close the Lessons Learned process.

Lessons Learned Log A Lessons Learned Log will be utilized to document lessons learned. Participants in the lessons learned sessions should identify elements such as the business areas/function, point of contact, Project track, Project phase, situation, resolution and any information that can be used to avoid or improve the process in the future.

Roles and Responsibilities for Lessons Learned The first step in creating a process is defining how the process should work. The following exhibit describes the Project staff’s roles and responsibilities.


of 66 02/19/2016

Table 2: Lessons Learned Roles and Responsibilities


Identifier Identify a Lesson Learned worthy of sharing and documenting

Creates content for Lessons Learned Log

Track Lead(s)

Participating in discussions with the to fully understand the need

Facilitate a meaningful resolution/solution description

Approves the content for publication and sharing

Shares the information with other Project staff members

Utilizes the information to avoid duplication of issue in future work


of 66 02/19/2016

References DFS Agency Policy and Procedure # 2-02 (Purchase of Commodities/Contractual Services) DFS Contract Management Life Cycle Guide DFS Recruitment and Selection Forms Florida PALM BPS Strategic Plan Florida PALM Collaboration Strategy Florida PALM FFMIS Pre-DDI Engagement Strategy Florida PALM Staff Guidelines Project Charter for Florida PALM Project Governance Charter


of 66 02/19/2016

Project Approvals The signatures of the people below indicate their agreement with this document. Electronic approval _________________________________________________________________________ Robert Kneip, Chief of Staff Date Electronical approval _________________________________________________________________________ Paul Whitfield, Deputy CFO - Operations Date Electronical approval _________________________________________________________________________ Charles Ghini, CIO Date Electronical approval _________________________________________________________________________ Christina Smith, Director of Accounting and Auditing Date Electronical approval _________________________________________________________________________ Bert Wilkerson, Director of Treasury Date Electronical approval _________________________________________________________________________ Melissa Turner, Project Director Date