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.	APM 1.8 Release Notes
Self-Guided Walk-Thru'	Click here to interactively explore the changes in this release!
Highlights		Table of Contents
download Actify APM 1.9 Release Highlights revB.pdf

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
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	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

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

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.

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.