Document number: PGM.PLAN.0007 Version: 2.0

Delivery of Automated Systems for Healthcare (DASH) Program

Schedule Management Plan

ATTM 019

PGM.PLAN.0007 - Schedule Management Plan Ver.2.0

Table of Contents

1. INTRODUCTION

1.1. PURPOSE

1.2. SCOPE

1.3. REFERENCES

2. ROLES AND RESPONSIBILITIES

2.1. DASH PROGRAM DIRECTOR

2.2. DASH PROGRAM MANAGER

2.3. VENDOR PROJECT MANAGER

2.4. SCDHHS PROJECT MANAGER

2.5. DASH PROJECT MANAGEMENT OFFICE (PMO) MANAGER

2.6. FUNCTIONAL MANAGERS

3. SCHEDULE DEVELOPMENT PROCESS

3.1. OVERVIEW

3.2. CHARACTERISTICS OF A QUALITY SCHEDULE

3.2.1. Comprehensive

3.2.2. Well-constructed

3.2.3. Credible

3.2.4. Controlled

3.3. SCHEDULING GUIDELINES AND ASSUMPTIONS

3.4. WORK BREAKDOWN STRUCTURE (WBS)

3.5. SCHEDULE DEVELOPMENT STEPS

3.5.1. Defining all Work Activities

3.5.2. Estimating the Work

3.5.3. Scheduling the Work

3.5.4. Schedule Validation

3.5.5. Rolling Wave Planning

4. SETTING AND MANAGING BASELINES

4.1. STANDARDS FOR BASELINING

4.2. BASELINE QUALITY CHECKLIST

4.3. SET INITIAL BASELINE

4.4. SCHEDULE AND BASELINE MAINTENANCE

4.5. BASELINE SCHEDULE UPDATES

4.6. AS-NEEDED IMPLEMENTATION ADVANCED PLANNING DOCUMENT UPDATES (IAPDU)

5. SCHEDULE CONTROL AND MONITORING

5.1. SCHEDULE VERSION CONTROL

5.2. RESOURCE MONITORING AND ADJUSTMENT

5.3. WEEKLY PROJECT SCHEDULE TRACKING PROCESS

5.3.1. Weekly Update Schedule

5.3.2. Schedule Update Guidelines

5.4. SCHEDULE COMMUNICATION

5.5. OUTPUTS FROM SCHEDULE CONTROL

6. SCHEDULE MANAGEMENT METRICS AND REPORTING

6.1. DASH PROJECT WEEKLY STATUS REPORT

7. GOVERNANCE AND PLAN MAINTENANCE

8. APPENDIX A - GLOSSARY

9. APPENDIX B – SCHEDULE ROLE TO RESOURCE CROSS REFERENCE

1. Introduction This document describes the plans and processes used by the Delivery of Automated Systems for Healthcare (DASH) Project Management Office (PMO) to develop, augment, maintain, and control the project schedule. The intended audience is the DASH Program, DASH PMO, Vendor Project Managers, and Vendor Managers.

1.1. Purpose

The purpose of the Schedule Management Plan is to document the approach for planning and managing the complex project schedules of the DASH Program. It is a management discipline that is one of the DASH PMO’s highest priorities and is a critical success factor.

The DASH PMO will manage the project schedule which provides a framework for assigning staff to complete the work. Schedules are built top-down, reflecting the needs and milestones of each DASH project, and bottom-up with the “how” it will be achieved. The DASH PMO will utilize three key concepts:

• A proven Project Management Institute (PMI) – Project Management Book of Knowledge (PMBOK) methodology of Cost / Schedule Management to validate work in process

• Revisions are made as process improvements are identified and implemented. The changes to the Schedule Management Plan are initiated in accordance with Section

8.2.5 of the PGM.PLAN.0001 - Program Management Plan

• The DASH Program will use Microsoft Project (MS Project) as the primary management tool to manage and communicate project schedules

The approved project schedule will be version controlled and posted in the individual DASH Project SharePoint project repository.

1.2. Scope

The Schedule Management Plan defines the plans and processes by which the DASH project schedules are defined, estimated, staffed, and tracked. The plan also provides roles, responsibilities, processes, and procedures in each of the following areas:

o Schedule Development o Progress Reporting o Schedule Maintenance o Schedule Baselining

All schedule definition and maintenance activities fall under the processes and procedures described in this document.

Schedule development and maintenance is an ongoing function throughout the project.

The project schedule, at all levels, must be analyzed on an on-going basis to deal with progress updates, approved change requests, changing conditions and priorities on the project. With the focus on monitoring schedule and progress, there are many participants in this process, from the individual teams to the executive management level, each following clearly defined roles and responsibilities.

1.3. References

1) PGM.PLAN.0001 – Project Management Plan

2) PGM.PLAN.0006 - Change Management Plan

3) Practice Guide for Scheduling – Third Edition, Project Management Institute (PMI)

4) Practice Standard for Work Breakdown Structures – Third Edition, PMI

5) Planning and Scheduling Excellence Guide (PASEG) – Version 3.0, National Defense Industrial Association (NDIA)

6) Schedule Assessment Guide (GAO-16-89G) – United States Government Accountability Office

(GAO)

2. Roles and Responsibilities The set of roles associated with the Schedule Management Plan include:

2.1. DASH Program Director

The DASH Program Director has overall responsibility for all projects and workstreams within the DASH Program. Within the Schedule Management Plan, the DASH Program Director will:

• Approve project baselines

• Escalate critical impacts to project schedules to SCDHHS Senior Management

• Provide Program approvals of formal change requests

• Approve and provide project schedules as needed for Implementation Advanced Planned Document (IAPD) submission to CMS

2.2. DASH Program Manager

The DASH Program Manager provides overall direction to the Schedule Management Plan and ensures adherence to a standard process by project stakeholders.

The DASH Program Manager will:

• Plan, schedule, monitor, and report on activities related to the Program

• Ensure that effective project control, change management, and risk management are maintained

• Recommend approval of project baselines

• Escalate critical impacts to project schedules to DASH Program Director

• Provide Program approvals of formal change requests

• Direct project schedule development as needed for Implementation Advanced Planned Document (IAPD) submission to CMS

• Collaborate with Vendor Project Managers, SCDHHS Project Managers, and Functional Leads in the development of project schedules

• Present schedule metrics to SCDHHS Senior Management

2.3. Vendor Project Manager

Under the direction of the DASH Program Manager, and in coordination and collaboration with the SCDHHS Project Manager and the DASH PMO Manager, the Vendor Project Manager has overall accountability for vendor execution of this plan, and for the ongoing assessment of the effectiveness of the processes described herein.

Within the scope of Schedule Management Plan responsibilities, the Vendor Project Manager will:

• Ensure the project schedule is developed and updated in accordance with these processes

• Direct the weekly schedule update process for Vendor-assigned activities

• Perform schedule analysis and reporting for senior management

• Participate in schedule refinement, review, and approval activities

2.4. SCDHHS Project Manager

The SCDHHS Project Manager, and in coordination and collaboration with DASH Program Manager, is the primary owner of the portions of the master project schedule solely executed by DASH and SCDHHS-assigned resources. This role is also responsible for oversight of the entirety of the master schedule and activities that modify, update, and maintain it. They are expected to work closely with the DASH Program Manager and other project vendors to ensure that interdependencies are properly represented and changes to the schedule are reviewed, approved, and documented.

The SCDHHS Project Manager will review the weekly progress updates for variances from the master schedule, or for trends indicating schedules may not be met, and determines if these variances or trends are within the defined tolerance thresholds. The tolerance threshold will be if any task on the critical path falls behind schedule, or if any task that has slipped could become a critical path task. This includes tasks with late starts, slipping tasks, slipping progress or late tasks.

Within the scope of Schedule Management Plan responsibilities, the SCDHHS Project Manager will:

• Ensure the project schedule is developed and updated in accordance with these processes

• Analyze the schedule

• Participate in schedule refinement sessions

• Participate in resource balancing activities for SCDHHS and DASH Program resources

• Produce task assignment reports for use by the DASH PMO

• Actively monitor schedule changes

2.5. DASH Project Management Office (PMO) Manager

The DASH PMO Manager will review the weekly progress updates for variances from the master schedule or for trends indicating schedules may or may not be met and determine if these variances or trends are within the defined tolerance thresholds.

Within the scope of Schedule Management Plan responsibilities, the DASH PMO Manager will:

• Develop and maintain the Schedule Management Plan

• Ensure the project schedule is developed and maintained in accordance with the Schedule Management Plan

• Perform schedule analysis and reporting for the DASH Program Director and DASH Program Manager

• Participate in schedule building, refinement, and review activities

• Update the project schedule based on data from the functional managers and project team members

• Analyze schedule variances and produce reports thereof

• Interpret schedule metrics

• Publish the master schedule and the change request schedule

2.6. Functional Managers

Under the direction of the appropriate Project Manager and in coordination and collaboration with the DASH PMO Manager, the appropriate Managers Team Leads are responsible for collecting data required for some of the schedule development process steps. The Functional Managers report on the tasks they are responsible for on a weekly basis to the DASH PMO Manager.

Within the scope of Schedule Management Plan responsibilities, the Functional Managers will:

• Provide expert judgement for activity decomposition and dependency analysis

• Determine specific individual or team resources to apply to activities

• Collect work estimates from experienced resources of the appropriate type

• Report status of schedule tasks assigned to their area of responsibility

• Report risks to or problems with scheduled completion of activities

3. Schedule Development Process

3.1. Overview

The Schedule Management Plan describes the DASH Program’s approach to:

• Planning work

• Measuring progress of work completed

• Comparing actual progress to planned progress

• Initiating corrective action when actual progress falls behind the baseline schedule to potentially cause a major milestone to slip

• Ensuring quality schedule development and management

This process specifies the types of reviews and tools that are used to create, and then monitor, track, and maintain the project schedule.

Listed below are some of the key planning considerations:

• The planning methodology consists of developing a series of work products that communicate project information at different levels and for different purposes

• This approach focuses on project coordination and identifying and managing dependencies between related activities

• Focus on the definition of relationships between tasks and minimizing date constraints and lags to determine scheduling so that changes in the schedule can be seen dynamically

• Dependencies are identified and mapped in the project schedule

• The components are developed in the project-scheduling tool, MS Project, and the tasks created are detailed to their logical task level, no lower than WBS level 10 in the project schedule

• The principal tool for the project schedule is Microsoft (MS) Project

• MS Project computes the critical path for the overall project and adds another perspective into the critical elements of the schedule

3.2. Characteristics of a Quality Schedule

3.2.1. Comprehensive

• Reflects all activities as defined in the project WBS

• Reflects the resources needed to do the work and whether those resources will be available when needed

• Reflects how long each activity will take, allowing for discrete progress measurement with specific start and finish dates

3.2.2. Well-constructed

• All activities are logically sequenced with predecessor and successor logic

• Limits and justifies use of unusual or complicated logic

• Includes a critical path that determines the activities that drive the project’s earliest completion date

• Includes total float that accurately reflects the schedule’s flexibility

3.2.3. Credible

• Reflects the order of events necessary to achieve project objectives, deliverables, and outcomes

• Uses best practice estimation methods resulting in documented and quantitative estimates

• Activities in varying levels of the schedule map to one another and key milestones and dates

• Reflects varying levels of activity, supporting activity, and subtasks

• Reflects confidence in meeting a project’s completion date based on data about risks for the project

• Includes necessary schedule contingency and prioritized risks based on schedule risk analysis

3.2.4. Controlled

• Updated regularly by staff with the appropriate level of project scheduling skills

• Status reports include an explanation for tasks that are late

• Schedule is compared against a designated baseline schedule to measure, monitor, and report the project’s progress

• Subject to a change management plan

3.3. Scheduling Guidelines and Assumptions

In order to make the DASH project schedules more maintainable, several guidelines have been established by the DASH PMO.

Scheduling guidelines defined to date are:

• Resource planning considers vacations, holidays, and unplanned time off. Therefore, the available resource pool is not a constant, so the DASH assumes their resources work a standard 8-hour workday. By using a standard 8-hour day in developing the schedule, DASH does not over commit resources. SCDHHS contractors and vendors assume an 8-hour workday and SCDHHS FTEs assume a 7.5-hour workday as identified in the project Resource Sheet in MS Project

• Within the schedule, DASH resource assignments are made to actual named staff persons or a unique title that represents an individual person. Resource assignments should not be made at a group or team level. If the decision is made to use a title instead of a resource name, a Schedule Role to Resource Cross Reference list must be provided. This list will be kept for this purpose and stored in the project SharePoint site under Controlled Documents/Reports(REPT). An example report is listed in Appendix B – Schedule Role to Resource Cross Reference. Changes to this list will be managed through the Document Management Process.

• Names of tasks shall be unique within the overall schedule (e.g., “project plan” is unacceptable, “Project Management Plan” is acceptable). Tasks should be created with the following conditions:

• Task Duration should be defined in days

• Task Work should be defined in hours

• All detailed tasks with work hours must have a resource(s)

• Summary Tasks should not have resources

• Dependencies are defined at the detailed task level in the WBS (there should be no dependencies defined in a Summary Level task)

• Resource assignments are managed at the task level of the WBS (e.g., sprint design, development, and system test execution). This ensures that all tasks are properly staffed

• Assignments are based on mapping resource availability, skills, and skill levels to the requirements of the task to maximize productivity and minimize rework

• The critical path for the overall project is computed by the MS Project tool and adds another perspective into the critical elements of the schedule and resource planning process to ensure these critical tasks are properly staffed

3.4. Work Breakdown Structure (WBS)

The Work Breakdown Structure, as defined in the PMBOK, 7th Edition is, “The hierarchical decomposition of the total scope of the work to be carried out by the project team to accomplish the project objectives and create the required deliverables.” This organizes and defines the total scope of the project into smaller, more manageable tasks, and provides a structured version of what is being delivered. A WBS:

• Supports the definition of all work required to achieve an output, objective, deliverable, or tangible result

• Is constructed to illustrate and define the hierarchy of deliverables. This is organized into parent-child relationships

• Has an objective or tangible result referred to as a deliverable or output or result

The DASH PMO has structured the DASH project schedule at multiple, interrelated levels:

• Strategic Management Milestones represent the executive view of the entire project, which consists of the Contract Summary Milestones or Deliverables. Strategic Management Milestones consist of three categories of milestones:

o Project Global Milestones – those contractual milestones used to establish the completion dates for major project activities o Project Milestones – those key milestones (primarily contract deliverables, delivery, and acceptance) produced as part of the project o Strategic (Management) Milestones – those milestones jointly determined by the Vendor and the DASH Program and are strategic in nature

• Project Areas represent the partitioning of project scope into separate phases. The following is an example of high-level project areas:

o Project Management Oversight o Life Cycle Phases

Requirements Design Development Test Systems Integration Testing (SIT) End-to-End Testing (E2E) User Acceptance Testing (UAT) Federal Certification Implementation o Organizational Change Management (OCM)

Major project milestones should be identified for each project phase.

3.5. Schedule Development Steps

The following diagram depicts the processes involved in developing and refining the project schedule. Modifications are triggered during ongoing planning or by changes in project scope or circumstances.

Figure 1: Schedule Development Steps

The schedule development steps are:

3.5.1. Defining all Work Activities

The initial activity to be performed when developing or modifying the schedule is to define the work that is needed to complete a particular set of tasks to be scheduled.

This process step is a combination of the PMBOK Activity Definition and Activity Sequencing processes. It also includes the initial iteration of the PMBOK Activity Resource Estimation process, but the resource estimates are based on resource titles rather than specifically identified individuals.

The schedule should reflect all activities as defined in the program’s work breakdown structure (WBS), which defines in detail the work necessary to accomplish a project’s objectives, including activities both the DASH Program and Vendor(s) are to perform.

Typically, the following steps will be conducted in informal meetings with the appropriate team leads, business and technical experts, and at least one member of the

PMO.

3.5.1.1. Define Milestones

Milestones:

o Are reference points used to monitor the progress of a project o Reflect major events or deliverables o Have zero duration and zero work (do not consume resources) o May mark the start and/or finish of an interim step, event and/or program phase, making them convenient indicators of attaining project objectives o Have percent complete of only zero or one hundred percent

3.5.1.2. Activity Definition

Activity Definition is the mechanism whereby the set of tasks necessary to produce a specific project deliverable are determined. The basic concept is to take the elements at the lowest level of decomposition of a project work breakdown structure (called work packages) and identify the specific schedule activities necessary to produce them.

Although industry standards (e.g. PMBOK) often address the production of all WBS elements as part of scope definition, in practice it is possible to decompose high-level deliverables and define the activities needed to produce them at the same time.

When defining activities, the general approach used is to apply expert judgment and past experience of the team to divide the work packages into smaller pieces to fully understand the work.

A work package decomposed to the activity level contains tasks that:

• Can be realistically and confidently estimated

• Make no sense practically to break down any further

• Produce a deliverable or a work product which is measurable

As this decomposition is done, the team should name the activities so that they make sense – a good rule of thumb is to use simple declarative sentences with active verbs. For example, “Produce first draft of drawing X”. In cases where the team anticipates potential confusion, this description should be elaborated to include a full description of the work to be performed, including listing the intermediate internal deliverables.

The following guidelines should be utilized when the WBS is broken into work packages/activities:

• 80 Hour Rule - No single activity at the lowest level of detail should be more than 80 hours (10 days) of duration

• 8 hours Rule - No single activity at the lowest level of detail should be less than 1 day of duration

• Handoff Rule - Clear, distinct activities should be created when work products or deliverables are passed between teams. For example, if a development team is delivering code to a test team for testing there should be a separate task or tasks for the development team to complete the code and a separate task or tasks for the test team to test the code that do not overlap with the development tasks

• Measurable Rule – The activity should consist of a quantifiable, measurable deliverable. However, the measure should not be the passage of time such as a timebox or level of effort other than a few document exceptions. For example, if an activity has a 10-day duration a clear metric must be used to determine % complete after the first 5 days other than “half the time has passed so the task is 50% complete”

• Level of Effort (LoE) – LoE activities represent effort that has no measurable output and cannot be associated with a physical product or defined deliverable

• Common Sense Rule - Apply common sense when creating the duration of a single activity or group of activities necessary to produce a deliverable defined by the WBS

In addition, it is suggested that the team members involved in this process be aware of the schedule guidelines described in Sections 3.2 and 3.3.

If the team identifies activities or deliverables that are predecessors of the activities in the list, these should be documented.

The outputs of Activity Definition are lists of activities and any additional information about those activities uncovered. The activity list is a comprehensive list that includes all schedule activities required on the project. The activity list also includes the activity identifier and a scope of work description for each activity in sufficient detail to ensure that project team members understand what work is required to be completed. Each activity should have a unique title that describes its place in the schedule, even if that activity title is displayed outside the context of the project schedule. The activity list is fed to downstream processes, providing the foundation data upon which estimates, dependencies, work assignments and schedule paths can be constructed

3.5.1.3. Activity Sequencing

The schedule should be planned so that critical program dates can be met. To do this, activities must be logically sequenced and linked and listed in the order in which they are to be carried out and joined with logic. In particular, a predecessor activity must start or finish before its successor. Date constraints and lags should be minimized and justified. This helps ensure that the interdependence of activities that collectively lead to the completion of activities or milestones can be established and used to guide work and measure progress.

Project activities are analyzed in order to understand precedence of the activities in relation to each other and to external activities, milestones, and deliverables.

The activities in the sequence should also have associated lead and/or lag times that make them achievable within the constraints of project time, scope, and cost objectives.

The recommended method for the DASH Program for sequencing activities is the Precedence Diagramming Method. This technique produces a depiction of the elements of the activity list in which the activities are represented as boxes and lines are used to connect them in dependency order. The specifics of this method are up to the particular team performing the sequencing; whiteboard diagrams or “sticky note” exercises are effective ways to do the work.

The dependencies between tasks are normally based on the nature of the work being performed; certain things just have to be done before others. These are called mandatory dependencies. The sequencing team strives to identify and document all mandatory dependencies within the activities being sequenced.

3.5.1.4. Predecessors and Successors

The sequencing of activities and milestones connected with relationship logic form the basis of the schedule. Every activity should be connected with at least one predecessor and one successor activity which indicates how the activities are related to each other. The types of relationships are:

• Finish-to-Start (FS) – The initiation of the successor activity depends on the completion of the predecessor activity

• Finish-to-Finish (FF) – The completion of the successor activity depends on the completion of the predecessor activity

• Start-to-Start (SS) – The initiation of the successor activity depends on the initiation of the predecessor activity

• Start-to-Finish (SF) – The completion of the successor activity depends on the initiation of the predecessor activity

After the dependencies are understood, the sequencing team then reviews the relationships to determine whether to apply leads or lags. Lead times allow successor tasks to start before the completion of the predecessor task (i.e. allowing tasks to overlap); lag times force successor tasks to start later (making “gaps” in the timeline).

3.5.1.5. Use of Leads and Lags

Leads and lags are scheduling techniques used in illustrating a delay or planned overlap. They help refine the schedule’s workflow model. Misuse of leads/lags in the project may have unintended consequences.

• Lag – Denotes the passage of time between two activities. Lags simply delay a successor activity; no effort or resources are associated with this passage of time

• Lead – Used to accelerate a successor activity. This is also referred to as negative lag

Lags and leads:

• Lessen the ability to dynamically respond to changes in the status of predecessor activities

• Must be changed manually if there is a change in the expected passage of time

3.5.2. Estimating the Work

This process combines the activities described by PMBOK as Activity Resource Estimating and Activity Duration Estimating. Note that it is also possible that any or all of the steps listed in Defining the Work will be repeated, but it is assumed that this will be within the context of further decomposition of the outputs of the previous step in the vast majority of cases.

The steps of this section are expected to be executed by teams that should include appropriate team leads, managers, technical experts, and members of the DASH PMO.

3.5.2.1. Activity Resource Estimation

This step determines the people, equipment, and material required to complete project activities.

The initial resource estimates will be performed by experienced staff with expertise in the activities being estimated. The primary techniques will be expert judgment of this staff based on historical information, knowledge of the capabilities of available resources, and an analysis of alternatives for completing the work.

Should the complexity of an activity make such estimating uncertain, the activities are to be further decomposed until they can be effectively estimated.

The primary output is the resource requirements for each activity in the list. The human resource requirements will indicate specific individual or specific position title and the work hours for that resource. If a position title is indicated then a cross reference is to be created that assigns a specific named individual to the specific position.

Resource estimates are to be delivered in electronic form to the appropriate PMO staff member for incorporation into the project schedule or fed directly into the Activity Duration Estimation process step.

3.5.2.2. Activity Duration Estimation

This step involves the application of expert knowledge and various estimation techniques to estimate the effort involved to complete each activity. While not always practical, it is best to have these estimates made by the people that will actually perform the work.

The DASH Program primarily utilizes expert judgement to provide duration estimates and activity durations for the activities in the project schedule. One of the advantages in utilizing expert judgement is using analogous estimating. This technique allows estimating the duration of the activities using historical data from similar projects. Analogous estimating uses the duration parameters from a previous, similar project as the basis for estimating the durations of the current project. The focus on the estimates is using the actual data from previous projects and is adjusted based on the differences in project complexity.

Group decision making techniques are also utilized to provide activity duration estimates. This technique is used by the DASH Program to improve estimate accuracy. This is performed by sitting down with several team leads involved with a set of activities. Additional information is shared across teams to obtain more accurate estimates.

The primary output of Duration Estimation is an updated duration estimate for each activity in the list. These estimates are to be provided as total staff hours for each of the resource types assigned to the activity.

Duration estimates are to be delivered to the appropriate PMO staff member for incorporation into the project schedule or fed directly into the Schedule Development process step if the latter is being executed immediately.

3.5.3. Scheduling the Work

This process step corresponds to the Schedule Development Process of the PMBOK. As previously noted, this is an iterative process that determines the planned start and end dates for project work. Within this process, inputs from the preceding processes are reviewed, adjusted, and applied to the master project schedule.

Resource balancing and reconciliation between top-down Strategic Management Milestones and bottom-up tasks take place. Conflicts due to unbalanced resources or discrepancies between the top-down milestones and bottom-up tasks will be resolved by teams that should include appropriate team leads, managers, technical experts, and at least one member of the DASH PMO.

Supporting detail for project activities will be included in the Task Notes field of the master schedule. Note that in many cases, project activities are governed by documented processes or correlated to the steps of those processes. Supporting detail about those tasks will in general not be included.

3.5.3.1. Resource Balancing

Since all project activities within the MS Project schedule share a common resource pool, it is vital to reconcile resource usage in the project schedule. There will be instances where a resource might be over-allocated since some tasks may take more than 40 hours a week to complete. The DASH PMO will ensure that no resource is over-allocated by more than 10 hours per week for more than 4 consecutive weeks.

The DASH PMO will ensure that no SCDHHS or DASH Program resources are over-allocated by more than 10 hours per week for more than 4 consecutive weeks. The project schedule has been setup for an 8-5 work week (40 hours for Vendor and

SCDHHS Contractor resources and 37.5 hours for SCDHHS Full Time Equivalent (FTE) resources and State holidays have been added.

3.5.4. Schedule Validation

This step in the process ensures that the schedule is valid. The primary ways the schedule is validated is by checking the critical path and internal schedule traceability.

3.5.4.1. Critical Path Validity

In order for the critical path to be valid, it should meet the following conditions:

• Does not include LOE activities, summary activities, or other unusually long activities, except for future planning packages

• Is a continuous path from the status date to the finish milestone

• Does not include constraints that cause unimportant activities to drive a milestone date

• Has no lags or leads

3.5.4.2. Schedule Traceability

A traceable schedule has the following attributes:

• Depicts logical relationships between different program elements and hand-offs and clearly shows when major deliverables and hand-offs are expected

• Includes complete logic from program start to program finish and fully integrates the entire scope of work from all involved in the program

• Includes milestones representing key decisions or deliverables with validated predecessor activities to ensure that they are directly related to completing the milestone

• Dynamically reforecasts the date of a key milestone through network logic if activities related to accomplishing the milestone are delayed

• Is affected by activities whose durations are extended by many days

• Allows traceability of activities to higher-level milestones from lower-level schedule components

• Allows lower-level schedules to be rolled up into the overall program schedule, which includes government activities, other contractor schedules, and interfaces with external parties

3.5.5. Rolling Wave Planning

Rolling wave planning is an iterative schedule planning method in which the work to be performed in the near term is planned in detail, while the future work is planned at a lower level of detail. This method, also known as “Progressive Elaboration”, assumes the project team is very likely to have accurate and detailed information regarding near-term activities (current wave) and information about future work (future waves) is less reliable. In rolling wave planning, detailed planning occurs at regular intervals and the planning for the next interval should be completed before the start of the next wave.

Wave duration guidelines are set by the DASH Program Manager and define the expectations by which detailed work will be added at a later date. Rolling wave projects must:

• Maintain a minimum of six months of detailed activities

• Include estimated durations and work at a summary level for all future activities

4. Setting and Managing Baselines

4.1. Standards for Baselining

One of the most important responsibilities of a project manager is to keep the project under control. A baselined project schedule is the tool used to control the project and measure the project’s progress. The Schedule Baseline is the version of the project schedule which has been placed under control, to which all progress will be measured and is used to drive status reporting and project Key Performance Indicators (KPI).

The baseline formalizes the project’s scope, cost, and schedule. Once the project has been contained in these three dimensions, progress can be tracked, measured, monitored, and controlled.

4.2. Baseline Quality Checklist

The Baseline Quality Checklist contains a list of basic quality points that should be reviewed and corrected or accepted as complete prior to scheduling the baseline review. The template for the Baseline Review Checklist (PGM.TMPL.0021) is located in Controlled Documents>Templates (TMPL). Exceptions to these criteria should be documented and explained in the Baseline Review with DASH Program Management. Quality criteria are listed below:

• Durations - Long durations should be broken into shorter activities if logical breaks can be identified in the work being performed

• Linkages – schedule activities are well-linked with predecessors and successors

• Relationship Types – Finish to Start (FS) should be the primary relationship type used. Other relationship types should be used sparingly and exceptions documented. FS provides a logical path through the schedule

• Leads - The use of leads (negative lags) normally indicates that the schedule is not detailed enough or the scheduler is trying to “fix” activity dates. This makes it harder to analyze the critical path, distorts the total float in the schedule and may cause resource conflicts. Leads will not be allowed unless there is not a suitable predecessor for activity linking. Tasks with leads should be explained during the baseline review

• Lags - The use of excessive lags complicates the schedule to the point of not being maintainable and ineffective in forecasting future dates. This makes it harder to analyze the critical path. Tasks with excessive lag should be explained during the baseline review

• Float – The schedule should identify reasonable total float (or slack)—the amount of time a predecessor activity can slip before the delay affects the project’s estimated finish date—so that the schedule’s flexibility can be determined. High total float on an activity or path may indicate that schedule logic might be missing or invalid

• Critical Path – The schedule’s critical path represents the sequence of activities that drive the project’s earliest completion date, and total float depicts schedule flexibility o Has zero float o Does not include LoE activities, summary activities, or other unusually long activity durations o Is a continuous path from the status date to the finish milestone o Does not include constraints that cause unimportant activities to drive a milestone date o Has minimal to no lags or leads

• Date Constraints – Constraints override network logic and restrict how planned dates respond to actual accomplished effort or resource availability and can impact the critical path; they should be used only when necessary. These should be explained during the baseline review

• Resource Assignments - The schedule should realistically reflect the resources that are needed to do the work and compared to total available resources, should determine whether all required resources will be available when they are needed. All detailed tasks are assigned a resource. There are no resources assigned to summary tasks or milestones. Team Leads are able to explain the logic behind their resource estimates. Resource titles or resource names are loaded in the schedule and correctly map to the Schedule Role to Resource Cross Reference Table

• Level of Effort (LoE) – Project oversight and other management activities indicate the passage of time and not discrete effort. LoE activities are not on the critical path and therefore do not affect the length of the project

4.3. Set Initial Baseline

Once the initial scheduling efforts have been completed for the project, the project schedule is ready to be baselined. The SCDHHS and Vendor Project Managers, the DASH Program Director, the DASH Program Manager and the DASH PMO Manager will meet to review and set the baseline in the Baseline Review meeting. The schedule will be reviewed and any final revisions to the activities are performed. The review will also include checking that the current status on all tasks are correct, including the correct start and finish dates and percent complete. This is important as once the schedule is baselined; the Schedule Performance Index (SPI) should have a value of 1. Once all in attendance agree that the project schedule is accurate, the baseline will be set in MS Project and the project schedule will be uploaded to SharePoint.

4.4. Schedule and Baseline Maintenance

The project schedule baseline will not be updated. Individual task baseline data will not be manually updated, nor will a task be re-baselined once the original baseline has been set without the approval of the DASH Program Manager.

It is expected that requests may be made to add new tasks into the schedule as the project moves between phases or between each rolling wave effort, if applicable. Each request will be reviewed by the DASH PMO Manager and the following questions will be asked for each request:

1. Does the new task need to be added (i.e., work cannot be covered in any task in the schedule)?

• If No, the request will be rejected and progress will be covered in the appropriate project schedule task

• If Yes (i.e. the task is in scope), then:

2. Does this new task further clarify work that has already been agreed upon (i.e. is within current project scope)?

• If No, the task may not be added until an Impact Analysis has been completed, reviewed, and approved by the DASH Program Manager. Once approved and thus now part of project scope, the new task(s) can be baselined as described in Section 4

• If Yes (i.e. the task is in scope), then:

3. Will any CDML delivery dates or summary tasks be affected as a result of this task?

• If No, the new tasks will be entered into the schedule if they are a further breakdown of existing tasks. Non-date changes are entered, and the corresponding tasks are baselined. If there are any date changes, they will be noted

• If Yes (i.e. the task is in scope), the DASH PMO Manager will report the request to the SCDHHS Project Manager and will be reviewed in the schedule review meeting with the Vendor project manager. DASH Program Manager approval will be required before baselining

4.5. Baseline Schedule Updates

Baseline schedule data are those schedules that have been agreed to as the established dates for the project. They represent the plan of record and are the base against which progress and deviations are measured. The baseline is established at the start of the project and may be revised by scheduled phases or rolling wave efforts defined during the project. During these checkpoints, the following adjustments may occur:

• Revised details from the requirements and design phases or rolling wave planned updates

• Revised dates based on the estimate to complete dates that have significant consequences to the overall project schedule

• Assigning and allocating resources to elaborated tasks

Change Requests may happen at any time during the project and may have an impact to the project schedule. Change Requests go through the process outlined in PGM.PLAN.0006 - Change Management Plan. Any approved change request that impacts the project baseline schedule and resources will be added to the project schedule once the change is approved.

Project schedule updates that are required by rolling wave efforts or change requests will be performed by making a copy of the current schedule and updating and/or adding the required tasks. Once complete, the DASH and Vendor Project Managers, the DASH Program Director, the DASH Program Manager and the DASH PMO Manager will meet to review the change. Once agreement is reached on the changes, those tasks are added to the current schedule. After a final review and approval, the baseline for the updated and/or added tasks is set. The affected tasks are selected, and the baseline is set only on these tasks. If the baseline is set for updated tasks, the baseline dates are kept, and the revised dates will be placed in another baseline start and finish date fields. This keeps the original baseline dates intact.

4.6. As-Needed Implementation Advanced Planning Document Updates (IAPDU)

Major project initiatives that involve updates or changes to Medicaid Automated Data Processing (ADP) systems require the submission and approval of an Advanced Planning Document (APD) to secure federal funding from The Centers for Medicare and Medicaid Services (CMS). Once approved, the SCDHHS is required to provide annual updates or as needed updates to communicate project status and to update funding requests as needed.

Change Requests or other changes that impact the schedule baseline by more than 60 days for major milestones will cause the as needed IAPDU process to be initiated. The CMS approval will delay to ability to formally re-baseline the schedule when an as needed IAPDU is required.

5. Schedule Control and Monitoring Control of the project schedule is accomplished by the Vendor and the DASH PMO in a cooperative manner. The focus of schedule control is:

• Determining the current schedule status

• Knowing when the project schedule has changed

• Controlling the causes and mechanisms by which the schedule is changed

Inputs to Schedule Control and Monitoring are proposed updates to the schedule. These updates can be changes, additions, reassignments, or deletions. The respective Project Manager or PMO Team Lead discusses the inputs with the submitters to resolve potential discrepancies or obtain necessary clarifications. Status updates to existing activities are provided in the form of the Weekly Turnaround Report. The process followed for the weekly schedule updates is described in Section 5.3 Weekly Project Schedule Tracking Process. New activities are added to the schedule utilizing the steps described in Section 4.4 – Schedule Baseline Maintenance. The Weekly Turnaround Document (PGM.TMPL.0022) template is located in Controlled Documents>Templates (TMPL).

The DASH PMO is responsible for investigating variances from the plan and for producing a set of variance reports used to examine the state of the project. These activities are performed each week in preparation for the regular schedule review meeting. The metrics and reports generated are described in Section 6.

Each week a joint weekly status meeting is held to review the reports and any schedule changes proposed during the previous week. The proposed status updates and consequent impacts to the schedule are reviewed and approved in this meeting by the appropriate managers. In instances where additional work is required, a prompt follow-up meeting is called to specifically address those changes with the DASH Program Manager and SCDHHS Project Manager.

Additional schedule development and review sessions are held as needed to plan activities and prepare materials to be submitted for updating the project schedule for the next week. These planning sessions include activities by managers and staff that result in:

• Resource leveling

• What If analysis

• Adjusting leads, lags, and dependencies

• Schedule compression

5.1. Schedule Version Control

For normal updates to the project schedule, the form of version control exercised is that enforced by SharePoint. The DASH PMO will incorporate completion percentage and task status information in the manner that works best for them when updating the “working copy” of the schedule in the workspace dedicated to that purpose in SharePoint.

The “published” version of the schedule uploaded to SharePoint each week updated by the DASH PMO. Prior published versions are maintained in SharePoint under version history for historical reference.

Schedule maintenance is the activity of keeping the DASH project schedules current and accurate.

5.2. Resource Monitoring and Adjustment

An important element of effective resource management is the real-time monitoring of workload and available resources. The DASH PMO accomplishes this by:

• Managers and supervisors managing tasks and resources through daily communications with staff members to monitor status and workload. Balancing and resource optimization occurs as assignments are reviewed and refined against project requirements

• Managers adjust to both planned and unplanned absences by effectively adjusting work assignments to minimize extreme peaks and lows

• As managers and supervisors evaluate the project schedule, for instance looking at tasks that are two weeks out and reviewing the critical path, they assess their detailed task schedules and resource allocations and make the necessary adjustments so not to impact the critical project milestones. If this assessment reveals that additional resources are required, area managers present those requirements to management for review

5.3. Weekly Project Schedule Tracking Process

This section documents the weekly efforts involved in tracking, maintaining, and updating the schedule for each DASH Project. The regular weekly schedule is listed in Table 1 below.

(Note: The days of week listed below are approximate and define the optimal schedule for the weekly processes. Exceptions to the weekly schedule, for instance holiday weeks, may occur.)

The schedule below is the standard schedule for DASH project schedule updates. The update schedule can be adjusted for each project, with approval of the DASH Program Manager with coordination of the SCDHHS Project Manager.

5.3.1. Weekly Update Schedule

Table 1: Weekly Schedule Update Schedule

Thursday Friday

Sc he du le

A ct iv ity

Pr og re ss

PMO sends the Weekly Turnaround Document to the Task Owners for activity updates to the project schedule.

The Weekly Turnaround Document will include activities for the coming three weeks.

Task Owners report their status in the Expected Updates Section of the turnaround document.

The Owner will provide the status as of reported tasks as of COB Friday. The Owner submits the updated document to the PMO by 12:00pm the following Monday.

Monday Tuesday Wednesday

An al ys is

, R ep or tin g an d M iti ga tio n

The PMO will review the respective updates. Any questions, issues, or concerns on the weekly updates will be discussed with their respective managers for clarifications.

The PMO updates the Master Project Schedule with the activities that have been updated on the Weekly Turnaround Document.

The following reports are created and placed in the weekly project status meeting folder:

• Full Schedule

• Two Week Outlook

• Critical Path Report

• Late Task Report

Schedule progress and upcoming tasks are reviewed at the weekly project status meeting. Tasks that are behind schedule will be reviewed in order to determine mitigation approach. Action items are assigned and risks or issues added at the direction of Program Manager.

5.3.2. Schedule Update Guidelines

The following guidelines will be utilized to update the status of an activity:

• Task status will be determined by examination of the remaining duration compared to the remaining work. Each responsible manager is responsible for this determination o The exception to this are Level of Effort (LoE) tasks which are “marked on track” as…