2024R1.2 - New Features

Below is a summary of the new additions to PowerSteering in the 2024R1.2 release. PowerSteering 2024R1.2 is set to be deployed to the staging site on November 13^th, 2024 and deployed to the production site on December 8^th, 2024. When this happens, the listed features will become available.

Note: This page will be updated as new functionality becomes available.

The following key features will be made available with the 2024R1.2 PowerSteering release:

New Approve gate advances and extend report subscriptions through PowerSteering emails

What's Different:

PowerSteering email recipients now have the ability to interact and make changes to PowerSteering directly from the emails they receive from the application.

The following actions can now be carried out through emails:

Approve gate advances
Extend report subscriptions

Approve gate advances

Once gate approval is requested on a Gated Project, each designated Gate Approver will now be able to approve the request directly from the notification email.

Note: See Phase Advancement Configuration for information on which users can request approval on Gated Projects.

Along with the name of the Project, the current gate, and the next gate, the email now also contains an Approve button and a Reject button, as well as a textbox to include a comment.

Note: If your organization is a Microsoft 365 tenant, the email will match this formatting. Users that are not tenants will see this email in plain text instead. If your organization is a tenant but you are not seeing this formatting, contact your PowerSteering representative.
Please be aware that non-tenants will not be able to include comments with their approval or rejection.

Note: The message at the bottom of the email indicates when the gate can no longer be approved or rejected directly from the email. Speak to your PowerSteering representative if you would like to customize this time limit.

The approver can either approve or reject the gate advance request directly from the email without actually logging into PowerSteering.

Example: The "Digital Five Phase Plan" Gated Project is currently on the "Define" gate. All of its Pre-Advance Conditions have been met, and it is time to advance the Project to its "Measure" gate.

Stephanie is not one of the designated Gate Approvers, so she selects the Request Approval button.

Jack is the only designated approver for the "Define" gate. He receives the "Awaiting Approval or Rejection of Gate" email.

He writes a comment in the text box and selects the Approve button.

Jack was the only designated approver for the "Define" gate, so the Gated Project will automatically advance to the next stage upon his approval. Stephanie finds that the "Digital Infrastructure Five Phase Plan" Project has been advanced to the "Measure" gate when she revisits the Project in PowerSteering.

When Stephanie visits the Gated Project's History page, she sees that an "Approval Action" event has been created for the approval. Jack's comment is included in the event.

Extend report subscriptions

PowerSteering users can now extend their report subscriptions directly from the "set to expire" email.

Report creators receive the "set to expire" email when the end date of a subscribed report arrives. Prior to this release, the "set to expire" email would contain a link to a PowerSteering page that allowed the report creator to change the report's end date.

With this update, the creator can now update the report's end date directly from the email itself.

Selecting the Extend button will automatically push back the end date by an amount of time that depends on the report's "Frequency" selection.

Note: A report's "Frequency" can be seen on the Edit Details & Schedule page.

Daily: The end date will be extended by 3 months.
Weekly: The end date will be extended by 6 months.
Monthly: The end date will be extended by 12 months (1 full year).

When the report's end date is extended, it will continue to be sent out to each email address listed under the orange text.

Alternatively, the recipient can select the Open Report Definition button to open the report's Edit Details & Schedule page in a web browser.

Benefit:

Prior to this upgrade, gate approvers and report creators who received email notifications would have to log into PowerSteering to address them. Although the emails provided links, these users were still required to navigate away from their email applications and onto a web browser. This tedious process was especially irritating for users who received a large number of gate approval requests and expiring report notices at once; they would constantly have to open up new browser tabs in order to take action.

Email actions allow users to quickly address items without logging into PowerSteering, making it more likely that they will promptly respond and less likely that they will procrastinate and forget. Additionally, users can often access emails from mobile devices, which means this is especially helpful for people who are away from their workstations but would still like to take actions in PowerSteering.

In the case of gate approvals, many designated approvers are often managers or executives that are responsible for many Projects and initiatives at once. Prior to this upgrade, responding to gate approval requests via email required them to repeatedly select the link to open the Gated Project in a web browser, approve or reject the request, and repeat the process over again for the next Gated Project. Quick actions allow them to easily approve or deny each gate advance request with a single click.

In the case of expiring reports, report creators find it tiresome to repeatedly edit the settings of their reports whenever they are set to expire. Some users have requested the ability to omit report end dates, but this would unfortunately lead to reduced application performance and orphaned data. Instead, report creators can now easily keep their reports active by selecting the email's Extend button.

New Prevent users from being assigned to Roles outside of their Profile Roles

What's Different:

PowerSteering can now restrict users to only be assigned to Roles that are listed on their Profile.

Note: This feature must be enabled by PowerSteering. Please reach out to your PowerSteering representative if you are interested.

Note: Users that are assigned to work items are often referred to as "Resources".

Tip: Roles can be designated to users by editing their User Profiles.

This was only partially enforced prior to this release. When a Resource was assigned to a work item, only the Roles configured on the Resource's User Profile could be selected. For example, have a look at the Roles configured to Jackson O'Reilly's User Profile:

Cindy, Jackson's Project Manager, is currently using Project Central to assign Resources to her Project. After she uses the "Assignment" column to assign Jackson to a work item, she can use the "Role" column to assign a Role for him.

Notice that the only Roles available are Roles that have been configured to Jackson's Profile.

Note: Only 4 of the 6 Roles are available because the other 2 Roles on his Profile (Executive Sponsor and Financial Rep) are not available on the Object Type of the work item he is being assigned to. See Roles Associated with an Object Type for more information.

Prior to this release, however, Cindy could work around this if she selected the "Role" first. If she wanted Jackson to be a Developer on this Project, she could clear Jackson from the "Assignment" column and select "Developer" from the Role column.

This would not restrict her from selecting Jackson from the "Assignments" column, which means she could assign him to a Role that was not on his Profile.

Additionally, the "Edit Team Members" window on the Summary Page could be used to add a user to the work item under any Role that was allowed on the work item's Object Type. Users could be added as Roles that were not configured on their Profiles.

With this update, PowerSteering can prevent both of these workarounds and enforce users to be added to work items under their Profile Roles only. If a Project Manager attempts to use Project Central to assign a Resource as a Role that is not configured to the Resource's user profile, the Resource will not be loaded into the "Assignment" column and an error message will appear.

If the Project Manager attempts to use the "Edit Team Members" window to do the same thing, the Resource will not be added to the work item and the same error message will appear.

Note: As part of this enhancement, the "Role" column on Timesheets can be limited to Profile Roles as well. Speak to your PowerSteering representative if you are interested.

Benefit:

The purpose of Profile Roles is to define the type of work certain PowerSteering Resources should be doing. When Resources are assigned to work within their specific Roles, they are more likely to understand their responsibilities. They can focus on the functions of these familiar Roles without having to deal with any confusion, leading to greater productivity and more efficient workflows.

Additionally, Role restrictions can result in enhanced PowerSteering security. PowerSteering work items can define permissions by Role. If certain users are accidentally assigned to Roles on work items that are not defined on their User Profiles, they may be able to access sensitive information that was only meant for other PowerSteering users. Also, users without sufficient training or knowledge in these Roles could inadvertently alter settings, delete data, or perform actions that disrupt work. Restricting assignments to Profile Roles ensures that users are only able to access and interact with the components of PowerSteering that are meant for them.

New Automatically reactivate past gates when Pre-Advance Conditions are no longer met using the Re-activate Gate Agent

What's Different:

The new Re-activate Gate Agent is now available in PowerSteering.

Note: Only PowerSteering administrators can edit PowerSteering Agents.

When enabled, this agent will automatically re-activate past gates when the Pre-Advance Conditions of those gates are no longer satisfied. It will search for Gated Projects of specific Gated Project Templates (defined by the parameters, more information below) and re-activate their past gates if any of those gates contain Pre-Advance Conditions that are not met.

Note: If the Gated Project has more than one past gate with unsatisfied Conditions, the earliest gate will be re-activated.

Example: This Gated Project is currently on the "Execute" gate. When the previous gate, "Scope & Accept", is selected, we can see that all of the Pre-Advance Conditions have been met.

However, imagine the Resource that is assigned to the "Finance" Role is removed from the Project without a replacement. This causes the "Role is staffed : Finance" Condition to be unsatisfied.

If the template used to create this Gated Project is identified in the agent's parameters, the "Scope & Accept" gate will automatically be re-activated once the agent runs again.

Administrators can configure the agent's settings by editing the agent's details.

Agent Task Name: Rename the agent task.
Is Active: Determine whether the agent is currently running or not.

Note: This new agent will be disabled by default.
Interval: Determine how often the task will run in minutes. For example, entering "1440" will cause the task to search for work to start every 1440 minutes (24 hours).
Oldest Log Age (Days): Determine how long log entries will be retained for.

Tip: See View Details of an Agent Task for information on viewing agent log entries.
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).
Completed projects in the last days: Gated Projects that have been completed for longer than the specified number of days will be ignored by the agent.

Note: The default value is 180 days.
Gated Project Templates: Use the drop-down menu to select which Gated Project Templates the agent will search for while determining which gates to re-activate.

Tip: A work item's template can be identified by navigating to the work's Summary page and scrolling your cursor over the icon next to the title in the blue banner.

Benefit:

Pre-Advance Conditions are a great way to ensure that a gate is ready to be advanced. However, certain Conditions can become unsatisfied as a Gated Project progresses. When this occurred prior to this upgrade, there was no way for users to be aware of this; Project Managers would have to find out about the unsatisfied Condition themselves, check the previous gate to confirm, and then (if necessary) re-activate the gate. With this update, PowerSteering users now have the option to automate this tedious process. If the future of the Gated Project relies on past Conditions remaining satisfied, certain Gated Projects can automatically be re-activated so users can reevaluate these Conditions, ensure the Gate is complete, and advance again when necessary.

New Automatically advance related Gated Projects during gate advance

What's Different:

Users advancing Gated Projects will now have the option to simultaneously advance the gates of Related Work that is currently on the same gate. After the Advance button is pressed, Gated Projects can be configured to allow users to advance the gates of related Gated Projects as well on the "Advance" window.

Note: The Gated Project's Related Work will only appear in the list if the same Gated Project Template was used to create it and it is currently on the same gate. Also, only Gated Projects that the user has permission to advance will appear in the window. If the user does not have permission to advance the Gated Project, it will not be listed.

Users can select the checkboxes of the Related Work they would like to advance as well.

Selecting the Advance button will advance the gate of the current Gated Project as well as all of the selected related ones.

A report on each Related Work included in the gate advance will immediately appear.

Note: Gated Projects that were listed are expected to successfully advance if selected. Failures are most likely due to a recent change in data (i.e. one of the Gated Project's Pre-Advance Conditions was no longer satisfied after the window was opened).

Before this option can be used, an administrator will need to enable it on the Gated Project's Object Type while updating the Object Type's settings. The new "Advance Related Works" checkbox will need to be selected.

Note: Only PowerSteering administrators can edit PowerSteering Object Types.

Once this is enabled, users will need to enable it on the Gated Project itself by selecting the new "Advance Related Works" checkbox while editing the Gated Project's configuration settings.

Benefit:

Many Project Managers are responsible for a large number of Gated Projects at once. This makes it extremely difficult to visit and advance each one of them when the times comes to advance similar Gated Projects. With this upgrade, Project Managers no longer need to tediously visit the Summary pages of each of their Gated Projects at once; they simply need to ensure that they are related in order to advance them all at the same time.

This is especially beneficial when used with Pre-Advance Conditions. Many Project Managers might be hesitant to advance many Gated Projects at once without reviewing them. However, setting up Pre-Advance Conditions help ensure that the gates have been properly completed before they are advanced. Related Gated Projects without satisfied Pre-Advance Conditions will not appear in the list, so as long as Project Managers trust their Conditions, they can confidently automate this process.

Improved Dynamic Field Management visibility and mandatory rules now applied to work item creation

What's Different:

Dynamic Field Management settings for Tags and Custom Fields will now be respected during the creation process in PowerSteering. In particular, certain Tags and Custom Fields can now be configured to appear or become mandatory based on the selections of other Tags and Custom Fields.

Note: Users will require the "Create Root Work" Context permission to create work items in PowerSteering.

Prior to this release, Tags and Custom Fields could still generally be hidden or made mandatory on the creation screen. However, administrators could not configure them to appear based on the selections from other Tags and Custom Fields during the creation process. These particular Field Management visibility settings were only applied while viewing or editing the work item itself after it was created. For example, if Field Management was used to hide a certain Custom Field unless a specific value was selected on a Tag, the Tag would not appear on the "Custom Fields &Tags" page or the creation wizard.

With this update, these rules will now be applied while users create new work. For example, administrators can create a visibility rule that only displays a textbox when "Other" is selected from a Tag.

If "Other" is not selected, the textbox will be hidden.

If "Other" is selected, however, the textbox will be displayed.

Note: Administrators must use the Formula Builder to create dynamic rules for Tags and Custom Fields. If you are not familiar with the Formula Builder, reach out to a PowerSteering representative for guidance.

Benefit:

PowerSteering enables administrators to customize the dependencies that determine how Tags and Custom Fields appear and behave in the application. Prior to this update, however, there was no way to apply these dynamic dependencies to the work item creation process. This often caused confusion because the Tags and Custom Fields that remained hidden did not have any values once the work item was created.

Example: While configuring the Field Management settings for the "Construction Project" object type, Cristina adds a required "Funding Type" Tag that must be used to indicate the Project's funding source. One of the selectable values of this Tag is "Other". Cristina always wants the funding source to be identified on Projects, so she configures a required "Alternate Funding Method" Custom Field textbox to only appear if "Other" is selected.

This way, users can manually type in the source of funding if it is not one of the selectable options from the "Funding Type" Tag.
When Jennifer creates a new Project with this template, she selects "Other" from the "Funding Type" Tag. Prior to this release, the "Custom Fields & Tags" portion of the creation wizard was not able to implement this dynamic visibility rule. It could only identify that the "Alternate Funding Method" was set to be initially hidden; it could not make it appear once "Other" was selected.

Once she finished creating the Project, an error immediately appeared because the required field that was supposed to be displayed did not contain any text.

With this update, the dynamic visibility rule will be applied during creation. This means that Jennifer will be able to address the "Alternate Funding Method" Custom Field within the creation wizard if "Other" is selected from the "Funding Type" Tag.

Improved Automatically advance Gated Projects if all Pre-Advance Conditions are met using the Gate Advance Agent

What's Different:

The Gate Advance Reminder Agent has been renamed to the Gate Advance Agent by default. With this new name, the agent can now automatically advance certain Gated Projects if the current gate's Pre-Advance Conditions have been met.

Note: Only PowerSteering administrators can edit PowerSteering Agents.

Prior to this release, the Gate Advance Reminder Agent's only job was to send out reminder notifications whenever a current gate's Pre-Advance Conditions were met and the gate was ready to be advanced. Administrators could configure two parameters on the agent to determine how these reminders behaved.

With this update, both of these parameters will still control how the agent sends gate advance reminders. However, three new parameters have been added. These will determine how the agent will automatically advance the current gates of specific Gated Projects.

Advance gate automatically: Select this checkbox to enable the agent to automatically advance gates when their Pre-Advance Conditions are met. Whenever the agent runs, it will search for Gated Projects with satisfied Pre-Advance Conditions and automatically advance them if they meet the criteria of the other two parameters (below).

Note: This checkbox will be unselected by default.

Note: See Gate Advance Agent for information on determining how often the agent runs.
Auto-advance Gated Project Templates: Use the drop-down menu to select which Gated Project Templates the agent will search for while determining which gates to advance. Gated Projects that were created with the selected templates will be advanced if their current gate's Pre-Advance Conditions are met.
Do not advance gates requiring approval: Select this checkbox to exclude any gates from being advanced if they require approval. If this checkbox is not selected, gates will automatically be advanced even if one or more approvers have not yet approved the gate.

Tip: Be careful disabling this parameter. Many Gate Approvers prefer to review their gates before they allow them to be advanced.

Note: When the agent automatically advances a gate, an event will be logged on the Gated Project's History page.

Note: Users who are subscribed to the "Approval Action" Alert Subscription on the Gated Project will receive a notification when the agent automatically advances the gate.

Benefit:

Prior to this upgrade, users had to select the Advance button whenever it was time to advance a gate. This can be a problem because individuals would often forget to advance the gate themselves, which would lead to Gated Projects moving along slower than they needed to. However, many users still prefer to review Gated Projects themselves before advancing. To satisfy both of these scenarios, administrators can now use the Gate Advance Agent to move certain Gated Projects along without any users selecting the Advance button.

The following enhancements will also be available with the 2024R1.2 release:

Agents

New Email parameters added to the Delete Old Users agent

What's Different:

Administrators can now configure email parameters for the Delete Old Users agent.

With this update, a new "Email Parameters" section of fields is available while editing the agent.

Tip: HTML elements (such as <p>, <strong>, and <i> in the example above) can be used to format the text.

The following tokens can be entered into the email header, body, or footer in order to be replaced by PowerSteering data:

<% BASE_URL %>: A link to the PowerSteering site.
<% HELP_LINK %>: A link to the PowerSteering online help site.
<% COMPANY_NAME %>: The name of the organization.
<% COMPANY_NAME_HTML %>: The name of the organization represented by an HTML string equivalent. Use this option for HTML emails.

Tip: Administrators who wish to return to the default header, footer, and body can select the new Reset button at the bottom of the page.

Benefit:

Email parameters were recently added to the Signup Reminder agent as part of the 2024R1.1 release. This gave administrators the ability to customize the agent's emails and properly tailor them to their unique organizational needs. With this in mind, the next logical step was to implement these parameters into the Delete Old Users agent as well.

API

New GET endpoint for retrieving Measure values by Measure Templates

What's Different:

A new GET endpoint has been added to the Measure service of the PowerSteering REST API. This new endpoint can be used to retrieve current Measure values by Measure Templates; only Measures that were created with the identified Measure Template will be included.

Note: PowerSteering users require the "REST API - Read" Context permission to hit "GET" endpoints.

Caution: Please be aware that API permissions are not restricted by other PowerSteering permissions. For example, a user with the "REST API - Read" permission will be able to successfully hit any GET endpoints even if they do not have permission to view certain work items.

The endpoint is as follows:

GET <http://<host>/<context>/rest/measureservice/v1/measuretemplate/{measure template id}/measurevalues>

Note: A Measure Template's ID can be found by hitting the GET <http://<host>/<context>/rest/measureservice/v1/measuretemplates> endpoint.

Alternatively, it can be found in the URL after the "U" while editing a Measure Template.

The following request parameters can be included:

templateId (required): The 26-digit ID number of the Measure Template.
modifiedSince: Only Measures that have been modified since the indicated date (formatted yyyy-mm-dd) will be included in the response. If no date is provided, values that have been modified since January 1^st, 2000 will be included.
start: Indicate which result the list should start with. For example, including "start=2" will start the list of Measures with the second result in the list. The first result will be excluded.
count: Indicate how many Measures should be returned in the response. For example, including "count=4" will only include the first 4 Measures in the list (unless a "start" value was also included).

includeProjectDetails: Determine whether the response will include details on the work item that the Measure is attached to. Including "includeProjectDetails=true" will include the 26-digit ID number, the name, and a GET endpoint of the work item.
includeMeasureDetails: Determine whether the response will include details on the Measure itself. Including "includeMeasureDetails=true" will include the 26-digit ID number, the name, and a GET endpoint of the Measure.

Benefit:

The "modifiedSince" request parameter can be used to filter out older changes to Measure values that may not be relevant. For instance, users who are only looking for Measures that received new values in the past week can now enter the first day of the week in the parameter.

Improved Additional response attributes for the last time data or locks were changed on a Metric or a Metric View

What's Different:

Both the "Metric" and the "Metric View" API object types have been updated with new attributes that retrieve data about when specific Metric information was changed. This data includes numeric values, numeric locks, Tag and Custom Field values, Tag and Custom Field locks, and Comments.

Note: PowerSteering users require the "REST API - Read" Context permission to hit "GET" endpoints.

Note: Do not confuse API object types for PowerSteering Object Types.

Prior to this release, the "Metric" API object type contained a "lastChangeDate" attribute that would return the date the Metric was last edited.

The "Metric View" API object type did not contain this attribute.

With this update, the "Metric" and the "Metric View" API object types now contain new attributes that expose data on the last time Metrics and Metric Views were changed.

lastChangeDateNumbers: The date when the Metric's numeric values were last edited.
lastChangeDateLocks: The date when the Metric's numeric value lock settings were last edited.
lastChangeDateFields: The date when the Metric's Tag and/or Custom Field values were last edited.
lastChangeDateFieldLocks: The date when the Metric's Tag and/or Custom Field lock settings were last edited.
lastComments: The last Comment left on the Metric.
lastCommentsDate: The date when the last Comment was left on the Metric.
lastCommentsUpdater: The user who left the last Comment on the Metric.

lastChangeDateNumbers: The date when the Metric View's numeric values were last edited.
lastChangeDateLocks: The date when the Metric View's numeric value lock settings were last edited.

Benefit:

Prior to this release, GET API endpoints for Metrics could only retrieve a single date that indicated when the Metric as a whole was last edited. Although this may have been helpful for some, it was too general. Metrics have too many components for a single, all-encompassing attribute to cover. With this update, the PowerSteering REST API can now be used to report on when each component of a Metric was changed.

Improved Exclude archived and deleted work items from Measure-related GET endpoints

What's Different:

While using GET endpoints to retrieve Measure data with the REST API, users can decide to include or exclude data from archived, deleted, and/or current work items. A new "exclude" request parameter can now be used to filter the work items.

Note: PowerSteering users require the "REST API - Read" Context permission to hit "GET" endpoints.

This parameter has three possible values.

Note: Multiple comma-separated values can be included at once.

CURR: Currently active (not archived nor deleted) work items will be excluded from the results.
ARCV: Archived work items will be excluded from the results.
DLTD: Deleted work items will be excluded from the results.

This parameter can be used in the following endpoint from the Measure service:

GET <http://<host>/<context>/rest/measureservice/v1/measuretemplate/{templateId}/measures

It can also be used in the following endpoint from the Project service:

GET <http://<host>/<context>/rest/projectservice/v1/project/{projectId}/measures

Example: Samantha wants to retrieve a list of "Project Estimates MONETARY" Measures on different work items through the API. She decided to use the GET.../measuretemplate/1a236pg0000oljggmrmg000000/measures endpoint to retrieve these Measures, but she quickly realizes that this endpoint retrieved a list of this Measure on archived and deleted work items as well as current ones. To fix this, she uses the "exclude" parameter to remove work items that are archived or deleted. Her new endpoint becomes GET.../measuretemplate/1a236pg0000oljggmrmg000000/measures?exclude=ARCV,DLTD

Benefit:

Filtering out archived and deleted work items ensures that the API response will only contain Measures from relevant, ongoing work items that still require attention. It also reduces clutter by minimizes the volume of results returned, making it quicker for users find the Measures they are actually looking for. Additionally, it avoids confusion that might arise when users are not aware of a work item's status. They might mistake an archived or deleted work item for an active one, which could lead to the use of irrelevant data.

Dashboard

Improved Display Scorecard Metric labels on Dashboards

What's Different:

PowerSteering administrators now have the option to configure Dashboard Layouts to display Scorecard Metric labels instead of static Discrete Values.

While creating Scorecard Metric Templates, administrators can use the "Static/Constraint Values" tab to add drop-down menus to the Metric's line items (rows). For each line item, the administrator can add Discrete Values (aka "scores") and associate a value with each one.

In this example, the "Complexity" line item will contain a drop-down menu with three options that have associated scores. For instance, if a user selects the "Small Team" value, it will result in a "Complexity" score of 50.

On Scorecard Metrics themselves, the drop-down menus always display labels instead of their associated values.

Prior to this release, administrators could not determine how Scorecard Metric values would appear on Dashboards while configuring special columns on Dashboard Layouts. The Discrete Value (score) would always be displayed on the Dashboard.

With this update, administrators can now configure a "Display" field while adding Metric columns to Dashboard Layouts.

This drop-down menu offers three options for displaying Scorecard Metric values on the Dashboard.

Value: Only the Discrete Value (score) for the Metric line item will be displayed.

Note: This is what was displayed prior to this release.
Value & Label: Both the Discrete Value (score) and its associated label will be displayed.
Label: Only the associated label will be displayed.

Tip: When this is selected, users can scroll their cursors over a label to see its Discrete Value.

Benefit:

The purpose of adding drop-down menus to Scorecard Metrics is to associate understandable terminology to each available score. For example, it may be difficult for a Scorecard Metric user to rate a Project's "Complexity" score on a scale of 1-100. However, it is much easier for her to evaluate the "Complexity" score when she can select one of the available plain language options:

With this upgrade, Dashboard viewers can read these plain language evaluation criteria instead of the Discrete Values. This gives them a better understanding of these scores and what they mean in the context of the work item and the organization as a whole.

Metrics

Improved Expanded / collapsed Metric row preferences saved per user

What's Different:

The expanded / collapsed state of Metric rows will now be preserved for each user on each Metric Template. This means that when a user expands or collapses a Tag Breakdown on a Metric row, the state of that row will be saved when the user leaves and revisits the page. When the user visits the same Metric on another work item, the same rows will be expanded and collapsed.

Note: "The same Metric on another work item" refers to a Metric Template that was applied to multiple work items. For example, if Juan expands the "Funding" row on a work item's "Expenses" Metric, the same row will be expanded when he visits the "Expenses" Metric on another work item.

Note: See Basic Info Metric Tab for information on adding Tag Breakdowns to Metric Templates. See Enter Data for a Metric with Tag Beneficiaries for information on navigating Metrics with Tag Breakdowns.

Prior to this release, expandable Metric rows were always collapsed whenever a user opened a Metric. Any rows the user expanded would not remain expanded when the user revisited the Metric.

Click thumbnail to play. Notice how the Metric rows used to collapse again once the page was refreshed.

With this update, the expanded rows will remain expanded when the user leaves and revisits the page.

Click thumbnail to play. Notice how the expanded Metric rows remain expanded once the page is refreshed.

Benefit:

Many PowerSteering users prefer their Metric rows to be expanded. When rows are collapsed, it becomes more likely that the Metric viewer will accidentally miss out on key Metric data. Prior to this release, these users would have to expand these rows each time they visited a Metric. This needlessly wasted time and effort, which could interrupt the user's train of thought. With this upgrade, users only need to set these preferences once; they will no longer need to expand their Metric rows every time they navigate to the same Metric.

Portfolios

New Configure the "My Projects" Portfolio for other users with Portfolio templates

What's Different:

Administrators can now use Portfolio templates to customize how the "My Projects" Portfolios of other users will appear in PowerSteering.

Note: Users require the new "Portfolio Administration" Context permission to both view and edit these templates. For more information on this new permission, see below.

Every PowerSteering user has their own "My Projects" Portfolio on the Portfolio page that is only visible to them. Prior to this release, this Portfolio was listed just like any other Portfolio on the page.

Users could edit their own "My Projects" Portfolio however they liked. Administrators could not configure the "My Projects" Portfolio of any other user aside from themselves.

With this update, a black dot icon is now displayed next to the "My Projects" Portfolio to signify that it is unique.

This Portfolio will still be listed on the Portfolio page for every user. However, users with the new "Portfolio Administration" Context permission will notice a new "My Projects [Template]" Portfolio with a black dot that is owned by "PowerSteering".

Note: If any template's name is too long for the "Name" column, the black dot icon will not be visible. Keep this in mind while naming your Portfolio templates.

Note: If the "Is Template" column is displayed on the Portfolios page, the value will be set to "Yes" for templates.

Use the "Select columns" drop-down menu to add and remove columns from your Portfolios page.

This is not a Portfolio; it is a template that can be applied to the "My Projects" Portfolios of other PowerSteering users. Administrators can edit the settings and filters of this template just like they would for a Portfolio. They can then apply those changes to the "My Projects" Portfolios of specific users and User Groups in PowerSteering.

Unlike Portfolios, however, the template does not contain the "Share With" and "Editable by Sharees" fields that can be seen while editing. Instead, three new fields can be found on templates.

Template Targets: Select this field to determine which users and User Groups this template will be applied to. The "My Projects" Portfolios of the selected users will automatically inherit all of the template's settings and filters once it is saved.

Use the search bar to search for users and/or User Groups to apply the template to. Selecting a user or group from the search results will add it to the "Selected Entities" box. Select the Trash icons to remove any users or groups from the box.

Note: If a user is targeted by more than one template, that user's "My Projects" Portfolio will automatically inherit the settings of the template that was most recently saved. Users that have never been targeted by a template will inherit the settings of the default template (more information below).
Editable by Portfolio Owner: When this checkbox is selected, users identified in the "Template Targets" field will be able to edit their "My Projects" Portfolios. These users will see the Edit button in the top right-hand corner of the screen when they select the "My Projects" Portfolio. When this checkbox is not selected, the users will not be able to edit their "My Project" Portfolios even if they have the "Portfolio Administration" Context permission.
Is Default: When this checkbox is selected, the template will be the default "My Projects" Portfolio template for new PowerSteering users or users that have never had a template targeted at them before.

Note: Once a template has been targeted at a user, that user will never automatically inherit the "My Projects" Portfolio settings of the default template if they are no longer targeted by a template. The user's "My Projects" Portfolio will continue to resemble the last changes that were saved to the template while the user was still a target.

Note: Only one template can be the default at once. If another template is already the default template when this checkbox is selected, the previous template will no longer be the default template.

Users with the "Portfolio Administration" Context permission can create new Portfolio templates by copying existing ones. By default, every user with this permission will be able to see the original "My Projects [Template]" Portfolio template when this update is released.

Note: This template, like others, can be renamed while editing. Unlike other templates, however, it cannot be deleted.

To create another Portfolio template, an administrator simply needs to open the template's drop-down menu and select Copy.

The administrator can then edit settings of this new template and use the "Template Targets" field to apply it to the "My Projects" Portfolios of a select set of users.

Benefit:

The "My Projects" Portfolio is a great tool for users to keep track of the work items that concern them. The Portfolio is often applied to Home pages so users can see it whenever they log into the application.

Prior to this upgrade, there was no way to configure the "My Projects" Portfolios of other users (similar to how Home page configurations can be applied to different users). This especially became a problem whenever a new object type was introduced; unless every user who was meant to work on work items of this object type configured their "My Projects" Portfolios to include it, certain individuals would miss out on important work.

With this update, administrators can ensure that the "My Projects" Portfolios of their users always include relevant PowerSteering data. They can keep these Portfolios up to date without having to rely on multiple users to edit their Portfolios themselves. Additionally, administrators can restrict users from editing their own "My Projects" Portfolios to ensure that these users will not make any unwanted changes that prevent them from viewing relevant information.

Improved Updated Portfolio interface

What's Different:

The user interface of the Portfolio page has been updated.

Prior to this release, the Portfolio page resembled the legacy PowerSteering interface.

With this update, the page has been refreshed to match the new PowerSteering interface.

Additionally, the following columns are now available for each Portfolio listed on the page.

Note: See Data Grids for more information on adding columns to PowerSteering grids.

Is Template: Indicates whether or not the Portfolio is a Portfolio Template. See above for more information on Portfolio Templates.
Last Modified Date: The date (formatted mm/dd/yyyy) and time the Portfolio was last edited.

Note: Unfortunately, there is no Portfolio modification data from before this release. If the Portfolio was most recently modified prior to this release, this column will display the date that your PowerSteering environment was migrated to the 2024R1.2 version.
Last Modified By: The name of the user that last edited the Portfolio.
Created Date: The date (formatted mm/dd/yyyy) and time the Portfolio was created.

Note: Unfortunately, there is no Portfolio creation data from before this release. If the Portfolio was created prior to this release, this column will display the date that your PowerSteering environment was migrated to the 2024R1.2 version.
Created By: The name of the user that created the Portfolio.
Last Accessed Date: The date (formatted mm/dd/yyyy) and time the Portfolio was most recently viewed or applied to a Dashboard, Executive Review, Financial Review, or Report.

Note: Unfortunately, there is no Portfolio access data from before this release. If the Portfolio was used prior to this release, this column will be empty.
Last Accessed By: The name of the user that most recently applied the Portfolio to a Dashboard, Executive Review, Financial Review, or Report.

Tip: Both of the "Last Accessed" columns will indicate which Portfolios are still in use. Administrators can use them to determine which Portfolios can be removed from PowerSteering.

The Portfolio details page has been updated as well. Prior to this release, users would see a legacy page when they accessed a Portfolio.

With this update, the Portfolio details is organized in a similar way with a fresher interface. The details can still be found at the top of the page with the Portfolio's work items directly under them.

Just like on the previous interface, users can select the Edit button in the top left-hand corner to edit the Portfolio.

The legacy Define Portfolio page simply allowed users to address any of the Portfolio's details.

With this update, a new editing panel opens up on the right-hand side of the screen. Portfolio editors will be able to see a list of Portfolio work items directly to the right.

The new panel has two tabs: the Portfolio Info tab and the Filters tab.

The Portfolio Info tab allows users to edit the Portfolio's basic details.

Note: These are the same fields that could be found on the legacy page.

The Filters tab allows users to edit the Portfolio's filters. The list of work items next to the tab gives them a preview of the effect the filters will have.

Click thumbnail to play.

Users can select the Apply button to preview their changes in the list of work items or they can select the Revert button to reverse their most recent change.

Finally, users can select the Save button in the top right-hand corner of the screen to save their changes to the Portfolio.

Note: Creating new Portfolios follows the same process as editing them. Users can enter data into the Portfolio Info tab and the Filters tab while reviewing their applied changes in the list of work items to the right.

Benefit:

This new interface matches the new look and feel that has been implemented across PowerSteering over the last couple of years. This is one of many ongoing updates being worked on to make PowerSteering more modern, unified, and intuitive.

Additionally, the Portfolio editing and creation processes is much more user-friendly than before. The ability to view the effects of changes before saving them will help users make more careful decisions about their Portfolios.

Improved Filter Portfolio work items by all Roles

What's Different:

PowerSteering users can now create Portfolios that filter work items by Resources assigned to any Role.

Prior to this release, Portfolio work items could only be filtered by five Roles: "Owners", "Contributors", "Champions", "Financial Reps", and "Approvers".

With this update, work items can now be filtered by all Roles in PowerSteering. Four of the five Role fields have been replaced by a "Roles" drop-down menu. The "Approvers" field still remains on the page.

Note: The interface for creating new Portfolios has been updated with this release. See above for more information on this new look and feel.

When users click on the "Roles" drop-down menu, they can select which Roles they would like to filter work items by.

The selected Roles will appear on the page as fields.

For each Role, users can select which Resources will be used to filter the Portfolio's work items.

Click thumbnail to play.

Work items that do not have at least one of the Resources assigned to an indicated Role will be filtered out of the Portfolio.

Note: The "Approvers" field works just like it did prior to this release.

Benefit:

Filtering Portfolio work items by Resources assigned to specific Roles provides users with an easy way of keeping track of the work certain Resources are carrying out. Prior to this release, this feature was restricted to the four system Roles. With this upgrade, any Role can be used to filter the work items in a Portfolio.

Example: Leah is responsible for two employees who are Developers. While creating a Portfolio, she adds "Developer" as a Role and selects both of these employees. This allows her to keep track of every Project they are assigned to as Developers.

Reports

New "Estimated Effort Remaining" Report Type

What's Different:

A new "Estimated Effort Remaining" Report Type has been added to the Report Wizard. Users can find it as part of the "Resource" category while creating new reports.

Note: Users require the "View Reports" Context permission to use the Report Wizard.

Report builders can now create reports on Estimated Effort Remaining (EER) change proposals that Resources have made during a specific time period on specific work items. These proposals can be compared to the original EER values, allowing the reviewer to analyze which assignments require reallocation.

Each row of this report represents a proposed EER from a Resource. If a Resource proposes a new EER on their Timesheet, it will exist as its own row on the report.

Example: Bob's Project has been underway for a couple of months now. It is progressing well, but he wants to make sure that the time he assigned to his Resources is accurate. He is concerned because he received some notifications for EER proposals, but he never had a chance to address them. Instead of going through all of the proposals one-by-one, he decides to create an "Estimated Effort Remaining" report for his Project. This way, he can see all the proposals at once and decide which time he should adjust.

Benefit:

The 2024R1.1 release introduced Estimated Effort Remaining (EER) to PowerSteering Timesheets. This new tool promotes more agile Resource management by ensuring that effort is allocated effectively, avoiding overallocation and underutilization. Prior to this current release, however, EER proposals were only sent as notifications to the Owner of the work items. There was no other way to communicate these requests.

This became difficult for work item Owners because it forced them to review EER proposals by opening each notification one-by-one. This was extremely tedious for Owners of multiple Projects with a large number of assigned Resources.

The process became even more complicated when the Owner was not primarily responsible for adjusting the Resource allocations. For example, many Projects use Resource Managers to assign Resources to work items and allocate their time. If Resource Managers, not Owners, were responsible for adjusting Resource time, the Owner would have to find a creative way to share these requests.

With this update, all of these requests can now be viewed in a single report. Owners and/or other users will be able to efficiently review EER proposals and respond to the ones they deem appropriate.

Resource Review

Timesheets

New Configure Estimated Effort Remaining on Timesheets

What's Different:

Administrators can now use the Timesheets Configuration Options page to determine how Estimated Effort Remaining (EER) will behave on Timesheets.

The Timesheet Configuration Options page now contains a new "Estimated Effort Remaining" section.

The following configuration options are available:

Estimated Effort Remaining: Selecting this checkbox will enable EER for all user Timesheets in PowerSteering.
Mandatory comment for Estimated Effort Remaining: If selected, users will be required to enter a comment whenever they submit an EER change request.

The Request Update button will not be selectable until a comment is entered into the "Comments" field.

Benefit:

Prior to this release, Timesheet users were able to submit their EER change requests without any comments. This was sometimes problematic because many Project Managers needed to know the reasons behind the request. Project Managers would then have to reach out to their Resources before making any changes to the schedule. Now that the "Comments" field can be marked as required, Project Managers can always be aware of the reasons behind each EER change request, allowing them to make informed decisions about schedule changes.