2024R1.1 - New Features

What's Different:

PowerSteering users can now save their Metric Bulk Actions. From here, the actions can be run at any time or scheduled to automatically run later.

Note: Metric Bulk Actions always respect the permissions that users have on the work items they are attempting to adjust. For example, a user will not be able to use Metric Bulk Actions to unlock Metrics on work items that they do not have the "Lock Metrics" Project Tasks permission on.

Prior to this release, Metric Bulk Actions could not be saved. Each Metric Bulk Action had to be enacted by manually going through each step of the Metric Bulk Action wizard.

The Metric Bulk Actions wizard. Prior to this release, this was the landing page when users selected Metric Bulk Actions from the Navigation Menu.

With this update, users will now be directed to the new "Metric Bulk Action Jobs" page when they select Metric Bulk Actions from the Navigation Menu.

This page lists all of the Metric Bulk Actions that have been saved to run at a later date (more on saving Metric Bulk Actions below). Each Metric Bulk Action is now referred to as a "job".

The "Metric Bulk Action Jobs" page contains the following columns:

• Metric Bulk Action Job: The name of the Metric Bulk Action job.

• Created By: The name of the user who created the Metric Bulk Action job.

• Description: A description of the Metric Bulk Action job's purpose.

• Last Run Details: Some information on the last time the Metric Bulk Action job was run. Users can select Results for information on each Metric that was updated or failed to update.

• Last Run Start: The date (mm/dd/yyyy) and time the last run of the Metric Bulk Action job started.

• Last Run End: The date (mm/dd/yyyy) and time the last run of the Metric Bulk Action job finished.

• Next Run: The date (mm/dd/yyyy) and time the Metric Bulk Action job is scheduled to run again.

Note: Columns can be removed and added by opening the "Columns" drop-down menu .

Users looking to create a new Metric Bulk Action job can do so by selecting the Create button in the top right-hand corner of the page.

This will open up the Metric Bulk Actions wizard that users may be familiar with. Prior to this release, however, creating a new Metric Bulk Action was a 4-step process.

With this update, users will notice that a new "Save & Schedule" step has been added.

The following fields can be filled out during this step:

Note: These fields are only relevant if you plan on saving the Metric Bulk Actions Job. If you select Run instead of Save, the Metric Bulk Action will run immediately and it will not be saved to the "Metric Bulk Action Jobs" page. Values in these fields will be discarded if this is the case.

• Name (required): Enter an informative name for your new Metric Bulk Action job.

• Description: Enter a description of your new Metric Bulk Action job's purpose.

• Frequency: Determine when the Metric Bulk Action job will run.

  

  • Never: The Metric Bulk Action job will be saved, but it will not have any scheduled run times in the future.

    Tip: This option should only be selected if a schedule has not been determined yet or if a temporary pause should be placed on the job.

  • Weekly: The Metric Bulk Action job will run on a weekly basis. The fields that appear can be used to specify the run schedule.

    

    • Start: Select a start date for the Metric Bulk Action job.

      Note: The job will not necessarily run on this day. This date determines when the job becomes active. It will run based on the "Every" and "On" selections below.

    • Time: Select the time of day the Metric Bulk Action job will run.

      Tip: It is best to schedule jobs to run outside of working hours. This will reduce the likelihood of users editing their Metrics during a Metric Bulk Actions job.

    • End: Select an end date for the Metric Bulk Action job.

      Note: The job will not necessarily run on this day. This date determines when the job becomes inactive. It will run based on the "Every" and "On" selections below.

    • Every: Determine the weekly interval for the Metric Bulk Action job.

      

      Example: If "2 Weeks" is selected from the "Every" menu and "Tuesday" and "Friday" are selected from the "On" menu (below), the job will run on the Tuesday and Friday of every second week. During the first week, the job will run on Tuesday and Friday. During the second week, the job will not run. During the third week, the job will run on Tuesday and Friday again. This pattern will continue until the "End" date is reached.

    • On: Determine the days of the week that the job will run on.

  • Monthly: The Metric Bulk Action job will run on a monthly basis. The fields that appear can be used to specify the run schedule.

    

    • Calendar: Determine which Calendar will be used to schedule the Metric Bulk Action job.

      Note: Administrators can create Alternative Calendars in PowerSteering.

    • Start: Select a start date for the Metric Bulk Action job.

      Note: The job will not necessarily run on this day. This date determines when the job becomes active. It will run based on the fields below.

    • Time: Select the time of day the Metric Bulk Action job will run.

      Tip: It is best to schedule jobs to run outside of working hours. This will reduce the likelihood of users editing their Metrics during a Metric Bulk Actions job.

    • End: Select an end date for the Metric Bulk Action job.

      Note: The job will not necessarily run on this day. This date determines when the job becomes inactive. It will run based on the fields below.

    • Schedule By: Determine how the schedule will search for the day to run the Metric Bulk Action job.

      

      • Fixed day of the month: A fixed date of the month will be used to identify when the job runs. This will open up drop-down menus that can be used to specify when the job will run.

        

        Example: Selecting "5" from the "Day" menu and "2 months" from the "Of every" menu will cause the Metric Bulk Action job to run on the 5^th of every second month.

      • Relative day of the month: A relative day of the week will be used to identify when the job runs. This will open up drop-down menus that can be used to specify when the job will run.

        

        Example: In the image above, the Metric Bulk Action job will run on the third Thursday of every second month.

Once the settings on the "Save & Schedule" page have been determined, the Save button must be selected.

Note: If Run is selected instead, the Metric Bulk Action job will run immediately and the job will not be saved. All of the "Save & Schedule" settings will be discarded.

Note: When a Metric Bulk Action job is scheduled, there is no way to temporarily delay it. If a user requests more time to edit a Metric before a Metric Bulk Action job occurs, it is best to wait for the job to complete and then manually edit the Metric afterward.

Tip: It might be wise to designate a specific PowerSteering administrator to create and schedule Metric Bulk Actions Jobs. Users who belong to the Admin Group have permission to edit Metrics on all work items, so this will ensure that all Metrics in the chosen Portfolio will be affected when the job runs.

Benefit:

Metric Bulk Actions exist to save PowerSteering users time and effort whenever they make uniform changes to multiple Metrics at once. However, many customers find themselves repeatedly conducting the same Metric Bulk Actions time and time again. Although it prevented users from having to make identical changes to each individual Metric at once, having to run the exact same Metric Bulk Actions over and over again is tedious in itself. Furthermore, forgetting to run a Metric Bulk Action was a costly mistake because it affected every Metric that would have been changed; failing to run a bulk lock, for example, could result in a great number of Metrics receiving edits when they were not supposed to.

With this update, PowerSteering users no longer need to repeatedly run the exact same Metric Bulk Actions; they can simply create a Metric Bulk Action job that runs on a set schedule. This will also prevent any issues that occur due to forgetting to run a Metric Bulk Action.

Example: Mary, a Financial Manager, is responsible for overseeing the Metrics of each work item in the "Digital Projects" Portfolio. Every Friday, the executive team runs reports on the total projected expenses for the portfolio, which are tracked using the "Expenses" Metric. This is why Mary uses a Metric Bulk Action to set every "Expenses" Metric as "Ready for Rollup" every Thursday evening.
Prior to this release, Mary could have forgotten to conduct this Metric Bulk Action, resulting in the executive team wondering whether or not the data was ready to be used for reports. With this update, Mary can now easily create a Metric Bulk Action job that is scheduled to lock these Metrics and set them as "Ready for Rollup" every Thursday night. Also, she can create another job that unlocks each of these Metrics and removes their "Ready for Rollup" label on Friday night so the Metrics can be edited the following week.

What's Different:

PowerSteering users can now receive reminder notifications when all of a gate's Conditions have been met and the gate is ready to be advanced. This new ability comes in the form of two new features that work in conjunction with each other: the "Gate is ready to be advanced" Alert Subscription and the "Gate Advance Reminder" agent.

Users can now subscribe to the new "Gate is ready to be advanced" Alert Subscription on a Gated Project. It can be found under the "Gate approvers" category on the Alert Subscriptions page.

Note: Alert Subscriptions under the "Gate approvers" category will only appear on Gated Projects.

Note: Administrators can set Alert Notifications by Role or users can select their own Alert Subscriptions on specific work items.

Users who are subscribed to this alert for a Gated Project will receive reminder when all of the Conditions of the current gate are satisfied. The reminders are sent out by the new "Gate Advance Reminder" agent.

When this agent runs, it will search for Gated Projects with "Active" work statuses that have completed Conditions on the current gate. Users who are subscribed to the "Gate is ready to be advanced" Alert Subscription on these Gated Projects will receive a reminder alert stating that the gate is ready to be advanced.

Tip: See the Work Status Names page to see which work statuses are considered "Active".

Tip: Users can configure the alert to be sent by email as well by enabling "Notify by email" on the Alert Subscriptions page.

Administrators can configure how the agent operates by selecting the name of the agent from the Agents page and selecting the Edit button in the top right-hand corner of the screen.

The following fields can be configured on the agent:

• Title: Select the title field to change the name of the agent task.

  Note: This will only change the name of the agent task, not the agent itself.

• Is Active: Determine whether the agent is active or not. Inactive agents will not run.

• Interval (Mins): Determine the time interval (in minutes) between runs. This means that whenever the agent runs, its next run will automatically occur again after the indicated interval.

  Note: A reminder will not necessarily be sent for the same Gated Project every time the agent runs. After sending an initial reminder for a Gated Project with completed Conditions on the current gate, the agent will not automatically send another if the gate has still not been advanced by the time the agent runs again. See "Days until follow-up reminder is sent" and "Maximum number of reminders" below for information on sending additional reminders for the same Gated Project.

  Tip: The recommended interval is 1,440 minutes (24 hours).

• Oldest Log Age (Days): Enter the number of days that the oldest logs will be saved. Runs that occurred after the indicated number of days will be removed from PowerSteering.

  Tip: Try to enter the lowest number of days possible in order to ensure that PowerSteering runs efficiently.

• Next Run Time: Click on the field to select a date and time for the agent's next run. The currently-scheduled next run will auto-populate the field.

• Expiration Date: Click on the field to select a date and time for the agent to automatically expire (turn off).

• Days until follow-up reminder is sent: Enter the number of days that will serve as an interval between the initial reminder and each follow-up reminder.

  After the initial reminder is sent when the agent first identifies a gate that is ready to advance, follow-up reminders can be sent afterward if the gate has still not been advanced and the Conditions are still satisfied. Follow-up reminders will continue to be sent until the gate is advanced or the maximum number of reminders is reached (see below).

  Note: If the "Interval (mins)" is a longer time period than this value, it will not result in multiple follow-ups being sent at once. Each run will only send one reminder per Gated Project.

• Maximum number of reminders: Determine how many reminders should be sent when a gate has still not been advanced. This includes both the initial reminder and any follow-up reminders.

  Tip: Enter "1" if you would not like follow-up reminders to be sent after the initial reminder.

Benefit:

Prior to this release, PowerSteering would only send notifications to gate approvers when gate approval was requested. A notification that alerted users when gate Conditions were satisfied did not exist. Although this might appear to be enough to many users, some actions outside of Conditions may need to be taken before gates can be advanced.

Example: Erin is in charge of creating Project Reports for each gate of a specific Gated Project. Once the gate is ready to be advanced, she runs a report to show the management team. If the management team is happy with the results, they will advance the gate.
Erin is not a gate approver, so prior to this release, she would never know when a gate was ready to be advanced. The management team would often have to reach out to her in order to request the report before they could determine whether the gate could be advanced or not.
With this update, Erin can subscribe to the "Gate is ready to be advanced" Alert Subscription on the Gated Project. If an administrator has enabled the "Gate Advance Reminder" agent to send notifications, Erin will be notified when the Conditions of the current gate are met. She can now create her report without having to be reminded by the management team.

What's Different:

PowerSteering users can now see an "EER" column on the right-hand side of their Timesheets.

"EER" stands for Estimated Effort Remaining. This column displays the remaining number of hours allocated to the selected Role on a work item after today (the day the users views the Timesheet).

Note: Keep in mind that the value reflects the amount of time assigned to the Role on the work item after the current day. This value will not change after time is entered or submitted toward the Role.

Example: Jack is assigned to the "Infrastructure Bill Press Release" as a Contributor.

A total of 72 hours have been allocated to this Role over 9 working days between July 2^nd and July 12^th, which equals 8 hours per day.

Jack views his Timesheet on July 5^th. After July 5^th is over, he will be 4 working days into the allocated time. Over these 4 days, a total of 32 allocated hours have passed (remember that 8 hours per day were assigned to the Task). So, when Jack enters "Infrastructure Bill Press Release" as a work item and "Contributor" as a Role on his Timesheet, he will see that these 32 hours have been subtracted from the total 72 hours that were originally allocated to the Role. Only 40 allocated hours remain after today.

Furthermore, Timesheet viewers can use the EER value to request a change to the remaining effort. Selecting the value itself will open up the "Estimated Effort Remaining" window, which can be used to propose a new EER.

Selecting the Request Update button will send an Inbox notification to the Owner of the work item indicating that the Timesheet viewer has proposed a change to the Estimated Effort Remaining.

Tip: If a comment has been included, viewing the email notification instead of the Inbox notification makes it easier to read it.

From here, Owners can choose to navigate to the work item and change the schedule to accommodate the recommendation.

Benefit:

Although Project Mangers do their best to schedule work and allocate effort before their Projects begin, Project schedules will often inevitably require changes over time. The original effort estimates may no longer reflect the actual remaining work as the Project progresses. As time goes on, the Resources who are assigned to these work items have the best perspective of how much more effort will be required. Encouraging Resources to propose EER changes allows for more agile Resource management by ensuring that effort is allocated effectively, avoiding overallocation and underutilization.

Example: Jack views his Timesheet at the end of his workday on July 5^th. After entering the work item (a press release) and his assigned role on the work item, he sees that his EER after today is 40 hours.

However, the press release is almost finished; he determines that he can comfortably finish it within two more work days. With this in mind, he selects the 40.00 and uses the "Estimated Effort Remaining" window to propose a new EER of 16 hours. He uses the "Comments" field to explain that he has been overallocated for the work item.

The Owner of the work item receives a notification containing the proposed EER and makes the appropriate changes to the schedule. Jack now has 24 free hours that can be allocated to other work.
Alternatively, Jack might have realized that the remaining 40 hours were not enough to finish his work. In this case, he can request a new EER that is higher than 40. When the Owner receives this request, she has the option to rework the Project schedule ahead of time before a conflict arises.

What's Different:

Gated Projects can now be configured to create new Document versions after a gate is advanced. If the Document requires approval on the gate, the new version will need to be approved before the gate can be advanced.

Prior to this release, Documents that were required Deliverables for multiple gates would not require approval during each gates. If the Document was approved for one gate, it would be approved for every other gate on the Gated Project.

"Measure" is the second gate on this Gated Project. The "Gate Summary" Document Deliverable was approved on the previous gate, so it is automatically approved on this gate as well.

Example: A "Gate Summary" Deliverable Document was added to each gate of a Gated Project. One of the Team Members on the Project is expected to complete it for every gate. Approval is required for the Document.

This automatically creates a "Required Deliverables" Condition for each gate; a gate cannot be advanced until the "Gate Summary" Document is approved.
Once the first gate ("Define") is complete, Jack (the approver) approves it.

This satisfies the "Required Deliverables" Condition on the "Define" gate, allowing the gate to be advanced.

However, once the Gated Project is advanced to the "Measure" gate, the same document has already been approved without Jack addressing it.

This is because approving a Document on one gate approves it for the entire Gated Project. Even though Jack has not approved the Document on the "Measure" gate, it is already approved and the "Required Deliverables" Condition is already satisfied on it.

However, Documents require approval once again after a new version is added. A Document is only considered "Approved" if its latest version has been approved.

With this update, Gated Projects now come with a new "Version Deliverable Documents on Gate Advance" Configuration option while editing the Gated Project's details.

Note: Users require the "Edit Controls" Project permission on the Gated Project to configure this checkbox.

When this checkbox is selected, a new version will automatically be added to the Document whenever the gate is advanced.

Note: A comment will automatically be generated for the version indicating that it was created by advancing the gate.

This means that once the gate is advanced, the "Required Deliverables" Condition will not be automatically satisfied. This requires the original Document to be approved again for the gate.

The latest version of the "Gate Summary" Document that was created during a gate advance has not been approved yet.

Note: This new feature also includes a new "Deliverable status" column in the "Documents" module.

This column indicates which gates the Document has already been approved for as well as the gates it has not. In the example above, the "Gate Summary" Document has been approved on the "Define" gate, but it requires approval on "Measure" gate. The other gates have not been reached yet, so they do not have a value in the column.

Benefit:

Prior to this update, approving a Document Deliverable on a Gated Project would approve it for the entire Gated Project. This is useful for Documents that transcend specific gates and apply to the Project as a whole. However, many customers add Document Deliverables to multiple gates with the intention of requiring the approvals on the same Document for each gate. When a single approval applies to the Document on every gate, it defeats the purpose. This new configuration option gives Project Managers the choice between both approval options based on the Document Deliverable.

Example: Imagine the "Gate Summary" Document in the examples above. This Document has been added to every gate of the Gated Project as a "Required Deliverable" because a Team Member is expected to write and upload a quick summary of how the gate progressed. The designated approver is expected to read this summary and approve it before the gate can be advanced.
Prior to this release, approving a Document on one gate would approve it for the entire Gated Project. This means that the "Gate Summary" Document that was approved in the first gate would not require approval in order for any more gates to be advanced. The only workaround was to add another version to the Document as soon as the previous gate was advanced so it would once again require approval.
With this update, Document versions can be configured to appear on their own as soon as the gate is advanced. This means that the "Gated Summary" Document will require approval on any other gates it has been attached to before those gates can be advanced. The gate cannot be advanced until the approver reads and addresses the "Gated Summary" Document on each gate.

What's Different:

By default, non-admin PowerSteering users will no longer be allowed to act as proxy users for PowerSteering administrators. This can be overturned for specific users by contacting your PowerSteering representative.

Prior to this release, users could always impersonate administrators if they were added as a proxy for an administrator. This gave the user full administrative permissions while acting as a proxy.

With this update, this ability has been limited. PowerSteering users will no longer be able to proxy as administrators by default. If a user has been added as a proxy for a user in the Admin Group, the administrator's name will be grayed-out when the user attempts to act as a proxy for them.

However, certain users can still be given permission to act as proxies for admin users. Customers can reach out to their PowerSteering representative to add specific individuals to a list of trusted users that are allowed to act as proxies for users in the Admin Group.

Benefit:

The main purpose of PowerSteering permissions is to prevent users from making significant changes to the application that could potentially cause harm or disorganization. The Admin Group is only supposed to consist of users who can be trusted with this responsibility. Although proxying will sometimes give certain users permissions they would not have otherwise, regular users should not be given the option to inherit administrator permissions. Regular users with administrator permissions may intentionally or unintentionally cause configuration mishaps that can affect the organization as a whole.

Action Required:

When PowerSteering 2024R1.1 is released, regular users will no longer be able to proxy as administrators right away. Administrator names will be grayed-out when a regular user attempts to proxy as one of them. However, certain regular users can be granted this permission upon request. If there are any regular users that you would like to give this ability to, reach out to your PowerSteering representative. Only the indicated users will be able to act as proxy users for administrators going forward.