This release provides a configurable way for managers to define program-level Required by Dates (RBDs), viewable at program and project levels as well as a unique Dual View mode for evaluating what-if schedule changes before applying them to the Active project.
Click here to interactively explore the changes in this release!
Table of Contents
Required By Dates (RBDs)
Managers can configurable define up to 10 Required By Dates (RBDs) at the program level, which are then visible in the timeline strip in the Program Dashboard and within the Timeline views for each of the Projects in that program. RBDs carry a date, can be marked as either Hard or Soft and given both a short display label and longer description. Changes to (Active project) RBDs are logged with a reason code.
Hard Line: shown solid red in the program timeline strip and as a solid red line in timeline charts
Soft Line: shown with a red outline in the program timeline strip and as a dotted red line in timeline charts
Up to a maximum of 10 RBDs can be defined.
RBD Labels must be 5 characters or less
Each RBD date must be unique (no coincident RBDs)
Program Dashboard - timeline strip with RBDs
Setting Up RBDs, via Program Setup
RBDs on the Program Dashboard timeline strip
On the Program Dashboard - click SETUP
Exit Setup using the Grid View button
RBD Change Reasons
After an RBD has been created, changes to it (for an Active project) generate a prompt for a Reason to capture why it was changed. Users can also provide an optional Note or comment.
The valid Change Reasons can be adjusted using Configure.
RBD Change Reason prompt
Adjusting Change Reason List (via Accelerate > Configure > Lists > Required By Date Change Reason)
Dual View Timelines
The Timeline views provide a dual view compare function so that 2 “versions” of the schedule can viewed at the same time.
The dual view appears as a thinner task bar (or compare strip) below each Task, in a contrast color - if/when Phases have been expanded
In the normal (Project) Timeline view, team members can compare the currently Active Project schedule against the Baseline schedule (shown in saddle brown). The Baseline schedule is the schedule that was established when the project was first made Active - i.e., the schedule that the team members began with.
if a manager is editing an Active Project, the dual view compares the currently being-edited schedule with the Active plan (shown in dark green) - i.e., with the plan the team is currently working to
If the manager is editing a Draft state project, the dual view shows the currently being-edited or developed schedule against the last schedule defined if any, in saddle brown. (There is no Active schedule for a Draft project)
for example: a user can plan the project forward, then evaluate a Reschedule of the plan backwards, and compare them
Note that if the current edit/reschedule is not saved, the baseline-color plan will become the Baseline for the project when is made Active.
If the current edited view (grey) is saved, it becomes the “brown” one and will then be the Baseline when the project is made Active, if no further schedule edits/changes are made.
The examples below illustrates the Dual View as a project moves through its lifecycle”
In a DRAFT State Project
DRAFT State project (in Project Setup)
Generating the schedule - Forwards or Backwards
Comparing a Candidate schedule against the current Baseline
In an ACTIVE State Project
ACTIVE State project
Manager or editor view from Project Setup
Normal or team member view from the Project Dashboard
Comparing the What-If schedule with the currently ACTIVE Schedule
The Active schedule is show in dark green
Comparing the ACTIVE schedule with the Baseline
The Baseline schedule (when the project was initially made Active) is shown in saddle brown
Message content generation has been refined to reduce email noise and improve clarity.
Emails are consolidated and sent out when Projects are made Active and thereafter on significant changes to the Active project
Notification emails include the Program and Project context and clickable links to them, in addition to the specific notification content or link, for example in an Approval notice.
Key Fixes in this release are below. A detailed list is available on request.
Key Fixes in this release
Visualize: Intermittent failure-to-load in Visualize for some items.
Project Setup: Extending the Target Finish date later for Tasks with very large durations (> 730 days) could result in the duration being updated incorrectly
Key Known Issues with this release are below. A detailed list is available on request.
Note: A screen refresh or repeating the action after a refresh is often a successful workaround for apparent issues.
Key Known Issues in this release
Project-Timing view: Long task names are not always truncated properly in Timing view left panel