CWDS

Schedule Management Plan

Executive Summary

The CWDS Schedule Management Plan (SMP) covers the approach to managing work performed under Agile/ Scrum using the Pivotal Tracked tools and a sequential methodology in using MS Project.

The SMP covers the updated schedule management approach made necessary when the agile methodology was selected for the project. The focus of this SMP is on the process model guiding the development, tracking, monitoring and controlling, reporting and close out of project work. The SMP will describe how to schedule and manage project tasks using MS Project and Pivotal Tracker as appropriate and how MS Project will be used provide overall status on the project work.

The CWDS Project has adopted an agile/scrum methodology and is using two methodologies to manage project work and track progress: Sequential (aka Waterfall) and Agile/Scrum. A CWDS Project Master Schedule is used to manage and track sequentially scheduled work and to provide overall project status. Microsoft Project is used to maintain the Project Master Schedule. Work perform using Agile/Scrum by Scrum teams is managed using the Pivotal Tracker tool.

Schedule management is an integral part of project management. This SMP is organized according to the sequence of activities performed during the project lifecycle. The feedback loop identifies the new tasks being added or tasks being modified during schedule monitoring & control.

1. Schedule Development
   The Project Master Schedule was initially developed according to the CWDS Project Work Breakdown Structure (WBS). A WBS is a hierarchical decomposition of the project into phases, deliverables, and work packages (aka activities or tasks). With the pivot to Agile, the Agile planning tools have been utilized, specifically the planning Roadmap. The roadmap provides a high-level view of the project work, similar to the WBS, but adds a time component.

2. Schedule Tracking
   Vendors contracted to perform work on digital services are expected to manage and track their work in Pivotal Tracker. If the vendor uses a project schedule, Milestones and High-level Summary tasks from the Vendor’s schedule will be duplicated in the Project Master Schedule and the status be kept in-sync with the Vendor’s schedule.

3. Estimating Work Effort
   Detailed work activities are represented by Tasks in the schedule and Stories in Scrum. Schedule task measure work effort by duration: how much time will be required to complete a deliverable or product. Scrum Stories are measured by Story points: how many deliverables or products (or a portion of) can be completed in a set timeframe.

4. Schedule Baseline
   Baselining a project schedule is establishing a starting point for the schedule tasks against which progress is measured. The CWDS Project Master Schedule was initially baselined when the Feasibility Study Report was approved, which provide the OK for the project to start. Variance calculations will always use the baseline as approved by the most recent SPR, and the project will have a record, in the schedule, of all previously approved SPR dates.

5. Schedule Tracking

   Schedule tracking begins every Monday of a non-status week (see Section 3.4.4 The Biweekly Status Update Cycle.) The Scheduler reviews the MS Project schedule to determine impact to key milestones, and progress on the previous week’s tasks. The project uses the Look Ahead Report to track active tasks by project team. The Look Ahead Report prompts the Scheduler to select a date in the future for analysis.
    

6. Schedule Monitor and Control

   Schedule will be monitored on a regular basis and schedule performance variances will be measured in order to either initiate corrective actions or initiating formal change requests. A change to the finish date of a key milestone that is 20 or more days from its baseline finish date will trigger a change request unless the Project Manager takes a corrective action (crash or fast-track) to remove the deviation.
    

7. Schedule Reporting

   The Project uses multiple custom MS Project views, tables, filters, and groupings to build reports.

Introduction

Purpose

The CWDS Schedule Management Plan (hereafter called the “SMP”) covers the approach to managing work performed under Agile/ Scrum using the Pivotal Tracked tools and a sequential methodology in using MS Project.

Scope

The SMP covers the updated schedule management approach made necessary when the agile methodology was selected for the project. The focus of this SMP is on the process model guiding the development, tracking, monitoring and controlling, reporting and close out of project work. The SMP will describe how to schedule and manage project tasks using MS Project and Pivotal Tracker as appropriate and how MS Project will be used provide overall status on the project work.

Assumptions and Constraints

Risk Assessment

The following risks were identified in development of this Plan.

• The lack of project team experience in the execution of their assigned tasks and Stories may result in schedule delays or timely achievement of milestones.
• Poor estimation of the task duration or Story points may result in schedule delays or achievement of milestones.
• The use of 25 teams to track project effort may result in several teams not providing schedule updates in any given update cycle resulting in an inaccurate representation of project progress.

Integration with other CWDS Plans

Project Management Plan

The Project Management Plan describes how the project will be executed, monitored and controlled. This plan is supported by a number of subsidiary plans, including the Schedule Management Plan.

Configuration Management Plan

The Configuration Management Plan (Note: This link is temporarily for OSI internal use only) establishes processes and procedures used to maintain the integrity of the project’s work products, including the project schedule.

Quality Management Plan

The Quality Management Plan establishes the quality policies and processes that are to be performed during the development, review and completion of project artifacts, including the Schedule Management Plan.

Communications Management Plan

The Communications Management Plan establishes how, when and by whom information about the project will be developed, distributed, managed and measured, including the project schedule.
(Note: These links are temporarily for OSI internal use only)

Document Development and Maintenance

Transition to Agile

In November of 2015, the CWDS Project pivoted to an agile methodology. The purpose of version 3.0 of this Plan is to update components of the Schedule Process Model as made necessary by the pivot to an agile methodology.

With the adaptation of agile, the project began using two software platforms to track project activity. The Project Master Schedule is maintained using Microsoft Project and is used to depict and report the overall progress of the project. Pivotal Tracker serves as the Agile/Scrum management tool and is used to track and report activity at the team level.

Definitions and Acronyms

Table 1: Terms and Definitions  

Table 2: Index of Acronyms 

Roles and Responsibilities

This section describes key roles and responsibilities specific to schedule management on the CWDS Project.

Schedule Roles and Responsibilities

Table 3: Roles and Responsibilities 

Stakeholders

Table 4 - Stakeholder Participation and Expectations  

*Making progress and within established constraints/boundary conditions 
**

Responsible - The entity (person or group) that performs the work to complete the task
Accountable - The one who is ultimate owner and answerable for the correct and thorough completion of the task
Consulted - The entity (person or group) whose opinion is sought
Informed - Those who are kept informed (up-to-date on progress)

Plan Approach

Approach and Methodology

The CWDS Project has adopted an agile/scrum methodology and is using two methodologies to manage project work and track progress: Sequential (aka Waterfall) and Agile/Scrum. A CWDS Project Master Schedule is used to manage and track sequentially scheduled work and to provide overall project status. Microsoft Project is used to maintain the Project Master Schedule. Work perform using Agile/Scrum by Scrum teams is managed using the Pivotal Tracker tool.

Sequential Project Work

Project work performed sequentially is managed using Microsoft Project by identifying, decomposing, and sequencing the tasks required to develop the project deliverables, and to identify major milestones and release information. The tasks in the schedule will be arranged in task groups (identified in the Work Breakdown Structure [WBS]) to facilitate the management of the time, and scope of the project.

Tasks are depicted at the Phase, Deliverable, Activity/Task, Milestone and Phase Completion Milestone level. The Schedule Manager will work with the Project Managers to schedule work to be performed by their teams. Project managers will participate in the Schedule Update process.

Agile/Scrum Project work

Scrum teams will track Releases, Epics, Stories, and Tasks using Pivotal Tracker. Service Managers, working with Scrum Masters, will provide the Schedule Manager with high-level tasks/work packages in the form of Epics as well as LOE tasks. These high-level Epic/tasks will be tracked in the Master Schedule, providing a high-level status of the Stories and Tasks managed in Pivotal Tracker. Service Managers and Scrum Masters will participate in the Schedule Update process.
Dependencies between Tasks and Stories

MS Project provides the capability to set hard dependencies between tasks. These dependencies will automatically show how a change to a task affects it dependent tasks. Pivotal Tracker does not provide this capability with Epics, Stories, and Tasks, so dependencies must be manually tracked outside of Pivotal Tracker.

In addition, there is no automated interface between MS project and Pivotal Tracker, so the Scrum Masters will need to be cognizant of how potential changes in Epics and Stories may impact high-level Epic/tasks tracked in the Project Master Schedule.

Table 5 below shows where and at what level of schedule information is managed for the Digital Service and Non-Digital Service Teams.

Table 5: Project Team and Task Scheduling 

The Schedule Manager will work with Project Managers and Scrum Masters to update the Master Schedule per the Schedule Update Process described in this Plan. Scrum Masters will work with their teams to update tasks in Pivotal Tracker.

Process Model

Schedule management is an integral part of project management. This SMP is organized according to the sequence of activities performed during the project lifecycle. The feedback loop identifies the new tasks being added or tasks being modified during schedule monitoring & control. Figure 1 identifies the major schedule management processes for the project.

Figure 1 - Schedule Management Processes

Schedule Development

Schedule Development and Organization Approach

Work Breakdown Structure

The Project Master Schedule was initially developed according to the CWDS Project Work Breakdown Structure (WBS). A WBS is a hierarchical decomposition of the project into phases, deliverables, and work packages (aka activities or tasks) as illustrated in Figure 2.

Figure 2 - WBS Outline

 CWDS Digital Service Roadmap

With the pivot to Agile, the Agile planning tools have been utilized, specifically the planning Roadmap. The roadmap provides a high-level view of the project work, similar to the WBS, but adds a time component. The CWDS Digital Service Roadmap is found in the Child Welfare Services – New System Project Special Project Report #2 (Note: This link is temporarily for OSI internal use only)

The Agile/Scrum work is organized around Digital Service modules listed on the Digital Services Roadmap. Pivotal Tracker is configured around the Digital Service Modules also.

The Project Master Schedule has been updated to reflect how work is managed under Agile/Scrum. Specifically the detailed tasks in the Design and Development and Implementations Phases have been replaced with high-level Epic/Tasks that represent the Scrum work being managed in Pivotal tracker.

Tracking Vendor Work

Vendors contracted to perform work on digital services are expected to manage and track their work in Pivotal Tracker. If the vendor uses a project schedule, Milestones and High-level Summary tasks from the Vendor’s schedule will be duplicated in the Project Master Schedule and the status be kept in-sync with the Vendor’s schedule. The Service Manager and Scrum Master response for the digital service the vendor is working on is responsible for the reporting the status of the work being performed to the Project Scheduler.

Estimating Work Effort

Detailed work activities are represented by Tasks in the schedule and Stories in Scrum. Schedule task measure work effort by duration: how much time will be required to complete a deliverable or product. Scrum Stories are measured by Story points: how many deliverables or products (or a portion of) can be completed in a set timeframe.

Schedule Task Duration Estimation

Task duration is an examination and appraisal of a task against time constraint to develop an estimate that specifies a limited and definite period or duration required for the task to achieve its goal and desired outcomes.
Estimating task duration involves a consistent process that comprises several basic steps, such as:

• Define a task to be estimated

• Identify time-related requirements

• Decompose the task into smaller elements (sub-tasks)

• Estimate time length for each of the elements

• Determine duration of the task as total of individual time lengths of each element

• Develop an estimate that specifies the task duration

There are several tools and techniques that can be used to estimate activity durations: the CWDS Project will use the Expert Judgment technique.

Expert Judgment technique of activity duration estimation involves consultation with one or more subject matter experts and also uses historical information or information from past projects to develop estimates. The accuracy of this estimation technique depends on the expertise and judgment of the subject matter experts and the availability/accuracy of the historical information.

Creating Tasks

For the purposes of this Plan, a task is an activity that needs to be accomplished within a defined period of time, or by a deadline. The following standards should be followed for definition of the tasks.

• Task Name
  The task name should begin with a verb (action-oriented) and briefly yet clearly describe the task. Further definition of task detail can be recorded in the task notes field in MS Project.

• Task Dates (Start and Finish)
  Task dates should be established through dependency relationships. In situations where task constraints must be used, record the reason for the constraint in the task notes field in MS Project. When applicable, the deadline feature in MS Project Task Information can be used to mark deadlines. Task dates in Pivotal Tracker are governed by the two week Sprint cycle.

• Task Duration
  Task duration should never be less than one working day and should not exceed 20 working days. Tasks with duration less than one working day should be considered for consolidation into a higher-level task. Tasks with duration greater than 20 working days should be decomposed into smaller tasks.

Tasks based on Agile/Scrum Epics

Teams that use Agile/Scrum Epics and User Stories to manage their project work report their progress at a high-level in the Project Master Schedule by creating and maintaining tasks that represent Epics. The presentation Tracking Epics in the Master Schedule provides an overview of this process. Schedule Management procedure CWDS SM Procedure 106 – Tracking Epics in the Master Schedule explains how Epics are added to and maintained in the Master Project Schedule. (Note: These links are temporarily for OSI internal use only)

Task Dependencies and Sequencing

Tasks in the Master Schedule are linked together and sequenced to identify the relationships between activities. These relationships are called dependencies. There are four types of dependencies:

1. Finish to Start (FS) - The finish date of one task drives the start date of another

2. Start-to-Start (SS) - The start date of one task drives the start date of another.

3. Finish-to-Finish (FF) - The finish date of one task drives the finish date of another.

4. Start-to-Finish (SF) - The start date of one task drives the finish date of another.

Benefits of task sequencing include the ability to determine critical path and task float for tasks in the Master Schedule. The following rules should be applied when creating task dependencies in MS Project:

• All tasks in the Master Schedule must have at least one predecessor task, which cannot be a summary task or a roll-up task.

• Tasks in the Master Schedule that contribute to the achievement of a milestone should have at least one successor task, which cannot be a summary task or a roll-up task. A milestone task may not have any successor because it is the termination point of a segment of work.

• Dependencies should not be linked to a summary task or a roll-up task.

Task Resource Assignment

Previously the standard definition of a resource name followed the form [F_First Name Last Name. The “F_” allowed state resources to be distinguished from vendor resources and provided the ability to sort the resource column by resource names beginning with “F_”. This was useful when for example one wishes to only display “state” resources. Conversely, resource names that do not begin with “F_” would have represented resources supplied by a vendor, or state resources that are not active.

As of May 2016, a project decision was made and logged stating that resources will no longer be assigned to tasks in the schedule. The MS Project resource sheet remains intact to support tasks prior to the pivot that did have resource assignments.

Story Point Estimating

Story points represent a judgment by the Scrum team of the relatively complexity of creating a deliverable or product. A story assigned a story point of 1 has a relatively easy deliverable whereas a story point value of 21 is rather involved.

The CWDS project uses the Fibonacci Number Sequence to assign relative complexity values to a story. Fibonacci sequence starts as follows: 1, 2, 3, 5, 8, 13, and 21. Stories are rarely assigned as value larger that 21 as stories with a value larger than 5 are usually too complex to be completed within an iteration or sprint and are decomposed into 2 or more stories.

More details about Story Point estimation can be found in procedure 201_CWDS Agile Procedure Assigning Story Points (Note: This link is temporarily for OSI internal use only).
 

Creating Stories

Stories are created based on the following outline:

As a <type of user>

I want <a goal or objective>

So that <the benefit or value >

The story description is created from the end-user’s point of view, what the end-user expects and the benefit or value the end-user expects to get the from the deliverable or product being created.

Further detail on the creation of Stories, acceptance criteria and the definition of done can be found in the presentation CWDS Training Presentation Assigning Tasks to user Stories (Note: This link is temporarily for OSI internal use only).

Story Resource Assignment

Stories are created, placed in the product backlog, and prioritized before bring assigned to a scrum team.

Schedule Baseline

Baselining a project schedule is establishing a starting point for the schedule tasks against which progress is measured. The CWDS Project Master Schedule was initially baselined when the Feasibility Study Report was approved, which provide the OK for the project to starts. A new baselined was established when the Special Project Report (SPR) was approved. The SPR documented changes to the scope of the project, which required updates to the schedule.

Each time the schedule is baselined, the next sequential number is used for the baseline. For example, when the original FSR was approved, Baseline 1 was established. SPR#1 established Baseline 3, and SPR#2 established Baseline 4.

In each case, immediately after establishing a baseline as the result of an approved SPR (Baseline 4 for example), the schedule is baselined a second time using the “baseline” field. This results in Baseline 4 being equal to “baseline”. This is performed because Microsoft Project uses by default, the field called “baseline” to calculate variance.

By following this practice, variance calculations will always use the baseline as approved by the most recent SPR, and the project will have a record, in the schedule, of all previously approved SPR dates.

When a new baseline is established, the schedule is archived to SharePoint, the document status is set to “Baseline”, and the notes field is used to indicate that the schedule is an archived baselined version resulting from the approval of a specific SPR.

When new tasks are added to the schedule, the new tasks are baselined using the “baseline” field. The “baseline” field is used to calculate variances when producing schedule reports. The procedure used by the Project Scheduler when managing the baseline is the CWDS SM Procedure 100 - Baseline Log (Note: This link is temporarily for OSI internal use only).

Agile/Scrum Epics and Stories do not have an activity equivalent to Schedule Task Baselining. Agile/Scrum performance measurements include Story points completed during an iteration or sprint (Burn down) and a Scrum team’s Sprint velocity. These metrics and more are available in Pivotal Tracker.
 

Schedule Tracking 

Tracking

Schedule tracking begins every Monday of a non-status week (see Section 3.4.4 The Biweekly Status Update Cycle.) The Scheduler reviews the MS Project schedule to determine impact to key milestones, and progress on the previous week’s tasks. New action items will be assigned and corrective actions/change request will be proposed as appropriate.

The project uses the Look Ahead Report to track active tasks by project team. The Look Ahead Report prompts the Scheduler to select a date in the future for analysis. Therefore, a single custom report in MS Project may be used to produce a look-ahead report for any timeframe desired.

Currently the project uses a 4 week time horizon on the Look Ahead Report. This report is produced on the “status” Friday, and published to SharePoint. An email is then sent to all Service Managers informing them the 20 Day Look Ahead Report is available for their review. The 4 Week Look Ahead Report is reviewed at the next Service Managers meeting.

Critical Path Analysis

In order to perform critical path analysis the project schedule must contain:

• A list of all activities required to complete the project

• The time (duration) that each activity will take to completion

• The dependencies between the activities

Using this information, CPA calculates:

• The longest path of planned activities to the end of the project

• The earliest and latest that each activity can start and finish without making the project longer

This process determines which activities are “critical” (i.e., on the longest path) and which have “total float” (i.e. can be delayed without making the project longer).

Since work task management and tracking is split between the Project Master Schedule and Pivotal Tracker, the Project Master Schedule does not contain all activities required to complete the project nor the dependencies between all project activities. This arrangement precludes performing a valid critical path analysis, so the project no longer conducts critical path analysis.

Schedule Performance Analysis

Schedule Performance Analysis is performed beginning Monday of a non-status week (see Section 3.4.4 The Biweekly Status Update Cycle.) for tasks in MS Project. Analysis includes identification, review and monitoring of:

• Tasks forecasted to start or finish late

• Tasks scheduled to begin within seven days of the schedule review date

• Tasks requiring an update

• Finish variance days

• Planned % Complete vs. % Complete

• Finish Variance (percent and days)

All schedule reports are archived on the Schedule Management page of the project’s SharePoint site.

The Biweekly Schedule Status Update Cycle

The Project Master Schedule is updated on biweekly cycle. The cycle consists of a “status week” and a “non-status week”. Status weeks begin on Monday and runs through Friday. The schedule is published by close of business on the Friday ending a status week. The week following a status-week is called a non-status, or planning week. A non-status week is reserved for schedule planning, adding new tasks, and producing reports. See Appendix B – Master Schedule Update Process Workflow for a diagram of the process

The Schedule Manager, the Project Managers, and Scrum Masters have different duties during the biweekly status update cycle. The Scheduler sets the Status-as-of-Date for the project at the beginning of a cycle and coordinates schedule updates with the Project Managers and Scrum Masters, who are responsible for providing schedule updates.

The Project Scheduler produces an extract in MS Excel for each Project Team detailing all tasks that are active for the reporting period. This extract is called the Schedule Update Report. See Appendix C for a representative example of a Schedule Update Report.

The Schedule Status Update Report is posted to SharePoint by close of business Monday of a Status Week. Project Managers and Scrum Masters work with their teams to update the Schedule Update Report. The Schedule Update Reports should be completed by close of business Wednesday of a Status Week.

This document is stored in SharePoint as noted in Appendix A, and may be accessed by clicking on: CWDS SM Procedure 101 - Producing the Schedule Update Report 

There are two procedures used by Scrum Masters and Project Managers to update the Schedule Status Report. The main procedure is CWDS SM Procedure 102 - Completing the Schedule Update Report. It is supplemented with procedure  CWDS SM Procedure 106 – Tracking Epics in the Master Schedule, which explains how Epics are represented on, added to, and maintained on, the Project Master Schedule.
(Note: These links are temporarily for OSI internal use only)

Monitoring, Control, and Measures 

Success Criteria/Measures

Schedule will be monitored on a regular basis and schedule performance variances will be measured in order to either initiate corrective actions or initiating formal change requests. A change to the finish date of a key milestone that is 20 or more days from its baseline finish date will trigger a change request unless the Project Manager takes a corrective action (crash or fast-track) to remove the deviation. Milestones based on Epics from Pivotal Tracker may move more than 20 days as Stories are added to Epics. A Change Request for Pivotal milestones will not be required as long as the extension to the finish date of the Pivotal milestone does not impact a Release date. Success criteria will include minimization of the variances with respect to the baseline and will be measured in terms of the number of formal/informal change requests per month.

Table 6: Schedule Success Criteria

Milestone Tracking & Reporting

Milestones are events used in project management to mark specific points along a project timeline. Project milestones have been identified within the schedule to track the start or completion of specific project phases, task groups, deliverables or tasks. New milestones can be identified in the schedule as new tasks or deliverables are added to the schedule throughout the life of the Project.

The Project Master Schedule also contains milestones tied to specific State and Federal project reports, specifically the PSR and SPR. PSR Milestone flag is configured to enable filtering the schedule for all tasks listed as milestones in the monthly Project Status Report. Similarly, an SPR Milestone flag is configured to enable filtering by SPR milestone tasks.

Schedule Task Archiving

Project Schedules that are used to manage projects that span one or more years may grow to thousands of tasks, which makes navigating the schedule unwieldy and the schedule file size rather large. The current CWDS Project Master schedule is currently 47 MB, which is large for a MS Project Schedule file.

Archiving tasks is the process of pruning/deleting the detailed tasks under a completed summary task. The resulting single task must be updated to ensure the Duration, Start Date and Finish Dates match the match what those of the summary task before the detail tasks were pruned.

1. recent pruning of the CWDS Project Master Schedule of tasks completed before 1/1/2015 reduced the number of schedule tasks from 7,305 to 6,420 and reduced the file size from 46 MB to 34 MB.

Schedule Close Out

The project schedule will be closed out and archived when the full scope of the work is completed and accepted by the CWDS Project Director. In order to keep the schedule maintainable (e.g., < 2,500 tasks), a portion of the project schedule may be archived at the end of a major project lifecycle phase.

The schedule is published on the CWDS SharePoint site, Schedule Management page, on Friday of each Status Week. When a portion of the schedule has been archived the SharePoint Doc Status field will be set to “Archive”. The Doc Status of the final version of the schedule will also be set to “Archive”. 

Microsoft Project serves as the Project Master Schedule. This tool will be used to estimate duration, and sequencing of project activities, incorporate status, conduct schedule analysis, and other schedule management tasks as described in this document. The Project Schedule Manager uses MS Project to report overall project status.

Pivotal Tracker

Pivotal Tracker is used to track Sprints, Epics, Stories and Tasks for teams electing to use this platform. Project and Sprint status is reported by Scrum Masters using Pivotal Tracker.

Microsoft Excel

Microsoft Excel is used to generate the Schedule Status Update Report and the Baseline Log. In addition, Excel is used extensively to produce ad hoc schedule extracts for Management, and Project Teams.

Appendices

CWDS Schedule Management Procedures.

(Note: The above links are temporarily for OSI internal use only)

Master Schedule Update Process Workflow

Schedule Update Report

Schedule Look Ahead Report by Team