I n f r as t r u c t u re E n h a n c e m e n t a n d
T r a f f i c M i t i g a t i o n P r o g r a m
Program Management Plan
Department of Transportation and Drainage
Submitted by
MOVEBR PROGRAM MANAGEMENT TEAM
Capacity Improvements – CSRS
Community Enhancements – Stantec
April 2020
Rev. 1
RI PROGRAM MANAGEMENT PLAN
Revision Control Log
Revision Date Issued Description of Changes
Pages
Affected
Revision 1 4/20/2020 Chapter 1: Misc. grammar edits, edited org. chart.
Chapter 2: Misc. edits to incorporate Concept Reports
and Prioritization; acknowledge other program
standards manuals. Chapter 3: Edited schedule
update frequencies; removed work/resource
elements; reference SharePoint. Chapter 4: Misc. edits
to reflect application of Goverence Committees and
stage gate approvals. Chapter 5: Edited process
graphics; misc. edits to match PMT’s applications of
Risk/Opportunity, Issue, Action Item, Decision, and
Change processes; reference SharePoint; removed
5.1.3 Risk Severity Scoring Matrix section; removed
Issue, Action Item, Decision Meetings tables. Chapter
6: Misc. edits to reference SharePoint and eBuilder.
Chapter 7: Edited to reference current tools used by
PMT. Chapter 8: Misc. edits to reflect current meeting
and reporting frequencies by PMT; reference SBO
Engagement Plan. Chapter 9: Misc. edits to
incorporate PMT’s application of stage gate meetings.
Chapter 10: Edits to address differences between
organizational and personnel staff changes. Entire
Document: Edited MoveBR to MOVEBR to match
program style guide
All edits approved by Senior Leadership Team on
4/15/2020
Multiple
RI PROGRAM MANAGEMENT PLAN
i
Program Management Plan
As of April 1, 2019, the City of Baton Rouge and the Parish of East Baton Rouge have started implementation
of MOVEBR, a historic Sales Tax referendum created to improve transportation. The MOVEBR initiative will
help the citizens in East Baton Rouge Parish with traffic mitigation by building new roads, sidewalks, and
managing traffic in the parish. The tax initiative passed on December 8, 2018, is expected to generate $46M
annually for the City-Parish and will be spent on the published MOVEBR projects. The program will last
through March 31, 2049.
As presented, this Program Management Manual is a living Program Management Plan (PMP) evidencing
the strong management systems that will be put in place to achieve efficient and effective delivery. It is
comprehensive in content and serves as a firm foundation for the life of the program. It demonstrates how the
successful execution of the unique project groupings will be accomplished through the Baton Rouge
Department of Transportation and Drainage (DTD) and our partners as we operate in a seamless, integrated
manner.
The PMP documents the structure, processes, and resources that will be used to execute a successful program
and create concrete deliverables that meet the contractual requirements. The PMP covers the organization,
approach and timeline, controls, schedule and resource management, tools, quality management,
communication plans, Small Business Outreach and public involvement. This will provide the foundation to
achieve program goals and communicate to stakeholders how the program will be managed. By adhering to
this plan, DTD will implement and utilize the proper management controls for the program, thereby promoting
the achievement of the program’s goals and objectives. This PMP also demonstrates how successful execution
of the program and projects in the two unique portfolios of Community Enhancement and New Capacity will be
accomplished utilizing the customized and complementary resources of two teams operating as a fully
integrated entity with a seamless approach to management and delivery.
Two teams, known as New Capacity and Community Enhancement, will work with DTD staff to effectively
and efficiently deliver the MOVEBR program and projects. As defined in this document, any MOVEBR project
refers to any proposed or existing undertaking named in the approved MOVEBR referendum list or to the
individual efforts resulting from a parish-wide call for projects.
Approved by the sponsor and leadership during the quick start phase in July and August of 2019, this PMP will
be maintained throughout the life of the program; it will be kept up-to-date and should be considered the
primary source for information about the program’s structure, systems and management processes, tools, and
terminology. The DTD Team will review the PMP at the beginning of each program phase to confirm
compliance with the direction that has been established.
Once the PMP has been approved, the management processes described herein will be the basis for training
the teams. This training will be included in the team member onboarding procedures so that new team
members are properly trained as they rotate on to the project. This plan will be baselined and archived in the
Document Management System. Except for minor wording changes or changes to the organization charts
and/or resource assignments in the Governance section, this plan will not be changed without an approved
Change Request from the City-Parish Department of Public Works (DPW) Assistant Chief Administrator’s Office
(ACAO). The Program Management (PM) Lead is responsible for updating this document, as required, when
resource assignments change or there is an approved Change Request. The revised PMP will be reviewed and
approved by the DPW’s ACAO’s Office prior to being updated in the Document Management System.
RI PROGRAM MANAGEMENT PLAN
ii
Contents
1
Program Overview ......................................................................................................................... 1
1.1
Vision Statement ..................................................................................................................... 1
1.2
Organization and Governance ................................................................................................... 1
1.2.1
RASCI Chart ................................................................................................................... 2
1.2.2
Program Governance Bodies ............................................................................................. 2
1.3
Escalation Process ................................................................................................................... 5
2
Scope Management Plan ................................................................................................................. 6
2.1
Scope Management ................................................................................................................. 6
2.1.1
Define Scope .................................................................................................................. 6
2.1.2
Validate Scope ................................................................................................................ 6
2.2
Methods and Standards Management ........................................................................................ 7
2.2.1
Define Standards ............................................................................................................ 7
2.2.2
Approve Standards .......................................................................................................... 7
2.2.3
Maintain Standards ......................................................................................................... 8
3
Schedule and Resource Management Plan ......................................................................................... 9
3.1
Key Schedule Management Concepts ......................................................................................... 9
3.1.1
Develop and Baseline ...................................................................................................... 9
3.1.2
Track Progress and Maintain ........................................................................................... 10
3.1.3
Refine and Revise ......................................................................................................... 10
3.2
Program Work Plan Definition ................................................................................................. 11
3.3
Project Work Plan Definition ................................................................................................... 11
3.3.1
Work Plan .................................................................................................................... 11
3.4
Project Work Plan Management ............................................................................................... 12
3.4.1
Monthly Work Plan Management Process .......................................................................... 12
4
Deliverable Management Plan ........................................................................................................ 14
4.1
Define Deliverable Expectations .............................................................................................. 14
4.2
Sign-off Deliverable ............................................................................................................... 14
4.3
Deliverable Process Timing ..................................................................................................... 14
4.4
Deliverable Reviews ............................................................................................................... 15
5
Change Control Management Plan .................................................................................................. 16
5.1
Risk Management .................................................................................................................. 16
5.1.1
Process Summary ......................................................................................................... 16
5.1.2
Risk Types ................................................................................................................... 18
5.1.3
Risk Monitoring ............................................................................................................. 18
5.1.4
Risk Meetings ............................................................................................................... 19
5.2
Issue Management ................................................................................................................ 19
5.2.1
Process Summary ......................................................................................................... 19
5.2.2
Issue Types .................................................................................................................. 21
5.2.3
Issue Monitoring ........................................................................................................... 21
5.2.4
Issue Meetings.............................................................................................................. 22
5.3
Action Items ......................................................................................................................... 22
5.3.1
Process Summary ......................................................................................................... 22
5.3.2
Action Item Priorities ..................................................................................................... 22
5.3.3
Action Item Meetings ..................................................................................................... 22
5.4
Decisions ............................................................................................................................. 23
5.4.1
Process Summary ......................................................................................................... 23
5.4.2
Decision Priorities .......................................................................................................... 23
5.4.3
Decision Process ........................................................................................................... 23
5.4.4
Formal Decision-making Process ..................................................................................... 24
5.5
Change Control ..................................................................................................................... 25
5.5.1
Process Summary ......................................................................................................... 25
6
Document Management Plan ......................................................................................................... 28
6.1
Document Management Overview ........................................................................................... 28
RI PROGRAM MANAGEMENT PLAN
iii
6.1.1
Purpose ....................................................................................................................... 28
6.1.2
Document Management Roles and Responsibilities ............................................................ 28
6.2
Document Management System .............................................................................................. 28
6.2.1
Document Management Tool .......................................................................................... 28
6.2.2
Directory Structure and Permission Levels ........................................................................ 28
6.2.3
Document Naming Conventions ...................................................................................... 29
6.2.4
Document Management Process ...................................................................................... 29
6.2.5
Document Management Tool Administration ..................................................................... 29
7
Tools Strategy Plan ...................................................................................................................... 31
7.1
Purpose ............................................................................................................................... 31
8
Status and Stakeholder Communications Plan.................................................................................. 32
8.1
Status Communications ......................................................................................................... 33
8.1.1
Communications Plan .................................................................................................... 33
8.1.2
Meeting and Communications Schedule............................................................................ 33
8.2
Stakeholder Engagement ....................................................................................................... 35
8.2.1
Stakeholder Involvement Plan ........................................................................................ 35
8.2.2
Stakeholder Monitoring .................................................................................................. 35
8.2.3
Stakeholder Effectiveness .............................................................................................. 35
8.3
SBO Engagement .................................................................................................................. 35
9
Quality Management Plan .............................................................................................................. 37
9.1
Quality Management Plan Objectives ....................................................................................... 37
9.1.1
Implementing the Quality Management Plan ..................................................................... 37
9.1.2
Maintaining the Quality Management Plan ........................................................................ 37
9.2
Quality Assurance Plan ........................................................................................................... 37
9.2.1
Quality Verifications ...................................................................................................... 37
9.2.2
Quality Verification Approach .......................................................................................... 38
9.2.3
Non-Compliance and Escalation ...................................................................................... 38
9.2.4
Quality Verification Reporting ......................................................................................... 39
9.2.5
Quality Verification Closure ............................................................................................ 39
9.3
Quality Control Plan ............................................................................................................... 39
9.4
Quality Testing...................................................................................................................... 39
10
Organizational Change Management Plan .................................................................................. 40
RI PROGRAM MANAGEMENT PLAN
1
1 Program Overview
The Chief Engineer is responsible for providing standards and guidance to the PMT and managing the program
processes (described herein). In programs and projects, there can be differences between the work of the PM,
which is focused on program-specific management processes, and the work of the teams who build the
solution.
There are two guiding principles that are cultural in nature aiding in the effective deployment of PM processes:
• First, the Project Managers, from day one, will have a commitment to executing sound PM processes.
Project managers will ensure team members execute on documented procedures thereby managing
program risks. The program and project leadership will establish, promote and monitor compliance with
the PM’s processes.
• The other principle is a corollary of the first. PM will streamline processes and procedures to simplify them
for team members to execute. PM will also train team members, as necessary, in understanding these
processes, and confirm that essential disciplines are maintained.
1.1 Vision Statement
MOVEBR will be the industry standard of excellence in delivering transportation solutions that will
move our region in a safe, sustainable manner and further enhance strong neighborhoods,
communities, and economic vitality for all residents of East Baton Rouge.
1.2 Organization and Governance
The organization chart below shows the program governance and team management structure. Escalation
procedures are directly aligned with the governance hierarchy.
RI PROGRAM MANAGEMENT PLAN
2
1.2.1 RASCI Chart
This section describes the participation by role or team for deliverables or major work products. These terms
are used in the subsequent sub-sections:
• Responsible—the role or team that is primarily responsible for performing or overseeing the creation of
the deliverable or work product
• Accountable—the role or team that is answerable for the content of the deliverable or work product (only
one per row below)
• Supportive—can provide resources or can play a supporting role in implementation
• Consulted—the role(s) or team(s) that participate in creation of the deliverable or work product
(frequently knowledge leaders)
• Informed—the role(s) or team(s) to whom the deliverable or work product will be communicated
The following describes the participation by role or team for deliverables or major work products. These terms
are used in this table:
1.2.2 Program Governance Bodies
As identified below, the following titles refer to the defined positions and entities throughout the PMP:
• Executive Management Sponsor – Assistant Chief Administrative Officer, Public Works
• Program Manager – refers to Director of DPW/Department of Transportation and Drainage
• PMT – refers to both firms collectively performing program management services over the life of the
program
RI PROGRAM MANAGEMENT PLAN
3
• PM Lead – refers to either of the project managers (or both) of the two firms leading program
management services over the life of the program
1.2.2.1 Program Executive Sponsor
Accountabilities
• Sponsor the program
• Provide strategic direction for the program
• Promote the long-term vision for the program solution in the client organization
• Realize and sustain the program benefits
Relationships
• Highest level of authority for the program
1.2.2.2 Executive Management Sponsor / Program Manager (PM)
Accountabilities
• Represents the enterprise perspective from key organizations
• Advise and guide the PM to promote the program meeting its goals and objectives
• Resolve escalated program controls in a timely manner
Relationships
• Provide guidance and/or decision-making for high-impact program issues and
escalated requests
• Monitor program and projects’ status on an ongoing basis, including attendance in
Program Steering Committee status meetings
• Champion the program and individual projects within constituent organizations
• Represent the perspective and issues of constituent organizations to the Program
Executive Sponsor
• Provide strategic guidance to the Program Executive Sponsor in meeting program
objectives
• Resolve escalated issues and decisions
1.2.2.3 Chief Engineer
Accountabilities
• Direct overall project success
• Manage the project schedule, scope, budget, and quality so they align with
leadership expectations
• Manage team performance, training, mentoring and reputation
Relationships
• Supervise team
• Report to Project Manager
• Client liaison and relationship manager
RI PROGRAM MANAGEMENT PLAN
4
1.2.2.4 Program Team (PMT) – Community Enhancements / New Capacity Improvements
Accountabilities
• Promote and maintain method(s), tools and standards
• Manage policies and compliance
• Define and execute quality procedures and measures
• Produce and distribute reporting and communications
• Provide the program and project management processes infrastructure and
guidance to coordinate the various teams and to integrate the processes across the
program
• Maintain PMP
• Provide projects’ status reports and communications
Relationships
• Support project manager, Chief Engineer, and PM leads
• Respond to governance body information requests
• Meets weekly to report projects’ progress and identify corrective actions
• Develop, deploy, and operate project management protocols that are both effective
and efficient
• Perform the program management processes, such as management of issues, risks,
finances, communication, status reporting, and schedule
• Facilitate and coordinate cross-project process integration and issue resolution
• Guide the teams in creating the Work Plans
• Maintain baselines
• Create and publish program level status reports
• Manage the program issue, risk, and change control escalation processes
• Manage and report on quality assurance and quality control activities
• Perform quality reviews of deliverables from a scope and format (not content)
perspective
• Manage interactions between external governance bodies and the teams
RI PROGRAM MANAGEMENT PLAN
5
1.3 Escalation Process
Proper, timely escalation of risks, issues, decisions, and change requests is critical for keeping a program on
track. The escalation levels are described below.
The table below describes the overall escalation levels by process and threshold/criteria.
Level Escalation Process Thresholds / Criteria
Chief
Engineer
Escalation 1: PM leads escalate controls to the
Chief Engineer (e.g., issues team) by changing
the escalation level to 1.
Project controls will be escalated to the
program level/PM when:
•
The control impacts multiple teams, or
the resolution requires coordination
across teams.
•
Controls that are blocking and are not
resolved within 5 days will be
escalated to this level.
Program
Manager
Escalation 2: Chief Engineer escalates controls
to the PM by changing the escalation level to
2.
Controls will be escalated to the PM when:
•
The control cannot be resolved by the
Project Teams or Chief Engineer and
the control priority/criticality is not
“low.”
•
The control priority is critical.
•
Controls that are blocking and are not
resolved within 10 days will be
escalated to this level.
Executive
Management
Sponsor
Escalation 3: The PM and Chief Engineer will
jointly determine when items need to be
escalated to the executive sponsor.
To escalate a control to the executive sponsor,
the Chief Engineer and PM will:
1. Change the escalation level to 3.
2. Confirm that the control documentation is
complete.
3. Present the control, alternatives and
recommendations to the executive
sponsor.
Controls will be escalated to the executive
sponsor when:
•
The issue cannot be resolved at lower
levels and the priority is not low.
•
Controls that are blocking and are not
resolved within 30 days will be
escalated to this level.
RI PROGRAM MANAGEMENT PLAN
6
2 Scope Management Plan
Scope Management defines the process and procedures for confirming, verifying, and controlling scope. A
clearly defined scope promotes the stability required to the goals of a program. By adhering to this process,
the projects within the program will improve their control of project scope, leading towards program
completion on time and on budget. There are two aspects of program scope that must be controlled:
• Scope of the solution—This is the set of features and requirements that have been identified and will, in
conjunction with people changes, generate the business benefits that justify the program.
• Scope of work (SOW) —This is the set of activities and deliverables that the team will do to deliver the
solution within the projects.
2.1 Scope Management
Program scope of the solution is initially defined in the early phases of a program in the SOW and then further
detailed in the requirements and use cases (or equivalent documentation). The scope of work is defined in the
project Concept Reports. The following sections describe the overall concepts to Scope Management, as well
as the major scope activities that occur after project kick-off following the scope management lifecycle of
define, validate, and control scope throughout the project lifecycle.
2.1.1 Define Scope
Scope definition is completed during the inception phase of the program and is a joint activity performed by
the PMT New Capacity and Community Enhancement, PM and Chief Engineer. In the SOW, the group will
define the scope of the solution which can be described as the overall end state to be achieved by the project
effort. The scope of the solution differs from the scope of the work. The scope of the work describes the tasks
and deliverables needed to achieve the scope of the solution while the scope of the solution involves the
overall features and components that will produce the defined business benefits. The deliverable for this effort
is the series of Project Concept Reports that collectively define the scope of the solution.
2.1.1.1 Scope and Work Plan
The scope definition phase provides input to the Finalize and Baseline Work Plan activity. The outputs of the
Finalize and Baseline Work Plan activity—the baselined Work Plans—are key component of the scope, because
they document:
• Prioritization of all projects in the program
• The major activities and their timing that the team will perform
• Accountability (by teams and/or organizations) for performing those activities
• External dependencies and their timings, and the teams and/or organizations that is responsible for their
completion
Moreover, once the Work Plan is baselined, it is subject to scope control.
Refer to the Schedule Management Guideline that describes the Finalize and Baseline Work Plan activity.
2.1.2 Validate Scope
Once the scope is defined and baselined, the PM is responsible to validate scope throughout the program
lifecycle. To validate scope, they will confirm the work being performed remains in and fully addresses the
boundaries of the scope of the solution, via the SOW, as well as the scope of the work, via requirements,
design definition, and use cases. The PM will compare major solution definition deliverables with predecessor
deliverables (e.g., requirements to charter, use cases to requirements, design to use cases, etc.) to confirm
RI PROGRAM MANAGEMENT PLAN
7
that the original scope is addressed fully, and additional scope elements have not been added. The PM will
document that this scope confirmation activity has occurred in meeting minutes and ensure that any scope
issues are addressed by the team.
The PM will also validate the scope of the project work against the baselined Work Plan. This validation activity
confirms that:
• Resources are working on their assigned activities and tasks
• External teams are working towards meeting the deadlines established in the project Work Plan
Refer to the corresponding Project Handbook for the protocols for scope validation.
2.2 Methods and Standards Management
Standards are the protocols, including the processes, templates, and tools, for Program and Project
Management throughout the implementation lifecycle. The City-Parish’s existing adopted and approved
processes and procedures will define the methods and standards for procurement and invoicing for the
implementation of the MOVEBR program
2.2.1 Define Standards
Standards, or protocols, are defined as an integrated set of policy, process, template(s), tool(s), and training
materials. The corresponding responsible organization will document the standards described above. To define
the standards, the responsible organizations will apply existing Highmark methodologies, industry leading
standards, and project/ program requirements.
Documented standards must describe:
• Purpose—an explanation as to why the standard is necessary
• Objectives—a listing of the objectives that the standard should address
• Application—a listing of the artifacts and processes to which the standard applies
• Constraints and Assumptions—a listing of any organizational, technical, policy, and/or people factors
that either influence the standard (constraint) or are foundations for how the standard will be constructed
(assumptions)
• Processes—a description of the processes required to enforce the standard; typical processes include
artifact creation, artifact maintenance, quality review of artifacts and integration (to ensure that quality is
present from both the individual artifact and the holistic perspective)
• Standard Management—a description of the process to maintain the documented standard
Major standards developed for MOVEBR include: Design Guidelines, Right of Way Manual, Communications
Plan, and SBO Plan.
2.2.2 Approve Standards
After the standards are created, the responsible organization will review the standard internally to ensure it is
accurate and complete. Once a standard has been approved by the responsible organization, it will be
published to the management of organizations that participate in executing the standard and the PM for
review and comment. Participating organizations will review the standard for understanding and efficiency, the
PM will review the standard for compliance with this guideline and the standard for completeness and
compliance with overall organizational direction. Upon review and integration of review comments, the
standard will be considered approved and it will be implemented. After approval, the responsible organization
must archive the documents according to their document management process.
RI PROGRAM MANAGEMENT PLAN
8
2.2.3 Maintain Standards
After approval, the responsible organization will manage changes to the standard in accordance with their
documented standard management processes. For instance, the PM has created guidelines and a timeline for
the review, approve, and submittal process for making changes to the PM documents.
RI PROGRAM MANAGEMENT PLAN
9
3 Schedule and Resource
Management Plan
Consistent, high-quality schedule management processes allow PMs to understand the current situation,
forecast the future, accurately assess the impact of changes, prioritize team efforts, and effectively
communicate both internally and externally. PM team coordination requires a structured process to confirm
that the team develops, baselines, maintains, and reports status against the project Work Plan. A key to
building and maintaining a good Work Plan that will accurately model the project is to keep the Work Plan as
simple, yet realistic, as possible.
3.1 Key Schedule Management Concepts
• Dynamic scheduling. The PMT will build a dynamic, integrated Work Plan with a clearly identified critical
path. In conjunction with the PM Leads, the PM will link the tasks using predecessors and successors as
opposed to using date constraints. Whenever a task date changes, this approach will allow the scheduling
tool to automatically update the entire Work Plan, thereby displaying the impact of performance variances
upon the critical path.
• Rolling wave planning. The teams will use a Rolling Wave planning approach to Work Plan development.
The fundamental concept underlying Rolling Wave planning is to develop a high-level Work Plan for the
entire project lifecycle at the outset of the project and then refine and add more detail at the beginning of
each project phase. The Rolling Wave planning approach defers the time and effort to build detailed plans
before those detailed plans are useful. However, it is important to note that Rolling Wave planning is plan
refinement, not re-planning. Should a team member seek significant changes to the Work Plan during
schedule refinement that would add or delete scope, or adversely impact time or cost goals, they must
prepare and submit a Change Request.
• Milestones. The project Work Plan will include milestones to show completion of major activities,
contractual deliverable events, and phase ends. It will also include milestones to reflect key external
dependencies. An external dependency exists when a group or team outside the boundaries of the project
produces a deliverable or completes a task required to complete the project. An external dependency
represents a schedule risk to the project and must have an appropriate risk included in the risk register.
• Deliverables. The Work Plan should include every deliverable included in the SOW. In addition, for each
deliverable, the quality review cycle (refer to Quality Management) should be included in the project Work
Plan.
• Duration vs. Work. Duration is time-based, and Work is effort-based. Though related, they are not
necessarily equal, but must ultimately be considered together when scheduling. Task duration is the total
timeframe over which work on that task is conducted. Duration is typically expressed in days and work is
expressed in hours.
• Owner. The owner is equivalent to the project team level. Each summary task, detailed task, and
milestone will have a team name assigned to it. Tasks that cannot be assigned to a single team for
ownership either should be decomposed or the scheduler should document the supporting team and their
responsibilities.
3.1.1 Develop and Baseline
To develop the Work Plan in preparation of the baseline, the project team should:
• Conduct Preliminary Planning and Logistics
RI PROGRAM MANAGEMENT PLAN
10
• Define Scope (e.g. Activity Durations, and Owner)
• Establish Network Dependencies and Optimize
• Address Resources and Re-optimize
• Baseline and Publish Work Plan
For the Define Scope activity, the PM should incorporate the metrics, process reporting, and compliance into
the Work Plan. See the Schedule and Resource Management Guidelines for detailed procedures for these
activities. For the Baseline and Publish Work Plan, refer to Scope Management for the guidelines in obtaining
approval to baseline the Work Plan.
3.1.2 Track Progress and Maintain
To effectively monitor actual versus planned, the project Work Plans will be regularly updated and maintained
throughout the life of the project. The PM will update the project Work Plan bi-weekly. The update process
includes the following steps:
• Document progress
• Review progress updates
• Update the Work Plan and create reports
• Analyze the results and determine corrective actions
• Document corrective actions
• Update project schedule, if applicable
Refer to the Schedule Management Guideline for the specific procedures regarding these steps. The
corresponding Project Handbook will define the specific schedule for collecting the actuals for the project Work
Plan if it differs from the Schedule Management Guideline.
3.1.3 Refine and Revise
During the Rolling Wave planning activities, the PM and PM Leads will refine and revise the schedule. The PM
will initiate the process with a phase planning meeting, including the PM leads of the various work-streams.
During this meeting, the PM will describe the scope of the plan refinement activity and the process for refining
the schedule. The group will discuss the major activities for the team to refine and determine the approach.
The various leads of the work-streams will create a concise written summary of the major activities in the next
phase for which their team is responsible. The summaries will include the following for each major activity:
• The overall approach
• Quality Control activities
• Roles and responsibilities at a summary level
• Key needs from other teams
• Major risks
• A list of the internal challenges for the activity (i.e., those elements, components, or aspects that they
know will be challenging to complete)
Rolling Wave planning is plan refinement, not re-planning. Should changes to the Work Plan be identified
during Work Plan refinement, a Change Request is prepared and submitted to request the change. The PM will
only re-baseline with changes or refinements made to the Work Plan once the request is approved per the
Change Control Process.
RI PROGRAM MANAGEMENT PLAN
11
3.2 Program Work Plan Definition
The PMT will create and maintain a Program-level Integrated Master Plan (IMP) to identify inter-program
dependencies and milestones. Execution of the IMP will be aligned to existing resources. The Team will have
primary responsibility for creating and maintaining the IMP. To create the IMP, the Team will incorporate the
milestones of formally approved, baselined projects into the IMP.
The PM will follow the baseline approval process for the IMP described in the Project Level Process of Schedule
Management with the exception being that the Program Executive Sponsor will provide the baseline approval.
After approval, the PM and PM Leads will meet with the teams at least bimonthly to:
• Review/ update planned and actual start/finish dates and durations of the IMP milestones and review gate
• Incorporate updates from formally approved change control requests
• Detect cross-project, or inter-project, dependencies
• Identify risks and issues.
The Project Teams will provide the summary level planned/ actual start/ finish dates and Gantt chart in the
monthly program-level status report.
3.3 Project Work Plan Definition
3.3.1 Work Plan
Note: Regardless of the Work Plan strategy the project takes, the Work Plan(s) must align with the overall
Master Plan schedule for the project.
The project will develop a single end-to-end Work Plan during startup. This Work Plan will adhere to the
standard WBS format and contain phases, major activities (as documented in the Master Plan), contractual
deliverables, and major milestones for planned project phases. Each task will include work (effort), high-level
dependencies, and responsible team, but not resource assignments.
The end-to-end Work Plan will be refined to include additional detail for shorter duration activities prior to the
start of each phase. This refined Work Plan will be deliverable-based and will guide the day-to-day execution
of the project. The additional details will be created by augmenting the end-to-end Work Plan, such that
current phase tasks have more granularity than later phase tasks. As tasks are refined and additional detail
added, the estimates for each task will be confirmed and adjustments made to the schedule if preliminary
effort estimates are changed.
Work Plans will contain:
• Tasks (selected from the appropriate method as identified in the SOW)
• Milestones—zero effort/zero duration tasks that identify:
• Project Start and Project Finish
• Phase and Sprint completions
• Deliverable or event-based payments
• Other key events (e.g., Go-Lives, Kick-Offs)
• Duration (the span in days between the Start and Finish date of each task)
• Dependencies (a set of predecessors and successors that define the critical path of the project)
• Financial expenditures by major activity grouping
Each Work Plan will be reviewed by the PM and the PM leads and revised based upon feedback while
maintaining the overall signed-off schedule. Once the PMT has approved a Work Plan, it will be baselined,
archived, and placed under change control.
RI PROGRAM MANAGEMENT PLAN
12
3.4 Project Work Plan Management
Each week, the current task assignments will be published to the designated responsible individuals, progress
will be tracked in the Work Plan, schedule performance will be analyzed, and the Work Plan will be revised (if
necessary) to reflect current conditions. The table below highlights each of these steps, the responsible
individual for each, and the timing.
3.4.1 Monthly Work Plan Management Process
Manage Work Plan
Step
Description Responsible
Publish
Assignments
The tasks scheduled to be
performed during the next four
weeks are published to the
project team.
Project Manager
Track Progress
Planned responsible individuals
update progress of assigned
tasks. Updates will forecast
status as of the end of the work
week.
Planned Responsible
Individuals
PM Leads review and QA
progress tracking updates.
PM Leads
Analyze Progress
and Performance
The integrated progress tracking
is reviewed to determine the
impact upon the project
schedule.
PM Leads
Re-plan
Project leadership adjusts the
Work Plan (if necessary)
considering changing
circumstances.
PMT
To accomplish the above activities, the following will be performed:
• Publish Assignments—the phase Work Plan will be synchronized with SharePoint.
• Track Progress—each planned responsible individual will logon to SharePoint to update the status of
his/her assigned tasks:
• Update Percent Complete—indicate the percentage of work that is complete for the designated
task.
• Document Estimated Finish Date (if required)—this field should only be populated if the task being
updated is projected to be finished on a date that is after the currently planned finish date.
• Analyze Performance—the project manager will leverage existing dashboards and capabilities to review
the Work Plan after the track progress activity is complete. This analysis will consider:
• Critical Path
• Late/slipping Tasks
• Deliverable Completion Rate
• Earned vs. Planned work
• Re-plan—the project manager will review the latest Work Plan after incorporating progress tracking
updates (including adjusting planned durations of tasks that have a revised estimated finish date). This
review will evaluate currently planned vs. baseline dates for milestones to determine if actual progress is
impacting critical dates. If issues are identified, the project manager will revise the phase Work Plan (e.g.,
add lag, adjust assignments, augment resources, etc.) to bring the schedule back in line.
The PM also needs to adjust the Work Plan during re-planning to implement any approved change requests for the
project received that month.
RI PROGRAM MANAGEMENT PLAN
13
Upon completion of the re-plan activity, the PMT Project Leads will review any Work Plan changes with the
MOVEBR project manager. During this review, any concerns or issues about late / slipping tasks will be
discussed, and corresponding corrective actions will be identified. The revised Work Plan will be archived with
documentation of Program Management approval. The Master Plan will be adjusted, if required, to stay aligned
with the Work Plan.
RI PROGRAM MANAGEMENT PLAN
14
4 Deliverable Management Plan
A “deliverable” is any work product that is signed-off and put under change control as a unit. A “contractual
deliverable” is a deliverable that is explicitly defined in the Statement of Work (SOW) or consultant contracts
that PMT is managing. Deliverables will obtain sign-offs as described in the Design Guidelines Manual and
associated stage gate meetings that are mapped to various design milestones. In certain cases, one
contractual deliverable might contain multiple individual deliverables. This section describes the processes,
assets, and protocols to develop and manage deliverables through client acceptance.
Deliverable Management is a four-step process:
4.1 Define Deliverable Expectations
The team collaborates to complete the Deliverables Log at the beginning of each phase. The Deliverables Log
will include the deliverables—both contractual deliverables as well as other work products that require sign-
off. Deliverable Logs will be located at PMT SharePoint site.
The Deliverables Log documents deliverable expectations, including:
• Deliverable templates—available deliverable templates created for the specific project by tailoring the
standard method templates to meet project-specific needs, such as the project logo.
• Named DTD resources and/or Goverence Committees (MPC, MTC, MCC) responsible for participating in
deliverable reviews.
• Every deliverable requires at least one deliverable review.
• See the Quality Control section of the Quality Management Plan for more information on the types of
deliverable reviews planned for the program.
4.2 Sign-off Deliverable
The DTD resource(s) and/or Goverence Committees identified in the Deliverables Log will review the
completed deliverable and the documentation supporting the review activities. During the sign-off process, the
reviewer may provide additional feedback which will be documented and addressed. The reviewer will sign-off
or provide feedback on the deliverable within the time documented in the table in section 5.6.
Once a deliverable is signed off, the PMT will archive the approved deliverable (along with the completed
Deliverable Sign-off Form in the appropriate repository, and any additional changes to the deliverable will
need an approved change request.
4.3 Deliverable Process Timing
The following sample table describes the timing commitments for the review, sign-off, and accept steps in the
Deliverable Management process. The time periods in this table begin upon receipt of the deliverable for the
designated step. The PMT will construct the Work Plan dependencies such that successor deliverables can be
started once the predecessor deliverable has begun the review process. Changes to the predecessor
deliverable that occur because of the review and sign-off processes will be incorporated into the development
of successor deliverables upon client sign-off.
Deliverable
Deliverable
Review
DTD Sign-off
or Feedback
PMT
Addresses
Feedback
DTD
Acceptance or
Feedback
PMT Addresses
Feedback
All 5 days
5 days 3 days 5 days 2 days
<Add rows and
deliverables as
needed…>
RI PROGRAM MANAGEMENT PLAN
15
4.4 Deliverable Reviews
Deliverable reviews aim to detect defects. Before a deliverable goes through the deliverable sign-off process,
deliverable reviews are performed by the team to:
• Verify the completeness of a deliverable
• Verify the accuracy of a deliverable
• Verify that a deliverable meets program standards (for example, using the right template), as well as any
deliverable-specific or custom requirements
• Verify that the content of a deliverable meets its objectives and is consistent with prior approved
deliverables
The program will plan the type of review for each deliverable in the Deliverables Log. Each deliverable review
cycle will follow one of the following approaches:
Formal Review: Formal reviews represent the most structured review type and are used as development
step for critical designs or deliverables with cross-team impact. They often follow a walkthrough or offline
review for the same deliverable. The most common formal review is the Plan In Hand, or 60% review for
design and the Final Inspection for a project during construction.
The formal review takes place as a scheduled, facilitated meeting between two or more reviewers, after
previously providing the deliverable and review criteria in advance of the meeting to all review participants.
Formal reviews are not meant to be conducted as walkthroughs. Reviewers must come prepared to share their
findings from their individual preparation review with the other reviewers.
Walkthrough Review: Walkthrough reviews are an effective deliverable review type for medium-risk
deliverables or deliverables that may be hard to understand (for example, complex business process flow
documentation).
The format of this walkthrough review is a face-to-face meeting where the authors of the deliverable walk a
reviewer group through the deliverable. The reviewer group should include at least two individuals, with at
least one subject matter expert.
Offline Review: Offline reviews are performed by someone other than the deliverable author in a distributed
or asynchronous manner (that is, not a face-to-face meeting or live teleconference).
Deliverable Review Defect Classifications
The defects identified in the deliverable review are classified by the following severity levels:
• Critical: Defect that would result in the inability to construct a project, an unsafe condition for the
motoring public or an observable departure from specification (or any other input document). No known
work around is available.
• Major: Defect that would result in the inability to construct a project, an unsafe condition for the motoring
public or an observable departure from specification (or any other input document). Work around possible,
but with significant additional effort to ensure expected product behavior.
• Minor: Defects that deviate from specifications but will not cause immediate safety concerns, would
not render the project not constructible, or an observable departure in performance. Minor defects
could have a cosmetic impact in terms of navigation or usability.
• Low: Low or no impact on the quality or safety of the project.
RI PROGRAM MANAGEMENT PLAN
16
5 Change Control Management
Plan
This section describes the applicable program controls (template includes risks, issues, action items, decisions,
and change requests). The PM and Chief Engineer should determine which program controls will be used, but
all projects will utilize risks, issues, and change requests, and will therefore need to include the corresponding
sections below.
5.1 Risk Management
This section documents the process, templates, and tools that projects will use to identify, evaluate, and
manage risks throughout the life of the project. A risk is an event that has not occurred that will, if it does
occur, impact the schedule, scope, budget, or quality.
5.1.1 Process Summary
The flowchart below summarizes the risk management process:
RI PROGRAM MANAGEMENT PLAN
17
5.1.1.1 Identify and Analyze Risk
At the beginning of the project and then monthly (or weekly) during the risk review meeting (see Risk
Meetings below), project leadership (i.e., project managers and PM leads) will identify risks that can
negatively impact project outcomes.
• Risks are identified during risk meetings organized by the project manager (see Risk Meetings section
below).
• Initial project risks that were identified as part of upfront project planning and documented in the SOW
are reviewed during the initial risk review meeting.
• As risks are identified, the following information will be captured:
• Project
• Assigned To (“risk owner”)—the team member responsible to develop and implement the risk
response plan
• Status—the status of the risk as it flows through the process
• Threat or Opportunity
• Note risk impacts project costs
• Note if risk impacts project schedule
• Priority—a subjective assignment of the significance of the risk used by the project manager for
prioritization and status reporting. The priority risk ratings for the project are as follows:
-
- High— the risk response plan must be defined and executed as soon as possible. High
Level risks are to be communicated at PMT Leadership Meetings.
- Medium— the risk response plan can be developed any time before the next risk review
meeting
- Low— a risk response plan is not required
• Type—a means for categorizing risks (see subsequent section)
• Description—a brief description of the risk
5.1.1.2 Develop Risk Response
For “High” severity risks, the assigned team member(s) (i.e., risk owner(s)) will analyze the risk in more
detail, determine the appropriate risk response strategy and develop the risk response plan:
• Risk response—Proposed risk response strategy
• Accept— accept the risk, but monitor it
• Avoid— devise a strategy to avoid the risk
• Mitigate— determine actions to eliminate or reduce the risk
o
Transfer— transfer the risk responsibility to another group
• Response plan—Details for the risk response strategy selected
o
Contingency Plan—Identify actions to take as a backup plan if the initial risk response plan does
not work
Once the risk owner completes his/her risk assessment and proposed risk response strategy and response
plan, the risk meeting team needs to review and approve the plan, which may not occur until the next risk
review meeting, unless the risk’s priority is “High,” in which case a special risk meeting may be organized to
review and finalize the risk strategy, response plan, and contingency (i.e., “backup”) plan for the risk.
For risks using the Basic workflow process in PMC or the corresponding Risks Log available in the PM
discipline, risks will have “Active” status during this process. Where needed, the risk will be escalated to the
RI PROGRAM MANAGEMENT PLAN
18
appropriate project level for review and analysis, per the levels defined in section 2.2 of this PMP. High Level
risks are to be communicated at PMT Leadership Meetings.
5.1.1.3 Monitor Risk
The project manager monitors the risk throughout the life of the project through SharePoint, for as long as the
risk remains in “Active” and “Treated” status.
• Determine the appropriate new risk owner(s) if the risk assignment needs to change
• Where necessary, update the risk assessment, response, or other details
•
Determine if or when a risk needs to be escalated to the next project level
5.1.1.4 Determine if Risk is realized
As part of risk monitoring, the project manager determines whether the risk has been realized on the project.
• For realized risks, follow the risk realization steps included in the approved risk response plan (where
applicable), and log a new issue in the project’s Issues Log for the realized risk.
• Once the issue record is created, cross-reference the new Issue # in the old risk record before closing the
risk record.
• If the risk has not been realized, continue monitoring it throughout the project, for as long as the risk is
active or “In Progress.”
5.1.1.5 Manage Issues
For a realized risk that converts to a project issue, address it using the project’s standard issue management
process through SharePoint
5.1.1.6 Determine if Risk is still active
Determine the status of the risk:
• If the risk is no longer active, proceed to closing the risk
• If the risk is still active, continue monitoring the risk, escalating when necessary
5.1.2 Risk Types
While all types of risks are to be tracked, the following additional risk type identifiers will be noted in
SharePoint.
Risk Type Risk Type Description
Financial Any risk related to the budget or cost structure of the project (such as increase or decrease in
the project-related budget).
Schedule
Any risk related to the Work Plan and related tasks (such as extensions or reductions of the
project timeline).
5.1.3 Risk Monitoring
Active risks will be tracked and published in SharePoint project logs . Risks that are tagged for monitoring
from the various governance committees (e.g. MPC, MTC, or MCC) will be available for review through
SharePoint filters. A risk that is realized will either: (1) Initiate the approved response plan defined for the
risk; or (2) Be logged as a new issue to be addressed by the project’s defined issue management process.
The following risk measurements are provided in the Risk Log and are used to monitor and control project
risks:
RI PROGRAM MANAGEMENT PLAN
19
• Risks by status
• Risks by priority and status
• Active risks by priority
• Active risk aging by priority
5.1.4 Risk Meetings
The PMT meeting framework is designed to discuss Risks, Issues, and Actions by committees (e.g. MPC, MTC,
MCC, SLT) based on type and level of priority. High level Issues, Risks, and Actions will be escalated to Senior
Leadership meetings for discussion. SharePoint will manage the appropriate meeting forum. Project
leadership will meet monthly to review and add/update risks. This meeting will be scheduled by the PMT.
After each risk review meeting, the PMT has the following responsibilities:
• Update Risk Log to record risk changes and additions
• Archive any approved risk response plans
• Communicate the updated risk records
5.2 Issue Management
This section documents the process, templates, and tools that projects will use to identify, evaluate, and
manage issues throughout the life of the project. An issue is an event that has occurred that will impact the
schedule, scope, budget, or quality.
5.2.1 Process Summary
The flowchart below summarizes the issue management process:
1. Create Issue 2. Resolve Issue
Legend
Step
Supporting
Output
Decision
Task Procedure
Inputs /
Outputs
Project
Management
Plan
3. Change
Request?
5. Close Issue
4. Manage
Change
Requests
Yes
No
Issues Log
RI PROGRAM MANAGEMENT PLAN
20
5.2.1.1 Create Issue
Project team members identify issues impacting the project and document them in the project’s issue logging
tool.
• Any team member can identify a project issue at any point in the project lifecycle.
• The person identifying and logging the issue needs to provide as much information as possible on the new
issue. Required fields include:
• Project
• Assigned To
• Priority
• Type
• Description
• Detailed Description
• The issue status tracks the status of an issue as it flows through the process
• The project manager (or PM leads) will review and validate “New” issue status records from the team,
canceling issue entries that are not valid.
• The project manager (or PM leads) will then confirm or re-assign valid issues to the appropriate team
member(s) (issue owners) for detailed analysis and resolution planning.
The assigned team member(s) will confirm or define the following fields for an issue record after completing
the necessary due diligence and analysis on the issue:
• Priority—the priority issue ratings for the project are as follows:
• High— the issue is negatively impacting the project significantly (for example, cost overruns or
milestone delays) and must be addressed as soon as possible
• Medium— the issue is negatively impacting the project and should be addressed, monitored, and
controlled using regular project issue management processes
• Low— the issue has minimal impact and should be addressed as cost and schedule permits
• Type—Issue types are defined in a table in a later section
• Project areas and stakeholders impacted: Release, Team, Phase, Thread, Stakeholder(s)
• Resolution, including:
• Escalation Level
• Resolution
• Other closure criteria
• Where appropriate (e.g., for “Critical” or “High” priority issues), the project manager should
review and approve the proposed issue resolution.
5.2.1.2 Resolve Issue
The issue owner works to manage the issue to a successful close.
• Implement the resolution actions to close the issue.
• Document the resolution results.
• If the issue cannot be resolved, escalate the issue.
RI PROGRAM MANAGEMENT PLAN
21
5.2.1.3 Close Issue
Confirm that the resolution steps completed resolved the issue successfully.
• The appropriate stakeholder(s) identified for the issue should help confirm the issue resolution.
• Issues where the resolution results were not confirmed will remain in “In Progress” status until they can
be successfully confirmed.
5.2.2 Issue Types
The following issue types will be discussed when logging issues.
Issue Type
Issue Type Description
Contract
Any issue related to the contracts of the project (such as a signed agreement
between MOVEBR and subcontractors).
External
Any issue related to environmental factors largely outside the control of the project
(such as cultural, legal, or regulatory).
Financial
Any issue related to the budget or cost structure of the project (such as increase or
decrease in the project-related budget).
Functional
Any issue related to the overall function of the product (such as requirements or
design) being developed by the project.
Quality
Any issue related to the quality requirements of the project.
Organization
Any issue related to internal
,
MOVEBR
, or third
-
party organizational or business
changes (such as executive leadership role changes).
Project
Management
Any issue related to the management of the project (such as communications,
status reporting, and issues management).
Resource
Any issue related to project resources (such as the addition or removal of
resources).
Schedule
Any issue
related to the Work Plan and related tasks (such as extensions or
reductions of the project timeline).
Scope
Any issue related to project scope (such as process, module, and development
objects).
Technical
Any issue related to software or hardware,
including infrastructure related to the
project.
General
Any issue that cannot be categorized into one of the above categories.
5.2.3 Issue Monitoring
Unresolved issues will be reported either during bi-weekly DTD Progress Meetings or MPC, MTC, or MCC
meetings. ; Unresolved High priority issues will be discussed in Senior Leadership meetings. Changes to
Schedule and Cost performance will be noted in monthly Senior Leadership reports.
The following issue measurements are provided and are used to monitor and control project issues:
• Issues by status
• Issues by priority and status
• Active issues by priority
• Active issue aging by priority
RI PROGRAM MANAGEMENT PLAN
22
5.2.4 Issue Meetings
Issue identification and resolution is an ongoing process. Identifying and resolving issues in a timely manner is
a critical success factor for the project, and both DTD and PMT staff need to commit to supporting timely issue
resolution. The PMT meeting framework is designed to discuss Risks, Issues, and Actions by committees (e.g.
MPC, MTC, MCC, SLT) based on type and level of priority. High level Issues, Risks, and Actions will be
escalated to Senior Leadership meetings for discussion.
5.3 Action Items
This section documents the process and tools the project will use to log action items and manage them to
closure throughout the life of the project. An action item is an assignment to do some work or address a
question. These action items will typically be action items that are originated from decisions made in the PMT’s
various meetings.
5.3.1 Process Summary
The flowchart below summarizes the action item management process:
1. Create Action
Item
2. Perform Action
Item
4. Close Action
Item
Legend
Step
Supporting
Output
Decision
Task Procedure
Inputs /
Outputs
Project
Management
Plan
Yes
3. Action Item
Ready to Close?
Action Items Log
No
5.3.2 Action Item Priorities
The following are the recommended action item priorities and descriptions:
• High - the action item must be addressed as soon as possible to prevent significant negative impacts to
the project (for example, cost overruns or milestone delays)
• Medium - the action item will be addressed, monitored, and controlled following regular project action
item management processes
• Low - the action item will be addressed as cost and schedule permits
5.3.3 Action Item Meetings
The PMT meeting framework is designed to discuss Risks, Issues, and Actions by committees (e.g. MPC, MTC,
MCC, SLT) based on type and level of priority. High level Issues, Risks, and Actions will be escalated to Senior
Leadership meetings for discussion.
RI PROGRAM MANAGEMENT PLAN
23
5.4 Decisions
Managing decisions includes identifying, documenting, prioritizing, assigning, and tracking the results of
decisions throughout the lifecycle of the project. This section documents the process and tools the project will
use to log and manage decisions. Decisions to be tracked are those that project management deems
necessary to document and track for future reference.
5.4.1 Process Summary
The flowchart below summarizes the decision management process:
5.4.2 Decision Priorities
The following are the recommended decision priorities and descriptions:
• High - the decision must be addressed as soon as possible to prevent significant negative impacts to the
project (for example, cost overruns or milestone delays)
• Medium - the decision will be addressed, monitored, and controlled following regular decisions
management processes
• Low - the decision will be addressed as cost and schedule permits
5.4.3 Decision Process
Although most decisions do not require a formal decision process using a detailed qualitative and quantitative
analysis of alternatives, important decisions will be logged in a Decisions Log and managed to closure, similar
to risks, issues, and action items.
The objectives of the decision-making process include:
RI PROGRAM MANAGEMENT PLAN
24
• Documenting and communicating key decisions needed
• Confirming that decisions are made in a timely manner
• Preventing decisions made from being revisited
Decisions are to be documented at the SharePoint site.
5.4.4 Formal Decision-making Process
Decisions that meet the formal decision criteria defined in the following section are decisions that may impact
project outcomes regarding the solution schedule, cost, or quality. It is critical that formal decisions be made
once, by the right level of authority, and in a timely manner.
The formal decision-making process allows the team to analyze possible critical decisions using a formal
evaluation process that evaluates identified alternatives against established criteria. The formal decision
process results in a recommended solution and rationale that are provided to key stakeholders for review and
approval before it is considered final.
The objectives of the formal decision-making process include:
• Making decisions using qualitative and quantitative feedback based on established solution criteria at the
appropriate level of authority
• Driving timely decision-making
• Documenting and communicating formal decisions made
• Preventing formal decisions from being revisited
The table below lists the types of decisions where the formal decision-making process should be used and
includes the approval authorities for each decision type. In addition to decisions of these types, the project
should consider using the formal decision process in scenarios where the outcome may significantly impact the
ability of the project to meet its commitments or established objectives.
RI PROGRAM MANAGEMENT PLAN
25
5.5 Change Control
This section documents the change control process, tasks, and tools the project will use to identify, analyze,
prioritize and implement change requests that can impact the project scope, budget, quality, or schedule.
5.5.1 Process Summary
The flowchart below summarizes the change control process:
1. Identify and
Document
Change Request
2. Perform Impact
Analysis
4. Cancel or
Reject Change
Request
Legend
Step
Supporting
Output
Decision
Task Procedure
Inputs /
Outputs
Project
Management
Plan
No,
Cancel
Or
Reject
3. CCB Review
and Approval?
Change Requests
Log
No, Rework
Yes
5.5.1.1 Identify and Document Programmatic Change Request
This previous chapters described Risks, Issues, Decisions, and Actions that will are most appropriate for
project level application. Programmatic standards have been approved by senior leadership that include
processes for project specific variances to those programmatic guidelines. This section addresses proposed
programmatic changes that impact programmatic budgets, objectives, and application of program. These
changes will typically not be project specific, but instead, impact the program and possibly multiple projects.
Change requests can be identified throughout the life of the program. Changes that affect the scope, budget,
schedule, and/or effort or requested changes to signed-off deliverables of the project are formally
documented, prioritized, analyzed, reviewed, and approved before implementation.
Identification is the first step of the change control process, and project stakeholders are encouraged to
identify and log change requests (CRs). Any project stakeholder can create a “New” change request.
Minor revisions to the management plans (project and quality management) that address usability or
personnel changes (e.g., a new team lead) will not require a change request. For these minor revisions the
change will be documented in version notes through the Issues/Decision log in SharePoint. Both the MOVEBR
management team and PMT project managers will review and approve minor revisions made in this manner.
Any disagreement about the need for or nature of a minor revision will be addressed using the change control
process.
The priority level assigned to a CR reflects the criticality and urgency of the CR:
• High— the change request is addressing a problem that can negatively impact the program significantly
(for example, cost overruns or milestone delays) and will be addressed as soon as possible
RI PROGRAM MANAGEMENT PLAN
26
• Medium— the change request is addressing a problem that can negatively impact the program or parts of
the program. The change request should be addressed, monitored, and controlled using regular program
change control processes
• Low— the change request is addressing a problem with minimal negative impact and will be completed as
cost and schedule permits
The PMT leads or applicable committees (e.g. MPC, MTC, MCC, ROW) will validate each “New” change request,
and prioritize and assign each valid CR to the appropriate team member for impact analysis on scope, budget,
quality and schedule, information that will be presented to the Project Sponsor for their review and approval
for implementation. Each valid CR will have a status of “In Analysis.” If project leadership collaboratively
determines that a change request at this stage should be “Cancelled,” the status of the CR record will be
updated accordingly, and the CR will not be assigned for impact analysis.
The Change Requests Log that will be used by MOVEBR to document change requests.
5.5.1.2 Perform Impact Analysis
All change requests need to be analyzed for impact to project scope, budget, quality and schedule, as well as
for clarity, accuracy, and relevance. All impacts of the change request are documented in the Change Request
Log. Feasible options to address the change request should be summarized in the Detailed Description and
Justification fields of the CR record. This can also include a description of the impact when the change request
is not implemented.
The impact analysis should be reviewed and incorporate the input of each of the primary teams on the project
(e.g., the technical team lead determines the technical impact; the organizational change management (OCM)
team lead determines the change impact, etc.).
When determining impact, both the estimated effort and the overall schedule impact will be evaluated. If a
change request will impact the critical path of the project, then the cost of that change request will include
both the incremental effort plus the cost impact of maintaining other essential resources through the extended
duration. The PMT Leads are responsible for determining the cost of any change requests, based upon the
impact determined by the various team members.
Each impact analysis includes:
• The project work products affected by the proposed change
• The impact of the proposed change on project size, deliverables, and requirements
• The impact of the proposed change on existing assumptions and constraints
• The impact of the proposed change on schedule, including milestones and dependencies
• The impact of the proposed change in terms of effort and cost
The result of this impact analysis is a recommendation on disposition of the change request. Because changes
made earlier in the program lifecycle typically have less impact than changes that occur later, each change
request impact analysis will be assigned an expiration date (i.e., the “Due Date” field in the Change Request
Log). This is the date by which the CR must be approved. If a CR is not approved by this date, it will either be
“Cancelled,” or a new impact analysis will be required.
5.5.1.3 Approve Change Requests
The information collected for a change request (CR) is reviewed for approval for implementation. The
information should be captured in the respective CR record in the Change Requests Log.
Prior to bringing a completed CR to the program sponsor, the project managers should jointly review the
completed documentation. Any questions or issues regarding the CR should be addressed, so that the
documentation is complete, clear, and accurate. Once the CR documentation is complete, MOVEBR will
schedule the CR for the next change control meeting.
The PM team will review “Pending Approval” CRs with complete analysis and justification, and determine the
appropriate change control decision:
• Approve the CR, changing its status to “Pending Implementation”
RI PROGRAM MANAGEMENT PLAN
27
• Defer the CR, marking its status as “Deferred”
• Reject the CR, marking its status as “Rejected”
• Request more analysis, changing status of the CR back to “In Analysis”
5.5.1.4 Close Change Requests
Once the approved CR implementation updates have been reviewed and approved by the PM, the status of the
CR can be set to “Closed.”
Communicate the results of implemented (i.e., “Closed”) or “Rejected” change requests to the team and
stakeholders. Update the project’s Change Request Log accordingly. Refer to the project’s Status and
Stakeholder Communications section for appropriate distribution of information.
RI PROGRAM MANAGEMENT PLAN
28
6 Document Management Plan
Document Management describes the tools and processes to manage and store documents created throughout
the program and project lifecycles. The term "document" refers to an item created by a team member using a
desktop application (Microsoft Word, Excel, PowerPoint, Visio, Adobe, etc.). It does not refer to software used.
6.1 Document Management Overview
6.1.1 Purpose
The purpose of document management is to establish and maintain control over a program’s documents. The
tools necessary to complete administration and execution of the program will be further detailed by the PMT in
conjunction with City-Parish staff as project and deliverable schedules are finalized.
6.1.2 Document Management Roles and Responsibilities
The table below lists the roles and responsibilities involved in the program’s document management activities.
Role Responsibility
Project Document Manager
• Establishes and maintains the program document management plans
• Establishes and manages the program document management system
• Coordinates program document management activities
• Manages, maintains, and controls program documents
Project Team
• Train team members and adhere on the approved document management
process
• Archive documents using the designated Document Management System
6.2 Document Management System
6.2.1 Document Management Tool
SharePoint and eBuilder have been identified by the team as the appropriate system and tool for managing
documents. The roles of each tool will be more defined as the program transitions from program standup
phase to implementation. This tool will be administered by DTD and accessible by all team members. The
document repository will retain version history of all documents automatically for archival purposes.
6.2.2 Directory Structure and Permission Levels
The MOVEBR document repository will contain the following folders initially. Additional folders and sub-folders
will be created as appropriate to support document management needs of the team.
Additionally, as a replacement to document structure, the PMT may organize through a metadata structure,
organized by terms and definitions.
• Project Information—Used to store general program data
• Final—Used to store final versions of work products and signed-off deliverables under change control.
• Document Storage Library—Used to store work-in-progress documents
• Project Teams—Used to store specific team information and/or working documents
• Project Calendar—Standard program calendar to post relevant program events by date
• Team Announcements—Used to post news, status, and other relevant program information
• Team Contact List—Common program contact list with information about team members
• Useful Links—Offers a list of links to other relevant, helpful sites and resources
• Discussion Board—Provides a forum for team members to discuss important topics together and share
knowledge
RI PROGRAM MANAGEMENT PLAN
29
Permission levels will be assigned based on overall program management role with City-Parish staff as content
owners and PMT as content creators and contributors.
6.2.3 Document Naming Conventions
The following table describes the document naming conventions to be followed for MOVEBR. Software naming
conventions are not included here.
Controlled Documents
# Description Naming Convention
1
<Insert description of
program document>
<Work
Product Name>.<File Extension>
6.2.4 Document Management Process
6.2.4.1 Pre-Sign-off (deliverables) or finalization (work products)
Documents that are in development will be managed by individual team members under the guidance of their
PM leads. These documents will be stored in the appropriate section of the Document Storage Library folder.
All team members will have access to the documents in the Document Storage Library folder.
6.2.4.2 Post-Sign-off
As documents are finalized they will be reviewed and, if the document is a deliverable or part of a deliverable,
signed-off (see Section 4). The final version of documents will be archived in the Final folder by PM staff. The
PM will manage the deliverable sign-off process and will archive documents that are part of a deliverable. It is
the responsibility of the PM Leads to communicate the document name and version of work products (no
formal sign-off) that are final to the PM so that those documents can also be archived.
Once a document is archived in the Final folder, it will not be updated without an approved change request
(see Section 5.5). The PM will notify PM Leads when change requests requiring document updates are
approved so that the approved change can be implemented.
6.2.5 Document Management Tool Administration
6.2.5.1 Team Member Access
TBD
6.2.5.2 Backup and Recovery
TBD
6.2.5.3 End of Project Archival
TBD
6.2.5.4 MOVEBR Policies and Procedures
TBD
RI PROGRAM MANAGEMENT PLAN
30
6.2.5.4.1 Building Access Policies
6.2.5.4.2 Project Security Policies
6.2.5.4.3 Remote Working Policies
6.2.5.4.4 Health & Safety Procedures
6.2.5.5 Team Policies and Procedures
TBD
6.2.5.5.1 Project Vacation Request Process
6.2.5.5.2 Project Time Reporting Process
6.2.5.5.3 Project Travel and Expense Guidelines
RI PROGRAM MANAGEMENT PLAN
31
7 Tools Strategy Plan
7.1 Purpose
The Tools Strategy defines what tools will be used to facilitate and support the program and projects, as well
as what tools the client will use to maintain and support the solution on an ongoing basis after it is deployed.
The Tools Strategy defines when and how the tools selected for a program will be used, tool ownership, plans
for the acquisition and installation of the program tools needed, as well program tool training and ongoing
support. Details on how the tools will be installed and configured are addressed in the Install and Configure
tools task.
Developing a Tools Strategy considers the program implementation method, the client’s existing tool suite and
long-term vision for program tools supporting the solution, and the overall integration requirements for the
tools that will be used.
The table below summarizes the tools that will be used to support the successful planning, execution, monitor
and control, and delivery of the program.
#
Project Name Project Area Selected Tool(s)
1 Requirements Capture and Traceability
2
Work Planning
Primavera P6
3
Project Management Information System for
Project Controls (e.g., risks, issues, action items,
decisions, change requests, deliverable reviews)
SharePoint, eBuilder
Microsoft Excel, Microsoft
Word
4
Business Process Mgmt
TBD
5
Document Management
SharePoint and
eBuilder
6
Financial Cashflow
eBuilder
, Primavera P6,
7
Schedules
Primavera P6
8
RFQ Advertisements
RFQ Manager
RI PROGRAM MANAGEMENT PLAN
32
8 Status and Stakeholder
Communications Plan
* The information below may be modified or replaced with input from the PMT communication experts.
The Status and Stakeholder Communications Plan addresses three areas:
1.
Communications Plan, including types of communications, audiences, frequency, and party(ies)
responsible
2.
Meeting and Communications Schedule, including planned status meetings and other important
program events (e.g., kickoff meetings)
3.
Stakeholder Engagement
Sharing the status communication plans is critical to managing expectations across the program and client
organization regarding what information individuals should expect to receive, and when they should expect to
receive it.
RI PROGRAM MANAGEMENT PLAN
33
8.1 Status Communications
8.1.1 Communications Plan
The table below defines the plan for status reporting, addressing the needs of identified stakeholders.
Communication Description Audience Frequency
Chairperson/
Responsibility of
Program Project
Status Update
The PM consolidates the project
level-reports into a program
level report and delivers it to
PM:
• Execution status
• Key deliverable status
• Program level issues
• Project
Sponsors
• PM
•
Monthly Program Manager
Program Leader
The PM consolidates the project
level-reports into a program
level report and delivers it to
PM:
• Execution status
• Key deliverable status
Program level issues
• Project
Sponsors
• PM
•
Monthly Program Manager
Project Status
Meeting
Regularly scheduled meeting to
update the project sponsor and
key leaders on project progress
and status. Information
presented:
• Schedule and budget
performance
• Milestone progress
• Deliverable status
• Risks, issues, action items,
or decisions that need
attention
• Change request updates
• Sponsor
• Client
business
leads
• Client
project
manager
Bi-Weekly,
through
project closure
PMT project
manager
Project Status
Distributions
Distribute standard status
report after the weekly status
meeting, and/or post in the
appropriate project
community site
• PM leads
Weekly
Project office
support in PM
team
8.1.2 Meeting and Communications Schedule
Guidelines for completing the meeting and communications schedule in the calendar below:
• A day of the week can occur five times in a month. Use the row marked ‘Week 5’ when those scenarios
apply.
• Record only meetings that will occur on an ongoing basis for the duration of phase, release, or entire
project. Include standing governance body meetings defined in Section 2.
• Indicate frequency by repeating a meeting entry against the corresponding day in every week. If possible,
include the timing of the meeting.
The table below depicts the monthly schedule for key meetings and communications:
RI PROGRAM MANAGEMENT PLAN
34
MOVEBR
Program Quick Start Meeting Summary & Cadence |
March 2020
Workgroup
Current Purpose / Agenda –
Updated as Program Progresses
Cadence PPR EBR / DTD
Co-
Facilitator
When/
Where
Comments
Senior
Leadership
Team
- Review progress, set agendas, establish
program cadence, and meetings plans.
- Review progress reports from Workgroups
- Review / Approve Workgroup Deliverables &
Key Decisions
Weekly Kelvin Hill
Kelvin Hill
Fred Raiford
Tom Stephens
Ingolf Partenheimer
Mike Songy
Mike Bruce
Wednesdays
8-10 AM
Room 808 City
Hall (Kelvin’s
Office)
Finance
- Review status of revenue projections to
understand financial and bonding delivery
constraints
- Draft initial program funding stream & budget
- Develop P6 cashflow model
As Needed Kelvin Hill
Kelvin Hill
Fred Raiford
Finance Office
G. King
Mike Songy
Mike Bruce
Cashflow and revenue projections
are discussed during Senior
Leadership Meeting Quarterly
SBO
- Develop approach to outreach and schedule
initial SBO contractor meeting
Bi-Weekly
Raymond
Jetson
Kelvin Hill
Mayors Office
Fred Raiford
Kahli Cohran
Workgroup
Kickoff
July 31
ROW
- Establish standard ROW acquisition
procedures
Bi-Weekly
Travis
Woodard
Parish Attorney’s Office
Fred Raiford
Tom Stephens
Bryan
Harmon
Thursdays
1:30 PM
Tom’s Office
Management
Systems & PMIS
- Establish MOVEBR Management Systems and
PMIS
Monthly
Gavin
Gilchrist
Fred Raiford
Tom Stephens
Shaun
Sherrow
Public
Involvement
- Develop PI plan
Bi-Weekly
Perry
Franklin
Fred Raiford
Tom Stephens
Mark Armstrong
Rannah Gray Monday PM
Communications
- Establish and implement MovER
Communications Plan
Bi-Weekly
Rannay
Gray
Fred Raiford
Tom Stephens
Mark Armstrong
Perry
Franklin
Monday PM
Complete
Streets, Green
Infra., ADA &
Mobility
- Establish guidelines and standards
As Needed
April
Renard
Fred Raiford
Tom Stephens
Ingoff Partenheimer
Joe Cains
Ready to Go
Projects
- Review status of active projects that require
decisions
Bi-Weekly
Kate
Prejean
Fred Raiford
Tom Stephens
Ingoff Partenheimer
Jason Crain
Friday
8 AM
Tom’s Office
Utilities
- Establish standard utility coordination
approach
Schedule utility kickoff meeting
As Needed
Josh
Renard
Fred Raiford
Tom Stephens
Marshall
Pounds
Traffic
- Establish approach to traffic modeling as
needed to support prioritization and delivery
planning
As Needed Brin Ferlito
Fred Raiford
Tom Stephens
Ingoff Partenheimer
Joey Lefante
LADOTD
Interface
- Coordination
As Needed
John
Basilica
Fred Raiford
Tom Stephens
Ingoff Partenheimer
Gary
Heitman
Fed/State
Funding
- Identify and pursue
As Needed
Michael
Songy
Fred Raiford
Tom Stephens
Ingoff Partenheimer
Mike Dement
Mike Bruce
RI PROGRAM MANAGEMENT PLAN
35
8.2 Stakeholder Engagement
Formal planning and management of stakeholder involvement is vital to meeting program goals and
objectives, particularly when external resources can influence the direction or outcome of program results. For
this reason, the program will define the activities and levels of participation required by important
stakeholders and establish a mechanism for monitoring their participation and engagement effectiveness.
8.2.1 Stakeholder Involvement Plan
The Stakeholder Involvement plan is created and used to proactively plan stakeholder involvement on the
program and make certain that the right stakeholders are present when their participation is needed to
support specific activities in the individual project Work Plan.
At the beginning of each phase, the team will identify the resources not on the team who are required to
support the project and document those resources in the table in the Appendix. The Project Managers will
review the plan and confirm it is correct. The Project Sponsor will confirm that the required resources are
available to participate per the approved plan.
Each stakeholder identified will receive an e-mail at the beginning of the phase notifying them of their
required participation and asking them to confirm their commitment. Stakeholder responses to this e-mail will
be monitored by the appropriate PM Leads, and any discrepancies between the approved plan and the
stakeholder responses will be escalated to the PM for resolution using the issue management process.
8.2.2 Stakeholder Monitoring
Monitoring of stakeholder involvement is a fundamental risk-avoidance technique whereby the team validates
that the committed stakeholder resources participate in key program activities. For any activities where
external stakeholders are required (SME’s, client, or other) the program will create agendas and capture
meeting notes which documents the expected stakeholders’ participation and the actual stakeholders’
participation. The lack of appropriate stakeholder involvement will be managed through the issue
management process.
8.2.3 Stakeholder Effectiveness
The team will evaluate the effectiveness of the stakeholders that participate in the identified key activities.
This will include determining if the right levels of participation have occurred and that the stakeholders
possess the correct levels of knowledge and influence to be effective at driving the stated objectives for the
activity. Should the team find that the participants are not effectively contributing to the program goals and
objectives for an activity; the team will log an appropriate issue and immediately escalate to program
management.
8.3 SBO Engagement
The City-Parish is committed to ensuring that small, disadvantaged, veteran and women-owned businesses
are not inhibited from bidding on or proposing for contracts and consulting agreements related to the MOVEBR
Program. To aid in supporting this, the PM shall provide for a Small Business Outreach (SBO) consultant(s) as
part of the firm/team, to create, implement and monitor a plan to increase and maximize contracting and
procurement opportunities for small and disadvantaged business enterprises, including Certified and Non-
certified DBE firms, throughout the entire MOVEBR program.
The PMT will be responsible for development, implementation, monitoring and evaluation of an SBO program,
and shall work closely with the City-Parish to:
•
Formulate goals, objectives and timelines for the program
•
Obtain approval from the City-Parish, in keeping with its economic development goals, on all initiatives of
the SBO Program.
The PMT will work closely with the City-Parish to ensure that contracting and solicitation-related processes
promote equity in access, capacity building, consideration and opportunities for DBE’s, small, veteran- and
women-owned entities, as part of the overall MOVEBR program strategy
RI PROGRAM MANAGEMENT PLAN
36
The SBO Engagement Plan that is appendix item to the document provides details of the program objectives
and strategy regarding SBO engagement.
RI PROGRAM MANAGEMENT PLAN
37
9 Quality Management Plan
The purpose of the Quality Management Plan is to define the objectives, processes, tools, and roles and
responsibilities required to implement an effective quality management program.
9.1 Quality Management Plan Objectives
The objectives of this Quality Management Plan are to:
• Define the program’s quality goals
• Define the approach to verify that methods, processes, templates and tools are being used by the teams
properly and they are effective
• Define the approach to verify that deliverables are meeting standards and quality expectations
• Define what additional groups outside the core teams will be visiting and supporting the program to help
achieve these quality objectives
• Document the approach to data privacy
9.1.1 Implementing the Quality Management Plan
Successful implementation of the Quality Management Plan is the shared responsibility of the entire team. The
team is responsible for implementing the quality standards, processes, and requirements identified in this
Quality Management Plan.
9.1.2 Maintaining the Quality Management Plan
It is the responsibility of the quality manager to identify and implement required revisions to the program’s
Quality Management Plan to keep it current and relevant. Material changes to the Quality Management Plan
will not be undertaken without an approved Change Request as defined in the PMP.
9.2 Quality Assurance Plan
Quality assurance is the application of planned, structured activities to help verify that the program employs
all processes needed to create high-quality deliverables that meet requirements. This section of the Quality
Management Plan describes the tasks related to quality assurance and defines the verification review plans for
the program.
9.2.1 Quality Verifications
Quality verifications are performed to confirm that the processes and standards as defined in approved plans
(such as the PMP) are followed by the team. Quality verifications are focused on addressing three questions:
• Are the documented processes being followed?
• Are the documented processes working?
• Are the documented processes efficient?
As quality verifications are performed, it is up to program leadership to evaluate the results and determine
what, if any, corrective actions should be taken. Corrective actions might include (a) additional training, (b)
process enforcement, or (c) process refinements. It is important to weigh the cost of process changes against
their expected benefits before making refinements.
The purpose of this section is to define the program’s plans for: performing verifications; identifying, tracking,
and resolving non-compliances found during the verifications; and communicating findings and status to
program leadership.
RI PROGRAM MANAGEMENT PLAN
38
9.2.2 Quality Verification Approach
The table below describes the types of quality verifications that will be performed on the program:
#
Quality Verification
Type Description
1 Milestone Based
Quality verifications are planned at the end of major program milestones and
focus on the activities that lead up to the milestone. Verification will be
monitored during MTC stage gate process for each design milestone.
2 Deliverable Based Quality verifications are performed upon completion of major deliverables or
work products. These verifications focus on program deliverables and the
activities performed to create them. Verifications will be monitored through the
Deliverable Management Process as described in Chapter 4.
3 Scheduled Quality verifications are based on a schedule and focus on assessing all
processes and work products over time.
4 Spot Spot quality verifications are typically unannounced and performed as a
statistical sampling across the program.
9.2.3 Non-Compliance and Escalation
Non-compliances identified during the verification represent risk to the program and therefore need to be
documented, prioritized, addressed, and tracked to closure. The Quality Verification Checklist is used by the
assessor to review the program’s processes and work products and any identified non-compliances are
transferred to the Non-Compliance Tracking Log. The assessor may refer to previously completed quality
verifications to refer to non-compliances that are still open and/or identify trends where non-compliances are
recurring that may impact prioritization or escalation of new non-compliances. It is the responsibility of the
team to address the identified non-compliances, and it is the quality manager’s responsibility to monitor the
Non-Compliance Tracking Log, verify the closure of remediation actions, and escalate risks when necessary.
The following table outlines the escalation criteria and procedures the program will follow if non-compliances
are not accepted by the program or resolved in an appropriate amount of time.
Escalation Criteria
# Escalation Path/Level Level of Risk Age of Non-Compliance
1
(Ex)
Log as a risk to the program Low, Medium
= > 10 days
2
(Ex)
Escalate to program leadership Medium, High = > 10 days
3
(Ex)
Escalate to the program steering
committee and/or program sponsor
High = > 20 days
4
5
6
RI PROGRAM MANAGEMENT PLAN
39
9.2.4 Quality Verification Reporting
Quality verification results and status will be reported and maintained in the program’s Non-Compliance
Tracking Log.
9.2.5 Quality Verification Closure
When all non-compliances have been addressed and closed, and the status for each has been appropriately
updated in the Non-Compliance Tracking Log, the quality verification can be considered closed. The assessor
will report the status of the quality verification as closed, and then archive the Non-Compliance Tracking Log.
For future quality verifications, access to the results of previous quality verifications will be important to
identify any non-compliance trends.
9.3 Quality Control Plan
Information TBD from PMT
9.4 Quality Testing
Information TBD from PMT
RI PROGRAM MANAGEMENT PLAN
40
10 Organizational Change
Management Plan
Organizational Change Management (OCM) is a proactive, structured approach to addressing the people and
organizational risks inherent in any change effort associated with the program management team. OCM is
organized into core work streams consisting of the following:
• Communications
• Culture Alignment
• Training
• Organizational Alignment
With particular regard to organizational alignment and staffing matters, the PMT shall not, as noted in the
respective contracts, except for the firms listed below, sub-contract any of the services covered by this
contract nor assign any interest in this Contract or transfer any interest in same (whether by assignment or
novation) without the prior written approval of the City-Parish.
Regular contract renewal milestones, as well as through regularly scheduled management communications,
will provide the opportunity for key personnel assignment changes to be discussed.
Any changes to key personnel staff of project design leads are to be addressed through appropriate Risks,
Issues, Decisions, and Actions project logs.
