Florida PALM Pre DDI Project Management Plan

Pre-Design, Development
and Implementation (DDI)

Project Management Plan
(PMP)
Department of Financial Services

Date: 11/09/2017
Revision: 4.0
Pre-DDI Project Management Plan
Revision History
Version Date Author Revision Notes
Draft 12/02/2014 Terry Owen Original draft
Draft 03/5/2015 Danielle Kosberg, Updates to original draft
Brendan Jones
Draft 04/9/2015 Melissa Turner, Danielle Updates to revise draft in preparation for
Kosberg, Brendan Jones 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 Updates made as a result of review
Kosberg
1 07/06/2015 Paul Whitfield, Charles Updates made as a result of sponsor review
Ghini, Christina Smith,
Bert Wilkerson, Melissa
Turner, Danielle Kosberg
Draft 10/19/2015 Phil Harman and Melissa Identify edits for Governance Charter and
2.0 Turner subset of items identified on Florida PALM
“consideration log”
Draft 11/04/2015 Melissa Turner Updates made as a result of internal Project
2.0 Team review
Draft 11/10/2015 Sean Cooley and Melissa Updates made for Style Guide
2.0 Turner
2.0 11/20/2015 Paul Whitfield, Charles Updates made as a result of schedule
Ghini, Christina Smith, management changes and sponsor review
Bert Wilkerson, Melissa
Turner, Danielle Kosberg
2.1 02/19/2016 Melissa Turner Updates based on discussions with House
2.2 07/29/2016 Maryanne Marchese FY 15/16 Q4 Updates
2.3 10/07/2016 Maryanne Marchese FY 16/17 Q1 Updates – PMP Consolidation;
integrated Standards and Procedures
3.0 06/01/2017 David Gilmore, Danielle Completion of PMP Operationalization
Kosberg Phase 3 (I-PMO3)
4.0 11/09/2017 Phil Harman, Jonathan FY 16/17 Q4 Updates based on
LeBeaud, David Gilmore consideration log items and consolidation of
Quality Control checklists
Page 2 of 138 11/09/2017

Table of Contents
1 Document Overview......................................................................................................... 4
2 Purpose ........................................................................................................................... 4
3 Document Scope ............................................................................................................. 4
4 Out of Scope .................................................................................................................... 5
5 Assumptions .................................................................................................................... 5
6 Project Life Cycle ............................................................................................................. 5
7 Roles and Responsibilities ............................................................................................... 7
8 Performance Management............................................................................................... 8
9 Cost Management...........................................................................................................15
10 Schedule Management ...................................................................................................23
11 Quality Management .......................................................................................................36
12 Procurement Management..............................................................................................44
13 Staffing Management ......................................................................................................51
14 Collaboration Management .............................................................................................56
15 Project Scope and Change Management........................................................................61
16 Risk Management ...........................................................................................................65
17 Communication Management .........................................................................................71
18 Issue Management .........................................................................................................89
19 Decision Management ....................................................................................................93
20 Deliverable Management ................................................................................................97
21 Action Item Management ..............................................................................................105
22 Content Management ...................................................................................................108
23 Lessons Learned Management .....................................................................................123
24 Appendix A: Project Talking Points ...............................................................................127
25 Appendix B: Deliverable Expectations Document (DED) Template ...............................130
26 Appendix C: Deliverable Review Form ..........................................................................131
27 Appendix D: Deliverable Acceptance Form ...................................................................132
28 Appendix E: Master Quality Control Checklist ...............................................................133
29 Appendix F: Definitions .................................................................................................134
Page 3 of 138 11/09/2017

1 Document Overview
The Florida PALM Project (Project) will ensure it meets its cost, schedule, scope, and quality
objectives by employing a set of defined and repeatable project management processes. The
Project Management Plan (PMP) details the processes to be used during the Project’s Pre-
Design, Development and Implementation (Pre-DDI) phase for all work identified in the Project
Charter and supporting Strategies, Plans, Contracts, and Scope documents. Compliance with
these repeatable processes will help expedite the successful, on-time completion of the work.
2 Purpose
The purpose of this document is to establish and communicate project management
standards and procedures to be adhered to by the Project Team to effectively deliver the
Project’s lifecycle stages.
3 Document Scope
This document communicates the complete lifecycle of project management as it relates to
delivery of the Florida PALM Pre-DDI phase including the purpose, scope, and process for the
following project management processes:
1. Performance
2. Cost
3. Schedule
4. Quality
5. Procurement
6. Staffing
7. Collaboration
8. Project Scope and Change
9. Risk
10. Communication
11. Issue
12. Decision
13. Deliverable
14. Action Item
15. Content
16. Lessons Learned
3.1 Who Should Use This Document?

Project Team Members should use this document for guidance on Project standards and
procedures associated with the above identified Project Management processes across all work
completed by the various Project Tracks.
3.2 Interdependence and Related Documents

This document shall be used in conjunction with the following Project documents to govern and
manage the Project.
Page 4 of 138 11/09/2017

• The Project 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
o Organizational Change Management Support Services Contract
o System and Data Strategy Support Services Contracts
3.3 Distribution of Document

This document shall be distributed to Project Team Members, the Executive Steering Committee
(ESC), 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
Project Management Office (PMO) Manager.
4 Out of Scope
This document does not include 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.
5 Assumptions
To fully understand this document, the reader has a general working knowledge of the project
management processes and has read and understands the Project Management Body of
Knowledge (PMBOK). Updates to the Project Management Plan (after initial approval) will follow
the processes defined in the Project Scope and Change Management section.
6 Project Life Cycle

Traditionally, project management includes several elements, four to five stages, 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 determines the nature and scope of the Project. This stage is
complete for the Project. The Project has multiple Tracks staffed to simultaneously support the
Project across the four critical dimensions: people, process, technology, and project
management. The Project’s Pre-DDI Tracks are listed below:
Page 5 of 138 11/09/2017

1. BPS – Business Process Standardization – responsible for business process

standardization activities and creating functional requirements for the new Enterprise
Resource Planning (ERP) system.
2. OCM – Organizational Change Management – responsible for developing and executing
change management strategies (the people-side of change) in preparation for the new
ERP.
3. SDS – Systems and Data Strategy - responsible for developing and executing technical
strategies in preparation for the new ERP.
4. PMO – Project Management Office - responsible for developing and executing project
management strategies for all Project phases. The PMO will also be responsible for the
procurement activities for the new ERP and Software and System Integrator (SSI).
.
The majority of the content in this document is focused on what the Project’s approach is to fulfill
the executing, monitoring, and controlling stages to successfully execute and deliver the Pre-
DDI outcomes defined in the approved scope and strategy documents.
After the execution stage, the Project’s Pre-DDI phase will be closed. 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:
Archive Finalize
Project Contract
Project Work Lessons
Signoff Closeout
products Learned
Figure 1: Project Closeout Components
6.1 Archive Project

Significant documentation will be developed over the course of the Project. Project work
products, which are defined as Project Management documents, Project deliverables,
supporting documents and data, interview notes, etc., needs to be organized and archived for
future reference and use.
Project Team Members will place Project work products on the dedicated Project SharePoint
site in adherence with the prescribed file structure. Each Track or Contract Manager is
responsible for establishing a final PDF version of the accepted or approved deliverable and
storing it in SharePoint. These documents provide historical knowledge and will be critical to
answering future questions that arise.
6.2 Finalize Lessons Learned

Over the course of the Project, the Project Team will identify areas for improvement as well as
strong practices that should be propagated in the future. Lessons Learned will be documented
in the Lessons Learned Log as they are identified. See additional information in the Lessons
Learned Management section.
Page 6 of 138 11/09/2017

6.3 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.
6.4 Contract Close Out

Contract Managers have the responsibility to complete the Contract Close Out Checklist and
Contractor Evaluation Form identified in the DFS Contract Management Lifecycle Guide, at the
conclusion of the assigned contracts.
7 Roles and Responsibilities

The roles and responsibilities for each Project Management Process are presented in a RACIV
responsibility matrix where:
• Responsible – Project Team Member is responsible for completion of the action

• Accepting – Project Team Member is responsible for accepting the action
• Consulted – Project Team Member(s) that are consulted during the action
• Informed – Project Team Member(s) who are informed of the progress, completion, or
information generated from the action
• Verify – Project Team Member is responsible for verifying the action was completed
according to the strategy or plan
Note: The Project Director has the authority, per the Project Charter, to delegate assigned
responsibilities to the Deputy Project Director, or others as needed.
Page 7 of 138 11/09/2017

8 Performance Management
8.1 Overview
Performance Management describes the measures that will be used to measure the performance
of the Florida PALM Project (Project) as well as the processes by which they will be collected and
reported. Adherence to these Procedures is the responsibility of designated members of the
Project Team.
Performance Management identifies a standard set of measures for the Project and provide clear
guidance to Project Team members in recording, tracking, and reporting measures across the
Project. The Performance Management Measures efficiently, effectively, and consistently
measure and report the performance of the Project to all stakeholders.
8.2 Purpose
The purpose of Performance Management is to clearly define measures which can be used to
measure the Project, to describe how these measures can be effectively communicated to the
appropriate parties, and to implement processes for measure collection and management.
The Performance Measures specifically identified within this document are those which provide
insight into the overall performance of the Project. Individual work streams are likely to use and
track additional measures to manage their day-to-day activities.
Performance Measures are evaluated elements that indicate whether the Project is likely to reach
its intended outcomes and identify an activity’s efficiency and/or effectiveness. These measures
should be measurable (quantifiable and qualitative) and tracked over time, to see trending.
8.3 Determination of Measures

The Project Team followed a multi-step process to determine the most appropriate measures to
use for measuring the performance of the Project. The process included the following activities:
1. Identification of a broad list of potential measures with input which included:

a. The Project metrics outlined in version 1.0 of the PMP
b. The analysis of the Project metrics outlined within the PMP performed as part of
the initial Independent Verification and Validation (IV&V) assessment
c. Measures being captured or recommended by the Agency for State Technology
(AST)
d. Project Measures and best practice based reporting processes and formats from
other similarly sized, successful projects as identified by the participants during
creation of this document
2. Grouping the Project Measures into categories based on the processes described in the
PMP (e.g., cost, schedule, risks and issues, etc.)
3. Removal of duplicate measures and those that could not be tied to a value driving question
4. Removal of supporting and secondary measures which might be tracked by individual
Project Tracks, but do not provide a clear indicator of Project-wide performance
5. Determination of the appropriate timing to begin tracking the measure based on the value
provided by the measure compared to the effort to collect the data
Page 8 of 138 11/09/2017

Note: The “Pre-DDI Metric History’ tab on the Pre-DDI Performance Measure workbook, located
in SharePoint, contains a history and full disposition of each metric considered as part of the
development process.
8.4 Performance Measures

The “Project Performance Measures” spreadsheet, located in SharePoint, contains a listing of
each individual performance measure along with additional information about each measure
including the data source, and process to generate each metric.
Each measure will be given a colored status indicator that gives an indication as to whether the
measures status is positive or negative. The Project will use the following colors and definitions
for its status indicators:
• Green. The Project performance area is on track without material issues.
• Yellow. The Project performance area faces a challenge or set of challenges that could,
if left unmanaged, negatively impact the Project’s outcome. The Project Team should
prioritize corrective action.
• Red. The Project performance area faces a challenge or set of challenges that threatens
its outcome. The Project Team should take corrective action immediately.
Page 9 of 138 11/09/2017

Table 1: Project Performance Measures
ID Assessment Criteria Ref Measure Name Measure Calculation Status Indicators

CPI as calculated by MS Project G = .925 – 1.075
Cost Performance Index
1 Cost C-1 using the current proxy resource Y = .85 - .924 or 1.076 – 1.15
(CPI)
value approach R = < .85 or >1.15
G = -.25 – .05
Project Spend Plan (YTD Spend - YTD Forecast) / YTD
2 Cost C-2 Y = .06 to .15 or under -.25
Variance (SPV) Forecast
R = >.15
G = .95 to 1.1
Schedule Performance
3 Schedule S-1 SPI calculated via MS Project Y = .89 to .95 or over 1.1
Index (SPI)
R = Less than .88
G = <5%
Schedule Variance
4 Schedule S-2 SV% as calculated from MS Project Y = >5% and <=11%
Percentage
R = Greater than 11%
G = 0 or 1
Risks Transitioned into Number of risks transitioned into
5 Risk R-1 Y = 1 or 2
Issues issues during the measured period
R = Greater than 3
G = <20 business days before
mitigation / monitoring plan is defined
Average age in business days of Y = > 20 or <=30 business days
Under Evaluation Risk
6 Risk R-2 each risk in the 'under evaluation' before mitigation / monitoring plan is
Aging
status defined
R = > 30 business days before
mitigation / monitoring plan is defined
G=0
Number of open issues past their Y = <=2 impacting Project critical path
7 Issue I-1 Overdue Issues
due date and <5 total open issues
R = >=5
G=0
Number of past due issues not
Issues Not Resolved Y = <=2 impacting Project critical path
8 Issue I-2 addressed within the standard
within Escalation and <5 total open issues
escalation process.
R = >=5
Page 10 of 138 11/09/2017


G = No Scope Change request, or
Processed Scope CR(s)s move, add,
Any Scope Related Change
or remove work, but do not have a
Requests open during the period
material impact on the completion of
which:
the Project’s Charter or critical path
1) Increase Scope (add deliverable
during the current funding period
or complexity);
Y = Processed Scope CR(s) move,
9 Scope SC-1 Scope Change Requests 2) Reduce Scope (activity, content,
add, or remove work, with an impact
or complexity);
on the critical path during the current
Or 3) Change Schedule past current
funding period, but not the Project’s
funding period (which pushes an
Charter
activity out past the end of the
R = Processed Scope CR(s) has a
current funding period)
material impact on the completion of
the Project’s Charter
G = <=5 days
Average number of days past the
10 Scope SC-2 Change Request Aging Y = >5 and <=10 days
due date for each overdue CR
R = >10 days
G = <=5 days
Average number of days past the
11 Governance G-1 Decision Aging Y = >5 and <=10 days
due date for each overdue Decision
R = >10 days
G = 0 or 1 contractor below 100%
service quality rating for one month
Y = More than one contractor with a
rating below 100% for one month, or
Number of vendors with a score
Contractor Service at least on contractor with a rating
12 Quality Q-1 below 100% from evaluations
Quality below 100% for multiple months.
performed in the current period
R = At least one contractor with a
rating below 100% for 3 or more
consecutive months with no positive
trend
Page 11 of 138 11/09/2017


G = 0 – 1 deliverables reviewed
during the period that have a severity
1 quality deficiency (pre or post
submission) and none have more
than Severity 1 defect
Number of deliverables reviewed
Y = 2 of the reviewed during the
Technical Deliverable during the period which failed the
13 Quality Q-2 period have one or more severity 1
Quality submission QC review or had a
quality deficiency (pre or post
severity 1 defect
submission) or one has more than
one Severity 1 defect
R = More than 2 of the deliverables
reviewed during the period have one
or more than 1 Severity 1 defect
G = 95% of planned positions staffed
per the staffing plan
Y = Between 85% and 95% of
Percentage of planned staff engaged
14 Resource ST-1 Project Staffing planned positions staffed per the
during the period
staffing plan
R = Below 85% of planned positions
staffed per the staffing plan
Page 12 of 138 11/09/2017

8.5 Process
This section contains the process used to define the collection, measurement, and reporting of
each measure and the details for monitoring and reporting each. Measures collection and
management consists of several steps that must be carried out by the Project Team, including:
1. Gather and Maintain Data and Draft Reports

2. Review Reports
3. Manage Quality
The PMO Manager has overall responsibility for this process, supported by the Project Team
members responsible for managing the measured functions. See the Roles and Responsibilities
section below for additional detail.
Gather and Maintain Data and Draft Reports

The designated individuals will be responsible for gathering data or compiling reports for each
individual area. Gathering data will require connecting to a source system (e.g. a spreadsheet or
SharePoint listing), extracting information from it, and compiling the data into the format specified
for the individual measure.
Given the set of tools available to the Project today, extracting information from source systems
will typically require manually copying information from the source system into a spreadsheet or
report template. As the Project develops, it may be beneficial to identify and implement additional
tools or templates to support Performance Management.
Collection and Timing

The Project performance measures currently identified are all collected monthly. The
Performance Measures will be collected and entered into the Project Performance Measures
spreadsheet on SharePoint during the first two weeks of the month.
Monthly Monitoring
The PMO will compile the Project performance measures. The PMO Manager will review them
with the Track Managers monthly to monitor trends, identify areas of concern, and prioritize
corrective action if needed.
Project Oversight Analysis Executive Summary Report (I-PMO7)

The Project will use the data collected for each measure to provide the primary evaluation of the
Project’s performance in each of the categories reported in the Project Oversight Analysis
Executive Summary Report. The Project will use the status indicators defined in the table above
to report on each Assessment Criteria. Where there is more than one measure for an assessment
Criteria, the Criteria will be given the ‘lowest’ score of the supporting measures.
Review Reports
The primary person responsible for reviewing initial Project performance data is the PMO
Manager, however they will be supported in this effort by the Track Managers or designated
individuals for each Project function as appropriate. If the PMO Manager identifies a measure that
appears out of the ordinary, the PMO Manager will review with the Track Manager or other Project
team member to determine if escalation or action is needed.
Page 13 of 138 11/09/2017

Manage Quality
A final activity associated with the measures collection and management process is a quality
review. On a regular basis, the Project’s Quality Manager will review the process for creating each
measure to ensure its accuracy and completeness. This is especially important for this Project as
the number of manual processes required to gather data and create reports 37
result in a higher than average number of errors when gathering data and compiling reports.
8.6 Roles and Responsibilities

The Performance Management roles and responsibilities are described below. This information
is presented in a RACIV (Responsible, Acceptor, Consulted, Informed, or Verify) responsibility-
matrix format, as defined in Section 7 of this document. The table below depicts the RACIV role
and responsibilities during each of the three (3) major areas of the Performance Management
Process as shown in the figure below.
1
2 3
Gather and Maintain Review Reports Manage Quality
Data / Draft Reports
Figure 2: Major Areas of the Performance Management Process
Table 2: Performance Management Roles and Responsibilities

Role Responsibilities 1 2 3
Responsible for the overall execution of the Project I A I/A
Project Director
and accepts Project measures
Responsible for developing and confirming the A* C I
measures with input from each data owner and
PMO Track Manager
oversees the collection and reporting of the
measures
Responsible for collection of monthly measures and R R C
populating in the Pre-DDI Performance Measures
PMO Support
Spreadsheet and the Oversight Analysis Executive
Summary Report
Responsible for gathering and maintaining data for R I C
an area of focus and transmitting to PMO Support
Data Owner*
as needed. (e.g. maintaining the Project’s spend
plan from which costing measures are extracted)
Responsible for overseeing the quality and integrity C* V R
Quality Manager
of the data collection and reporting process
*Note: Different Project Team members will have responsibility for different areas of the measures. Also,
the PMO Track Manager and Quality Manager may have responsibilities as a data owner in addition to their
other roles.
Page 14 of 138 11/09/2017

9 Cost Management
9.1 Overview
Cost Management establishes the procedures for efficiently controlling costs for the Project to be
completed within the approved budget. Cost Management includes the estimation and
management of funds for resources such as staff, equipment, hardware, software, facilities, and
expenses needed to complete Project activities. It also considers the effect of Project changes
and decisions that would impact the cost of completing the Project.
9.2 Purpose
The purpose of these procedures is to provide instructions to the PMO and other Project Team
Members regarding Cost Management and associated activities. Cost Management is used to
ensure the Project will be completed within the approved budget. This includes management of
a Spend Plan which contains planned, incurred, and actual expenditures within the appropriated
budget categories. Additionally, these procedures will detail the Cost Management processes to
be used for planning, monitoring, tracking, posting, and reporting on expenditures and cost.
9.3 Process
The Cost Management process is inclusive of three (3) major areas: Yearly, Releases, and
Monthly.
Yearly
The Cost Management Yearly Process Flow explains how the Project receives and is
appropriated funding.
Projection
The process begins with the Project projection of resources and costs for the upcoming fiscal
year. Ideally, projections would be based on historical data. Projections should include current
costs, costs for upcoming activities, and contractual obligations for future FY’s. The projections
are provided to the Department of Financial Services (DFS) Budget Office for inclusion into the
annual Legislative Budget Request (LBR).
Legislative Budget Request

Section 216.03, Florida Statute (F.S.) requires all state agencies to submit a LBR no later than
October 15 of each year. Therefore, DFS, on behalf of the Project, requests funds based on the
Project’s projections for the upcoming fiscal year in its annual LBR submission. Section 3(b) of
the Constitution of the State of Florida requires that a Regular Legislative Session (Session) be
held each year to consider the LBR’s submitted by each agency. The LBR will be provided to the
Executive Steering Committee (ESC) for review.
Recommendations
The Executive Office of the Governor (EOG) makes recommendations for funding based on each
agency’s LBR. The Florida House of Representatives, and the Florida Senate Appropriations
Subcommittees release proposed bills, and make recommendations independently of each other,
on what they believe should be funded. Once their recommendations are released, the Florida
House of Representatives and the Florida Senate work to pass bills and develop proposed
funding for the State of Florida. Upon agreement of the proposed funding, and proviso language,
the bill is entitled the General Appropriations Act. The Florida House of Representatives and
Florida Senate submit the General Appropriations Act to the Governor of Florida for approval or
Page 15 of 138 11/09/2017

veto. The Project Director and Budget Specialist track bills and proviso throughout Session. The
Project may be requested to give information, and/or answer questions about its LBR.
Appropriations
Once the Governor of Florida approves and signs the General Appropriations Act, it becomes the
official Budget for the State of Florida and is put into law. It becomes effective July 1 of each FY.
The Office of Policy and Budget (OPB) distributes appropriations for each agency, and the funds
are either released or put into reserve, based upon what is specified in the Budget. After the
appropriations are made, the Project drafts the annual Spend Plan (using the Project template)
based on the appropriations it receives and provides to DFS Budget for review. The figure below,
Cost Management Process – Yearly Flow, illustrates the LBR, Recommendations, and
Appropriations process.
Page 16 of 138 11/09/2017

Submit Evaluate Execute Close

Budget
Office
Submit LBR (no

DFS
Process Review Annual

later than October
Starts Spend Plan
15 of each year)
Project Budget
Specialist
Project needs for Respond to

Develop LBR
upcoming FY inquiries
Draft Annual
Spend Plan (By
Category)
Director
Project
Committee
Executive
Steering
Review LBR
House Releases
Executive Office of the
Proposed Funds released

Committee Bill
Governor (EOG)
(PCB) Annual
Legislature/
Conference Process
EOG Releases Appropriation
Review/Approval Ends
Governor’s Recs Made
Senate Releases Funds put into
Senate Proposed Reserve
Bill (SPB)
Figure 3: Yearly Process Flow
Page 17 of 138 11/09/2017

Releases
At the beginning of the FY, the Project receives an initial release of funds. The Budget may contain
proviso language that either releases funds or puts funds into reserve for the Project. If releases
are in proviso language, the proviso will specify the information and/or action needed to have the
funds pulled out of reserve and released.
Budget Amendment
The Project follows proviso language in coordination with the Executive Steering Committee, if
appropriate, and performs the action(s) specified. Upon completion of the action(s) specified, the
DFS Budget Office submits a Budget Amendment, on behalf of the Project. The Budget
Amendment requests the release of funds, specifying how it has met proviso. The OPB receives
the Budget Amendment and reviews with the House of Representatives, and the Florida Senate.
If additional information is requested, the Project works to provide that information. Once the
Budget Amendment has been accepted, it is put in consultation for review and approval. The
duration of consultation is dependent upon several factors such as the amount, and what the
budget amendment request is for.
Release
Once the Budget Amendment has been approved, the funds are released to the Project. The
Project reflects the release in the Spend Plan, per the date found in the Master Project Schedule.
The figure below, Cost Management Process - Release Flow, explains how the Project works to
request and receive release of appropriations, beyond initial release.
Page 18 of 138 11/09/2017


Budget
Office
DFS
Submit Budget Amendment

With Action To Request
Release of Funds
Requests
Information/
Changes
& Budget (OPB)
Office of Policy
Legislature/
No
No Release Funds Process Ends
Yes
OPB Puts Budget
Review Budget Is Budget Amendment on Is Budget
Amendment Amendment Yes Consultation for 14 Amendment
Request Accepted? Days Before Approved?
Approval
Specialist
Budget
Project
Record to Spend
Plan
Director
Project
Process Take Action

Starts Take Action
According to According to
Proviso (with ESC Request
support)
Committee
Executive
Steering
Figure 4: Release Process Flow
Page 19 of 138 11/09/2017

Monthly
Spend Plan
Once the annual Spend Plan is completed, baselined, and approved by the Project Director,
projected, incurred, and actual expenditures are monitored, tracked, and posted to the Spend
Plan. Historical projections do not change. Future projections do not change unless an event
occurs that requires the Spend Plan to be re-baselined.
Reconciliation
On the 1st of every month, a reconciliation between the Project Spend Plan, and FLAIR begins.
Using FLAIR reports, the Project Budget Specialist reviews expenditures, checks for coding
accuracy, and amount accuracy. Additionally, if there are any expenditures not logged in the
Spend Plan, those expenditures are then added to the Spend Plan. The totals on the Spend Plan
are checked against the Appropriations Ledger Report to ensure accuracy. If the totals aren’t
accurate, the reconciliation process begins again. Upon confirming accuracy, the Budget
Specialist will use the checklist below as a guide for final review. After final review, the Spend
Plan is submitted to the Project Director for approval. Upon approval the Spend Plan is provided
to the Project Management Office (PMO) for the Project Monthly Status Reports. The Project
meets with the DFS Budget Office staff throughout the FY as needed.
Table 3: Spend Plan Reconciliation Checklist

# Spend Plan Reconciliation Checklist
1 Ensure all expenditures are accurately recorded in the Details tab
2 Ensure all actions are accurately recorded in the Details tab
3 Ensure that the Spend Plan Total matches the Appropriation Ledger Total
4 Ensure that the Monthly Summary tab matches the Details tab
5 Ensure all formulas are updated and calculating correctly
6 Ensure that the Project is staying within its budget appropriations for each category.
Monitoring/Updating
The Spend Plan is monitored on a continuous basis. If an event occurs, it is evaluated to
determine if there impact to the Spend Plan. If it is determined that the event has impact to the
Spend Plan, the event is reflected in the Spend Plan. Events include but are not limited to:
• Purchases (P-Card)
• Purchase Orders (MFMP/P-Card)
• Contract Execution
• Contract Change Order
• Project Change Request (PCR)
• Deliverable accepted and incurred
• Deliverable invoice is paid
The figure below, Cost Management Process - Monthly Flow, illustrates how the Project
reconciles the Spend Plan to FLAIR each month.
Page 20 of 138 11/09/2017

Process Correct Coding

Starts
No
Post Any
Budget Specialist
Begin Monitor Additional Print to PDF

Is Coding Do Reports Review spend
Reconciliation Expenditures/ Yes Actual Yes and Provide to
Correct? Match? plan
At The1st of the Events Expenditures to PMO for Process Ends
Month Spend Plan Monthly Status
Report
Run FLAIR
Reports
Compare
Totals to
No
Update Spend Review Appropriation
Plan Expenditures Ledger Report
Request
Ensure All Tab
Appropriation
Totals Tie Back
Ledger Report
Annual Spend
Plan Drafted
(By Category)
Director
Project
Review
Updated Spend
Plan
DFS Budget
Office
Provide
Appropriation
Ledger Report
Figure 5: Monthly Process Flow
Page 21 of 138 11/09/2017


The Cost Management roles and responsibilities are described below. This information is
presented in a RACIV (Responsible, Acceptor, Consulted, Informed, or Verify) responsibility-
and responsibilities during each of the three (3) major areas of the Cost Management Process as
shown in the figure below.
1 2 3
Yearly Releases Monthly
Figure 6: Major Areas of the Cost Management Process
Table 4: Cost Management Roles and Responsibilities

Project Director Manages and leads all Project activities, A A A
including approval of all purchases, as well as
development and approval of Spend Plan
Procurement / Budget Manages Cost Management Process for the R V R
Specialist Project, to include the development, monitoring,
posting, and reporting on costs of the Project
and the Spend Plan
Requester / Purchasing Manages Project administrative purchases and C C C
P-Card purchases
Budget Support Provides subject matter expertise and offers C R C
guidance on budget matters
Executive Steering Reviews and receives updates for Project costs C I I
Committee Member
Page 22 of 138 11/09/2017

10 Schedule Management
10.1 Overview
Schedule Management describes how the Master Project Schedule establishes the breakdown
of work to be performed, during the Pre-DDI and Procurement phases of the Project, including
Project activities associated with all identified deliverables, work products, and supporting tasks
performed by Project Team Members. This section details the Schedule Management standards
and procedures to be used while monitoring progress within the Master Project Schedule.
Compliance with these processes will help collect and report accurate information in a timely
manner.
Effective July 2015, Chapter 74-1, F.A.C. mandated Cost Performance Index (CPI), Schedule
Performance Index (SPI), and Earned Value be calculated using a single baselined Project
Schedule. In order to be in compliance, the Project integrates each Track’s activities into the
Master Project Schedule.
10.2 Purpose
Schedule Management is a tool used to manage the listing of Project milestones, outcomes,
deliverables, reviews, and supporting tasks with intended start and finish dates. Additionally, it is
used to build processes to establish controls to accomplish timely Project completion.
The purpose of these procedures is to provide instructions to the Project Management Office
(PMO) and other Project Team Members for developing, maintaining, monitoring, and controlling
the schedule during the Pre-DDI phase. Additionally, these standards and procedures define how
the Project will manage changes to the Master Project Schedule.
10.3 Process
Initiation Phase
During the Initiation Phase, the PMO and Track Managers will develop the Project Scope
document and Track Strategy documents. The outcome of these documents will assist the PMO
in developing the Master Project Schedule.
Project Scope
The primary goal for the Project Scope document is to identify the major outcomes and
deliverables for Pre-DDI. Initial Project deliverables, work products, and supporting tasks
considered activities described in the FLAIR Study, Project Charter, and other agreements
established between the Project Team, stakeholders, and legislation.
Track Strategy
Project deliverables, work products, and supporting tasks identified in the Project Scope will be
assigned to the appropriate Project Track. The Florida PALM Project has four Tracks; Business
Process Standardization (BPS), Organizational Change Management (OCM), Project
Management Office (PMO), and Systems and Data Strategy (SDS). Each Track will identify
deliverables, work products, and supporting tasks from the Project Scope that it will take
ownership of by providing answers to the who, what, when and where within Track Planning
documents. Deliverables, work products, and supporting tasks will be broken down into smaller
components, required to be performed by the Track’s resources and be included in the Master
Project Schedule.
Page 23 of 138 11/09/2017

Master Project Schedule Structure

The Master Project Schedule will be created using MS Project starting with the activities identified
in the Project Scope and Track Planning documents. All activities will be sequenced to determine
the order of work and assign relationships between project activities.
Planning Phase
Upon completion of the Initiation Phase, the Planning Phase will commence and consist of
developing the hierarchical Master Project Schedule framework to present all Pre-DDI activities
and work to be performed for the fiscal year. The Project will leverage a hierarchical framework
to organize tasks. The activities, tasks and accompanying detail will follow standards prescribed
by the PMBOK® Project Management guidelines and Florida PALM PMO, as outlined in the
Schedule Management section.
Master Project Schedule Framework – Level 1

The Master Project Schedule’s Level 1 framework represents the schedule for the Project by its
major components. Level 1 is the building block for all subsequent levels and depicts the status
of the Project based on progress reported at the lower levels. The Project may identify and
implement various methods of categorizing activities as the Project progresses.
Project Milestones
The Project Milestones section contains Project “Key” Milestones and Track specific milestones.
Project “Key” Milestones have been identified as critical path significant events. The timely
execution of these milestones are crucial to the success of the Project.
10.3.2.2.1 Track Deliverables

The Deliverable section of the Master Project Schedule is primarily used to identify the Project’s
acceptance of Track Deliverables. Contract deliverables are organized by Track and identified by
a standardized nomenclature and deliverable number (e.g., PMO2, BPS20). Internal deliverables
identify Track specific deliverables submitted by non-contracted staff and are identified by the
prefix “I-” (e.g., I-OCM4, I-SDS1).
Contract Payments
The Contract Payments section is used to track the payment of invoices milestones for Contractor
Support Services.
Track Detail Work Plans

Track Detail Work Plans are organized by Track. Each Track’s section will display deliverables,
work products, and supporting tasks. In addition to each Track’s Detail Work Plan, this summary
level includes Project Set-up and Pre-DDI Phase Close-Out sections.
Master Project Schedule Framework – Beyond Level 1

Additional levels represent a further breakdown/detailing of the Level 1 activities. These levels
show the detail tasks needed to accomplish the work and are used by the Project to review, plan,
analyze, and control the Project. These levels will have logical relationships that roll up to
preceding levels and are organized in such a manner to facilitate critical path analysis and
variance analysis reporting.
Page 24 of 138 11/09/2017

Master Project Schedule Standards

The Project applies the following standards to the Master Project Schedule which take into
account specific project management requirements of Chapter 74-1 F.A.C.
Schedule Components (Columns)

The Master Project Schedule, at a minimum will consist of the following columns:
• Task Mode
• WBS
• CPI
• SPI
• Task Name
• % Complete
• Duration
• Start Date
• Finish Date
• Baseline Start Date
• Baseline Finish Date1
• Predecessor
• Successor
• Resources
• Notes
• Track
• Deliverable
• Task Type
*Baseline start and finish dates are specific to the most current baseline version. The Master
Project Schedule release notes identify the current baseline version.
Component Standards
The Schedule Components standards are as follows:
Table 5: Schedule Components Standards

Component Name Standard
Task Mode Auto Schedule mode is required for all tasks
WBS Auto calculated
CPI Auto calculated
Schedule Performance Auto calculated
Index (SPI)
Task Name Summary Level – Deliverable Name and Number
Non-summary Level - Description of tasks; begins with a verb
% Complete 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 is near complete
100% - Task/work product is complete
For staffing related tasks, the following is used:
Page 25 of 138 11/09/2017

Component Name Standard

0% - Planning/Not Started
25% - Interviewing
50% - Offer Extended
75% - Paperwork Processing
100% - On Board
Duration Number of business days to complete the task.
• All tasks are set to “fixed duration”
• Split tasks across months if the duration is greater than 30 days,
with the exception of Review Cycles
• Review Cycle durations can cross over a month
• Holidays and weekend days are marked as “non-working time”
• Activity duration estimating will be used to calculate the number
of days required to complete the non-summary level tasks.
• Tracks are encouraged to use the 3-point estimate technique
when planning task start dates, finish dates, and duration. The
3-point estimate uses the most optimistic estimate (O), the most
likely estimate (M), and the pessimistic estimate (least likely
estimate) or (L) when calculating the duration of a task. These
values are used to calculate the estimated values, where E =
(O+P+M)/3.
Start Date Pick from calendar drop down; use business days only
Finish Date Pick from calendar drop down; use business days only
Baseline Start Date Date entered as baseline for comparison to actual start date
Baseline Finish Date Date entered as baseline for comparison to actual finish date
Predecessor Task must be finished before the successor task can start
Successor Task starts after its predecessors
Resources Name of person(s) performing the task; Track name when
applicable
Notes Explanatory text when applicable
Track Pick applicable Track name from drop down
Deliverable Descriptive text; shortened deliverable name (e.g., PMO2)
Task Type Pick from drop down; indicates type of activity
Task Constraints
Since the Project uses dynamic scheduling, there should only be the “as soon as possible”
constraint type which schedules the earliest possible start and finish dates for the task, given
other scheduling parameters. All tasks will have a predecessor and successor with the exception
of milestones.
Milestones
Key Milestones will be tied to the acceptance of deliverables and will be reported in Florida PALM
Monthly Status Report. Track milestones will also appear in the Master Project Schedule however
these milestones are typically used to signal an anchor such as the submission of a deliverable
and need to begin the Review cycle process. These milestones also help the Track Mangers and
Project Director monitor performance to determine whether or not the Project is on schedule.
Deliverables and Deliverable Expectation Documents (DED)
Page 26 of 138 11/09/2017

In general, Contract deliverables will be preceded by a Deliverable Expectation Document (DED)

while Internal Deliverables may or may not require a DED.
The following naming convention and duration is recommended for Deliverables and DEDs within
the Master Project Schedule:
• Deliverable Expectation Document

o Develop/Submit DED (10 days)
o Review/Update DED (10 days)
• Deliverable
o Develop <Deliverable Name and Number> (# days TBD)
o Milestone: Submit <Deliverable Name and Number> (0 days)
o Round 1 Review - <Deliverable Name and Number> (10 days)
o Round 1 Edits - <Deliverable Name and Number> (5 days)
o Round 2 Review - <Deliverable Name and Number> (5 days)
o Round 2 Edits - <Deliverable Name and Number> (3 days)
o Final Review - <Deliverable Name and Number> (2 days)
o Milestone: Accept Deliverable Name and Number> (0 days)
o Invoice Receipt (Number of days agreed to by Contractor)
o Invoice Approved by Contract Manager (5 days)
o Milestone: Invoice Paid (0 days) – this accounts for the 40-day cycle defined by
F.S. 215 for invoice receipt to payment
Recurring Meetings
Recurring meetings that Project Team Members facilitate or support will not be captured in the
Master Project Schedule. These will be maintained in the Project Meeting Log.
Cross Track Activities

Project activities and tasks may be the responsibility of a specific Track and its resources but also
have support resources from another Track assigned to the task(s). In this case, the work will
only appear within the responsible Track’s detail section of the Master Project Schedule with the
named resources from the other Track listed in the resource column. Any Track deliverables or
activities or dependent on other Track deliverables or activities will be linked with predecessors
and successors.
Personnel (Staffing Plan)

Included in the Master Project Schedule, is the Project’s full-time positions which have been
approved by the Legislature. The positions are arranged by track and position title, and account
for the period of time in which each position was open. In the case of positions that have been
filled and subsequently vacated, tasks for backfilling those positions is included.
Procurement Activities
Procurement activities and tasks (e.g., ITN, RFQ) will be included in the Master Project Schedule
for planning and monitoring purposes.
Contractual Activities
Contractual deliverable dates will be added to the Master Project Schedule and baselined for the
entire life of the contract rather than using the rolling wave planning approach. The exception to
this standard is when a contractual activity is event driven and therefore does not have an agreed
Page 27 of 138 11/09/2017

upon start and end date. Examples include contractual deliverables that cannot start until a certain
number of weeks before or after the release of the ITN. These activities will be included in the
Master Project Schedule for planning and monitoring purposes but not be baselined.
Baseline Standards
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. The baseline will be used throughout
the Project for measuring actual performance against planned activities and tasks.
During the Planning phase, the PMO will perform an initial Master Project Schedule baseline.
This initial baseline will capture the original schedule as it was first envisioned and will establish
a baseline that can be updated as the Project progresses.
Prior to performing the initial baseline, the Project Director and Track Managers will review the
details of the Project deliverables, work products, supporting tasks, key milestones, and critical
path and verify the Master Project Schedule contains the appropriate predecessors, successors,
durations, start and finish dates, and resources. This exercise is also required to validate the work
approved in the Project Scope and each Track Strategy has been captured and incorporated in
the Master Project Schedule. A successful review and validation will result in the approval of the
initial baseline.
When setting the Master Project Schedule initial and subsequent baselines, the Schedule
Manager will choose to baseline either the entire project or selected tasks and then set the “Status
Date”.
Execution – Monitoring – Controlling

The purpose of this phase is to manage the work planned and approved during the Planning
phase to deliver the expected results. In order to do this, the progress of Project’s key activities
and tasks will be monitored, maintained, and updated.
Rolling Wave/Fiscal Year Planning

It is not always feasible to create accurate projections and estimates through the end of multi-
year projects. At the beginning of each fiscal year, the Project will document the major activities
for the fiscal year and then refine throughout the year. Beyond a certain time frame, work plans
and schedules become unrealistic due to the ever-increasing uncertainty of the future. To avoid
investing resources and time in creating plans with unrealistic detail, the concept of “rolling wave”
planning is employed in managing the schedule throughout the fiscal year. It facilitates the
process of further defining activities, schedules, inter-project dependencies and resource
requirements for the Project. In rolling wave planning, the Project includes summary level tasks
for all long-range work to be completed within the Fiscal Year. Detail tasks are confirmed monthly
and “committed” to (baselined) in the Master Project Schedule.
The PMO will coordinate rolling wave planning by scheduling the planning sessions and working
with Track Managers individually, or in groups, as necessary, to define their 30-day commitment
and long-range changes to existing or new tasks and resources through the Fiscal Year End. The
planning sessions will be scheduled monthly and should occur no later than the last week of the
month prior to the month being planned.
Page 28 of 138 11/09/2017

Activities and tasks scheduled to begin in the upcoming four weeks are planned in detail, while
activities scheduled to start beyond 30 days are only updated if additional detail is known.
The expected output of rolling wave planning is an updated Project Schedule with an updated
baseline including resources (named individuals replacing the roles identified in high-level plans)
allocated to the task(s).
Baseline Procedures
The PMO is responsible for updating the Master Project Schedule and baseline based on
information received from the Tracks. There are two types of baselines that may be employed:
new and selective. A new baseline is used only to capture the original schedule or when there is
an update to the critical path. The intention of rolling wave planning is to update the original
established and subsequent baselines monthly as the Project progresses.
With the selective baseline process, only selected tasks, such as 30 day committed tasks and
contracted activities, rather than the entire schedule are re-baselined. The Florida PALM Project
employs the selective baseline process.
Maintenance Procedures
In order to effectively monitor, update, and report on the Project’s progress, the following
processes are documented in order to communicate the procedures as well as the roles and
responsibilities in the process.
Track Status Meeting

On a weekly basis, Track Managers or Team Members will document the status of the week’s
assigned activities, including the percent of completion of the task. Additionally, each Track will
conduct a Weekly Status Update meeting to review and confirm the work completed for that week
and what is planned for the next week. A member of the PMO will participate in each Track’s
meeting and will compare the current week’s report to the previous week’s report to confirm
planned activities were completed and being reported against.
Schedule Review Meetings

In addition to Weekly Status Update meetings, each Track will conduct Schedule Reviews to
review progress on the Track’s 30-day committed tasks. The Tracks will be able to access the
most current released version of the Master Project Schedule, Four-Week Look-Ahead Report,
and Full Schedule Remaining Tasks Report on the Florida PALM Project SharePoint home page.
The Schedule Manager will publish a snapshot of the Master Project Schedule in Microsoft Project
format. The posted Four-Week Look-Ahead Report will consist of all Project activities and tasks
to be completed in the following four weeks. Each Track can save a copy of the report and filter
the data as needed. The data includes ID Number, Track Name, Deliverable Number, Task Type,
Task Name, % Complete, Start Date, Finish Date, and Resource Name(s).
Schedule Update Process

The Schedule Manager is responsible for compiling weekly project updates for inclusion in the
Master Project Schedule. To ensure a clear and definitive progression of the schedule, these
updates will be incorporated once weekly. A best practice for organizing updates throughout the
week is to print out a copy of the Four-Week Look-Ahead Report after each weekly update is
completed. A Quality Control (QC) check per the Florida PALM Master Project Schedule
Publication Checklist in Appendix A will be applied to ensure that the Master Project Schedule
meets expected standards.
Page 29 of 138 11/09/2017

The weekly lifecycle for updates to the Master Project Schedule typically includes the following:
• Thursday
o Track Status Reconciliation and Reporting; Tracks may report % updates within
the Track Status Report or on a hard copy of the Four-Week Look-Ahead Report.
o The Schedule Manager will use these % updates to update the Master Project
Schedule accordingly
• Friday
o QC Track updates weekly updates to the Master Project Schedule
• Monday
o Include updates in the Master Project Schedule and set the Status Date to the
previous Friday
o Review the updated Master Project Schedule with the PMO Manager, and prepare
the Master Project Schedule for peer review
o A PMO Team Member other than the Schedule Manager will complete a peer
review
o Post Four-Week Look-Ahead Report on the Florida PALM SharePoint home page
• Tuesday
o Release updated version of the Master Project Schedule by posting the file on the
Florida PALM SharePoint home page.
o Distribute a copy of the newly released version of the Master Project Schedule to
the Agency for State Technology (AST) along with release notes
Schedule Release Process

Per Chapter 74-1, Florida Administrative Code (FAC), the Project is required to submit an updated
Project Schedule to the AST on a weekly basis. The Schedule Manager will reconcile and update
the Master Project Schedule per the Quality Control Checklist and save a copy in a designated
folder on SharePoint for dissemination and historical record. In addition to the Master Project
Schedule, the PMO will also save and submit a Release Notes Document identifying modifications
to the Master Project Schedule (e.g., PCRs, corrections). A peer review will occur prior to
releasing the Master Project Schedule to AST.
Project Change Request (PCR) Process

Change requests can occur throughout the life of the Project. Changes that affect the scope,
budget, and schedule are documented, prioritized, analyzed, reviewed, and approved before
implementation.
Approved PCRs that impact the schedule will be forwarded to the Schedule Manger who will
create a PCR Implementation Plan. Once confirmed by the Track(s), adjustments will be made
to the Master Project Schedule in accordance with the PCR. The Master Project Schedule will
be re-baselined after PCR adjustments are made, if necessary.
Document Management
The Project utilizes the Florida PALM network shared drive to store and maintain the Master
Project Schedule. As a general rule, the Master Project Schedule will only be checked out to the
Schedule Manger for updates. The Schedule Manger and other approved administrators will use
Release Notes to establish a clearly-defined version history of changes applied to the Master
Schedule.
Page 30 of 138 11/09/2017

Schedule Performance Index (SPI) and Cost Performance Index (CPI)

As part of the weekly schedule reporting to AST, the Project must ensure that SPI and CPI are
operationalized and fully functioning within the Master Project Schedule. Since the Project uses
fixed cost deliverables, a proxy cost of $1.00 is assigned to all resources within the Master Project
Schedule (Planned, Fixed, and Actual Costs will not be inserted). Since the Project is using a
proxy cost value, the Master Project Schedule is not used to capture the cost of the Project. The
Project maintains a Project Spend Plan to capture and monitor Project costs.
SPI and CPI are methods recommended by the AST to measure the efficiency of a project. SPI
is intended to measure the schedule performance of a project representing how close actual work
is being completed compared to the schedule. CPI is intended to measure the cost efficiency of
a project representing the amount of work being completed for every unit of cost spent. An SPI
and CPI value greater than 1 indicates the Project is performing well against the expected
schedule and costs. The AST and Project Independent Verification and Validation (IV&V) monitor
the indices on a recurring basis. The AST defines the acceptable variance of these indices to be
between .9 – 1.1.
Quality Control
Throughout the Project, certain quality control standards will be maintained concerning the
schedule and processes tied to the schedule management. Quality control for schedule
management requires the Schedule Manager to inspect the project file to see if it aligns with the
Schedule Standards. The Schedule Manager will use the Florida PALM Master Project Schedule
Publication Checklist below as a guide to ensure quality control.
Table 6: Master Project Schedule Publication Checklist
Item
Review Item
Number
1 Clear all filters and expand all tasks before review.
2 Confirm all tasks are Auto Scheduled.
3 All tasks have predecessors (except parent tasks and “Project Begin” task).
4 All tasks have successors (except parent tasks and “Invoice Paid” tasks).
There are no tasks with an estimated duration (“?” adjacent to the number of
5
days).
All tasks have at least one resource assigned (except for parent tasks and
6
milestones).
7 Confirm accuracy of percent completed for all tasks.
8 Follow up on all task notes.
9 Review SPI for accuracy.
10 Review CPI for accuracy.
11 Review Critical Path for accuracy.
12 Update “Status Date.”
13 Clear all filters and expand all tasks prior to saving file.
14 Archive file for AST.
15 Overwrite “SharePoint Quick Link” file.
After the Schedule Manager has conducted quality control per the checklist above, and prior to
release of the Master Project Schedule as a result of updates and changes, a different PMO Team
Member will conduct a peer review according to the following criteria:
Page 31 of 138 11/09/2017

1. Compare the current week’s version to the previous week’s version

a. Open the current week’s Master Project Schedule
b. Select “Compare Schedules” from the Report tab
c. Click “Browse” and select the previous week’s version of the Master Project
Schedule
d. Leave the Task Table and Resource Table value as “Entry”
e. Click “OK”
2. Analyze the Master Project Schedule data differences from the side by side Comparison
Report
a. Each field type of the Master Project Schedule will be displayed as three columns;
Current, Previous, and Difference
b. Filter the difference columns to verify differences and/or identify anomalies
c. Verify the note for added or deleted lines indicated by a + or –
d. Validate added or deleted data
3. Analyze Earned Value Measures
a. Repeat steps 1.a. – c.
b. Change the Task Table and Resource Table value to Earned Value; click “OK”
c. Analyze the difference columns for CPI, SPI, BCWS, BCWP, and ACWP
i. CPI - Cost Performance Index
ii. SPI - Schedule Performance Index
iii. BCWS - Budgeted Cost of Work Scheduled
iv. BCWP - Budgeted Cost of Work Performed
v. ACWP - Actual Cost of Work Performed
d. Filter the difference columns to verify differences and/or identify anomalies
Observations found during the peer review will be sent via email to the PMO Manager and
Schedule Manager. The PMO Manager will make the final decision if any changes are required
prior to distribution. Acceptable and/or expected differences will be explained in the Release
Notes
Reporting Elements
The Master Project Schedule provides data to support various reports for the Project Team and
Stakeholders including the Track Status, RAIDL, Monthly, and Quarterly Reports.
To manage the Master Project Schedule, the PMO produces and distributes the RADAR and 30-
day Commit reports as described in detail below.
RADAR (Four-Week Look-Ahead) Report

The Four-Week Look-Ahead Report is an extract of tasks from the Master Project Schedule. It
lists all tasks that are due or will be due within four weeks. The Report includes the Master Project
Schedule’s ID and WBS, Track, Deliverable Number, Task Type, Task Name, % Complete, Start
and Finish Dates, Baseline Start and Finish Dates, and Resources. Users can filter each column.
It is compiled and emailed to the Project Team Master Project Schedule updates are completed.
Project Team Members use the Report for a variety of reasons including to confirm and validate
progress to date, planned activities, resource overutilization, and slippage.
Page 32 of 138 11/09/2017

RADAR Report
(Four Week Look Ahead)
(Updated through 04/29/2016)
Due Week of May 2 - 6
Past Due as of April 29
ID Track Deliverable # TaskType Task Name % Complete Start Finish Baseline6 Start Baseline6 Finish Resource Names
66 Oversight IV&V2 Submit IV&V Submission of Monthly Assessment (IV&V2) - April 2016 0% 5/11/2016 5/11/2016 5/11/2016 5/11/2016
178 PMO Invoice Milestone: Invoice Paid PMO2 Support (Mar) 0% 4/25/2016 4/25/2016 NA NA
180 PMO Invoice Invoice Received PMO1 Support (April) 0% 5/9/2016 5/9/2016 NA NA Brandi Babb ($0)
181 PMO Invoice Invoice Approved by Contract Manager - PMO1 Support (April) 0% 5/10/2016 5/16/2016 NA NA Brandi Babb ($0)
224 Oversight Invoice Milestone: Invoice Paid IV&V Support (Mar) 0% 4/27/2016 4/27/2016 NA NA
226 Oversight Invoice Invoice Received IV&V Support (Apr) 0% 5/13/2016 5/13/2016 NA NA Stuart Potlock ($0)
265 BPS BPS15 Invoice Milestone: Invoice Paid Training Manual and Conduct Training for State Staff on 0% 5/5/2016 5/5/2016 NA NA
514 PMO I-PMO1 DED Review and Update DED for project support tools (I-PMO1) 75% 4/1/2016 4/29/2016 4/1/2016 4/29/2016 Danielle Kosberg
516 PMO I-PMO1 Develop Gather Requirements for Project Support Tools (I-PMO1) - May 0% 5/2/2016 5/31/2016 5/2/2016 5/31/2016 Angie Robertson,Danielle
552 PMO I-PMO2A Training Develop Cost Management Training (I-PMO2A) 0% 4/25/2016 5/6/2016 4/25/2016 5/6/2016 Brandi Babb,OCM Team
553 PMO I-PMO2A Training Review and Update Cost Management Training (I-PMO2A) 0% 5/9/2016 5/20/2016 5/9/2016 5/20/2016 Brandi Babb,Danielle
554 PMO I-PMO2A Training Conduct Cost Management Training (I-PMO2A) 0% 5/23/2016 5/31/2016 5/23/2016 5/31/2016 Brandi Babb
561 PMO I-PMO2B Edit Round 2 Edits - Procurement Management Standards and Procedures (I-PMO2B) 0% 5/2/2016 5/4/2016 5/2/2016 5/4/2016 Stuart Potlock
562 PMO I-PMO2B Final Review Final Review - Procurement Management Standards and Procedures (I-PMO2B) 0% 5/5/2016 5/6/2016 5/5/2016 5/6/2016 Danielle Kosberg,Melissa
563 PMO I-PMO2B Accept Milestone: Accept Procurement Management Standards and Procedures (I-PMO2B) 0% 5/6/2016 5/6/2016 5/6/2016 5/6/2016
564 PMO I-PMO2B Training Develop Procurement Management Training (I-PMO2B) 0% 5/9/2016 5/13/2016 5/9/2016 5/13/2016 Stuart Potlock,OCM Team
565 PMO I-PMO2B Training Review and Update Procurement Management Training (I-PMO2B) 0% 5/16/2016 5/20/2016 5/16/2016 5/20/2016 Stuart Potlock,OCM
566 PMO I-PMO2B Training Conduct Procurement Management Training (I-PMO2B) 0% 5/23/2016 5/27/2016 5/23/2016 5/27/2016 Stuart Potlock
572 PMO I-PMO2C Review Round 2 Review - Schedule Management Standards and Procedures (I-PMO2C) 75% 4/25/2016 4/29/2016 4/25/2016 4/29/2016 Danielle Kosberg
573 PMO I-PMO2C Edit Round 2 Edits - Schedule Management Standards and Procedures (I-PMO2C) 0% 5/2/2016 5/4/2016 5/2/2016 5/4/2016 Jason Colson,Maryanne
574 PMO I-PMO2C Final Review Final Review - Schedule Management Standards and Procedures (I-PMO2C) 0% 5/5/2016 5/6/2016 5/5/2016 5/6/2016 Danielle Kosberg,Melissa
575 PMO I-PMO2C Accept Milestone: Accept Schedule Management Standards and Procedures (I-PMO2C) 0% 5/6/2016 5/6/2016 5/6/2016 5/6/2016
576 PMO I-PMO2C Training Develop Schedule Management Training (I-PMO2C) 0% 5/9/2016 5/13/2016 5/9/2016 5/13/2016 Jason Colson,Maryanne
577 PMO I-PMO2C Training Review and Update Schedule Management Training (I-PMO2C) 0% 5/16/2016 5/19/2016 5/16/2016 5/19/2016 Jason Colson,Maryanne
578 PMO I-PMO2C Training Conduct Schedule Management Training (I-PMO2C) 0% 5/20/2016 5/26/2016 5/20/2016 5/26/2016 Jason Colson,Maryanne
583 PMO I-PMO2D Edit Round 1 Edits - Communications Management Standards and Procedures (I-PMO2D) 0% 5/3/2016 5/9/2016 5/3/2016 5/9/2016 Sean Cooley
584 PMO I-PMO2D Review Round 2 Review - Communications Management Standards and Procedures (I- 0% 5/10/2016 5/12/2016 5/10/2016 5/12/2016 Melissa Turner,Danielle
585 PMO I-PMO2D Edit Round 2 Edits - Communications Management Standards and Procedures (I-PMO2D) 0% 5/13/2016 5/17/2016 5/13/2016 5/17/2016 Sean Cooley
586 PMO I-PMO2D Final Review Final Review - Communications Management Standards and Procedures (I-PMO2D) 0% 5/18/2016 5/19/2016 5/18/2016 5/19/2016 Melissa Turner
587 PMO I-PMO2D Accept Milestone: Accept Communications Management Standards and Procedures (I- 0% 5/19/2016 5/19/2016 5/19/2016 5/19/2016
593 PMO I-PMO2E Review Round 2 Review - Collaboration Management Standards and Procedures (I-PMO2E) 0% 4/28/2016 5/2/2016 4/29/2016 5/3/2016 Melissa Turner,Danielle
594 PMO I-PMO2E Edit Round 2 Edits - Collaboration Management Standards and Procedures (I-PMO2E) 0% 5/3/2016 5/5/2016 5/4/2016 5/6/2016 Julian Gotreaux
595 PMO I-PMO2E Final Review Final Review - Collaboration Management Standards and Procedures (I-PMO2E) 0% 5/6/2016 5/9/2016 5/9/2016 5/10/2016 Melissa Turner
596 PMO I-PMO2E Accept Milestone: Accept Collaboration Management Standards and Procedures (I-PMO2E) 0% 5/9/2016 5/9/2016 5/10/2016 5/10/2016
598 PMO I-PMO2 Training Develop Communications and Collaboration Training 0% 5/3/2016 5/12/2016 5/3/2016 5/12/2016 Julian Gotreaux,Sean Cooley
599 PMO I-PMO2 Training Review and Update Communications and Collaboration Training 0% 5/13/2016 5/23/2016 5/13/2016 5/23/2016 Julian Gotreaux,Sean
600 PMO I-PMO2 Training Conduct Communications and Collaboration Training 0% 5/24/2016 5/31/2016 5/24/2016 5/31/2016 OCM Team
636 PMO I-PMO3B Review Round 2 Review - Deliverable Management Standards and Procedures (I-PMO3B) 75% 4/21/2016 5/4/2016 4/21/2016 5/4/2016 Danielle Kosberg,Sean
637 PMO I-PMO3B Edit Round 2 Edits - Deliverable Management Standards and Procedures (I-PMO3B) 0% 5/5/2016 5/11/2016 5/5/2016 5/11/2016 Brandi Babb,IV&V
638 PMO I-PMO3B Review Round 3 Review - Deliverable Management Standards and Procedures (I-PMO3B) 0% 5/12/2016 5/18/2016 5/12/2016 5/18/2016 Danielle Kosberg,Melissa
639 PMO I-PMO3B Edit Round 3 Edits - Deliverable Management Standards and Procedures (I-PMO3B) 0% 5/19/2016 5/23/2016 5/19/2016 5/23/2016 Brandi Babb,IV&V
640 PMO I-PMO3B Final Review Final Review - Deliverable Management Standards and Procedures (I-PMO3B) 0% 5/24/2016 5/25/2016 5/24/2016 5/25/2016 Danielle Kosberg,Melissa
641 PMO I-PMO3B Accept Milestone: Accept Deliverable Management Standards and Procedures (I-PMO3B) 0% 5/25/2016 5/25/2016 5/25/2016 5/25/2016
648 PMO I-PMO3C Edit Round 1 Edits - SQE Standards and Procedures (I-PMO3C) 75% 4/26/2016 5/2/2016 5/2/2016 5/6/2016 Phil Harman,Brandi Babb,IV&V
649 PMO I-PMO3C Review Round 2 Review - SQE Standards and Procedures (I-PMO3C) 0% 5/3/2016 5/9/2016 5/9/2016 5/13/2016 Danielle Kosberg,Sean Cooley
650 PMO I-PMO3C Edit Round 2 Edits - SQE Standards and Procedures (I-PMO3C) 0% 5/10/2016 5/12/2016 5/16/2016 5/18/2016 Phil Harman,Brandi Babb,IV&V
651 PMO I-PMO3C Final Review Final Review - SQE Standards and Procedures (I-PMO3C) 0% 5/13/2016 5/16/2016 5/19/2016 5/20/2016 Danielle Kosberg,Melissa
652 PMO I-PMO3C Accept Milestone: Accept SQE Standards and Procedures (I-PMO3C) 0% 5/16/2016 5/16/2016 5/20/2016 5/20/2016
663 PMO I-PMO3D Review Round 1 Review - Metrics and Reporting Standards and Procedures (I-PMO3D) 0% 5/2/2016 5/13/2016 5/2/2016 5/13/2016 Danielle Kosberg,Angie
664 PMO I-PMO3D Edit Round 1 Edits - Metrics and Reporting Standards and Procedures (I-PMO3D) 0% 5/16/2016 5/27/2016 5/16/2016 5/27/2016 IV&V Contractor,Maryanne
677 PMO I-PMO3E Develop Develop Content Release Management Standards and Procedures (I-PMO3E) - May 0% 5/2/2016 5/13/2016 5/2/2016 5/13/2016 IV&V Contractor,Phil
678 PMO I-PMO3E Submit Milestone: Submit Content Release Management Standards and Procedures (I- 0% 5/13/2016 5/13/2016 5/13/2016 5/13/2016
679 PMO I-PMO3E Review Round 1 Review - Content Release Management Standards and Procedures (I-PMO3E) 0% 5/16/2016 5/27/2016 5/16/2016 5/27/2016 Danielle Kosberg,Angie
698 PMO I-PMO3G Develop Create Deliverable Quality Management Standards and Procedures (I-PMO3G) 0% 5/26/2016 6/9/2016 NA NA Brandi Babb,IV&V
726 PMO PMO5 Report Produce Track Project Status Reports (PMO5) - Reporting Period of April 22 - 28, 2016 75% 4/27/2016 5/2/2016 4/27/2016 5/2/2016 BPS Team,OCM Team,PMO
727 PMO PMO5 Report Produce Track Project Status Reports (PMO5) - Reporting Period of April 29 - May 5, 0% 5/4/2016 5/9/2016 5/4/2016 5/9/2016 BPS Team,OCM Team,PMO
728 PMO PMO5 Report Produce Track Project Status Reports (PMO5) - Reporting Period of May 6 - 12, 2016 0% 5/11/2016 5/16/2016 5/11/2016 5/16/2016 BPS Team,OCM Team,PMO
740 PMO Report Produce Florida PALM Project Weekly Report - Week of April 25 - 29 75% 4/29/2016 5/5/2016 4/29/2016 5/5/2016 Jason Colson
Figure 7: Sample RADAR Report
30-day Commit Report

The 30-day commit report will be used by the Project Team during the monthly Rolling Wave
Planning sessions as described in the Rolling Wave Planning section above. The Report will
assist the Team with planning and committing to work to be performed for the next 30 days. The
Team will also review the Full Schedule Remaining Task Report to identify summary level tasks
that fall outside of the next 30 days, and add detail to these if known.
Page 33 of 138 11/09/2017

Figure 8: Sample 30-Day Commit Report
Full Schedule Remaining Tasks Report

The Full Schedule Remaining Tasks Report is an extension of the Four-Week Look-Ahead
Report. The only difference is that this report shows all tasks through the Fiscal Year and not just
the next four weeks. Project Team Members use the Report for a variety of reason as mentioned
above as well as to confirm and validate planned tasks and activities and/or possibly re-planning.
It is compiled and emailed to the Project Team after Master Project Schedule updates are
completed.
Closing
Knowledge Transfer
The PMO promotes continuous knowledge transfer through varying activities including
participating in Track and Project-wide weekly review meetings, maintaining a considerations log,
updating templates, participating in Track deliverable review cycles, documenting standards and
procedures, and facilitating training.
Page 34 of 138 11/09/2017

Lessons Learned
The intended use for lessons learned gathered by the Project are to improve the overall
productivity and efficiency of its processes. The Project logs, reviews, and tracks Lessons
Learned as a RAIDL item and is discussed by the applicable Track during Track RAIDL meetings
and by the Project during the Project-wide Bi-weekly meetings.
Project Schedule Close-Out

To ensure that the Project maximizes the significant knowledge gathered throughout each phase,
it is imperative that this knowledge is captured in a manner that allows it to be leveraged in the
future. At a minimum, the following exit criteria must be considered when closing out the Pre-DDI
Master Project Schedule:
1. Are all tasks 100% complete?
2. What needs to be done if there are incomplete tasks?

The Schedule Management roles and responsibilities are described below. This information is
and responsibilities during each of the four (4) major areas of the Schedule Management Process
as shown in the figure below.
1 2 3 4
Fiscal Year Monthly Weekly Reporting
Planning Rolling Wave Updates Activities
Figure 9: Major Areas of the Schedule Management Process
Table 7: Schedule Management Roles and Responsibilities

Role Responsibilities
Schedule Manager • Manage updates to the Master Project Schedule
• Ensures Quality Control via Master Project Schedule
Publication Checklist
• Creates Schedule related Reports
• Facilitates 30-day Commit meetings
QC Reviewer • Performs peer review of Master Project Schedule prior to
release
PMO Manager • Approves versions of the Master Project Schedule prior to
release
• Facilitates schedule planning meetings
• Approves release of Master Project Schedule
• Approves revised baseline
Track Managers • Approves 30-day commit tasks
• Provides Weekly Updates
• Supports schedule planning activities
Project Director • Approves Project Scope and Track Strategies
• Approves new baselines
Executive Steering • Approves changes impacting due dates of major
Committee deliverables or key project milestones
Page 35 of 138 11/09/2017

11 Quality Management
11.1 Overview
Quality Management includes two components, Deliverable Quality and Service Quality
processes. These processes ensure Deliverable and Service Quality meets Project expectations.
The Project expects the highest quality in its Deliverables, work products, and performance from
both internal Project Team members and external Contractors. To achieve a positive outcome,
these processes will be carried out so expectations are aligned and met.
11.2 Purpose
The purpose of Quality Management is to provide instructions on the processes for Deliverable
Quality and Service Quality. The Service Quality processes are specific to evaluating the quality
of service for Contractors. It is important that each Contractor staff is fully aware of the Project
Quality Management processes.
11.3 Process
Quality Management is about performing discipline inspections throughout the work product life
cycle. These inspections are performed at key transition points in the creation, review, and
release of documents or information. The list below identifies the quality management control
points used by the Project.
1) Cost Management, Section 9: the Procurement/Budget Specialist performs a quality

review described in the checklist table prior to submitting the spend plan.
2) Schedule Management, Section 10: the Schedule Manager performs a quality review
described in in checklist table Prior to releasing the Master Schedule.
3) Communication Management, Section 17: For all content to be shared with entities or
people outside of the Project, the quality activities are described in this section.
4) Deliverable Management, Section 21: These five quality events are associated with the
development of a deliverable: DED, Peer Review(s), Submission QC, Deliverable Review
Comments, and Pre-Release QC.
5) Content Management, Section 23: All information accepted or released to outside entities
employs the processes described in this section of the PMP.
The remaining content in this section will describe in more detail the deliverable quality and
service quality expectations.
Deliverable Quality
The diagram below depicts the Deliverable Quality process. The Deliverable Management plan
provides the detailed steps for completing the elements below. Each yellow star indicates a quality
management element. These elements are described in more detail below.
Page 36 of 138 11/09/2017

Figure 10: Quality Management Process Overview
The Project’s Deliverable Quality Management process has elements designed into each of the
three key stages of a Deliverable. The following section outlines the Quality Management
elements within each of the stages.
1. Deliverable Expectation Document (DED) Development

The DED is the first step in establishing the quality expectations for the deliverable
before deliverable development begins. It establishes the criteria and format by which
the eventual deliverable submission will be measured. Through the review and
acceptance of the DED, the impacted stakeholders collaborate to set clear expectations
and agree upon outcomes as well as communicating the approach for developing and
accepting the content in parts or in its entirety.
2. Deliverable Development
The Project encourages coordination and collaboration throughout the development of
a deliverable. The deliverable Owner establishes quality checkpoints to confirm
acceptance criteria and approach is being demonstrated during the development of a
deliverable. For Contractual deliverables, the Project monitors and evaluates the level
of interaction between a Contractor and the Project Team following the Service Quality
Evaluation process as described in the next section. Prior to submission of the
deliverable, the deliverable Owner shall use the Submission Quality Control (QC)
Checklist to confirm that quality expectations have been included in the deliverable.
3. Technical Quality Evaluation

a. Submission QC Review – The first step in the Technical Quality Evaluation
process is to review the deliverable against a standard checklist to confirm it
meets the Project’s quality standards prior to the deliverable review process. If
any issues are found, the submission is not accepted and the deliverable is
returned to the Owner. This step helps ensure the most efficient use of the
Reviewers’ time and provides a clear indicator of the quality to the deliverable
Owner.
b. Deliverable Review – The quality component during the deliverable review
process confirms accuracy and completeness meets the deliverable acceptance
criteria communicated in the DED .
Page 37 of 138 11/09/2017

Service Quality
The purpose and scope of Service Quality is focused on the overall interactions and performance
of the Contactor(s) during a specific period of time. Service Quality Management and Procedures,
in conjunction with the Deliverable Quality, Schedule, and Deliverable Management, will provide
a complete view of a Contractor’s performance. The performance of Contractors providing
services to the Project will be monitored and evaluated at the direction of the Contract Manager,
Track Manager, and Project Director.
The Project has a process for evaluating Contractor service quality. The diagram below provides
an overview of the Service Quality Evaluation process.
Figure 11: Service Quality Management Process Overview
Initial Meeting
Within the first thirty days of the contract start date, the Contract Manager and Contractor Lead,
Contractor Engagement Executive, or other representatives will meet to confirm contractual and
service level expectations for the Contractor(s) on the Project. The key outputs of this meeting
are:
• For each role in the RACIV and responsibilities table, a Project team member name will
be provided
• Education on the Project’s Quality Management System expectations:
o Technical Quality Evaluation as described within Deliverable Management
o Service Quality Evaluation as described within Quality Management
▪ Planned timeline for regular Service Quality Evaluation Reviews
▪ Planned timeline for periodic Quality Reviews
▪ Primary Contractor contact for Service Quality Evaluation feedback
▪ Contractor contact for issue escalation
• Contractual Expectations
o Confirmation of deliverables and Contractor responsibilities
o Discussion of communication channels and protocols
o Discussion of technical and service quality risks
o Discuss any delivery and performance risks from the contracted services
During the initial meeting, the Contract Manager and Contractor will determine a schedule for
performing the regular Service Quality Evaluations. The timing of these evaluations is at the
Page 38 of 138 11/09/2017

discretion of the Project Director and Contract Manager. Reviews are typically performed on a
regular schedule (e.g., monthly). The Project may choose to perform non-schedule service quality
evaluation to coincide with significant Project events, deliverables, milestones, or transition points
throughout the Project lifecycle.
Service Quality Evaluation

The Contract Manager will collect feedback on the performance of the Contractor from Service
Quality Evaluators who are involved in work and interactions with the Contractor staff. The Service
Quality Evaluators may change from one review period to the next based on changes in the
Contractor’s work as well as what Project Team Member(s) is involved in creating work products
in collaboration with the Contractors.
Feedback will take the form of answers to a series of ‘Yes’ and ‘No’ questions, with the positive
result being an answer of ‘Yes’. The table below outlines the Service Quality measures for the
Project and apply to all contracted services. During the evaluation, any answer of “No” or “Can’t
Confirm” will require additional information to be documented by the Service Quality Evaluator
and Contract Manager and could result in items on the service improvement plan (SIP).
Table 8: Service Quality Evaluation Measures

# Measure Evaluation Question
1 Communication • Does the Contractor demonstrate clear communication skills and
keep the Project up to date with key activities and issues?
• Does the Contractor demonstrate acceptable:
o Written communication skills? (ex: Provides clear and
comprehensible written material.)
o Verbal communication skills? (ex: Provides clear and
comprehensible ideas and thought leadership.)
o Listening communication skills? (ex: Acknowledges
input/feedback and incorporates that information into Project
work products.)
• Does the Contractor pass along feedback and other information
heard related to the Project to the appropriate Project Team
member based on the content of the information?
• Does the Contractor follow established Project communication
standards including email, meeting scheduling, calendaring, and
status updates?
• Does the Contractor respond timely and thoroughly to requests
from Project Team Members, Track Managers, and Project
Management?
2 Availability • Are Contractors available for meetings and to answer questions
as agreed to and expected?
• Does the Contractor provide continuity of resources and
knowledge throughout the engagement?
• Is the Contracted Firm managing turnover (if it occurs) to
minimize the impact to the Project?
3 Recommendations • Do the Contractor’s recommendations and deliverable content
which have a provide a positive value to the Project?
Positive Value • Does the Contractor provide solutions which are practical within
the constraints of the State and Project environment?
Page 39 of 138 11/09/2017

# Measure Evaluation Question

4 Timeliness • Does the Contractor complete tasks/deliverables by the agreed
completion dates?
5 Professionalism • Does the Contractor respect other Project Team Members and
their roles, adapt to the Florida PALM environment, and
demonstrate a positive and cooperative attitude?
The Contract Manager will collect and collate the feedback from each of the Service Quality
Evaluators. In the case where there are differences in responses for a question from the Service
Quality Evaluators, the Contract Manager will coordinate, consolidate, and confirm the answers
and comments for that question.
After collating, and addressing any ambiguity with the Service Quality Evaluators, the Contract
Manager will share the Service Quality Evaluation results with the Contractor Lead. The Contract
Manager will then meet with the Contractor Lead and develop a SIP related to any negative
responses from the Service Quality Evaluators. This meeting and the finalization of the SIP should
happen as soon as possible after the Service Quality Evaluation. The Contractor Lead is expected
to formulate, gain acceptance from the Approver, and begin making progress on the SIP before
the next scheduled Service Quality Evaluation.
The format for the SIP may vary depending on the Contractor and situation, but should provide at
a minimum the following elements:
• A clear description of the concern or issue identified during the Service Quality Evaluation
• Identify specific steps and timing which will be taken by the Contractor to address the
concern
• Identify specific measures or criteria which demonstrates evidence the concern has been
remediated
If there is negative feedback from the Service Quality Evaluation, or there is insufficient
improvement for a Contractor with a SIP, the Contract Manager will escalate this shortcoming
according to the table below. Escalation is at the discretion of the Contract Manager and Project
Director.
Table 9: Service Quality Evaluation Escalation
Escalation Level Description and Action
For initial feedback or minor SIP opportunities, the Contract Manager

will work with the Contractor Lead to develop a SIP. Minor SIP being
Level 1 –
defined as, there has been no impact to schedule commitments or state
Contractor Lead
staff have been required to expended unplanned effort to get the
deliverable in acceptable quality prior to submission to the project.
Level 2 – If the concerns are significant, they impact the performance or
Contractor reputation of the Project, or if the Contractor is not making progress
Engagement against the SIP, the Contract Manager and Project Director or designee
Executive will escalate the concerns to the Contractor Engagement Executive.
On a periodic basis, typically quarterly, the Contract Manager and Contractor Engagement
Executive will meet to proactively review and confirm the service expectations established during
Page 40 of 138 11/09/2017

the initial meeting and any feedback from the regular Service Quality Evaluation. The purpose of
these meetings is to provide a designated opportunity to share and discuss the Service Quality
Evaluation results and determine if any of the initial expectations need to be revised. Outputs of
this meeting can include a revision to the timing of the regular Service Quality Evaluation
Assessments, updates to the Contractor expectations, or changes to the SIP.
The Project Quality Manager will review the results of the Service Quality Evaluations, to monitor
the progress of the SIP, overall improvement in the service level being provided to the Project,
and to look for trends in the results which may not be apparent to the Contract Manager. Examples
of potential trends the Project Quality Manager might identify include consistently lower (or higher)
evaluation scores from one individual or individuals within a Project Track indicating a
misalignment of expectations or that Track being underserved. A Project issues could be
generated if an identified completion date in the SIP is not met by the Contractor.
The Project Quality Manager will also be responsible for monitoring the overall effectiveness of
the Service Quality Evaluation process, including the amount of time spent collecting the
evaluation data versus the effort expended by the Project to collect and compile that data. On a
regular basis, likely bi-annually, the Project Quality Manager will meet with the Contract Managers
and PMO to review:
• The effectiveness of the Service Quality Evaluation process,
• The lessons learned from Periodic and Final Service Quality Evaluation Reviews, and
• Work with the PMO to determine if any changes are needed to the Service Quality
Management processes.
Final Evaluation and Review

At the end of each contract, the Contract Manager and the Contractor Lead will conduct a final
Service Quality Evaluation and feedback session. The purpose of this session is to review the
overall quality performance of the Contractor, and obtain the Contractor’s input and feedback on
the Service Quality Management process. The Contract Manager will evaluate the feedback from
the Contractor, document any lessons learned, and determine if any changes need to be made
to the Project’s Service Quality Management standards, procedures, processes, or tools. The
Project Quality Manager may participate in this session to obtain firsthand information on the
performance of the Service Quality Management process. The Contract Manager will document
the observations in the Project’s Lessons Learned repository and distribute as appropriate to other
Project Team members.
Page 41 of 138 11/09/2017


Reviewers
Provide
Complete
Additional
Evaluation
Information
and Return to
and
Owner
Clarification
Review
Evaluator List
Contract Manager
Yes
Confirm Provide
Additional
evaluators Report of
Process Add Review Information or Compile Negative Process
and distribute Yes No No No Contractor
Start Evaluators? Evaluations Clarification Results Responses? End
assessment Performance
Needed?
collection tool to Project
Yes Meet with

Contractor
and develop
service
Contractor Lead
or Engagement
improvement
Executive
plan (SIP) to
address
negative
responses.
Accepter
Approve
No Yes
SIP
Figure 12: Service Quality Process
Page 42 of 138 11/09/2017


The Service Quality Evaluation (SQE) roles and responsibilities are described in the table below.
This information is presented in a RACIV (Responsible, Acceptor, Consulted, Informed, or Verify)
responsibility-matrix format, as defined in Section 7 of this document. The table below depicts the
RACIV role during each of the three (3) major areas of the SQE Process as shown in the figure
below.
2 3
1
Service Quality Final Evaluation and
Initial Meeting
Evaluation Review
Figure 13: Major Areas of the Service Quality Evaluation Management Process
Table 10: Service Quality Evaluation Roles and Responsibilities

• Manages the overall process
• Initiates and conducts regular Service Quality
Evaluations
Contract Manager • Monitors the defined continuous process R R R
improvement and remediation process using a
Service Improvement Plan (SIP) for identified
service concerns or issues
• Participates in setting contractual and service
level expectations for the Contractor(s)
Contractor Lead C C C
• Contributes and monitors the Contractor’s
performance throughout the process
• Participates in setting contractual and service
Contractor
level expectations for the Contractor(s)
Engagement C C C
• Accountable for Contractor’s service delivery
Executive
performance throughout the process
• Responsible for meeting agreed upon contractual
Contractor and service level expectations and SIP, if I I C/I
applicable
Reviewers • Conducts Service Quality Evaluation I C C
• Monitors overall adherence to the process
• Reviews results across Contractors and time
periods to identify trends
Quality Manager • Supports Periodic Quality Checkpoint meetings; I/V I/V I/V
Participates in the Final Evaluation and Review to
capture and analyze feedback on the overall
process
Accepter • Accepts the final SQE and SIP C A A
Page 43 of 138 11/09/2017

12 Procurement Management
12.1 Overview
Procurement Management establishes the processes utilized to procure support services and to
acquire goods and services necessary for the operation of the Project. Procurement Management
also includes the process to manage contracts and vendor relationships.
12.2 Purpose
Members regarding Procurement Management and related contract management. All standards
and procedures described are in accordance with the DFS Agency Policy and Procedures (AP&P)
#2-02, Purchase of Commodities and Contractual Services which references relevant Florida
procurement laws and rules.
12.3 Process
The Procurement Management process includes four (4) major areas: procurement, contract
management, deliverable acceptance (or receiving), and contract closeout. The standards and
procedures of Procurement Management take input from the Quality Management processes
included in this document. Quality Management provides standards for which all work products
are developed by Contractors or Project Tracks. Additionally, the Project has incorporated
procurement and contract procedures from the DFS Contract Management Life Cycle Guide into
the Procurement Management process.
Procurement
At the beginning of the Fiscal Year, the Project plans procurement activities which serve as inputs
to the creation of the Project Spend Plan as well as the Master Project Schedule to account for
the activities, timing, and staff required for each procurement. More complex procurement
activities require an approved Procurement Strategy document.
Purchase Authority
The Project Director has the authority to purchase the necessary goods and services to achieve
the outcomes of the Project within the defined budget.
Spend Plan
The annual budget process includes estimation of all Project expenses and costs. The Spend
Plan must include significant or complex contractual services requirements such as statutorily
mandated services (e.g., Independent Validation and Verification [IV&V] services) and other
consultant or specialized services approved to support the Project.
The Spend Plan must also account for the purchase of supplies throughout the fiscal year. Supply
requisition purchases are generally small purchases, or state contract purchases1, and include
office consumables, computers, equipment, and office furniture as well as subscription services.
The Project continually reviews and forecasts any changes in future products and services
needed in the monthly updates to the Project Spend Plan.
1 Reference section 287.017 F.S., Purchasing categories. Reference 287.056, F.S., Purchases from purchasing
agreements and state term contracts.
Page 44 of 138 11/09/2017

The estimation of cost for goods and services is based on historical Project spend data as well
as averages of State Term Contract rates. Refer to the Cost Management Standards and
Procedures for more details about the Project Spend Plan and annual budget process.
Schedule Planning
The procurement of contractual services requires detailed schedule planning. The Master Project
Schedule is utilized to plan all activities, time requirements, and human resources needed to
develop and evaluate the appropriate solicitation for complex services. Supply requisition
purchases described later in this section are not included in the Master Project Schedule as they
are purchased on an as needed, or “just in time” basis throughout the fiscal year.
The Master Project Schedule includes the steps and resources assigned to each procurement
which typically include:
• Draft development;
• Draft review cycles;
• Solicitation release date range;
• Evaluation date range;
• Award or vendor selection date;
• Contract approval and execution; and
• Detailed service delivery schedules and deliverable acceptance review cycles.
For more information about the Master Project Schedule, see the Schedule Management section
of this document.
Solicitation Process
Procurement professionals on the PMO staff are responsible for the development and oversight
of each Project procurement activity. The PMO Track Manager assigns a procurement
professional to each procurement activity as a resource in the Master Project Schedule. The
Procurement professionals also serve as liaisons with the DFS Purchasing, DFS Contract
Management, and the DFS Legal Offices. The Project’s procurement professionals work with
Track Managers to document and verify that strategies, reviews, and required documentation are
obtained prior to the release and throughout each solicitation.
All documentation is stored on the Project SharePoint PMO/Procurement Libraries. As required

by DFS policy, each procurement that results in a contract includes a corresponding contract
management directory.
The selection of the most appropriate method of procurement is determined pursuant to Section
287.057(5)(f), F.S., and Rule 60A-1.002(f), F.A.C. Refer to Section 5.5, “Determine Solicitation
Method” of the DFS Contract Management Life Cycle Guide for additional information for selection
process definitions (i.e., competitive and noncompetitive methods) and detailed DFS process
flows for the development and approval of informal and formal solicitations. All procurements in
the amount of $35,000 or greater require documented approval of a Business Needs Analysis
(BNA) which identifies the Purchasing Methods and Rules and Statutes affected, or authorizing
the activities.
The Florida PALM Procurement Manager will obtain and maintain BNA documentation in the
Project SharePoint PMO/Procurement Libraries for each procurement activity.
Page 45 of 138 11/09/2017

Supply Requisition Purchases

Supply requisition purchases are small purchases or commodities state contract purchases and
include office consumables, computers, equipment, and office furniture as well as subscription
services. The Project plans for supplies and small purchases in the Project Spend Plan. Those
supplies are purchased on a “just in time” basis throughout the fiscal year or on a subscription
basis when appropriate.
The Project Director and Track Managers direct the Procurement Manager (typically, the Florida
PALM Office Manager) to create requisitions in MFMP for approved supplies purchases. See
MyFloridaMarketPlace (MFMP) “Agency Customers” for guidance on the State of Florida’s
eProcurement System.
http://www.dms.myflorida.com/business_operations/state_purchasing/myfloridamarketplace/mf
mp_agency_customers
Support Services Purchases

Unlike supply requisition purchases, support services purchases are more often complex
activities, each planned and executed by the PMO. Support services purchases require the
development of a detailed scope of work, evaluation or vendor selection criteria, and the execution
of a two-party contract or purchase order contract. Support services purchases may also include
the purchase of software or other tools required to support the project that require an RFQ or
formal solicitation, negotiation of terms, or licensing agreements.
Procurement Strategy Document Development

All procurement activities for support services that require development of a Request for Quote
(RFQ) from State Term Contract or a competitive solicitation2 are identified and planned for in the
Track Strategy document. The Project Director accepts all Track Strategy documents.
The Track Strategy document typically includes:
• Overview or objective of the procurement;

• Procurement scope and any optional or desired additional services;
• Market analysis;
• Timeline or timeframe for the solicitation and awarded services;
• Minimum and preferred experience or other qualifications;
• Relationship to other Project contracts;
• Method of procurement options;
• Proposed evaluation team;
• Proposed pricing model; and
• Recommendations.
Contract Management
Support services procurements that result in a contract must be managed by a certified Contract
Manager. A Project Contract Manager is assigned to each contract executed for the Project. Each
contract specifies the scope of work and tasks the contractor is required to perform by dividing
the contract into quantifiable, measurable, and verifiable units of deliverables that must be
received and accepted in writing by the Contact Manager before payment3. The responsibilities
2 Reference section 287.057(1), F.S., competitive solicitation processes authorized.

3 Section 287.056(b)
Page 46 of 138 11/09/2017

and procedures for each duly certified Contract Manager are provided in the DFS Contract
Manager Life Cycle guide and processes for project compliance with those procedures is
summarized below, including evaluation of vendor performance throughout the contract term.
Contract Routing and Execution

The DFS Contract Management Life Cycle Guide describes general information about the
contract routing and execution procedures. When the proposed contract documents are complete
and ready for internal approval, the Project proceeds with the appropriate contract routing
process. The contract routing process flows are described in the Contract Management Life Cycle
Guide and include:
• MFMP Requisition Process flow for Non-Technology contracts

• MFMP Technology Process flow
• The Two Party Contract Routing Process flow (Pre and Post Contractor Execution)
Contract Monitoring
The Project Track Managers coordinate work effort from contractors and State staff that support
each Track. The Project Contract Managers work with Track Managers to document and verify
that contract deliverables and work products are received from contractors as scheduled and in
accordance with the Project’s quality standards as described in the Quality Management section
of this document. The Project Contract Managers are responsible for monitoring all assigned
contracts to verify all contract deliverables (goods and services) are provided in accordance with
each contract. The Project leverages MFMP and SharePoint resources to manage and monitor
each contract upon completion of the routing and execution. Summary information for each
contract is maintained in the DFS Florida Accountability Contract Tracking System (FACTS) for
public access.
Contract Managers maintain a contract/purchase order log for services and subscriptions. The
log provides summary information about the agreements and monitors expiration dates for
planning future procurement activities or contract renewal lead time. The log is maintained in the
PMO SharePoint directory and includes:
• PO/Contract Number
• Contractor Name
• Date of Execution
• Expiration Date
• Contract Amount
• Service Type
• Track and Track Manager
• Contract Manager
The log includes automatic email notifications to the designated Contract beginning 6 months
prior to the expiration of each agreement.
SharePoint Contract Manager File Content and Structure

All documentation for each contract or purchase order contract is maintained by the assigned
Contract Manager in the SharePoint PMO Procurement Documents Library. All contract file
content is maintained by the Contract Manager for the term of the agreement is and maintained
Page 47 of 138 11/09/2017

in accordance with the State’s records retention schedules after completion of the services and
closeout of the contract. The content and structure for each contract file must include:
• The fully executed agreement;

o Documentation of the procurement,
o Routing and approval for the executed contract
• Documented contract management and monitoring activities
o DFS Contract Monitoring Checklist
o Vendor onboarding records
o Deliverable acceptance documentation
o Deliverable tracking document (for multiple deliverables)
o Invoicing and Payment
o Risk Assessment
o Attestation of No Conflict of Interest
o Contract Audit Records
Link for DFS Contract Management Tools/Templates:

http://dfsintranet.fldoi.gov/Administration/generalservices/Lists/Contract%20Management/AllIte
ms.aspx
Deliverable Acceptance
The Contract Manager collaborates with each Track Manager and other assigned reviewers to
develop (when appropriate), review, and accept contract deliverables and work products provided
by the Project’s Contractors through the process defined in the Deliverable Management section
of this document.
Deliverable Tracking and Management

The Deliverable Management section defines the activities for the collaborative development,
review, and approval of each contract deliverable and work product. Deliverable Management
procedures establish the roles, approach and timeline for acceptance review, and the
development of a Deliverable Expectation Document (DED) for each deliverable that includes
contractual and more detailed acceptance criteria.
Upon contract award, the review cycles, agreed upon acceptance dates, invoicing, and payment
dates are entered and tracked in the Project Master Schedule. The Contract Manager works with
the Schedule Manager to record the completion of each scheduled activity or the percentage of
work completed to date in the Master Schedule.
Acceptance of Deliverables
Upon completion of review cycles, the Contract Manager verifies that all terms and conditions of
the contract and any additional criteria set forth in the DED have been met. Once verified, the
Contract Manager makes a written recommendation to the Project Director via email to accept
the deliverable. If the Project Director accepts the recommendation, the Contract Manager obtains
signatures on the Deliverable Acceptance Form Template to document the contract file and to
notify the contractor of formal acceptance prior to invoicing for payment.
Invoice Processing
Upon completion and documentation of all contract activities, vendors submit invoices for
payment of deliverables or billable hours worked. The payment and processing of invoices is
Page 48 of 138 11/09/2017

accomplished when the Contract Manager sends approved invoices and accompanying
documentation via email to the DFS Bureau of Financial Services (InvoicesToPay@fldoi.gov), or,
if an electronic invoice is submitted, it may be processed directly in MFMP. The Contract Manager
communicates payment activities with the Budget Specialist and indicates the acceptance date
and payment dates in the contract management deliverable tracking document.
Contract Closeout
A Service Quality Evaluation (SQE), as part of the Quality Management procedures, is conducted
on an ongoing basis during the term of any Project contract. At a minimum, SQE must be
performed as a part of contract closeout. The SQE defines the Contractor and Contractor services
that are subject to ongoing evaluation and identifies the appropriate Project Team Member(s) who
provide evaluation of the services. Time and materials contracts should define the criteria and
timing for review of results from service evaluations. However, both time and materials or
deliverables based contracts rely on SQE procedures for development of corrective action plans
if contactors do not meet the expected level of service quality.
Contract closeout contains three components:
1. Programmatic closeout documents that all deliverables, reports, and services were
delivered and accepted in writing, all performance standards were met, and the contract
file is complete.
2. Fiscal closeout verifies that all funds associated with the contract were appropriately spent
and invoices are documented and paid. This includes closeout of FACTS records.
3. Security closeout ensures the protection of the DFS assets. During the Security closeout,
the Contract Manager verifies the removal of information technology access by contractors
and the return of any DFS devices or tools.
12.4 Referenced Documents

• Department of Financial Services (DFS), Contract Management Lifecycle Guide
o Process Flows
o DFS Purchasing Services Tools/Templates:
http://dfsintranet/Administration/generalservices/Lists/Purchasing%20Services%20Links/
AllItems.aspx
• DFS Agency Policies and Procedures (AP&P), #2-02 Purchase of
Commodities/Contractual Services
• Florida PALM Master Project Schedule
• Florida PALM Spend Plan
• MyFloridaMarketPlace Agency Customer Resources

The Procurement Management roles and responsibilities are described below. This information
during each of the four (4) major areas of the Procurement Management Process as shown in the
figure below.
Page 49 of 138 11/09/2017

2 3 4
1
Contract Deliverable Contract
Procurement
Management Acceptance Closeout
Figure 14: Major Areas of the Procurement Management Process
Table 11: Procurement Management Roles and Responsibilities

Role Responsibilities 1 2 3 4
Project Manages and leads all Project activities, approves all A A A A
Director procurement activities, and accepts all contracted
deliverables.
PMO Manager Manages Project Management Office, reviews all C C C V
procurement activities and contracted deliverables.
Track Manager Manages Project Track (BPS, SDS, PMO and OCM) C C R C
including the evaluation of contract award or vendor
selection in Track related procurement processes;
provides subject matter expertise in the development of
related solicitations for goods and services for each
Track; responsible for day to day operations within any
contract.
Executive Overall responsibility for ensuring that the Project meets I/A I I/A I
Steering its primary business objectives including the approval of
Committee all major Project Deliverables and solicitation related
documents associated with the replacement of FLAIR
and CMS.
Schedule Manages the Master Project Schedule to include C C C C
Manager approved procurement activities.
Budget Administers the Cost Management Process for the C I C I
Specialist Project to include the development, monitoring, posting,
and reporting on costs of the Project Spend Plan.
Procurement Manages the procurement process to include strategy R I I I
Manager development, execution, and award or vendor selection
for services and goods.
Contract Manages Contract and vendor relations. C R V R
Manager
DFS Reviews and executes procurement activities in V I/V I I
Purchasing accordance with DFS Policies and Procedures on behalf
of the Project resulting in purchase orders/contracts;
serves as the sole point of contact during all formal
solicitations.
Legal Reviews procurement documentation and processes for A I I I
legal sufficiency.
Page 50 of 138 11/09/2017

13 Staffing Management
13.1 Overview
Staffing Management establishes the processes for onboarding and management related
activities concerning state employees/full time equivalents (FTE) and contracted staff
(Contractor). Project Team Members include both State and Contracted Team Members.
13.2 Purpose
Members regarding Staffing Management and associated activities. Staffing Management is used
to identify project roles, skills, number of positions, resource types, and specify the method(s) for
acquiring new personnel or incorporating and backfilling the current responsibilities of existing
personnel. All standards and procedures described are in accordance with the DFS Agency Policy
and Procedures (AP&P).
13.3 Process
The Staffing Management process is inclusive of four (4) major areas: Planning, Recruitment,
Administration, and Separation.
Planning
Resource Planning
At the start of the Project and each fiscal year, the Project Team projects the number of resources
needed and related costs for the upcoming fiscal year. Planning activities include establishing
resource types, roles, and skills needed. The Project utilizes a “What If” spreadsheet to plan and
forecast cost for FTEs and Project Spend Plan to forecast for Contractors. Projections include
salary and benefits for FTEs and Contractor costs and are provided to the DFS Budget Office for
inclusion into the annual Legislative Budget Request (LBR).
Position Creation
Track Managers create position descriptions for FTE resources. The position description shall
include an accurate description of the duties and responsibilities assigned to the position; the job-
related knowledge, skills, and abilities required for the position; any licensure, certification or
registration required for the position (including testing); and any position designators. A Scope of
Work defines the minimum and preferred qualifications of the position assigned to work on the
Project.
Recruitment
When the Project receives funding and authority, it uses a variety of channels for recruiting FTEs
including People First and Career Builder. The Project also has the ability to appoint an individual
to a position. The Project follows this process in accordance with the DFS Agency Policy and
Procedures (AP&P) #5-07, Recruitment and Appointments for Vacancies.
Standard interview questions are used for each interview and Track Managers are responsible
for including Track related questions. The Project maintains an Interview Log that tracks each
interview the Project conducts. Once the interviews are completed, the Track Manager will
evaluate the candidates based on skills, interview, and needs of the Project, to select a qualifying
candidate. The Track Manager will contact the qualifying candidate to provide a verbal offer
contingent on background screening and reference checks. The Track Manager will request a
Page 51 of 138 11/09/2017

list of references along with a signed State of Florida Application. Once the candidate start date
is known, the salary information is provided to the Budget Manager to update the Project Spend
Plan.
The Procurement Management section of this document includes information pertaining to the
recruitment and placement of Contractors.
Administration
The Administration process describes how the Project onboards and tracks Project Team
Members.
State Team Onboarding

There are several steps the Project will follow when onboarding State Team Members. Track
Managers will complete and submit the Employer Reference Check form. The Project Office
Manager will then package the hire packet together for approval and submit to DFS Human
Resources (HR) for review and processing. The packet consists of a completed Appointment
Processing Form, Appointment Request Form, signed State of Florida Application, reference
check forms, Position Description, and Personnel Action Memo. HR reviews the New Hire
Package and sends notification of receipt. Once the package is reviewed and processed, HR will
send a notification of approval to the Track Manager and Office Manager to proceed with
fingerprinting. Additional onboarding steps include:
• The candidate is required to contact the HR representative to schedule a fingerprinting
appointment at DFS. HR will complete the background screening and notify the Office
Manager and hiring Track Manager when screening is cleared and approved.
• The hiring Track Manager contacts the candidate to confirm a start date.
• The Office Manager will notify HR and HR will generate an offer letter.
• After the offer letter is generated, the Office Manager completes the following forms and
the candidate is approved to start on the date agreed to with the Track Manager:
o DFS Form 1820
o Building Access Form(s)
o Parking
o Updates Team Tracker Log
• The candidate is sent a “Day 0” welcome email including the Project Guidelines and Day
1 information at their provided email address.
Contractor Onboarding
When executing contracts and onboarding Contractors, the Track Manager/Contract Manager is
responsible for monitoring the onboarding steps to ensure a smooth process. Onboarding can
take several weeks and stretches across various divisions within DFS. The Contractor onboarding
steps/requirements below take place after the contract is executed:
• Acquire start date of Contractor(s)
• Contractor(s) submit signed Non-Disclosure Agreement (NDA)
• Fingerprinting and Background Screening
o Contractor to register/make appointment for fingerprinting
▪ Local: Fingerprinting will take place at the UPS store next to the Lake Ella Publix.
Processing time is on average 24-48 hours.
▪ Non-Local: Individuals that do not reside in the State of Florida must register at
the site http://www.l1enrollment.com/, request fingerprinting, and mail in
completed fingerprint cards per the site’s instructions. Processing time is on
Page 52 of 138 11/09/2017

average 5-7 days. The Contractor may also call MorphoTrust at 1-800-528-1358
to complete the registration process.
o 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.
• Once background screening is complete, the Office Manager completes:
o DFS Form 1820
o Building Access Form(s)
o Sends the Contractor information regarding parking
▪ Monthly parking reservations are handled by Republic Parking. Their contact
information is 850-561-3066. Only check or cash is accepted and the Contractor
must obtain the tag at the Republic Parking office.
▪ Duval Street lot is paved - $30 per month
▪ Bronough Street lot is unpaved - $20 per month
• The Contractor is sent a “Day 0” welcome email including the Project Guidelines and
Day 1 information at their provided email address.
Orientation
The Organizational Change Management (OCM) Team conducts Project Team Orientation and
Project Management Plan (PMP) training for all new Project Team Members.
State Team Member Performance Evaluations

State Team Members are required to have SMART Expectations by their assigned Track
Managers and performance evaluations are to be conducted using these annually. The Project
follows this process in accordance with the DFS Agency Policy and Procedures (AP&P) #5 -
Employee Performance Evaluation.
Contracted Team Member Performance Evaluations

Each Track’s Strategy identifies contractual services needed and desired knowledge, skills and
abilities (KSAs). Executed contracts define the minimum and preferred qualifications of
Contractors assigned to work on the Project. State Team Members are ultimately responsible for
managing Project Contractor(s). To ensure the timely delivery and high quality of work products
from Contractors, the Track Manager, or his/her designee, will meet weekly with the Contractor
to discuss the progress of the procured services. These meetings will be in person, or when
agreed upon, by teleconference. The purpose of these meetings will be to:
• Review significant activities that have been conducted or are underway
• Discuss any tasks/activities that are behind schedule and a plan to bring them current
• Discuss any problems that have been encountered and their resolution or plan for future
resolution
• Review goals or upcoming deadlines
The weekly meetings serve as an opportunity to ask questions ahead of time to prevent delays in
delivery and schedule. All Contractors are expected to operate as partners and work in good faith
to provide professional services based on best practices and industry standards
For Support Services Contractors, the Contract Manger will provide a monthly performance
assessment (quality, communication, timely completion of tasks) on the Contractor’s time sheet
provided by the Project.
Page 53 of 138 11/09/2017

Tracking and Monitoring

The Project maintains a Team Tracker Log of all Project Team Members that have worked on the
Project. The Log contains name, Track, access, software, training, and separation information.
The Project also maintains Project Organizational charts which are updated as Team Members
onboard and separate from the Project.
Separation
State Team Members
To facilitate the roll-off of State Team Members, the Track Manager will notify the Project Office
Manager to begin the exit process. Additionally, the Track Manager will need to ensure the
appropriate transfer of knowledge and final acceptance of work are complete. The exit process
includes the following:
• Complete CAR form and submit to Human Resources
• DFS Form 1820
• Collect Keys/Badges/Parking Tag/PCard
• Return Badges to DFS/Capitol Police
• Update Team Tracker Log
The Project utilizes the same recruitment procedures describes earlier, to back fill a position
following separation.
Contracted Team Members

To facilitate the roll-off of Contractors, the Track Manager will notify the Project Office Manager
and Contract Manager to begin the exit process. The Track Manager and Contract Manager will
need to ensure the appropriate transfer of knowledge and final acceptance of work are complete.
The exit process includes the following:
• DFS Form 1820
• Collect Keys/Badges/Parking Tag
• Return Badges to DFS/Capitol Police
• Update Team Tracker Log

The Staffing Management roles and responsibilities are described below. This information is
during each of the four (4) major areas of the Staffing Management Process as shown in the
figure below.
1 2 3 4
Planning Recruitment Administration Separation
Figure 15: Major Areas of the Staffing Management Process
Page 54 of 138 11/09/2017

Table 12: Staffing Management Roles and Responsibilities
Project Director Manages and leads all Project activities, A A A A
including the development and approval of
all Staff for the Project.
Track Managers Manages and leads their tracks activities, R/C C C V
including the development and approval of
all Staff for their track.
Office Manager Manages Staff Management Process for R/V R R R
the Project to include the creation,
administration, and tracking of staff for the
project.
Procurement/ Provides subject matter expertise and C I I I
Budget Specialist offers guidance on budget matters.
Executive Steering Reviews and receives updates for Project I I I I
Committee Member Team Member(s).
Page 55 of 138 11/09/2017

14 Collaboration Management
14.1 Overview
Collaboration Management establishes the processes of effectively identifying and engaging in
collaboration activities with the appropriate collaborative partners. This section details the
Collaboration Management Standards and Procedures to be used when participating in
collaboration activities, engaging collaborative partners, reporting on collaboration metrics, and
managing overall Project collaboration.
14.2 Purpose
The purpose of this section is to provide instructions to the Project Team regarding Collaboration
Management. Collaboration Management ensures the Project effectively engages and
communicates with Project stakeholders and other entities to support the goals and objectives
identified in the Project’s Collaboration Strategy.
14.3 Process
The Collaboration Management process is described as four distinct time periods and outputs:
Annual Collaboration Strategy, Quarterly Collaboration and Communication Status Report, and
Monthly Collaboration Checkpoint.
Page 56 of 138 11/09/2017

Annually
Weekly Monthly Quarterly
(State Fiscal Year)
Process
Start
OCM Coordination
Coordinator
Develop and Update Draft Update Draft

Develop Publish Review Status
Update Draft Submit Draft Collaboration Collaboration
Draft Fiscal Fiscal Year Reports and
Collaboration Collaboration and and
Year Update Draft Collaboration Update Project
Strategy and Communications Communications
Collaboration Collaboration Strategy Meeting log Communications Status Report Status Report
Strategy Strategy Status Report
Conduct
Collaboration
Checkpoint
Meeting Yes
Track Managers
Review Draft
Yes
Collaboration
Conduct/Attend and Updates
Review Draft Collaboration Communicati Needed?
Updates
Collaboration Events and ons Status
Needed?
Strategy Update Track Report
Status Reports No
No
Yes
Project Director
Yes
Review Draft
Review
Collaboration
Fiscal Year
CRM #1 Updates CRM #1 and Updates
Collaboration No
Needed? Communications Needed?
Strategy for
Status Report
Approval
for Approval
No
Project Team
Member
PMO Team
Member
Attach Status
Report to Process
Project Status End
Report
Figure 16: Collaboration Management Work Process Flow
Page 57 of 138 11/09/2017

Annually
Prior to the beginning of each FY, the Project Team begins development of a new Collaboration
Strategy. First, OCM Collaboration Coordinator reviews the previous FY’s Collaboration Strategy
and data in order to evaluate its applicability to the new FY. If the Strategy is still consistent with
the Project’s collaboration goals and objectives, it’s carried over to the new FY. If the Strategy is
not consistent with those goals and objectives, a new strategy is developed. The OCC consults
with the Track Managers on continuing or new directions in collaboration for each Track and the
Project as a whole. The OCC reviews topics that were identified during monthly collaboration
checkpoint meetings, and Lessons Learned (as appropriate), for the previous FY. Using this
information, the OCC develops the draft Collaboration Strategy for the new FY and submits it to
the Project for review, acceptance, and later release.
Quarterly
The OCC and OCM Track Team members develop a quarterly Collaboration and Communication
Status Report. This Report attached to the Project’s monthly Status Report submitted on the final
month of each quarter. The Status Report is reviewed during the last Checkpoint meeting of the
quarter.
Monthly
The Project Track Managers (or their designees), Deputy Project Director, Project Director, and
the OCC participate in monthly collaboration checkpoint meetings. The purpose of this meeting
is to:
1. Review and verify the previous month’s collaboration activity information (as needed);
2. Discuss upcoming collaboration activities; and
3. Evaluate the progress of collaboration activities against the objectives outlined in the
Collaboration Strategy.
The OCC presents data on the Project’s collaboration activities for the month to the Track
Managers, Project Deputy Director, and Project Director for verification.
Weekly
Project Team Members conduct and/or participate in a variety of collaboration activities
throughout the FY. Information from these activities is collected, and entered in the Meeting Log
Summary table by each Track.
Reporting
The Project reports on collaboration activities using four reporting mechanisms. Each mechanism
provides support to, and information for, a specific time period listed above.
First, as described in the Annual section above, the Project produces an FY Collaboration
Strategy. Each FY Collaboration Strategy defines the focus for the Project’s collaboration efforts
and identifies potential collaboration partners and activities.
The second reporting mechanism is the Track Status Report. Each Track is responsible for
updating the Track Meeting Log Summary table in the Track Status Report. The OCC verifies this
information when populating the Meeting Log on the Project’s SharePoint main page. The Meeting
Log serves as the Project’s official record of meetings/activities that occur between Project Team
member(s) and at least one person from outside the project where the meeting was conducted
by Project Team Member(s); or if not conducted by Project Team Member(s), a discussion about
Page 58 of 138 11/09/2017

the Project was a component of the meeting. The Meeting Log is updated weekly following the
submission of Track Status Reports.
The third reporting mechanism are the Monthly Collaboration Checkpoint meetings. The OCC,
Track Managers, Deputy Project Director, and Project Director review and verify collaboration
activity details from the previous month (as needed) and discuss upcoming collaboration
activities. They evaluate the progress of collaboration activities against the objectives and goals
identified in the Collaboration Strategy. If progress is not consistent with the objectives and goals,
the OCC and the Track Managers determine where and how corrections need to be made. (e.g.,
Adjust future collaboration efforts to be in-line with the accepted Collaboration Strategy.)
The final reporting mechanism is the Collaboration and Communication Quarterly Status Report.
This report is prepared by the OCC and submitted at the end of each quarter. The final accepted
report is attached to the Project Monthly Status Report submitted the last month of the quarter.
The Project has identified three collaboration metrics for evaluating the Project’s collaboration
efforts:
• Collaboration Activity Efficacy – did the Project realize the expected benefit from the
activity? For example: Project Team Members attended a meeting where the focus was
possible pitfalls. Where potential pitfalls identified during the meeting?
o Yes – the meeting provided Project Team Members with excellent examples of
potential pitfalls
o No – the meeting did not provide Project Team Members examples of potential
pitfalls
• Collaboration Rates
o The total number of collaboration activities per month, quarter, and annum
o The total activities held with selected collaborative partners per month, quarter,
and annum
• Collaboration with State Agencies – The number of State agencies that use the FLAIR
and/or CMS with whom the Project has collaborated, and the frequency of collaboration.
While the Project will use some metrics across multiple FYs and evaluate for trends, the Project
will also continue to assess applicability of existing metrics and potential new metrics as the
Project matures.

The Collaboration Management roles and responsibilities are described below. This information
and responsibilities during each of the four (4) major areas of the Collaboration Management
Page 59 of 138 11/09/2017

4
1 3
2 Quarterly
Annual Monthly
Weekly Track Status Collaboration
Collaboration Collaboration
Report Updates Communications
Strategy Checkpoint
Status Reports
Figure 17: Major Areas of the Collaboration Management Process
Table 13: Collaboration Management Roles and Responsibilities
Manages and leads all Project activities,
Project Director including acceptance and verification of A A C A
collaboration management documents
Manages Project Track activities, represents
each Track during monthly collaboration
checkpoint meetings, leads and/or participates
Track Manager(s) C R V C
in collaboration activities, and provides
comments and feedback on collaboration
activities
Manages the Project’s Collaboration
Management process including the
OCC development of Collaboration documents, R I R R
monitoring of collaboration activities, and
reporting collaboration activities
In addition to Project work responsibilities;

Project Team
participates in, and provides comments and I C I I
Members
feedback on, collaboration activities
Ensures the Collaboration and Communication

PMO Team Status Report is attached to the Project’s
N/A N/A N/A V
Member Monthly Status Report submitted for the last
month of each quarter
Page 60 of 138 11/09/2017

15 Project Scope and Change Management

15.1 Overview
Project Scope and Change Management describes the change control process for tracking and
gaining approval on Project changes. The process exists to communicate to all necessary parties
a change is needed and will be managed to ensure the Project is protected against unauthorized
work activities.
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 change by submitting a Project Change Request (PCR).
The Project Scope and 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 (e.g., 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.
Project Scope and 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
Team Members will apply appropriate effort to support a timely Project Change Request process.
15.2 Purpose
The purpose of these procedures is to provide instructions and define how the Project will manage
changes that impact scope, cost, schedule, and/or quality.
15.3 Process
A PCR can occur throughout the life of the Project and are often the result of a Project risk or
issue that has been evaluated to determine that a change is required. A PCR can come from
newly identified or changing needs, or external factors having an impact on the Project.
Project Change Identification

The process begins when a Requestor has identified a change that impacts the Project’s scope,
schedule, budget, or resources. The Requestor is responsible for logging an identified change for
additional resources, additional funding, a change in the Project schedule, or change as
necessary for Project success.
The Requestor will draft a PCR Form and then enter the request in the PCR Log, which is used
to document and track change requests. The PCR Log is located on the Project’s SharePoint site
and includes all the information contained in the PCR Form. The PMO is responsible for the
maintenance of items in the PCR Log as well as monitoring the progress.
Minor Project Adjustments

As a basic guideline, any 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 PCR
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 Manager is responsible for
determining whether a change is a minor adjustment or a significant change. Minor adjustments
Page 61 of 138 11/09/2017

can be reclassified and moved to the PCR 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 Team to the Track Manager.
• The Project change is vetted by the Track Team to make sure it is reasonable.
• The Project change is reviewed by the Track Team to determine 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 Evaluation

The Project Management Office (PMO) is responsible for evaluating and determining the validity
of a PCR. If the PCR is determined to be not valid, the PMO will mark the PCR as Removed. If
determined to be a valid request, the PMO will work with the respective Track Manager to review
and update the PCR. A list of items to consider during review, can be found in the table below.
Table 14: Project Change Request Review Considerations

Review Considerations
Has a PCR been filed by a member of the Project Team or by a stakeholder
1
(requirement, change, problem, defect, or other change)?
2 Has the PCR been documented?
3 Has the PCR request been prioritized?
4 Has an approach been identified to handle the PCR?
5 Has a workaround been identified if the PCR is not implemented?
6 Has it been acknowledged that the PCR applies to this project?
Has an independent team or member (not the originator) reviewed the PCR to determine
7
whether or not it is worth evaluation for action?
Have estimates been developed for the effort, cost, schedule, and resources required by
8
the PCR?
Has the PCR, with estimates, been evaluated and authorized by a Change Control Board
9
or other authority?
10 Have the results of the above evaluation been communicated to the requester?
11 If the change is denied, has the requester been notified?
Any questions or issues regarding the PCR should be addressed, to make sure the
documentation is complete, clear, and accurate prior to submitting it to the Change Control Board.
Once the PCR has been determined to be ready for submission, the PMO will notify the Project
Director and request the Project Director conduct a preliminary review. Upon satisfactory review
from the Project Director, the PCR is scheduled for review by the Change Control Board (CCB).
After favorable recommendation from the CCB, the Project Director will review PCRs meeting Tier
1, as defined in the Project Charter. PCRs meeting Tier 2 criteria, as defined in the Project
Charter, are scheduled for review by the Executive Steering Committee (ESC). In both cases, a
decision will be rendered of Approved or Rejected. The PMO will update the PCR Log to reflect
the decision by the ESC.
Page 62 of 138 11/09/2017

Figure 18:Project Scope and Change Management Process
Page 63 of 138 11/09/2017


The Project Scope and Change Management roles and responsibilities are described below. This
information is presented in a RACIV (Responsible, Acceptor, Consulted, Informed, or Verify)
responsibility-matrix format, as defined in Section 7 of this document. The table below depicts the
RACIV role and responsibilities during each of the four (4) major areas of the Project Scope and
Change Management Process as shown in the figure below.
1 2 3 4
Identification Evaluation Approval Close
Figure 19: Major Areas of the Project Scope and Change Management Process
Table 15: Project Scope and Change Management Roles and Responsibilities
Roles Responsibility 1 2 3 4
Requester • Identify, document, log, and submit PCR. R I I I
• Works with the PMO to review all PCRs for I R/V I I
Track completeness and impact quantification (schedule,
Manager cost) prior to review by the Project Director and
Change Control Board.
• Owns and manages the PCR process. I R/V I R
• Reviews all PCRs for completeness and impact
quantification (schedule, cost) prior to review by
the Project Director and Change Control Board.
PMO
• Maintains PCR Log, monitors progress, and
reports on PCR decisions and outcomes.
• Updates Project work products (scope, schedule,
resource plan, etc.) as needed.
• Performs preliminary review of PCR prior to CCB I C/I R/A C/I
submission.
• Approves or rejects PCRs that meet the Tier 1
Project criteria, as defined in the Project Charter.
Director • Escalates changes that meet the Tier 2 criteria to
the ESC.
• Communicates PCR status to the CCB and
Project Team.
• Members will include PMO Manager, Track I I R I
Managers, Project Risk Manager, and designated
PMO Team Members.
• Reviews and provides considerations for changes
Change
requested.
Control Board
• Participates as needed in determination of
whether change is required.
• If change request is rejected, determine
appropriate course of action.
Executive • Approves or rejects changes meeting Tier 2 I I R/A I
Steering criteria defined in the Project Charter - Appendix
Committee A.
Page 64 of 138 11/09/2017

16 Risk Management
16.1 Overview
Risk Management proactively identifies or manages potential events that can adversely affect the
Project’s ability to achieve its stated goals or objectives. Risk Management employs mitigation
strategies to avoid risks turning into issues. The identification, tracking, and remediation of risks
is critical to the Project’s success.
16.2 Purpose
The purpose of these procedures is to provide instructions for the Project, Project’s Risk Manager,
and Project Team Members regarding Risk Management.
16.3 Process
Risk Management methods consists of four primary components: Assessment, Evaluation,
Control, and Reporting. Each component includes two elements as illustrated in the table below.
Table 16:Risk Components and Elements

Risk Management
Assessment Evaluation Control
Identify Analyze Prioritize Plan Actions Resolve
Risks assessments are performed on a regular basis throughout the project life cycle. The Project
shall adopt the following risk assessment events.
1. An assessment shall be conducted annually where risks are recorded in the Project’s
tracking tool.
2. At the completion of Project strategy, plans, or procurement documents, a risk
assessment exercise will be performed to record any challenges the Project may face to
operationalize and fulfill the objectives of the document.
3. After significant events, such as scope changes to schedule, cost, staffing, Project major
deliverables or outcomes, as well as staff turnover.
The remaining part of this section will provide an explanation of risk components and elements
illustrated in Table 16 above.
Risk Assessment Elements

Risk Identification
Risk Identification produces a list of Project-wide and Track-specific risk items likely to
compromise the Project's outcomes. Risks can be identified through risk surveys, interviews,
assessment meetings, and personal experience.
A Risk Log will be utilized to enter, track, review, modify, monitor, and update status. The Project’s
Risk Manager monitors the Risk Log to verify risks are recorded and updated appropriately. New
Risks will be reviewed, including determination of validity, by the Risk Management Team on a
bi-weekly basis. If the risk is deemed to be invalid, the status will be changed to “Removed” in the
Risk Log.
The following are guidelines for risk data collection attributes:
Page 65 of 138 11/09/2017

1. Risk Breakdown Structure (RBS) attributes are used in the risk log to categories the risks.
2. Risk status classified as “monitoring” is used when the actions required for mitigating are
outside the control of the Project.
3. Risk status classified as “mitigating” is used when the Project has direct control of the
outcomes.
4. Due dates differ for Risk status classified as monitoring versus mitigating.
a. Risk with a status classification of monitoring will use the end of fiscal year date.
Example: 06/30/2017
b. Risk with a status classification of “mitigating” will use a date identified on the
master project schedule that corresponds to a deliverable, milestone, or event that
matches the recorded risk. In the event a specific schedule due date is not
identified, the Risk Management Team will identify an appropriate due date, based
on the agreed to actions.
5. Ownership is assigned as Project-Wide or to a specific Project track.
a. Project-Wide ownership are risks having a mitigation or monitoring plan involving
participation from more than one Project track. These types of risks will be
assigned to the Project Director and plan task execution will be assigned to the
PMO.
b. Project track ownership are risks assigned to a Track Manager when the activities
of responsibilities fall within the functional responsibilities of a specific Project
track.
6. Risk trending attributes are stable, increasing, or decreasing. This value is also
established at the initial Project agreement to manage and record the risk and will likely
change during the risk mitigation life cycle. Risk trending values are updated, most often
when a risk mitigation step has been completed. The value also can be updated if an
unforeseen event occurs.
Risk Analysis
Qualitative risk analysis is the process of characterizing an identified risk into a set of impact
categories. The risk Owner, in collaboration with the Project’s Risk Manager, will present the risk
qualification description to the Risk Management team as part of the risk submission process.
Quantitative Risk Analysis is the process of quantifying the risk impact to determine their likely
impact to the Project’s identified outcomes in the Project’s charter, scope, and supporting strategy
documents.
Table 17 below provides the risk impact descriptions as a result of the qualitative and quantitative
analysis.
Page 66 of 138 11/09/2017

Table 17: Risk Qualitative and Quantitative Analysis
Risk Quantitaive Risk Qualitative Categories
IMPACT Rating Cost Schedule Requirements Staffing Quality
Adjustment less than 5 hours
Little or no impacts,
Low = 1 Little or no impacts to incorporate into all N/A N/A
less than $500
affected work products
Impact is "One Week or Adjustment, 5 - 10 hours to Staff member change Potential Quality issues
Moderate = 2 Impact is $501- $10K less to "Schedule Critical incorporate into all affected will have "Medium Cost will have "Medium Cost
Path" work products or Schedule" impact or Schedule" impact
Impact is One to Four Staff member change Potential Quality issues

Impact is $10K - Adjustment will have "HIGH
Important = 3 Weeks to "Schedule will have "HIGH Cost or will have "HIGH Cost or
$50K Cost or Schedule" impact
Critical Path" Schedule" impact Schedule" impact
Impact is greater than Staff member change Potential Quality issues

Impact is greater Adjustment will have "MAJOR
Critical = 4 Four Weeks to will have "MAJOR Cost will have "MAJOR Cost
than $50K Cost or Schedule" impact
"Schedule Critical Path" or Schedule" impact or Schedule" impact
Given risks are a forecast of potential issues, a probability value must be derived. Table 18
provides the values for risk probability.
Table 18: Risk Probability Values

Possibility of
Proability Value
Occurance
< 50% Low 1
> or = 50% High 5
The Risk Impact and Probability are updated in the Risk Log and the Risk Evaluation process
begins.
Risk Evaluation Elements

Risk Prioritization
The first step in the risk prioritization process is to confirm or revise the risk impact analysis
documented by the qualitative and quantitative values. The Risk Management team performs
this activity as a part of the evaluation step in the process.
The risk score is the product of the impact and probability values, and is calculated in the Risk
Log. This score sets the prioritization of the risk and aids in the mitigation and response planning,
as well as frequency of risk monitoring. The table below illustrates the derived calculations.
Table 19: Impact and Probability Calculations
Page 67 of 138 11/09/2017

After the risk score/prioritization has been determined, the Risk Management Team will determine
whether the risk will be mitigated, monitored, transferred, or accepted. The risk score never
changes after it has been approved to be worked on by the Risk Management team. The risk
trending value may change through the risk management life cycle. This is explained in further
detail in the Risk Control Elements section.
Risks with a score of “20” will be included in the Project’s monthly status report.
Risk Planning
The goal of risk planning is to determine close criteria and supporting action steps to be taken for
mitigating or monitoring risks. The results of the quantitative, qualitative, and risk score should be
considered when developing the action steps. The resulting information documented for risk
resolution includes:
1. The close criteria, most often associated with a Project milestone, deliverable, decision,
or action item.
2. Sequence of action steps to achieve the close criteria.
3. Resources who will own the action steps.
4. Expected completion dates for the action steps.
5. Action step status reporting: Not Started, In Progress, Completed
Typical risk 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 the Project’s planned
objectives and outcomes.
Upon completion of risk planning, the data is recorded in the Risk Log and presented to the Risk
Management team for review and acceptance.
Risk Control Elements

Risk Actions
Risk actions come in one of two forms: risk mitigation and risk monitoring. Risk mitigation includes
completing the identified steps to achieve the risk close criteria. Risks identified to be monitored
may have an event occur which could result in the need to identify risk response actions. These
actions are performed to minimize the impact of a risk.
The Project will track all risk actions to closure, taking any corrective action as appropriate and
will report on the risk mitigation progress and any impediment to close the risk. Additionally, the
Owner or Project Risk Manager will update the trending of the risk as stable, increasing, or
decreasing.
Risk Resolution
The primary goal of risk resolution is to successfully resolve the risks by executing the identified
actions for mitigating or monitoring described in the Risk Planning section above. These actions
are designed to prevent adverse impacts to the Project and address events which may lead to
the risk becoming an issue.
If a risk turns into an issue, follow the procedures document in the Issue Management section of
this document.
Page 68 of 138 11/09/2017

Figure 20: Risk Submission and Resolution Process
Page 69 of 138 11/09/2017


The Risk Management roles and responsibilities are described below. This information is
matrix format. The table below depicts the RACIV role and responsibilities during each of the
three (3) major areas of the Risk Management Process as shown in the figure below.
1 2 3 4 5
Identification Assess Evaluate Control Close
Figure 21: Major Areas of the Risk Management Process
Table 20: Risk Management Roles and Responsibilities

Role Responsibilities 1 2 3 4 5
Requester • Identifies and records the risk
R R I I I
(anyone) in the risk log.
• Works with Project Risk
Manager to characterize the
risk(s) and formulate and
execute the mitigation or
monitor action plan.
• The Track Manager owns,
Owner manages, and reports on task I C R R R
progress for risks assigned to
their Track.
• The PMO Manager owns,
manages, and reports on task
progress for risks identified as
Project-wide.
• Owns the creation,
implementation, and
Risk
continuous process
Management I I A V I
improvement of risk
Team*
management.
• Monitors risk progress.
• Coordinates and facilitates risk
assessments.
• Works with Track Managers to
Risk Manager C C V R/C R/C
identify and create risk
response and mitigation plans.
• Reports progress on all risks.
*Members of the Risk Management Team include the Project Risk Manager, Project Track Managers, Deputy Director, and Project
Director.
Page 70 of 138 11/09/2017

17 Communication Management
17.1 Overview
Communication Management establishes the process of effectively communicating with and
disseminating information to the Project’s stakeholders and the public, and includes the
generation, collection, storage, dissemination, monitoring, and disposition of Project information.
Efficient and effective communication management is critical to overall Project success. Both
Project leadership and Project Team members benefit greatly from timely, accurate, and
predictable communications. In addition, communication of progress to stakeholders supports
their alignment with Project goals, objectives, status, and upcoming events.
17.2 Purpose
Good communication management enables Project leadership and team members to be 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 communication with Project sponsors, Project
leadership, and stakeholders, managed by the PMO. The Organizational Change Management
(OCM) Track will develop a change communication strategy to facilitate awareness and support
among the Project’s external stakeholders.
As representatives of the Project Team, all individuals are responsible for delivery of clear and
consistent communication for the Project. There are many stakeholders with interest in the
progression of the Project. As such, it is vital for the Project Team to have established
communication standards within the organization to effectively deliver the intended message to
the target audience.
Overall objectives include, but are not limited to, the following:
• Raise and maintain stakeholder awareness of Project’s status/activities, which aligns with
the CFO’s commitment to encouraging responsible government, accountability, and
transparency
• Provide messaging which acknowledges and addresses audience concerns
• Increase desire for change among stakeholders
• Support ongoing collaboration activities
• Assist in readiness activities for stakeholders
Additionally, this section will identify:

• What will be communicated
• Who is responsible for communicating with each audience
• When the communication will take place
• How information will be communicated
• Where the sent communication will be documented
The following sections describe the Project’s Communication Management approach including
Communication Infrastructure, Project Brand Management, Stakeholder Groups, General Public,
Media, Vendors, Content Standards, and Communication Tactics.
Page 71 of 138 11/09/2017

17.3 Communication Infrastructure

While the Project has created a communication infrastructure, which is augmented by supporting
technologies (including SharePoint) and explicitly aligned resources, all members of the Project
Team are considered to be part of this necessary aspect of the Project. The OCM Team and the
Project’s Management Team collaborate and coordinate on Project-related communications with
the DFS Office of Communications as well as various stakeholders. The communication
infrastructure also includes utilization of several Project Support Tools (PSTs). The Project uses
these tools to distribute and/or manage communication tactics like surveys, emails, and the
website. In addition, the DFS Office of Communications and Office of Publications provide
creative and graphic design support services to the Project, as needed.
17.4 Project Brand Management

Given the volume of projects and programs implemented by varied State entities, it is important
that the Project continue to build and maintain its own unique brand. This Plan provides tools and
approaches to create and maintain positive brand awareness, as well as monitoring the use of
the brand both within the Project Team and among external audiences.
Project Style Guide and Templates

The Project has adopted a Project Style Guide that provides a set of standards for writing and
distributing Project content. This set of standards is used to establish a consistent approach to
Project communications and includes items such as logo usage guidelines, color templates, and
document standards. The intention of using a Style Guide is to help both Project Team members
create consistent and cohesive brand recognition for the Project. The Style Guide is updated
quarterly, and training on Style Guide updates is provided to the Project Team as needed.
The Project has also adopted several standard formats (e.g., agenda, meeting summary, status
report, and presentations) as commonly used templates. These templates are used to ensure
brand consistency across Project publications and are available to all Project Team members on
the main SharePoint page. Project Team members coordinate with the OCM Team for additional
needs when an existing template may not be suitable.
Brand Monitoring
In addition to monitoring efforts performed by the DFS Office of Communications, the Project’s
OCM tracks several keywords to monitor the Project’s online presence using Google Alerts.
Keyword detection often picks up new mentions of the keyword in news articles, blogs, and
message boards. Significant mentions of the Project are shared with the Project Director, OCM
Team, and DFS Office of Communications. The Project Team will coordinate and collaborate with
the DFS Office of Communications, as appropriate, should a response be necessary.
Keywords tracked by the Project include:

• CFO’s name
• Department of Financial Services PALM
• Department of Financial Services Planning, Accounting, and Ledger Management
• Department of Financial Services Project
• DFS PALM
• DFS Planning, Accounting, and Ledger Management
• DFS Project
• Florida Accounting Information Resource
Page 72 of 138 11/09/2017

• Florida Cash Management System

• Florida CMS
• Florida CMS replacement
• Florida ERP
• Florida ERP solution
• Florida Enterprise Resource Planning
• Florida Enterprise Resource Planning solution
• Florida Financial Management System
• Florida Financial Information Management Systems (FFMIS)
• Florida FLAIR
• Florida PALM
• Florida PALM Project
• Florida Planning, Accounting, and Ledger Management
• FLAIR replacement
• Project Director’s name
17.5 Stakeholder Groups

Project stakeholder groups are broken into target audiences for Project communications.
Communications are generally tailored by audience, and some individuals who receive Project
messages may be a part of multiple stakeholder groups. These groups have been categorized
and identified below as follows: State Government; General Public; Media; and Vendors.
State Government
Elected officials, employees, or contractors of the State of Florida. The Project has identified the
following State government groups that may impact or may be impacted by the future system.
Executive Office of the Governor (EOG)

The Governor is the State’s Chief Executive Officer and oversees the majority of State agencies.
The EOG also maintains the Office of Policy and Budget (OPB) as well as the State’s official
appropriations system called Legislative Appropriations System/Planning and Budgeting
Subsystem (LAS/PBS).
Governor and Cabinet

The Florida Cabinet is made up of the following three statewide elected officials: Attorney General;
Chief Financial Officer; and Commissioner of Agriculture. The Governor and Cabinet are
collectively responsible for overseeing several State agencies. Each member of the Cabinet also
individually oversees an agency related to their position. In addition, the Governor, Attorney
General, and Chief Financial Officer oversee the State Board of Administration.
Florida Legislature
The Florida Legislature is the legislative branch of Florida government and includes the Florida
House of Representatives, Florida Senate, and legislative staff. The House is comprised of 120
members elected from single-member districts across Florida, and the Senate is comprised of 40
members elected from single-member districts across Florida. In regard to the Project, the
Legislature, with the support of legislative staff, is responsible for appropriating funding for the
Project, creating proviso that stipulates requirements for funding to be released, and considering
legislative policy changes for successful financial management solution implementation.
Page 73 of 138 11/09/2017

Executive Steering Committee (ESC)

The 15-member Project governance body that has the overall responsibility for ensuring that the
Project to replace FLAIR and CMS meets its primary business objectives. The Chief Financial
Officer or Executive Sponsor serves as the Chair of the ESC.
Project Sponsor
The State Agency senior management role that approves the allocation of resources for an
endeavor, develops a common vision, provides ongoing commitment to the project, and
continually assesses success. Florida PALM Project Sponsors include leadership from the
Division of Accounting and Auditing, Office of Information Technology, Division of Treasury, and
the Deputy CFO of Operations.
FFMIS Partners
The accounting, budgeting, cash management, human resources, and procurement subsystems
of the State of Florida established by section 215.93, F.S. Each of the five Florida Financial
Management Information Systems (FFMIS) and their functions/owners are listed below:
• Legislative Appropriations System/Planning and Budgeting Subsystem (LAS/PBS)

– A system that serves as the statewide appropriations and budgeting system owned and
maintained by the (EOG).
• Florida Accounting Information Resource (FLAIR) – A computer-based accounting
system consisting of the following four components: departmental accounting (a double
entry general ledger based subsystem used by agencies); central accounting used by the
Chief Financial Officer (Division of Accounting and Auditing) for appropriation and fund
cash control; payroll processing; and information warehouse. FLAIR is owned and
maintained by DFS.
• Cash Management System (CMS) – A collection of Treasury-operated, separate
systems that supports DFS Division of Treasury’s responsibilities: of monitoring cash
levels and activities in State bank accounts; keeping detailed records of cash transactions
and investments for State agencies; and paying of warrants and other disbursements
issued by Florida’s Chief Financial Officer. CMS is owned and maintained by DFS.
• MyFloridaMarketPlace (MFMP) – A system that serves as Florida’s web-based source
for centralized procurement activities, streamlining interactions between vendors and
State government entities, and providing the tools to support procurement. Department of
Management Services (DMS) is the functional owner of MyFloridaMarketPlace.
• People First (PF) – A system that serves as the State of Florida’s self-service, secure,
web-based human resource information system, and enterprise-wide suite of human
resource services. DMS is the functional owner of People First.
Agency Leadership and Employees

Agency leadership include State agency heads or those who oversee a State agency (e.g.,
agency secretaries and directors) and their executive management teams. Communication to
agency leadership typically should originate from DFS leadership (e.g., the Chief Financial Officer,
Chief of Staff, or Project Director). Employees includes all staff (outside of DFS) who comprise
the workforce within their respective State agencies.
Page 74 of 138 11/09/2017

DFS Employees
DFS employees in the Division of Audit and Accounting (A&A), Division of Treasury, and Office
of Information Technology (OIT) will continue to be heavily engaged with the Project due to their
role as functional and technical owners of the current systems (FLAIR/CMS).
Agency for State Technology (AST)

Agency for State Technology (AST) was established in 2014 to oversee the State's essential
technology projects and house the State Chief Information Officer. AST serves as an oversight
entity for large State IT projects.
Agency Administrative Services Directors (ASDs)

The Administrative Services Directors (ASDs) are the individuals at State agencies responsible
for the human resource (personnel), purchasing/procurement, and finance & accounting functions
of their agency. The Division of Accounting and Auditing (A&A) coordinates monthly Florida
Association of State Agency Administrative Services Directors (FASAAD) meetings with ASDs.
Agency Chief Information Officers (CIOs)

The Chief Information Officers (CIOs) are the individuals at State agencies responsible for the
information technology (IT) functions of their agency. AST coordinates monthly CIO workgroup
meetings with agency CIOs.
General Public
DFS is dedicated to accountability, efficiency, and transparency. While most of the Florida PALM
Project’s activities are considered to be public record, the Project identifies the general public as
a target audience in an effort to increase transparency and share information about the Project
and its status.
Media
News organizations or other organizations dedicated to delivering news and mass communication
to the general public or targeted audiences.
Traditional Media
Traditional media include local, statewide, national, and international news organizations such as
newspapers, magazines, blogs, radio, and television. Examples of traditional media outlets
include organizations like: CNN, Tallahassee Democrat, WFSU, Florida Trend, SaintPetersBlog,
and WCTV.
Trade and Specialized Media

Trade publications are news organizations dedicated to targeted audiences and typically publish
articles tailored for their specified audience. Examples of trade publications include publications
like: Accounting Today, e.Republic, Florida CPA Today, and WIRED.
Vendors
Vendors are categorized in two non-exclusive categories described below.
Vendors Currently Doing Business with the State of Florida

The State of Florida has more than 80,000 vendors registered to do business with the State.
Florida PALM’s implementation will have broader implications for the State’s existing vendor
Page 75 of 138 11/09/2017

community (e.g., the Department intends to migrate the majority of vendor payments from paper
warrants to electronic funds transfer (EFT)).
Vendors Interested in the Project’s Procurements

Numerous vendors may be interested in the Project’s procurements for support services,
including those that may propose to be the SSI.
17.6 Content Guidelines

The Project has identified standards that all Project communications should consider
incorporating during development and release. Some of these standards are listed below:
• Data points: Communications should include interesting statistics or data relevant to the
topic (e.g., “Did you know there are more than 80,000 vendors registered to do business
with the State of Florida?”).
• DFS themes: The Project should seek to capitalize on the Department’s established
themes in all external and public communication. The Department’s themes are:
o Encouraging responsible government
o Expanding economic capacity
o Broadening consumer advocacy
o Fighting fraud and abuse
o Accountable and transparent financial transactions
• Project story: Communications should include components of the Project’s vision and
story while answering questions related to the Project.
• Graphics: The Project should use infographics, including charts and other images, to
provide visual representation of information, data trends or other knowledge that support
key messages
• Plain language: The Project understands the importance of speaking and writing in plain
language. All Project communications should be easily understood the first time they are
read or heard.
• Quotes: Direct quotes will be included in Project messages where relevant. Quotes will
be taken from varied executives, key stakeholders, and other individuals, and will primarily
be used with public communications.
• Project Talking Points: The Project has developed Talking Points, which are included in
Appendix A of this document. These Talking Points combine many of the content
standards mentioned in this section. The Talking Points will be updated as necessary by
the OCM Team, added to the Project SharePoint site, and disseminated to the broader
Project Team via email and in team meetings as the Pre-DDI Phase continues.
• Project themes: In addition to the aforementioned DFS themes, the Project also has
unique themes. Some of these themes are listed below:
o Collaboration
o Deliberate planning
o Documentation
o Risk mitigation
o Transparency
17.7 Communication Tactics

As previously mentioned, successful communication is critical to the Project’s overall success.
The Project routinely communicates with identified stakeholders through various communication
tactics as deemed appropriate. There are several communication tactics available for releasing
Page 76 of 138 11/09/2017

communications. Each of these tactics are briefly described below. These tactics are not exclusive
or exhaustive, and others may be added to this Plan and deployed as the project proceeds.
Ad Hoc/As Needed Communication

In an effort to adapt to the unique needs of such a large-scale project, ad hoc or as-needed
communications may be developed and released when deemed appropriate. These types of
communications may be reactive or proactive to various Project accomplishments, milestones,
and engagement opportunities. The Project’s Management Team and OCM Team are
responsible for identifying when this type of communication is warranted.
Conference Calls
Conference calls connect three or more individuals. Conference calls should be used to
accommodate meetings and collaboration with individuals not able to participate in person. In
general, conference calls should be set up through the FloridaPALM@myfloridacfo.com calendar.
Emails
Emails are used daily as part of Project operations, but mass email messages, which are primarily
be sent from FloridaPALM@myfloridacfo.com, may be used to distribute appropriate Project
information. Emails may also be sent using existing DFS infrastructure or an email marketing
Project Support Tool.
Events and Meetings

The Project may host events and meetings for targeted audiences to deliver up-to-date
information relevant to that audience. This tactic is often used in conjunction with other tactics like
printed materials and presentations.
Letters
Usually written by DFS leadership with support from the Project Team, letters may be used to
share information about the Project and/or make formal requests.
Press Releases
Press releases are a communication that is released to the news media. The Project Team will
coordinate with the DFS Office of Communications on all media-related outreach. The Project
may not leverage press releases until later in the DDI phase.
Meeting Invitations
Meeting invitations are used to invite individuals to a meeting or event. Meeting invitations may
be used to place calendar appointments on event or meeting registrants’ calendars, and should
be sent from FloridaPALM@myfloridacfo.com in most cases.
Newsletters
Newsletters may contain multiple articles related to a specified topic. The Project is considering
the development of a newsletter with Project branding.
Presentations/Speeches
Formal, verbal communication events, presentations/speeches may be presented to an audience
where two-way communication is minimal. If the audience is comprised entirely of members of
Page 77 of 138 11/09/2017

the media, it would be considered a news conference. The Project Team will coordinate
appropriately on speeches given by DFS leadership. Presentations should be created from the
approved Project PowerPoint template.
Printed Materials
Printed materials include one pagers, meetings agendas, and other printed collateral. The Project
has several approved templates for various printed materials.
Publications and Reports

Formal releases of information, publications and reports are typically intended for public and/or
external communications. These reports are created after a series of events or meetings to
summarize the meeting and highlight significant outcomes.
Social Media
Social media includes website and applications that enable users to socially create and share
content. DFS currently maintains a social media presence on Facebook and Twitter. The Project
Team, specifically the OCM Team and Project Director, will coordinate with the DFS Office of
Communications on all social media efforts. The Project does not intend on leveraging social
media during the Pre-DDI Phase.
Status Reports
Status reports outline status and other related indicators on a regular basis. The Project has
several mandatory reporting requirements, which are managed by the PMO. The majority of
status reports are considered a regularly scheduled communication.
Surveys, Questionnaires, and Assessments

An evaluation is typically given to an audience to assess an audience’s perception and
understanding of a topic or event. Surveys are typically administered to attendees after every
workshop or workgroup. The Project currently uses Survey Monkey ® to distribute surveys and
collate data. Additionally, these tools are focused on reinforcing and measuring awareness during
the Pre-DDI Phase but will be adapted as the Project progresses to measure other elements of
change and readiness. Survey tools will also be used to solicit other feedback on communication
efforts as the Pre-DDI Phase proceeds, as deemed appropriate by Project Management and the
OCM Team. Examples of input which would be solicited via surveys include the perceived
effectiveness and relevance of communications recently distributed, preferences for the use of
specific tactics for targeted audiences, and suggestions for future project messaging.
Talking Points
Talking points are used during discussions with various audiences to provide consistency in
messaging. The Project Team will be trained and updated on various talking points, as needed.
The full set of Project’s Talking Points as documented to date appears in Appendix A of this
document.
Trainings
Trainings teach individuals a particular skill or skillset. The Project may hold trainings on skills
needed during the Pre-DDI Phase of the Project but the Project does not intend to leverage
trainings on a large scale to agencies during the Pre-DDI Phase.
Page 78 of 138 11/09/2017

Videos
A video recording of events, speeches, news conferences, meetings, or trainings are an effective
way to capture information for later use. The Project may record major events such as an
announcement of the launch of the DDI Phase, as an example. The Project Team, specifically
the OCM Team, will coordinate with the DFS Office of Publications for video recording needs. The
Florida Channel may record ESC meetings from time to time.
Webinars
Webinars are an online-based training or presentation that may be self-paced or facilitated live.
The Project does not intend on leveraging webinars on a large scale during the Pre-DDI Phase.
Website
A grouping of webpages, a website delivers information to the various target audiences outlined
in this Plan and may contain copies of meeting materials, released reports, videos, research, and
webinars. This public facing tool should be used to increase the transparency of the Project’s
status and activities.
Workgroups/Workshops
Workgroups/Workshops encourage interactive discussions. A workgroup is typically smaller and
more interactive than a workshop. In workgroups, participants engage in active discussion in a
collaborative manner, and workshops are more presentation-like in nature with less interaction.
The Project often hosts both workgroups and workshops to engage and collaborate with the
appropriate stakeholders to gain input and feedback.
17.8 Communication Channels

The Project routinely communicates with identified stakeholders through various communication
channels as deemed appropriate. There are several channels available for releasing
communications. These channels are not exclusive or exhaustive, and others may be added and
deployed as the Project proceeds. The table below is a listing of the channel types used by the
Project. For each tactic, the table displays the:
• audience receiving the message,
• topic(s) of the message,
• objective of the message,
• medium used to send the message,
• frequency, and
• message owner.
Page 79 of 138 11/09/2017

Table 21: Communication Channels
Channel Audience Topic(s) Objective Medium Frequency Owner(s)

• Chair of Senate
Committee on
Appropriation
• Project Progress during
and designated
the reporting period
staff
• Overall Schedule,
• Chair of the
Budget, Scope, Risks,
House
and Issues status
Appropriations
Committee and • Project Schedule
designated staff Performance Index (SPI)
and Project Cost Fulfill proviso and AST
Monthly Project • Executive Office Project
Performance Index (CPI) requirements to report Email Monthly
Status Report of the Governor’s Director
(EOG’s) Office of • Status of Project status and activities
Policy & Budget Milestones, Deliverables,
(OPB) and and Major Tasks
designated staff • Detail of Scope Changes,
• Executive Issues, Risks, and
Steering Budget
Committee (ESC)
• Project Sponsors
• Project Team
• AST
Keep the Project
• Open Risks, Action Items,
Director and Track
Issues, Decisions, and
• Project Team Managers apprised of PMO
RADAR Report Lessons Learned Email Weekly
• Project Sponsors activities scheduled Team
• One week look-ahead
during the upcoming
• Four week look-ahead four weeks
Quarterly • Executive
Collaborations Steering Share ERP selection,
Communication Committee (ESC) implementation, OCM
Opportunities for engagement Email As needed
Report • Project Sponsors development, and Team
• Project Team maintenance strategies
• AST
Page 80 of 138 11/09/2017


• AST Monthly Oversight
Oversight Assessment Share side-by-side
Analysis General Public • IV&V Monthly comparisons of PMO
Website Quarterly
Quarterly Assessment oversight assessment Team
Dashboard • Project Performance data
Review
Florida
• Keep ASDs
Association of
apprised of Project
State Agency State Agency
• Project status updates status
Administrative Administrative BPS
Services • Opportunities for • Manage Meeting Monthly
Services Directors Manager
Directors engagement expectations for
(ASDs)
stakeholder
(FASAASD)
involvement
Update
• Keep CIOs
apprised of Project
Chief Information
• Project status updates status
Officers (CIOs) Project
Workgroup
State agency CIOs • Opportunities for • Manage Meeting As needed
Director
Update engagement expectations for
stakeholder
involvement
• MyFloridaMarket
Place (MFMP)
staff
• People First (PF) • Keep FFMIS
Florida Financial staff partners apprised
Management • Legislative • Project status updates of Project status
Monthly or OCM
Information Appropriations • Opportunities for • Manage Meeting
as needed Team
System (FFMIS) System/Planning engagement expectations for
Partner Update and Budgeting stakeholder
Subsystem involvement
(LAS/PBS) staff
• FLAIR and CMS
owners
Page 81 of 138 11/09/2017


• Public relevant and
up-to-date
• State information
Government regarding the
Employees Project to keep all
Project Website All Wordpress As needed All Tracks
• General Public stakeholders
• Media informed
• Vendors • Encourage
continued interest
in the Project
• Communicate
mitigation plans
and progress status
Risk Management • Monetize the risk
Project-wide
Team (Project impact
RAIDL (Risks,
Director, Project • Ensure there is a
Action Items, • Status of open risks Risk
Deputy Director, and clear association Meeting Bi-weekly
Issues, • Newly identified risks Manager
Decisions, and Track Managers) between the
Lessons identified risk and a
project outcomes or
contract deliverable
• Establish clear
close criteria
Track RAIDL
• Status of Track RAIDL
(Risks, Action
items status
Items, Issues, Share RAIDL status
• Newly identified RAIDL Track
Decisions, and PMO Manager across Tracks and Meeting Weekly
items Manager
Lessons team members
Learned) Review • RAIDL items ownership
Meeting • Updates to RAIDL items
Executive
Brief and obtain
Steering Executive Steering Communicate project status, Project
direction from Project Meeting Monthly
Committee Committee Members spend plan, and impacts Director
sponsorship
Meeting
Page 82 of 138 11/09/2017


• DFS Chief of Brief and obtain
Executive Project
Staff Varies direction from executive Meeting Bi-Weekly
Sponsor Meeting Director
• Deputy CFO sponsorship
Group collaboration on
Sponsor Working • Project Sponsors Project
Varies a Strategy and Meeting As Needed
Meeting • Track Managers Deliverables
Director
• Express appreciation for
Project • Sponsors
their support during the Per agreed
Track/Phase • Project Team Closeout Track/Phase Project
Project Meeting to calendar
Close-out Member(s) Director
• Conduct and record event
Meeting • Key DFS Staff
lessons learned
• Project Director
Independent • Project Deputy
• Updates from the IV&V Discuss IV&V IV&V
Verification and Director Monthly or
Contractor Lead Observations Meeting Contractor
Validation • PMO Manager as needed
• IV&V Observations Lead
Meetings • Contract
Manager
• Updates from the Project
• Project Director Director Integration and
Managers’ • Project Deputy • Status updates from coordinate priorities Project
Meeting Weekly
Meeting Director Track Managers across Tracks Director
• Track Managers • Follow-up on outstanding
action items
• Updates from the Track
Manager
• Status updates from team
members
• Follow-up on outstanding
action items Integration of activities
Track Status Track Manager and Daily or Track
Meetings Team • Includes status of within Track Meeting
Weekly Manager
Deliverables, Track
Activities, and Project and
Other Track Support
activities
• Includes current and next
period accomplishments
Page 83 of 138 11/09/2017


• Keep AST apprised
• Project Director
of Project status
• Project Deputy • Project status updates
AST Bi-weekly • Manage Project
Meeting
Director • Opportunities for Meeting Bi-weekly
expectations for Director
• PMO Manager engagement
oversight
involvement
• Updates from the Project
Quarterly Staff
Directors Updates of activities Project
Meeting Project Team Meeting Quarterly
• Updates from Track across the Project Director
Managers
• EOG
Legislative Staff Manage expectations
Briefings • Legislature and Project
Project Status Updates for stakeholder Meeting As Needed
staff Director
involvement
Page 84 of 138 11/09/2017

17.9 Process
Communication Management occurs in three stages: identification of need; communication draft
and review; and disseminate and monitor communication.
Identification of Need
Any Project Team member can identify a potential Project communication need. A Project
communication need may be precipitated by a direct communication with the Project such as an
email4, letter, memo, or telephone call; or a communication outside the Project such as a news
story, article, or other agency communication. If a Project Team member believes they have
identified a communication need, they should inform their Track Manager and notify the Project’s
Communication Coordinator.
The Communication Coordinator will review the potential communication need and consult with
the Management Team to determine if a Project communication is warranted. If the need is
verified, the Communication Coordinator with coordinate with the Track Managers to identify an
Author for the communication. The Author may be the Initiator, the Communication Coordinator,
or any other Project Team member depending on the area of expertise and need.
Communication Draft and Review

The Initiator and the Author (if different) will coordinate to develop the draft communication. They
should refer to the Project Style Guide and the Pre-DDI Communication Plan when developing
the draft communication.
The completed draft communication should be sent to the Reviewer(s) for review and comment.
In most cases, the Reviewer(s) will be a group of Project Team members and Track Managers.
Once the Reviewer(s) have completed their review, the Author will incorporate comments and
edits as appropriate and send the updated draft to the Project Director for review. All Project
communications to be released outside the Project must be accepted by the Project Director or
the Director’s designee before release.
The Project Director will review the draft communication and provide comments if needed. The
author will incorporate the Director’s comments as appropriate and return the updated draft to the
Director for review. This will continue until the Director is satisfied that the Draft is ready for the
next step in the draft and review process.
Once the Project Director has completed their review, the Author will determine if the draft
communication requires external review. Communications that may warrant outside review can
include meeting summaries for meetings with other State agencies, communications being
prepared and delivered by the Project for the Chief Financial Officer, and other communications
that require legal review due to their content. If the communication requires external review, the
Author will coordinate the external review and incorporate any comments received as appropriate.
The updated draft will be sent to the Project Director to begin the same review process listed
above.
Once this review is complete, or if the draft does not require an external review, the final draft
communication must go through the Content Release Management Process which establishes
Page 85 of 138 11/09/2017

Quality Control (QC) components that must be applied to the draft communication. Refer to the
Content Management section of this document for more information regarding the Quality Control
process and Appendix E – Master Quality Control Checklist applied to all communications Upon
a successful quality review, the Author will forward the final draft communication to the
Communication Coordinator for final review and formatting. The final review and formatting will
confirm the communication meets the following criteria (as applicable):
1. The content is consistent with the guidance in the Pre-DDI Communication Plan.
2. The format is consistent with the Project Style Guide. This is important when
messaging is delivered via email, document, or other written communication vehicles.
3. The format is compatible with the communication vehicle (e.g., if the communication
is to be published on the Project’s website, the PDF should be optimally formatted for
web publication).
The Communication Coordinator will coordinate with the Project Director to update the document
to meet any of the criteria listed above. In the figure below, the Communication Management
Process Flow, illustrates the three stages described herein.
Disseminate and Monitor Communication

The Initiator is the default role responsible for disseminating final communications. However, this
may not always be the case. Once the communication has been approved, the appropriate Project
Team member will disseminate the communication as is commensurate with the communication
audience and communication vehicle, and notify the Communication Coordinator. The
Communication Coordinator will monitor the communication and coordinate with the Initiator and
the Author if a follow up communication is needed.
The Project tracks and reports on communications using several tools. The first is the Project’s
Communication Log. Located on the OCM Track SharePoint main page, the Communication Log
is the Project’s official record of Project-related communications. After disseminating
communication, the Initiator or Track staff member designee enters the communication into the
log and notifies the Communication Coordinator. The log is reported on monthly by the
Communication Coordinator but relies on track staff members to update the log on a regular basis.
The second tool, or rather set of tools, is Project Monthly Status Reports. The Project will also
produce a quarterly Collaboration and Communication Report.
Each Project Track is responsible for recording Project communications originating from their
Track in the Track Status Report’s Communication Log Summary. The Initiator will work with the
Project Track owning the communication to make sure the Track Status Report is updated to
reflect the communication release. In the case where the communication is initiated from the
Project as a whole and not from a Track concerning the Project, the OCM Track will include the
communication on the OCM Status Report.
Page 86 of 138 11/09/2017

Figure 22: Communication Management Process Flow
Page 87 of 138 11/09/2017


The Communication Management roles and responsibilities are described below. This
responsibility-matrix format, as defined in Section 7 of this document. The table below depicts
the RACIV role and responsibilities during each of the three (3) major areas of the Communication
Management Process as shown in the figure below.
1 2 3
Identification Communication Draft Disseminate/Monitor
of Need and Review Communication
Figure 23: Major Areas of the Communication Management Process
Table 22: Communication Management Roles and Responsibilities
Role5 Responsibilities 1 2 3
Identifies the need for communication. This can be any

Initiator6 R R R
member of the Florida PALM Project Team.
Responsible for working with the Initiator to draft the

Author C R I
communication.
Responsible for reviewing draft communications and
Reviewer providing comments as necessary prior to submission to I A I
the Project Director for review and approval.
Monitors and tracks all communications from the Project to
Communication maintain consistent Project Messaging. Provides final
A C V
Coordinator review and formatting for all communications from the
Project. Coordinates major communication initiatives
Manages and leads all Project activities, including
Project Director V V A
acceptance and verification of Project communications
5 The Project Team Member responsible for distributing the communication may be any of the roles listed
in the Table.
6 The Initiator may be any Project Team member, including those fulfilling the Roles listed in the Table.
Page 88 of 138 11/09/2017

18 Issue Management
18.1 Overview
Issue Management establishes the process used to identify and resolve issues that arise due to
unplanned events, unexpected events, or a materialized risk. An issue tends to have a negative
impact on Project scope, schedule, and cost and therefore will have a resolution plan to minimize
the negative effects on the Project. This process enables the Project to resolve an issue in a
consistent manner.
18.2 Purpose
The purpose of these procedures is to provide a clear framework to facilitate effective, efficient,
and consistent issue resolution.
18.3 Process
Issue Identification
The process begins when a Requestor has identified an issue that impacts the Project’s scope,
schedule, and/or cost and subsequently logs the issue in the Issue Log. The Issue Log is used to
document and track Issues including steps for resolution. The resolution steps will focus on
speedy closure of Issues to maintain the Project schedule and quality of deliverables.
Both the PMO and assigned Track Manager are responsible for the maintenance and monitoring
of items in the Issue Log. Issue progress will be monitored daily and reviewed at the Track and
Project-wide levels on a bi-weekly basis.
Issue Evaluation
The Project Management Office (PMO) is responsible for evaluating the issue and determining
its validity. If the PMO deems the issue to be invalid, the status of the Issue will be changed to
“Removed” in the Issue Log. The PMO will assign an Owner for valid issues and work together
with the designated Track Manager to perform further evaluation. Together they will determine
the priority, due date, and resolution action plan. Issues are evaluated and categorized by priority
according to impact:
• Critical – Work has or will come to a complete stop in the next 24 hours
• High – Impacts either cost, schedule, contract deliverable, contract payment or any
combination thereof
• Low – All impacts not listed as Critical or High
The Project Director must be notified immediately if an issue has been categorized as Critical. In
addition, the action plan is required to be established and communicated to the Project Director
within eight hours of identification. The Project Director is responsible for the approval of all
resolution action plans.
The action plan is documented in the Issue Log and consists of the following components:
• Resolution strategy, including action steps
• Sequence of actions to be taken
• Resources responsible for the actions
• Expected due dates for the actions
• Reporting and Communication requirements
• Escalation schedule dates
Page 89 of 138 11/09/2017

• Contingency actions, in the event of failure
Issue Management
Issues will be managed to resolution by following the steps identified in the action plan. 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”.
Critical Priority Escalation

The Project Director must be notified immediately if an issue has been categorized as a Critical
priority. In addition, the action plan is required to be established and communicated to the Project
Director within eight hours of the identification of the issue. The Project Director is responsible for
the approval of all resolution action plans.
High Priority Escalation

An escalation process is triggered in the event a high priority issue remains unresolved by its due
date. The escalation process identifies the level of escalation, change in ownership, and
timeframe to determine the change in ownership. The Issue Escalation Levels are shown in the
Table below.
Low Priority Escalation

The escalation process for Low priority issues will be defined and agreed upon between the issue
owner and the Project Director. This issue priority will leverage the operating framework
described in the High Priority Escalation, described in the next section. The escalation owners
and timing are determined by the Project Director.
Table 23: Issue Escalation Levels

Level Issue Ownership
1 Chief Financial Officer (CFO)/Executive Sponsor
2 Project Director
3 Project Track Manager(s)
High Priority Issues that cannot be resolved by the established due date will change ownership
through the various Escalation Levels listed in the above table and is based on the number of
days past the due date. Issue ownership changes will occur as depicted in the figure below.
Issue Identification Due date Due date Due date

to due date + 3days + 10 days + 11 days
CFO / Executive
Issue Owner Track Manager Project Director
Sponsor
Due Date Day 4 Day 11

Figure 24: Issue Escalation Process
Page 90 of 138 11/09/2017

Figure 25: Issue Management Process
Page 91 of 138 11/09/2017


The Issue Management roles and responsibilities are described below. This information is
and responsibilities during each of the four (4) major areas of the Issue Management Process as
shown in the figure below.
1 2 3 4
Identification Evaluation Management Close
Figure 26: Major Areas of the Issue Management Process
Table 24: Issue Management Roles and Responsibilities

• Identifies the potential issue and enters into the
Requester R I I I
Issue Log.
• Works Low and High priority issue action plans to
Owner I R R R
resolution.
• Works with PMO to determine if the issue is valid.
• Identifies the priority, Owner, and due date.
Track Manager • Creates the action plan. I R R I
• Works Low and High priority action plans to
resolution.
• Determines if the Issue is valid.
• Identifies the priority, Owner, and due date.
PMO C R C/I R
• Creates the action plan and updates the Issue
Log accordingly.
• Approves action plans.
• Works with PMO to identify the priority, Owner,
and due date, and create and approve the action
Project Director I R/A R/C I
plan.
• Owns the Critical priority issues to resolution or
escalates to the CFO / Executive Sponsor.
CFO / Executive • Works past due, escalated High or Critical priority
I I R/C I
Sponsor issue action plans to resolution.
Page 92 of 138 11/09/2017

19 Decision Management
19.1 Overview
The Decision Management process, in the context of running the day-to-day operations of the
Project, establishes, and implements a defined structure that will facilitate an effective decision
making process 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/cost constraints. The Project Director and the Executive Steering
Committee (ESC) will make all significant Project Decisions. This multi-tiered governance
structure is in place for the Project as described below.
19.2 Purpose
The purpose of these procedures is to provide a clear framework to facilitate effective, efficient,
and timely decision making across all levels of the Project.
19.3 Process
Identify Decision
The process begins when a Requester determines that a decision needs to be made that is going
to have an impact outside of their immediate area. The Decision Log is used to document and
track Project Decisions including next steps and the impacted parties. Both the PMO and Track
Managers have responsibility for the maintenance and monitoring of items in the Decision Log.
Decision progress will be reviewed at the Track and Project-wide levels on a bi-weekly basis.
Evaluate Decision
After the Requester enters a record for the identified Decision into the Decision Log, the
appropriate Track Manager evaluates the requested decision to determine relevance,
completeness of the request, and if it should be categorized as either a Tier 1 (minor), or a Tier 2
(major); see below for additional detail on the characteristics of the Decision Tiers. At this point,
the Track Manager also makes the determination whether the decision is to be managed by the
Track Manager or the PMO. The PMO track will manage the decision process if the decision
impacts multiple tracks or requires a decision by the ESC or Project Director.
Decisions that must follow the formal Decision Management process have the following
characteristics:
• Does not impact scope, schedule, or cost, but represents a significant choice for the
project (Tier 1). These decisions shall be recorded exclusively in the Project’s Decision
Log with no PCR required.
• Impacts to scope, schedule, or cost (Tier 2). The decision will be entered in the Decision
Log and a Project Change Request (PCR) will be created. These decisions and resulting
PCRs will be escalated through the defined multi-tiered governance structure included in
the Project Charter, as well as follow the process described in the Project Scope and
Change Management section of this document.
• Impacts the Project objectives or the functional/technical direction of the Project (Tier 2).
These types of decisions require collaboration and agreement across multiple Project
Tracks and the ESC.
Decision due dates should tie to a specific event, milestone, or deliverable task in the Project’s
master schedule.
Page 93 of 138 11/09/2017

Tier 1: Florida PALM Project Director

The Project Director is charged with managing the Project and approving Tier 1 Decisions in
conformance with the Project Charter. The Project Director may delegate decisions to other
Project Team members, but retains responsibility for the decisions made. Tier 1 Decisions do not
significantly affect scope, schedule, or cost and include decisions regarding staffing changes,
risks, multi-Track issues, and the approval of Project deliverables not categorized as major Project
deliverables.
1. Scope – Changes that do not modify the Project scope as documented in the approved
Pre-DDI Project Charter.
2. Schedule – Changes not associated with major deliverable due dates or key Project
milestone dates (critical path).
3. Cost – Variances of +/- 10% of Project budget within spend plan categories, provided
it does not result in overall Project cost overruns.
Tier 2: Florida PALM Executive Steering Committee

The ESC is responsible for approving Tier 2 Decisions which are beyond the authority of the
Project Director. The following three areas comprise Tier 2 decisions and will be presented to,
and made by the ESC:
1. Scope – Changes that modify the Project scope as documented in the approved Pre-
DDI Project Charter.
2. Schedule – Changes to major deliverable due dates or key Project milestone dates
which impact the overall Project critical path.
3. Cost – Variances of greater than +/- 10% of Project budget within spend plan
categories.
Formalize Decision
After all necessary information is gathered and evaluated, the decision is presented to the
appropriate decision maker(s) based on the Tier of the Decision. The decision maker(s) will
then evaluate the options and choose one that best meets the needs of the State. Either the
PMO or Track Manager will then update the Decision record in SharePoint.
Page 94 of 138 11/09/2017

Figure 27: Decision Management Process
Page 95 of 138 11/09/2017


The Decision Management roles and responsibilities are described below. This information is
and responsibilities during each of the three major areas of the Decision Management Process
as shown in the figure below:
1 2 3 4
Identification Evaluate Formalize Close
Figure 28: Stages of the Decision Management Process
Table 25: Decision Management Roles and Responsibilities

• Initiates the Decision Management process
based on need identified.
• Logs the request and completes all fields of
Requester R C I I/R
the Decision Log.
• Submits the request to the associated Track
Manager.
• Evaluates the Decision and determines the
Decision-making level.
• Determines whether the decision is to be
Track Manager A/C R/V I/C I
managed by the Track Manager or the PMO.
• Develops the Decision Request and updates
the Decision Log.
• Owns the Decision and PCR process.
• Has same responsibilities as Track Managers
when it affects multiple tracks.
PMO • Tracks and reports all PCR decisions I A/V I/R I/R
escalated to the ESC.
• Updates the decision information and status in
the Decision Log.
• Manages the Project and approves or rejects
Tier 1 Decisions.
Project Director • Escalates and presents decisions and
I I A/R I
– Tier 1 associated PCRs, that meet the Tier 2 criteria,
to the Executive Steering Committee (ESC)
for consideration.
Executive • Reviews and approves or rejects any
Steering decisions and PCRs regarding the Project’s
I I A/R I
Committee scope, schedule, and cost beyond the Project
(ESC) – Tier 2 Director’s authority.
Page 96 of 138 11/09/2017

20 Deliverable Management
20.1 Overview
Deliverable Management describes the processes to be followed when developing, reviewing,
and accepting Project Deliverables. Adherence to this process is the responsibility of all members
of the Project Team. To achieve a positive outcome, this process must be carried out over the life
of the Project to ensure expectations are aligned and met. This process applies to all Project
Deliverables (contractual and non-contractual).
20.2 Purpose
The purpose of Deliverable Management is to provide instructions to Project Team Members
regarding Deliverable Management and associated activities.
20.3 Process
The process for deliverable management includes development and approval of a DED,
deliverable development, and deliverable acceptance. The figure below illustrates the Deliverable
Management Process.
Figure 29: Overview of Deliverable Management Process
The DED development process includes the steps the Project takes to establish the acceptance
criteria, the roles and responsibilities for the deliverable activities, and the development
methodology. Considering the acceptance criteria is a key element in the Submission QC
Review, as or core requirements for accepting the deliverable.
The deliverable development process includes the steps to be carried out to create the
deliverable. The deliverable Owner, the deliverable Contributors, and the Project’s Track and
Contract Managers identify what approach or methodology will be used to generate the
deliverable.
The deliverable acceptance process includes the steps used to review, document feedback,
and gain Project acceptance.
Deliverables will be developed using tools and techniques appropriate to their form. This may
include the use of Microsoft Office software (for written deliverables), Commercial of the Shelf
(COTS), custom software, or other tools. Each deliverable will be developed using a standard
Page 97 of 138 11/09/2017

template that is approved during the DED process. Version control and updates can be found
in the Content Management section of the PMP.
Deliverable numbers and titles will be chosen by the Track Manager. The title shall not include
the Track acronym and shall use the numbering conventions below:
Contractual Non-Contractual
Track Acronym-Number The letter I-Track Acronym-Number
I-XXX-#
XXX-#
Deliverables that are multi- part can include A,B,C,etc. as part
of the deliverable number
Deliverable Expectations Document (DED)

The figure below provides a high-level overview of the DED development process.
Figure 30: Overview of DED Development Process
DED Development
The DED shall be developed by the Owner of the Deliverable, and vice versa, when possible.
Each DED shall contain sufficient detail to provide clear expectations of the Deliverable’s contents
and acceptance criteria. The DED will be used by the QC Reviewer during the Deliverable
Submission Quality Control (QC) Review to ensure compliance with the acceptance criteria.
For contractual Deliverables, the Deliverable acceptance criteria included in the contract shall be
used as the basis for the DED. The DED will serve as evaluation criteria for fulfilling completeness
of any given Deliverable. The Owner and Coordinator shall ensure that all contractual elements
are included in the DED.
Once finalized, the DED is linked to the Deliverable and shall be in the same file location as the
Deliverable being developed. This includes version control and updates after approval as
specified by the Content Management section.
DEDs vary dependent upon the type of Deliverable, but each DED shall include at a minimum:
• DED Purpose
• Deliverable Objectives
• Content Draft Outline
• Deliverable Acceptance Criteria/Format
• Content Release Plan
• Deliverable Roles
• Deliverable Development Approach and Timeline
• Appendix (if applicable)
Page 98 of 138 11/09/2017

As part of the Deliverable Development Approach and Timeline, the Coordinator and the PMO
shall determine the amount of time needed to review the deliverable. The actual review period for
each deliverable will be included in the Master Project Schedule. Typically, the Master Project
Schedule accounts for the following:
• Initial Review and Edits (Round 1)
• Second Review and Edits (if needed) (Round 2)
• Final Review
Complex and multi-part Deliverables may require a segmented review process in which individual
sections are reviewed as they are completed. The format and schedule for this review shall be
agreed to by the Owner and Reviewers as part of the DED development process. As an additional
option, the Deliverable may be split during the creation of the DED, in which case each individual
element would be reviewed separately. When all sections are completed, the final Deliverable
shall be subject to the same full review process as any other Deliverable. Performing a segmented
review of the Deliverable helps ensure the Project can perform a thorough review of the content,
and suggested revisions will be made within the desired review period.
The last step in DED development process is to perform a DED submission QC review per
Appendix E – Master Quality Control Checklist. The results are document and provided to the
deliverable owner.
DED Review and Accept

The DED review process includes:
• Walkthrough the DED to clarify content, answer questions, and/or to familiarize the
Reviewers with the deliverable.
• The option for interactive review sessions to incorporate deliverable feedback in the
most effective manner.
Each DED shall be reviewed and accepted by the Acceptor. If the Deliverable is contractual, the
Contract Manager shall serve as the Coordinator. For internal Deliverables, the Track Manager
will name the Coordinator when development of the DED begins. Track Managers will identify
Reviewers for the DED.
DED Updates and Change Control

After a DED has been approved, it will only be updated and submitted for re-approval when a
change in scope content, schedule, or acceptance criteria was either initiated through a Project
Change Request (PCR), or agreement between the Deliverable Owner, Coordinator, and/or
Acceptor.
The figure below communicates the life cycle for the DED.
Page 99 of 138 11/09/2017

Figure 31: DED Development, Review, and Accept Process
Page 100 of 138 11/09/2017

Deliverable Development, Review, and Acceptance

Deliverable Development
The figure below provides a high-level overview of the deliverable development process.
Figure 32: Overview of the Deliverable Development Process
When creating the Deliverable, the Owner shall adhere to the criteria, format, and development
approach set forth in the DED. Some Deliverables may have Contributors (Project Team
Members), as identified in the DED, assisting the Owner during the development of the content.
Deliverable Owners are encouraged to review and discuss Deliverable content with other Project
Team Members via a peer review prior to submission, allowing the Deliverable review process to
be one of validation instead of a review of new content. Each deliverable shall contain sufficient
detail to meet the acceptance criteria specified in the DED.
Deliverables vary dependent upon the topic, but each deliverable shall include at a minimum:
• Number
• Name
• Revision History
• Date
After development is complete, the Deliverable along with the Deliverable Review Form (Appendix
C), is submitted to the Quality Control (QC) Reviewer. The QC Reviewer is responsible for
determining if the Deliverable meets the Project’s quality expectations and if the submission
should be accepted. The Submission Checklist is included in the Deliverable Review Form
(Appendix C).
Deliverable Review
The figure below provides a high-level overview of the deliverable review process.
Figure 33: Overview of Deliverable Review Process
Page 101 of 138 11/09/2017

The deliverable review process includes:

• A Submission QC Review Checklist, included in the Deliverable Review Form (Appendix
C), of the deliverable to determine if it meets the Project’s quality standards before the
review process begins.
• Walkthroughs of each deliverable to clarify content, answer questions, and/or to
familiarize the Reviewers with the deliverable.
• A formal review and written comments from Reviewers with the results tracked on the
Deliverable Review Form (Appendix C).
• The option for interactive review sessions to incorporate deliverable feedback in the
most effective manner.
• Formal written acceptance of deliverables by the Project Director, Project Sponsors,
and/or Executive Steering Committee.
• Archival of all deliverables in the designated Project repository.
The Submission QC Review is the first step in the Technical Quality Evaluation (TQE) process.
The QC Reviewer reviews the deliverable for submission acceptance prior to the formal review
process. Deliverables must pass the Submission QC Review before a formal deliverable review
can begin. Any defects recorded as part of the Submission QC Review, which do not address
the acceptance criteria, are recorded as Severity 1 Defects and the deliverable is sent back to the
Owner for correction and resubmission.
Once the deliverable has passed the Submission QC Review, the submission is officially accepted
and the formal review begins. If the Reviewer identifies a Severity 1 Defect during their review,
they should discuss the defect with the Coordinator to determine if the review process should stop
and the deliverable be sent back to the Owner, or it should be addressed during the edit process.
The review process can happen one of two ways: 1. Individual reviewers can document their
comments and requested changes individually on the Deliverable Review Form and send to the
Coordinator for consolidation, or 2. The Coordinator facilitates a group review where comments
and requested changes are compiled and documented using track changes. After the changes
are accepted, the Coordinator shall log the consolidated comments onto the Deliverable Review
Form. During the initial review cycle, the deliverable shall be reviewed and commented in its
entirety.
After round 1 review, subsequent reviews shall be focused on any added or modified content
except where the modifications have an impact on other Deliverable content. Prior to re-
submission, the Deliverable shall be reviewed by the Coordinator, or designee to ensure that all
comments and requested changes have been addressed. After the Coordinator or designee
reviews and verifies changes, the Owner shall re-submit the Deliverable and clearly identify
changes to the draft document. In addition, the Owner shall provide a response to each comment,
explaining how the requested change was addressed, or why it was not addressed.
Deliverable Acceptance
All Deliverables are accepted by the Project Director. If the Deliverable is contractual, the Contract
Manager will document the acceptance in writing on a Notice of Deliverable Acceptance Form
(Appendix D). Acceptance of non-contractual Deliverables will be documented in writing via email.
The figure below communicates the life cycle for the deliverable development.
Page 102 of 138 11/09/2017

Figure 34: Deliverable Development and Review Process
Page 103 of 138 11/09/2017


The Deliverable Management roles and responsibilities are described in the table below. This
the RACIV role during each of the four (4) major areas of the Deliverable Management Process
1 2 3 4
DED DED Review Deliverable Deliverable
Development & Accept Development Review & Accept
Figure 35: Major Areas of the Deliverable Management Process
Table 26: Deliverable Management Roles and Responsibilities

• Serves as primary Owner of the DED and
Deliverable
Owner R R R R
• Responsible for ensuring content is created
and fulfills the acceptance criteria
• Assists the Owner with content or other
Contributor(s) development C I C I
• Serves as an Advisor to the Owner
• Performs DED Quality Control
• Contract Manager for contract deliverables
• Verifies acceptance criteria is met
Coordinator • Responsible for facilitating and coordinating C C/V I V
the review and compiling comments
• Recommends Deliverable acceptance or
rejection
• Reviews the DED and Deliverable and
Reviewer(s) C C C C
documents findings and feedback
• The Track Manager is responsible for
reviewing DED’s with the Project Director, prior
to their acceptance
• The Project Director accepts all deliverables
Acceptor • Upon Project Director acceptance, the I A I A
Executive Steering Committee is responsible
for approving major Project deliverables that
have been agreed upon by the ESC
• Informed on progress being made throughout
the process
• Conducts the Submission QC Review verifying
the content meets the acceptance criteria and
QC Reviewer A I A I/V
Project quality standards
• Accepts the submission of the Deliverable
Page 104 of 138 11/09/2017

21 Action Item Management

21.1 Overview
Action Item Management enables the Project Team to effectively complete work in a timely
manner to keep the Project on track and provide the mechanism to bring Action Items to closure.
Action Items address a specific need in order to provide an outcome that is not on the Project
schedule or addressed in the Risk, Issue, or Decision Logs. Action Items are unique needs
created out of discussions, recorded, and require follow up.
21.2 Purpose
The purpose of these procedures is to provide instructions to facilitate effective, efficient, and
timely completion and closure of Action Items across all levels of the Project.
21.3 Process
Identification
The process is initiated with the identification and logging of an Action Item in the Action Item Log,
by the Requester. The Requester will identify and contact the Owner to describe the need or
desired outcome and include any other information that could be helpful to resolve the Action
Item. The Owner or delegate will review the information for completeness. If the Owner is satisfied
with the information, they will request a review with the Track Manager to proceed with developing
the Action Plan to be followed.
Evaluation
The Track Manager is responsible for evaluating the action item and determining its validity. The
Track Manager will validate the action item Owner and finalize the action plan steps. Together
they will determine the priority, due date, and outcome of the action plan. The Action Item dues
date will be determined during this evaluation. This due date should be tied to a specific task or
deliverable on the Project’s master schedule.
Note: Action Items may be assigned to individuals external to the Project, however they may not
be the named Owner. The Project Director, Deputy Project Director, or Track Manager will be
assigned as the Owner.
Execution
Upon approval by the Track Manager, the Owner will work the Action Plan to completion. The
Owner will inform the Requestor when the Action Plan has been worked to completion and obtain
the Requestor’s agreement for the Owner to close the Action Item. The figure below shows the
various stages of the Action Item Management process.
The Owner is responsible for maintenance of items in the Action Item Log. Action Item progress
will be reviewed at the Track and Project-wide levels on a bi-weekly basis.
Page 105 of 138 11/09/2017

Figure 36: Action Item Management Process
Page 106 of 138 11/09/2017


The Action Item Management roles and responsibilities are described below. This information is
and responsibilities during each of the four (4) major areas of the Action Item Management
1 2 3 4
Identification Evaluation Execution Close
Figure 37: Major Areas of the Action Item Process
Table 27: Action Item Management Roles and Responsibilities

• Responsible for identifying, logging, and defining the
outcome of the Action Item.
Requester R C V I
• Reviews the Action Plan to ensure request as
originally defined will be resolved.
Track • Reviews Action Item request to determine validity.
I V/A I I
Manager • Confirms Action Plan.
• Participates in discussions with the Requester to fully
understand the need.
Owner /
• Researches and documents the Action Plan steps to I R R R
Delegate
be executed to resolution and closure.
• Manages Action Item Log.
Page 107 of 138 11/09/2017

22 Content Management
22.1 Overview
Content Management describes the standard document management, content release, and
website management processes to be used by the Project. These processes are provided as
separate parts to this section; however, they are directly related and have multiple points of
overlap. Document management provides the Project standards for version control, document
retention, and revision history tracking. Content release provides the process for document
content review and update, and content release to Project stakeholders and the public. Website
management provides the process for requesting, reviewing, approving, developing, and verifying
updates to the Project’s website.
For information pertaining to project communication, style, or website standards, please consult
the following documents:
• Communication Management section of the PMP for communications standards;

• The Website User’s Guide for technical information about creating website updates, and
standards; and
• The Florida PALM Project Style Guide for document standards.
22.2 Purpose
The purpose of this section is to provide instructions to the Project Team related to document
management, content release, and website management. This is intended to confirm:
• Project documents are managed in a consistent manner;

• Content is reviewed for Project message continuity and consistency with Project standards
prior to release; and
• Information included on the website is accurate and consistent with the Project’s
communications and content release standards.
22.3 Document Management

There are three components to document management: versioning, file naming conventions, and
managing. Versioning provides the standards used when identifying the draft, final, and updated
documents. File naming conventions provide the standards to be used when assigning file names
to document files. Managing pertains to the repository and retention of documents.
Versioning
The Project uses two versioning conventions depending on the document: date versioning and
version numbering. Date versioning is used for documents that are developed and released on a
recurring basis (e.g., Project and Track status reports, FASAASD updates). Version numbering
is used for deliverables and large Project products (e.g., Project Management Plan, Project
Charter, or Business Requirements).
Date Versioning
Date versioning is used for documents that are released on a recurring basis. As mentioned
above, these include Track and Project status reports. Within this group, there are several
categories of documents; annual; quarterly; and weekly/periodically. A slightly different date
versioning format is used for each. These rules apply when using date versioning:
Page 108 of 138 11/09/2017

1. The file names for documents using date versioning will include the date is described later
in this section
2. The date version may also be included in the title of the document, though it is not required.
3. The date version is not included in the footer (refer to the Project’s Style Guide)
Annual documents (e.g., Fiscal Year Schedule Planning) use the fiscal year date versioning
format. This format has a space between the “FY” and the fiscal year. The fiscal year is
represented by the last two digits of the calendar year in which the fiscal year begins and the last
two digits of the calendar year in which the fiscal year ends, separated by a hyphen.
Figure 38: Fiscal Year
Quarterly documents (e.g., collaboration and communication status report) use the fiscal year and
quarterly date versioning format. This format includes the information used for annual documents
with the fiscal year quarter (e.g., 1, 2, 3, or 4) added to the end. There is a space between the
fiscal year and the quarter.
Figure 39: Fiscal Year and Quarter
Weekly/periodic documents (e.g., status reports) use the year, month, day date versioning format.
There are no spaces between the each. A zero will precede single digit months and days.
Therefore, each date version number will have eight digits.
Figure 40: Year-Month-Day
Important: date versioning does not apply to documents that are updated on a regular/prescribed
basis (e.g., Project Team Orientation, Project Management Plan). Those documents will still use
version numbering described in the next section.
Page 109 of 138 11/09/2017

The Project Style Guide contains guidance on the location of date versioning information in
documents of different file formats (e.g., Excel, PowerPoint, Word, Visio).
Version Numbering
The Project uses a two-level version numbering format for approved/accepted documents that
may be updated from time to time. As indicated above, these include Project deliverables.
Version numbering is only used for final accepted/approved documents. Drafts do not receive a
version number. They are marked to as “draft.” Refer to the Project Style guide for draft
formatting.
The version numbering format consists of two pairs of integers where XX represents major
updates and YY represents minor updates:
Figure 41: Version Numbering
Zeros are not added to the version number for single digits. For example, version 1.0 is not
represented as 01.00.
Major updates are substantial changes that alter the document’s message including additions or
deletions of substantial content. Minor updates are minimal in nature and include corrections in
grammar, data, formatting, and/or clarification of terminology. Draft documents do not receive a
version number. Accepted/approved documents should not be updated only to bring terminology
current with changes in Project jargon. However, terminology can be updated if done in
conjunction with another update. In all cases you should consult your Track Manager before
updating a deliverable.
Example version numbers
• Initial approved/accepted document – Version 1.0

• Major update to the initial document – Version 2.0
• Minor update to the previous major update – Version 2.1
Version numbers are referenced in the document’s cover page footer only. They are not added
to the file name. Refer to the Project Style Guide for document cover page and footer standards.
Version History
Updates made to Project documents are tracked using different methods for draft and
accepted/approved documents.
Draft Documents
Draft documents are not assigned a version number at any time during their development. They
are simply “draft.” Version history for draft documents is tracked using SharePoint’s Version
Page 110 of 138 11/09/2017

Comments function. Each time a draft document is saved to SharePoint, the author of the original
or updated document will enter a summary of the updates in the Version Comments window. The
following rules should be followed when entering version comments:
1. Notes should be succinct, explicit, and brief.

2. Do not enter the date of the update.
3. Do not enter the name of the author unless multiple persons contributed to the edits
during the update.
4. Notes must be entered each time a document is initially saved or checked-in to
SharePoint.
Revision notes should identify the types of updates made with enough detail to describe the
updates, but not so much as to list exhaustive detail. For example:
• Too little information: The document was updated

• Too much detail: Page seven, paragraph 3, line 2 was updated to replace “target” with
“objective”
• Recommended detail: Document terminology was updated to be consistent with recent
Project decisions
These rules should also be followed when entering revision notes for accepted/approved
documents.
Accepted/Approved Documents
In addition to SharePoint version comments, the Project uses a version table to track updates
made to documents that use the version numbering format. The Version History table is used to
identify and track the version numbers, the date each version was accepted, and revision notes
for each accepted/approved revision. Revisions are listed in numerical order beginning with the
first initial version in the top row. The location of the table depends on the documents file type.
Table 28: Location of the version table by file type
File Type Table Location
Word Title page and the first page following the title page
Excel First tab in the Excel workbook
PowerPoint First slide following the Project logo slide
Visio First page of the Visio diagram
Refer to the Project Style Guide for more information on the version table and how to use it with
different file types.
Table 29: Version history table template

Version Date Revision Notes
The version Date of this Summary of the changes made from the last version
number version
Table 30: Example version history table
1.0 01/03/2016 Initial accepted version
1.1 02/02/2016 Minor formatting updates to be consistent with new Project
guidance
Page 111 of 138 11/09/2017


2.0 03/03/2016 Removed section 3, updated existing tables, and added
Appendix 2
Version tables are only used for final accepted/approved documents. As indicated above, draft
document history will be tracked using SharePoint’s Version Comments function.
File Naming
File naming structures are designed to coincide with versioning conventions described above.
Although there are differences between the two conventions (date versioning and version
numbering), the following rules apply to each:
1. The title of the document (or a recognizable abbreviation) should be in the file name.
2. File names should be 30 characters or less while still identifying the document.
3. Draft document file names should not include:
a. “Draft”
b. “Final”
c. Version numbers
d. Names or initials of editors
4. File names may include spaces; however, the following characters are not allowed:
a. Ampersand - &
b. Asterisk - *
c. Backslash - \
d. Braces – [ ]
e. Colon - :
f. Number sign - #
g. Percent - %
h. Tilde - ~
i. Underscores - _
File Naming for Documents Using Date Versioning

The file name structure for documents using the date versioning will include the document name
(or abbreviation) and the date version based on the formats provided in the previous section.
Include a space between the document name and the date version.
Table 31: Example file names for documents using date versioning
Document Title Date Version Format Example File Name
Project Collaboration Strategy Annual Collaboration Strategy FY 16-17
Collaboration and Quarterly Collaboration and Communications
Communications Status Status Report FY 16-17 Q4
Report
January 31, 2017 Checkpoint Weekly/periodic OCM Weekly Status Report
meeting notes 20170303
File Naming for Documents Using Version Numbering

Documents using version numbering use only the document title for the file name. Do not add the
date or the version to the file name.
Page 112 of 138 11/09/2017

Table 32: Example file names for documents using version numbering
Document Titles Version File Name
Project Charter for Florida PALM 2.0 Project Charter
Pre-Design, Development, and Implementation 1.1 Pre-DDI PMP
(DDI) Project Management Plan (PMP)
Strategic Plan for Pre-SSI OCM Activities (OCM2) 1.0 OCM Pre-SSI Strategic Plan
Managing Documents on SharePoint

SharePoint is used to retain (i.e., store) and manage Project documents. It is the Project’s
direction that all Project documents should be saved to the Project’s SharePoint site. There are
several reasons for this:
1. Files on SharePoint can be accessed by Project Team members at any location with an
internet access and a virtual private network connection.
2. Files on SharePoint are backed up on a regular basis helping to avoid file loss and facilitate
file recovery.
3. Saving a file to a location other than SharePoint restricts access.
4. Each time a document is checked-out, it creates a record in the version history.
5. Except on rare occasions the Project does not allow files to be attached to emails or copied
to external storage devices (e.g., flash drives and laptops).
Each Project Track has developed a file structure for their SharePoint sites. Consult a Track Team
member for the site to which you’re saving your document to identify the proper location.
These rules apply when managing documents in SharePoint:
1. Documents should not be checked-out unless updates are being made

2. Version Comments must be entered for each document (e.g., new, draft, or
accepted/approved versions) when saved or checked-in to SharePoint
3. A PDF copy of the final accepted/approved version of a document will be created and
uploaded to SharePoint in the same location as the original file
4. Multiple copies of a document should not be created and saved on SharePoint
5. When a new accepted/approved version of a document is created, a new PDF copy is
created and uploaded
Project Team members will be prompted to enter version comments in the “Check in” pop-up
window each time they save a document to SharePoint. The same rules identified in Draft
documents section apply to version comments in SharePoint. For example:
• SharePoint Version Comments for draft documents

o Draft – updated table xx and provided comments on section x.y.; Ready for review
o Draft – Incorporated comments from AB, CD, and EF.
• SharePoint Version Comments accepted/approved documents
o Version 1.0 – Initial accepted version
o Version 1.1 – Corrected minor error in table x.y
o Version 2.0 – Updated document summary and added new data table
On rare occasions, documents are no longer appropriate or applicable to the Project. In these
instances, the Project retires a document. This will generally happen to documents using version
numbering. When retiring a document:
Page 113 of 138 11/09/2017

• The version number should be updated to “RETIRED.”

• The version table should be updated to indicate the document has been retired and the
new location of any information that may have been moved to other documents.
• The version comments on SharePoint should read “document retired.”
• RETIRED should be added to the end of the file name.
Document Standards
Documents will be managed according to the following standards:
• Default Paper Document Management Standard

o Applies to deliverables, working documents, work papers, and any other paper
documents.
o Project Team and staff are to treat all documents in accordance with the Staff
Guidelines for the Project. The Project’s Public Records Coordinator should be
consulted regarding documents for their status as exempt or confidential and
exempt under the Florida Public Records Law before any destruction of documents
appropriately in accordance with the referenced rules and the requirements of
sections 119.0701, and 501.171, F.S.
o Paper documents may be taken off-site, but cannot be left out and available,
unattended, unless they are in a secure space with minimal access, such as a
locked room or office.
• Default Electronic Document Management Standard.
o Applies to deliverables, working documents, work papers, and any other electronic
documents.
o Project Team Member(s) are to treat all procurement-related documents as
sensitive and confidential, and maintain them, in accordance with applicable laws,
rules, and the Staff Guidelines for the Project. For example:
▪ Documents will not be attached to e-mail messages unless absolutely
necessary; instead, links to SharePoint documents will be sent.
▪ If sensitive or confidential information is sent via an e-mail message:
• The message will be encrypted.
• A word(s) will be placed in the subject line to denote the message
contains sensitive or confidential information in an attachment
and/or the body of the message, as follows:
o UNREDACTED – Signifies that the content has not been
reviewed and redacted and may contain confidential
information
o REDACTED – Signifies that the content has been redacted
to protect confidential and/or sensitive information
o CONFIDENTIAL – Signifies that the content is not classified
as public
• If sensitive or confidential information is stored on a mobile storage
device (e.g., USB flash drive), that device will have encryption
technology enabled.
o Electronic documents shall be kept in the SharePoint environment. SharePoint
version control shall be utilized and enforced.
o Electronic documents may not be left up and available on a computer, unattended,
even for brief periods. Locking the computer when away from the computer is
required.
Page 114 of 138 11/09/2017

22.4 Content Release

Content Release describes the processes to be followed for any content to be released or shared
outside of the Project. The Content Release process includes content inspection to check for
publication compliance with Project standards and finalization of supporting content release
notes. Content includes website content, direct communications (e.g., emails), recurring
distributed documents (e.g., Project Status Reports), or presentations to stakeholders. It is
assumed that any Project document identified for release has been through the appropriate PMP
processes and accepted/approved. Additional review steps beyond what are outlined below may
be required when content is released by entities outside the Project (e.g., DFS Publications).
Process
Content Release Review
Content identified for release will go through two quality review control points. The first quality
review is performed after the content review and edit task has been completed and prior to the
Project Director’s acceptance. The second is after content has been accepted by the Project and
has been transmitted to target audiences or posted to designated repository. This is identified as
Post Release Quality Control (QC).
The first QC is performed during the respective PMP process areas where content is originally
created. Those areas are Cost, Schedule, Communication, Deliverable, and Website. Appendix
E - Master Quality Control Checklist captures all of the inspection elements across the mentioned
PMP process areas.
After the Project has accepted the content, it is now ready for post release review. Content that
does not pass this QC review will be sent back to the Owner for update and then resubmitted to
the QC reviewer. These steps will be repeated until the content passes QC review. This Post
Release QC review should not result in significant changes to document content. If there are
significant changes to content, the content must go through both first QC and Post Release QC.
These processes are communicated in the Content Release Review workflow figure, below.
Release Notes Instructions

Release notes may accompany updates to technical documents7. The determination to include
release notes shall be made on a case-by-case basis. Release notes are in addition to the
information provided in the Version History table described in section 22.3. They provide a higher
level of detail intended to assist readers in finding recently updated information. This is important
for documents like the Website User Guide, where updates may be for a software or plug-in and
they do not affect the entire document. However, they do alter a process. “Release notes” must
be maintained on the Project’s SharePoint site in the same location as the document to which
they apply. Release notes should be written as follows:
1. Created in Microsoft Word format and be consistent with the Project Style Guide;
2. Contain a new section for each revision;
3. Each new section should provide the version number, date the updates were accepted,
and a summary of the major update;
4. Sections should be ordered from newest to oldest; and
7
The Management Team may make exceptions
Page 115 of 138 11/09/2017

5. Contain a table at the end of the document providing the location and a detailed description
of each update. (See Table below)
Table 33: Example release notes

Version Date Location Description of update made
Document Date the revision Location of each A detailed description of the update
Version was accepted revision
number
Page 116 of 138 11/09/2017

Figure 42: Content Release Review workflow
Page 117 of 138 11/09/2017

Roles and Responsibilities

The Release Management roles and responsibilities are described below. This information is
and responsibilities during each of the two (2) major areas of the Release Management Process
Post Release Review
Figure 43: Major Areas of the Content Release Management Process
Table 34: Website Management Roles and Responsibilities

Role Responsibilities 1
Submits document for release review and acceptance; R
updates document based on QC review; If necessary,
Owner
assist with communicating the release; can be any Project
Team members
Reviews the document against the QC checklist and passes A/V
QC Reviewer
the document for release
Page 118 of 138 11/09/2017

22.5 Website Management

This part provides instructions to the Project Team regarding website update request submission
and approval and development, review, and verification of updates ensuring that Website content
is accurate and consistent with the Project’s communications and content release standards.
Process
Request, Evaluate Submission, and Communication Consistency Review
The steps for requesting, evaluation, and completing the Communication Consistency Review
are:
1. The Requestor identifies the need for an update.

2. The Track Manager of the Track requesting the update, or Project Director (or their
delegate[s]) will review the Request for approval.
3. The Request will be edited as needed to receive approval, if appropriate.
4. The Communication Consistency and QC Reviewer will review the proposed update for
consistency with the Project Communications Plan, Style Guide, and overall messaging.8
5. The Request will be edited as needed to meet the Communication Consistency review.
Steps 2, 3, and 4 will be repeated as necessary until the Request has been approved or
is no longer being considered.
6. The Requestor will create a new log item in the Website Request and Tracking log. It is
important that the Requestor complete all the required log fields. Omission of requested
information may delay assignment of the Request.
7. The Requestor will send an email to the Website Coordinator (WC) informing them of the
new Request.
8. The WC will review the new Request and work with the Requestor to gather any additional
information that might be needed to complete the Website Request and Tracking log.
9. The WC will evaluate the Request to determine whether the Request is for a content-only
(e.g., updating Website text or uploading new documents) or a technical update (e.g.,
creating new pages or installing new functionality). Content-only updates will be developed
by the WC (or their backup). Technical updates will be developed by the Technical
Coordinator (TC) (or their backup).
Update Development and Quality Control (QC) Review

The steps for update development and QC review are provided below. Steps vary depending on
the update type (e.g., Content-only, or Technical).
22.5.1.2.1 Content-Only
Content-Only updates will follow these steps for developing updates and completing the QC
review:
1. The developer (WC, TC or backup) will develop the update using a clone of the target
page. The developer may need to consult the Requestor when modifications to the initial
Request are necessary.
2. The Requestor (or their designee) will review the draft update for QC and identify any edits
or corrections that need to be made.
3. The developer will incorporate the edits identified during the QC review. Steps 2 and 3 will
be repeated until the update is ready to be published.
8In some instances, the communication consistency review may not be necessary. These include minor text updates and uploading
new documents. Requestors should consult with their Track Managers or the OCM Track if there are any questions.
Page 119 of 138 11/09/2017

4. The developer will publish the update to Production.
22.5.1.2.2 Technical Updates

As indicated in the Request, Evaluation Submission, and Communication Consistency Review
section, technical updates are developed by the TC or their backup. The TC will first evaluate the
update request to determine if it is a Stand-alone or Initiative update. Development and QC review
for Stand-alone updates will follow the same steps described in the content-only section above.
Initiative updates will be placed on the product backlog and may be managed using Agile Scrum.
22.5.1.2.3 Prelease QC Review and Release

The steps for Website Pre-Release QC review and publish updateare:
1. The QC Reviewer will review the updates and determine if it meets the Website Pre-
Release QC Review as described in Appendix E. If the update does not meet the criteria,
the WC or TC (or backup) will correct the update as appropriate. This step will be repeated
until the update meets the QC criteria and has been deemed released.
2. The Requestor will close the Website Request and Tracking log item.
3. The Requestor (or other Team Member as assigned) may communicate the update to the
appropriate audience in coordination with the Organizational Change Management (OCM)
Track.
Page 120 of 138 11/09/2017

Figure 44: Website Management workflow
Page 121 of 138 11/09/2017


The Website Management roles and responsibilities are described below. This information is
and responsibilities during each of the three (3) major areas of the Release Management Process
1
2
Request Submission, Evaluation, and Communication
Update Development and QC Review
Consistency Review
Figure 45: Major Areas of the Website Management Process
Table 35: Website Management Roles and Responsibilities

Requestor Enters the initial Request on the Website R A/V A/V
Update and Tracking Log; Provides QC review
of the draft update; Coordinates with the OCM
Track to communicate the update release as
appropriate
Track Manager Approves or denies Requests prior to submittal. A I I
Communication Provides communications consistency review V N/A R

Consistency and QC and final QC review for the update10;
Reviewer Coordinates with the Requestor to
communicate the update release as appropriate
Website Coordinator Responsible for coordinating the website C R C

(WC) management process for updates (not including
Initiatives). Reviews Requests to determine
update type (e.g., content-only, technical);
Develops content-only updates.
Technical Coordinator Researches Requests for technical updates; C R C
(TC) Determines if a technical update is a Stand-
alone or Initiative update. Develops technical
updates.
9
Responsibilities for development of an update are dependent upon the type of update requested
10
This is generally assigned to an OCM Track member.
Page 122 of 138 11/09/2017

23 Lessons Learned Management

23.1 Overview
Lessons Learned Management describes the process of identifying useful information the
organization should retain for future adoption. Depending on the Lesson Learned, it could be a
valuable technique or an outcome the Project might want to repeat. Conversely, a Lesson
Learned could be an undesirable result to avoid. Often, identifying Lessons Learned is as simple
as asking the question, “What worked well, what didn’t work so well, and what should have been
done that was not?”
23.2 Purpose
The purpose of these procedures is to provide instructions to Project Team Members regarding
Lessons Learned Management. Ultimately, Lessons Learned are a matter of improving the
effectiveness 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 shares information to
others who may benefit from it.
23.3 Process
Lessons Learned Management contains four phases: Identification, Evaluation, Execution, and
Closing. As Lessons Learned are identified by Project Team staff, the following process is utilized.
Identification
The process is initiated with the identification, submission, and logging of a Lessons Learned item
in the Lessons Learned log. The individual logging the Lesson Learned will set the status to
“Developing” and inform their Track Manager of the submission.
A Lessons Learned Log will be used to document, track, and manage Lessons Learned. Lessons
Learned progress will be reviewed at the Track and Project-wide levels on a bi-weekly basis. It is
important for the Project Team to regularly revisit the log and to stay up to date with its contents.
The following three questions should be considered when identifying Lessons Learned:
1. What worked well, so it can be repeated?

In asking this question the team, or individual, should focus on accomplishments. This is
an opportunity to recognize the value of the effort performed and to focus on the positive
outcomes of the activity/activities. These are the lessons to be repeated in future activities.
2. What did not work so well, so it can be avoided?
The purpose of asking this question is to facilitate discussion and to focus on areas of
improvement. The emphasis should be on reflecting on the team’s performance and
specific deficiencies which can lead to future solutions. During this exercise the team
should focus on facts as opposed to assigning responsibility for complications. These are
the lessons to avoid and/or improve upon in future activities.
3. What should have been done that was not?
When asking this question, the objective for the team is to think about how it can adjust,
enhance, or increase desired outcomes in the future on similar initiatives. Essentially, this
Page 123 of 138 11/09/2017

question gives team members an opportunity to look back, knowing all that they know
now, and determine what opportunities were missed. These are the lessons to implement
in future activities.
The goal of asking these questions is to develop some conclusions that may lead to process
improvement and will aid as an organizational process asset for the Project.
Evaluation
During the Evaluation phase, a Track Manager will evaluate the log item for completion and
validity. If the Track Manager deems the Lesson Learned to be incomplete, it will be sent back to
the Identifier to provide more information. If the information provided is sufficient, the Track
Manager will evaluate the Lesson Learned to determine its validity. If determined to invalid, the
status will be set to “Removed” and the Lesson Learned closed. Should the item be found to be
valid, the Lesson Learned will transition to the Execution phase.
Execution
Within the Execution phase, the Track Manager, Owner, or both will initiate the Lessons Learned
documentation process. Document components will be identified during Lessons Learned
working sessions, and may include 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. After completing the Lessons Learned working sessions, the Owner or Track
Manager will submit the updated Lesson Learned to the Identifier for verification. The Lesson
Learned will either be requested for rework or recommended for closure.
Documenting a useful Lesson Learned requires a clear understanding of the purpose and
importance of recording the successes and/or failures of the event. 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 Project work.
The following are to be considered for building relevance into Lessons Learned and creating value
to others in addressing similar situations:
• Identify the process or event 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.
To be easily accessible and beneficial across the Project, Lessons Learned should have the same
form and function. To preserve institutional knowledge, Lessons Learned sessions should be
performed within two weeks after the significant Project events/activities and should be
documented within the Lessons Learned log.
In addition, Lessons Learned will be organized and captured for sorting by “strength” or
“weakness”.
1. Strength are events, processes, or activities the Project desires to repeat in the future.
2. Weakness are those events, processes, or activities the Project desires to avoid in the
future.
Page 124 of 138 11/09/2017

Figure 46:Lessons Learned Management Process
Page 125 of 138 11/09/2017


The Lessons Learned Management roles and responsibilities are described below. This
the RACIV role and responsibilities during each of the four (4) major areas of the Lessons Learned
Management Process as shown in the figure below.
1 2 3 4
Identification Evaluation Execution Close
Figure 47: Major Areas of the Lessons Learned Management Process
Table 36: Lessons Learned Roles and Responsibilities

• Identify a Lesson Learned worthy of sharing
Identifier and documenting R R V I
• Creates content for Lessons Learned Log
• Participating in discussions to fully
understand the Lessons Learned
• Facilitate a meaningful resolution/solution
Track description
Manager • Shares the information with other Project
Team Members I V R A
• Utilizes the information to avoid duplication of
issue in future work
• As needed or directed by Track Manager,
may participate in discussions to fully
understand the need of the Lessons Learned
may facilitate a meaningful resolution/solution
description
Owner I R/C R/C R/C
may share the information with other Project
Team Members
may utilize the information to avoid
duplication of lesson in future work
• May participate in discussions to fully
Project
understand the need of the Lessons Learned
Management I I C C
• Approves the content for publication and
Team
sharing
Page 126 of 138 11/09/2017

24 Appendix A: Project Talking Points

General Dos/Don’ts
• DO: Explain acronyms. Those who are not close to the Florida PALM Project or otherwise
have less visibility to technology transformation projects may not know what “SSI” means,
even though we live and breathe this term every day.
• DO: Emphasize our, the collaboration the Project had with State agencies. Florida PALM
isn’t just an effort by this Project Team or DFS.
• DO: Speak positively about Florida PALM and the Project Team (including contractors).
• DON’T: Discuss draft strategies.
• DON’T: Discuss procurement-related items.
• DON’T: Discuss how/when FLAIR will officially sunset. The Project role is to deliver the
State a system that can replace FLAIR/CMS—the State will make the decisions about
when FLAIR and CMS will be sunset.
• DON’T: Say the Project was outsourced. The Project is using a team of State staff with
decades of State service and is augmented by experienced support services.
• Don’t disparage FLAIR or CMS. These systems were cutting-edge when they were
released and thousands of State employees still use them every day.
Why Replace FLAIR/CMS

• The Legislature approved funding to review options for replacing or enhancing FLAIR and
CMS. The Study recommended replacement of FLAIR and CMS to meet the State’s
financial management needs.
• FLAIR, Florida’s current accounting system, was cutting-edge when it was developed...
in the 1970s. But so were Atari, cordless phones, and the Oldsmobile Cutlass. Our
accounting system cannot keep up with today’s complex markets, regulations, and
practices.
• FLAIR was built in the 1970s but isn’t supported by modern developers, systems, and
upgrades.
• The current accounting system, FLAIR, was implemented in the early 1980s and is no
longer the industry standard.
• Agencies have had to develop expensive workarounds to make up for FLAIR’s limitations.
As Florida grows, agencies would continue to have to develop and maintain additional
agency unique business systems or find other creative solutions.
• FLAIR has been patched and bandaged to try to keep up with state and federal mandates.
• It Is becoming more challenging to find and hire talent with the technical skill to work on
the system.
• Data fields for accounting entries in FLAIR are size-limited, which limits the capability for
accurate accounting and reporting.
• The decades of experience State employees have with FLAIR simply cannot be replaced
in the future.
• Today’s new hires are not typically trained on technologies used by legacy systems like
FLAIR.
Florida’s Finances
• Florida primarily operates a $90 billion enterprise on a system built in the 1970s.
Page 127 of 138 11/09/2017

• Even though Florida has grown to become the third most populous State in the US with
an economy larger than most countries, Florida’s financial management system operates
on antiquated technologies.
Different than Project Aspire?

• Project Aspire was the State’s previous attempt to implement a modern financial
management solution. The Florida PALM Project glean best practices and lessons learned
from the Aspire Project.
• The State has made a significant investment with years of deliberate planning prior to
Florida PALM’s implementation.
• The Florida PALM Project is documenting and standardizing business processes prior to
the procurement and implementation of a new system, as this will allow both the State and
the selected SSI vendor to be better prepared.
• The Florida PALM Project is leveraging support from consultants who have significant
experience designing and building financial management solutions for the public sector
before a solution is selected and after the implementation
Anticipated Florida PALM Benefits (General)

• Records and documentation are expected to be managed in Florida PALM, making DFS
audits smoother and keeping records in one place.
• Florida PALM is anticipated to reduce many of the paper-intensive processes and will help
the State become more paperless.
• Florida PALM is expected to provide near real-time updates in the State’s new financial
management system, reducing the multiple reconciliations that occur today.
o Florida PALM may eliminate most, if not all, of the use of departmental and central
FLAIR in order to enable the State to have one set of books.
o The new financial management system is expected to consolidate where our
financial data is kept and allow the State to track and maintain its cash balance in
one location.
• Florida PALM will help the CFO better meet his/her constitutional obligation by painting a
much clearer picture of Florida’s finances, including an enterprise view of cash flow and
financial obligations.
• Florida PALM is expected to reduce the State’s risk exposure by harnessing modern
financial management technology built on the premises of scalability, flexibility, and
maintainability.
• Florida PALM is expected to improve State and agency-specific decision making by
capturing a consistent and an expandable set of data housed in a single system.
• Florida PALM is expected to improve the State’s financial management capabilities to
enable more accurate oversight of budget and cash demands today and in the future.
• Florida PALM is expected to improve productivity, reduce operational complexity, and
increase internal controls by enabling standardization and automation of business
processes within and between DFS and agencies.
• Florida PALM is expected to reduce financial reporting production and preparation time.
• Florida PALM is expected to provide more robust reporting functionality and reduce the
need to create reports outside of the system (e.g. reports created in Excel).
• Florida PALM is expected to allow the State to maximize interest earnings on the money
in state coffers through features like scheduled payments, where agencies can request a
“pay on” date.
Page 128 of 138 11/09/2017

• Florida PALM is expected to have the ability for workflow and approval processes that
promote internal controls and safeguarding of State assets.
Anticipated Florida PALM Benefits (Agency Specific)

• Agencies should be able to create “what if” analyses based on more robust financial
analysis abilities.
• Agencies are expected to have the opportunity to streamline workarounds and interim
processes used to compensate for the State accounting system’s limitations.
• Agencies should be able to issue one warrant per vendor instead of issuing several
warrants, even if the funds originate from different funding streams.
Timeline & Process

• The Project expects to receive many questions about timeline and process because
people want to know how and when they should expect to see Florida PALM. The Project
should share the most accurate information possible while not releasing any confidential
information about the procurement process.
• Currently, the Project is in the Pre-Design, Development, and Implementation Phase, with
a focus on planning and preparing for a financial management solution.
• At the end of the procurement activities, the Project intends on selecting a Software and
System Integrator and entering the Design, Development, and Implementation Phase.
• The State’s business needs led the development of standard business requirements for
the new financial management system,
• Our subject matter experts agree, the vast majority of State employees who participated
in Workgroups or Workshops feel confident in the Florida PALM Project and its Team.
• To develop the requirements for Florida PALM, the Project held more than 100
collaborative meetings, with over 500 individuals These individuals helped develop
requirements, which will be used in the procurement of our State’s new financial
management system.
• The Project Team worked with consultants, agencies, and leadership to define the Florida-
specific requirements needed for the State to adopt Florida PALM.
• Agency input and dedication to the Project is crucial to the success of this project.
• For the first time ever, the Florida PALM Project documented the State’s financial
management processes from end to end.
• As a System and Software Integrator (SSI) services are selected, our financial
management processes may slightly change depending on the software selected.
• This Project is a business transformation project (transforming the way the State does
business) and will be supported by modern technology.
The FLAIR Study

• In 2013, the Legislature directed DFS to conduct the FLAIR Study. The Study provided
analysis on considerations for either enhancing or replacing FLAIR. The Project has
developed a Project Management Plan and strategies based on what will work best for
the State.
• The FLAIR Study provided great insight into options for replacing FLAIR.
• The FLAIR Study also made the case for “why” FLAIR and CMS should be replaced.
• The Project incorporated insights from the FLAIR Study into the development of our
Project Management Plan and Project Charter, updating both where appropriate based
on our State’s current and future needs.
Page 129 of 138 11/09/2017

25 Appendix B: Deliverable Expectations Document (DED)

Template
The Deliverable Expectations Document (DED) is a tool used to record the Project requirements
for a deliverable and establish clear expectations and acceptance criteria for the deliverable’s
scope and content.
Deliverable Authors will use the DED to work with the Project’s Track Manager to identify the
acceptance criteria to be used during the deliverable submission review and acceptance process.
The DED communicates to the Owners, Contributors, Reviewers, and Approvers a clear
understanding of the approach to develop the deliverables and the acceptable outcome of the
collaborative work.
The DED template can be found in the PMO and PMP folder in SharePoint, file name “Appendix
B - DED Template”.
Page 130 of 138 11/09/2017

26 Appendix C: Deliverable Review Form

The Deliverable Review Form is a tool used to document whether a deliverable’s scope and
content meets the Project’s expectations and acceptance criteria.
Deliverable Authors and Reviewers will use the Deliverable Review Form during submission,
round 1 and 2 reviews, and final review. The Form consists of the following sections:
• Deliverable Review Instructions
• Deliverable Summary
• Submission Quality Control Review Checklist
• Deliverable Review Comments
The Deliverable Review Form can be found in the PMO and PMP folder in SharePoint, file name
“Appendix C – Deliverable Review Form”.
Page 131 of 138 11/09/2017

27 Appendix D: Deliverable Acceptance Form

The Deliverable Acceptance Form is used to formally acknowledge and accept delivery
of the work completed for the deliverable. The Contract Manager, Track Manager (if
applicable), and Deliverable Owner’s signatures attest to the agreement the deliverable
has been completed and no further work should be done.
The Deliverable Acceptance Form can be found in the PMO and PMP folder in SharePoint, file
name “Appendix D – Deliverable Acceptance Form”.
Page 132 of 138 11/09/2017

28 Appendix E: Master Quality Control Checklist

The Master Quality Control Checklist (MQCC) is the Project’s single file or source that identifies
and communicates the expectations for quality inspections across Project Management Plan
process areas.
The MQCC can be found in the PMO and PMP folder in SharePoint, file name is “Appendix E –
Master Quality Control Checklist”.
Page 133 of 138 11/09/2017

29 Appendix F: Definitions
Cost Management - The process of effectively planning and controlling cost. This includes
efficient estimation and management of funds for resources such as staff, equipment, hardware,
software, facilities, and expenses needed to complete Project activities. Cost Management also
considers the effect of Project changes and decisions that would impact the cost of completing
the Project.
Budget – Funds appropriated by legislation each Fiscal Year (FY).
Projected – Expenditures anticipated to occur for each month throughout the FY.
Incurred – Expenditures owed, but that have not been paid.
Actual – Expenditures that have been paid.
Schedule Management – Establishes the criteria and approach for developing, monitoring, and
controlling the Master Project Schedule.
Master Project Schedule – Tool used to review, plan, and analyze the Project’s progress and
critical path typically created in Microsoft (MS) Project. Includes a listing of Project milestones,
activities, and deliverables, with work estimates, start and finish dates, resource allocation, task
sequencing, and dependencies.
Baseline Schedule – The Project’s approved version of the Master Project Schedule that can only
be changed through formal Project Change Request procedures (PCRs).
Project Management Standards – Standards established by the Agency for State Technology
(AST) Rule 74-1 ascertaining define the expectation to execute and update the approved project
schedule with actual work effort and project progress (tasks, milestones, and deliverables
completed) to track Schedule Performance Index (SPI) and CPI.
Schedule Performance Index (SPI) – SPI is a measure of schedule efficiency. An SPI less than
1 indicates less work was completed than planned. An SPI greater than indicates more work was
completed than planned.
Cost Performance Index (CPI) – CPI is a measure of cost efficiency of budgeted resources for
the work completed. A CPI less than 1 indicates cost overruns for work completed. A CPI greater
than 1 indicates cost underruns of performance to date.
Key Project Milestones – Significant events on the Project's roadmap that serve as progress
markers.
Milestones – Zero-day duration tasks on the Master Project Schedule.
Critical Path – Longest sequence (path) of activities in the Master Project Schedule, through all
the inter-connected tasks, which must be completed for the Project to complete on time.
Quality Management System (QMS) - “The Project Quality Program”. QM S refers to management
methods used to enhance quality and productivity on the Project. QMS is a comprehensive
Page 134 of 138 11/09/2017

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 Managers, 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 Evaluation (TQE) - Process and standards compliance evaluations that are
concerned with technical deliverables. The elements for technical quality are:
1. Project work products (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 work products before they go through a
quality-control review.
2. Technology installation deliverables are evaluated per the test strategy and supporting
test plan.
Communication Vehicles – Methods that may be used for engaging targeted audiences. (See
Appendix 5 of the Pre-DDI Communications Plan)
Content Standards – A set of criteria identified in the Project’s Pre-DDI Communications Plan that
should be met during the development and release of Project communications.
External Communication – Outside of the Florida PALM Project (e.g., state agencies) but not
intended for the general public
Florida PALM Project Style Guide – The document identifying document and messaging
standards for the Project.
Internal Communication – Inside of the Florida PALM Project, which includes DFS employees
and contractors dedicated to the Project
Project Communication – A communication sent on behalf of the Project to its stakeholders or

other entities. This does not include communications such as emails or phone calls to agency
counterparts as part of a Project Team member’s everyday work.
Public Communication – Intended for the general public.
Page 135 of 138 11/09/2017

Acceptance – The acknowledgement that the content is adequate and suitable.
Approval – The Executive Steering Committee’s (ESC) approval of a Major Project Deliverable.
Work products - Documents in any medium, electronic, or hard copy, and MSOffice format such
as Word, Excel, PowerPoint, Project, Visio, etc.
Deliverable - Any tangible outcome specified in a contract, statement or scope of work, strategy,
or plan document. Deliverables are classified as work products, internal deliverables, technology
implementations, events, or qualified and quantified benefits. These may be contractual or non-
contractual.
Deliverable Expectation Document (DED) – A document used to record a mutually agreed upon
acceptance criteria in addition to or already communicated in the contract document(s).
Events - Training, meetings, knowledge transfer, interviews, or surveys.
Major Project Deliverable - A major Project deliverable is a deliverable on the Project's critical
path. Critical Path is a term used to define a task wherein none of the tasks can be delayed without
affecting the final Project end date.
Submission Quality Control (QC) Review – A review to affirm the deliverable meets the Projects
minimum acceptance criteria as laid out in the DED, and the quality of such deliverable meets the
standards defined in the Submission QC Review Checklist. The deliverable must pass this review
in order to start the review process.
Procurement Management - The process of planning, developing strategies, conducting formal

and informal procurement activities, negotiating contracts, and managing contracts and vendor
relationships through the contract life cycle.
Supply Requisition Purposes - Small purchases or commodity State contract purchases which
may include office consumables, computers, equipment, and office furniture or subscription
services. These purchases are included in the annual Spend Plan and acquired on a “just in time”
basis through the fiscal year as needed.
Support Services Purchases - More complex than supply purchases, each planned as part of
Track strategies, scheduled, and executed by the Florida PALM Project Management Office.
Support services purchases require the development of a detailed scope of work, evaluation or
vendor selection criteria, and the execution of a two-party contract or purchase order contract.
Procurement Planning - Includes annual needs assessment, budget analysis, and general timing
for the acquisition and delivery of services and supplies for the operation of the Project throughout
each fiscal year. Planning may also consider the effect of Project changes and decisions that
would impact the funding and scheduling.
Procurement Authority - The Project Director has the authority to purchase the necessary goods
and services to achieve the outcomes of the Project within the defined budget while the Executive
Steering Committee has the authority to approve major Project deliverables, which could be
procurement documentation or work products produced by a contractor.
Page 136 of 138 11/09/2017

Section 287.017, F.S. – States the purchasing categories and thresholds that dictate how formal,
informal, or exceptional purchases are made.
DFS Agency Policies and Procedures (AP&P) #02-2 and DFS “Contract Management Life Cycle
Guide” - Dictates the agency specific procedures and approval flows.
Performance Measure – Evaluated element that indicates whether the Project is likely to reach
its intended outcomes and identify an activity’s efficiency and/or effectiveness. These measures
should be:
• Measurable (Quantifiable and Qualitative)
• Tracked over time, to see trending
Status Indicators – A colored indicator that gives an indication as to whether the measures status
is positive or negative. The Project will use the following colors and definitions for its status
indicators:
• Green. The Project performance area is on track without material issues.
• Yellow. The Project performance area faces a challenge or set of challenges that could,
if left unmanaged, negatively impact the Project’s outcome. The Project Team should
prioritize corrective action.
• Red. The Project performance area faces a challenge or set of challenges that threatens
its outcome. The Project Team should take corrective action immediately.
Full Time Equivalent (FTE) – A unit that indicates the workload of an employed staff person is 40
hours per week. The Project typically uses this term to differentiate between State and Contractor
Team Members.
Contractor – For the purposes of the Pre-DDI phase of the Florida PALM Project, these are
individuals or groups providing support services. A list of these services can be found at:
http://www.myfloridacfo.com/floridapalm/SupportServices.htm. (Also referred to as consultant.)
Florida PALM Project (Project) – The project with the vision of implementing a statewide financial
management system that enforces standardization, acts as a scalable foundation to evolve as
business needs change, and positions Florida for future innovation as it adopts true enterprise-
wide solution. PALM is an acronym for Planning, Accounting, and Ledger Management.
Project State Team – The DFS employees dedicated to the Project.
Project Team – The Project State Team and Contractors dedicated to the Project.
Project Track – Workstreams that are staffed to simultaneously support the mission of the Project.
Risk - 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.
(i.e., “unborn issue”.)
Ad Hoc Risks - 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
meetings or schedule reviews.
Page 137 of 138 11/09/2017

Risk Assessments - Scheduled and formalized events for identifying Project risks.
Issue - Any unresolved situation that most often negatively impacts the Project and typically arise
due to unplanned or unexpected events.
Action item - An Action Item is a proactive task identified by the Project Team 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.
Decision - A formal communication of a judgement or management direction on an issue under

consideration.
OCM Collaboration Coordinator – Also known as the OCC; the OCM Track Team member
responsible for coordinating, tracking, and reporting on the Project’s collaboration activities.
Other entities – Entities that do not fall into the other groups, but that may provide helpful
information (e.g., Gartner).
Other States – States that have, or are in the process of, developing and implementing a Financial
Management (FMS) (e.g., Alabama, Georgia, and New York).
State of Florida agencies – Agencies that work in or support the Florida Accounting Information
Resource (FLAIR) and/or the Cash Management System (CMS), or will be affected by the
replacement of those systems (e.g., Florida Department of Transportation, Department of
Financial Services, and Florida Fish and Wildlife Conservation Commission).
Universities, cities and public sector entities – Other public entities that have, or are in the process
of, developing and implementing a FMS (e.g., the City of Tallahassee, FSU, and UF).
Additional definitions may be found in the Pre-DDI Project Glossary on the Project’s website.
Page 138 of 138 11/09/2017

Florida PALM Pre DDI Project Management Plan

Uploaded by

Copyright:

Available Formats

Florida PALM Pre DDI Project Management Plan

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Florida PALM Pre DDI Project Management Plan

Uploaded by

Copyright:

Available Formats

Pre-Design, Development

and Implementation (DDI)

Department of Financial Services

Page 2 of 138 11/09/2017

Page 3 of 138 11/09/2017

3.1 Who Should Use This Document?

3.2 Interdependence and Related Documents

Page 4 of 138 11/09/2017

• The Project Charter

3.3 Distribution of Document

6 Project Life Cycle

Page 5 of 138 11/09/2017

1. BPS – Business Process Standardization – responsible for business process

6.1 Archive Project

6.2 Finalize Lessons Learned

Page 6 of 138 11/09/2017

6.3 Project Signoff

6.4 Contract Close Out

7 Roles and Responsibilities

• Responsible – Project Team Member is responsible for completion of the action

Page 7 of 138 11/09/2017

8.3 Determination of Measures

1. Identification of a broad list of potential measures with input which included:

Page 8 of 138 11/09/2017

8.4 Performance Measures

Page 9 of 138 11/09/2017

Table 1: Project Performance Measures

ID Assessment Criteria Ref Measure Name Measure Calculation Status Indicators

Page 10 of 138 11/09/2017

ID Assessment Criteria Ref Measure Name Measure Calculation Status Indicators

Page 11 of 138 11/09/2017

ID Assessment Criteria Ref Measure Name Measure Calculation Status Indicators

Page 12 of 138 11/09/2017

1. Gather and Maintain Data and Draft Reports

Gather and Maintain Data and Draft Reports

Collection and Timing

Project Oversight Analysis Executive Summary Report (I-PMO7)

Page 13 of 138 11/09/2017

8.6 Roles and Responsibilities

Table 2: Performance Management Roles and Responsibilities

Page 14 of 138 11/09/2017

Legislative Budget Request

Page 15 of 138 11/09/2017

Page 16 of 138 11/09/2017

Submit Evaluate Execute Close

Submit LBR (no

Process Review Annual

Project needs for Respond to

Proposed Funds released

Figure 3: Yearly Process Flow

Page 17 of 138 11/09/2017

Page 18 of 138 11/09/2017

Submit Evaluate Execute Close

Submit Budget Amendment

Process Take Action

Figure 4: Release Process Flow

Page 19 of 138 11/09/2017

Table 3: Spend Plan Reconciliation Checklist

Page 20 of 138 11/09/2017

Submit Evaluate Execute Close