APM 1.9 Release Notes
Summary
Version | Key Changes | Prior Release |
|---|---|---|
1.9 | 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. | |
Self-Guided Walk-Thru' | Click here to interactively explore the changes in this release! | |
Highlights | Table of Contents | |
download |  | |
New Features
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
Note:
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 | |
 The timeline strip can be collapsed (see top right) | |
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 |  RBDs are always visible in timeline charts |
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 | Change Reasons | 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
Normal view,
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.
In Setup,
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 |
 Scheduling a Draft project |  The Candidate schedule is in grey, with the current or Baseline shown in saddle brown |
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 |
 The manager has moved the FMEA task out a month, |  in this example, the project was rescheduled from the original Baseline |
Improvements
Improved Messaging
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.
Fixes
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 |
Known Issues
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 |