The SRDP Schedule is maintained in Microsoft Project and includes activity assignments within the project office, tasks assigned within DMS, and external milestones critical to activities in the schedule.  This brief description explains some methodology and interpretive keys to better understand the schedule composition and tracking mechanism.

Most scheduled activities are assigned to a Jira issue.  Implementation activities are structured to reflect intermediate milestones, primarily within DMS.  These milestones are in bold, treated as roll up tasks (epics within jira) and map to Technical Use Cases in the L1 Requirements.  Test activities are mapped to the architectural model and also to the associated implementation activity.  All related tasks are assigned as children under the associated epic.  These are ultimately realized in a release as delivered features and capabilities.  A schedule baseline is established against these project milestones, upon agreement between DMS, the Project Office, and any other stakeholders of interest.  Most activities and tasks are tracked in Jira under the appropriate epic, with issue numbers carried back to the schedule and aligned with corresponding tasks.

• Gantt Chart – Scheduled task are displayed in the Gantt Chart as either a milestone (diamond, down arrow for baselined milestones) or a duration (bar).  The milestones are either complete or not, Progress for milestones is not reflected in the Gantt.  Tasks with duration show progress with a shading in the bar to reflect % complete

Progress is logged against the Jira workflow status in 25% increments as follows:

0%   Not started

25%  Scheduled (Should be recording comments in the ticket at this point)

50%  Under verification

100% Under Validation

The Gantt chart displays % completion as darker shading within the bar

Actuals against Baseline

The SRDP project is delivering capability over a ~5 year roadmap, with releases on an annual cadence.   For each release cycle (or planning wave), the project office will establish deliverables and the timeline for delivery.  Once the project office, DMS, and other stakeholders approve milestones for the subsequent wave, the agreement is captured as the working baseline.  Regular reporting to the Observatory Director’s office is against the baseline.  The baseline appears in the schedule in a variety of ways:

• Baseline Date Columns – The columns “Baseline Start” and “Baseline Finish” represent the starting duration for each task or activity.  If a baseline finish date is missed, a new target completion date is established and entered in the Finish Date column
• Start and Finish Date Columns -  represent (or are close to) the actual dates of the task duration.  The delta between the baseline and actuals illustrates a lead or lag in task completion
• Activities that are past due are highlighted in yellow
• Gantt Chart – baseline artifacts are shown in a different color and the displacement in the Gantt serves as a visual marker to illustrate actuals against the plan

Changes to scope

Scope for the current release cycle is established during the requirements decomposition and wave planning.  Any changes to baselined scope for the immediate planning horizon (i.e. prior to a wave release) must be approved by the Project Director.  Once approved, scope is captured in the project baseline and reflected in the schedule as described above.  Changes to scope are as follows:

• Scope Reduction - descoped items are discussed, approved, and recorded in the project decision log (Confluence page).  These are usually traded against schedule delays, displacement by newly discovered work, or resource constraints.  These changes are not intended to descope the overall project capabilities, but to allow some natural breathing room for course corrections.  Items descoped from the current planning horizon are marked as inactive tasks and appear (in MS Proj.) in shaded gray font with a strikethrough.  These tasks return to the backlog for consideration in subsequent wave planning.
• Scope Increase – Increases to scope come from newly discovered work, additional features approved since the baseline was established, and other work approved by the project director.  These tasks are also reflected in the schedule and can be readily identified by the absence of any associated baseline artifact.
• Scope changes mentioned above are managed within the overall project scope.  Changes that impact the project scope must be approved by the NRAO Change Control Board