Unlike ticketing apps, PPM is not segmented out into applications that can make multiple groups trying to share TDX easier to configure/administer. Although the goal is to add segmented apps for PPM in the future, as of version 11.2, we do not have the ability to do this.
A primary pain point for multiple PPM groups is that not only do you need to have full admin access to administer PPM items (unlike the app admin permissions that ITSM has), you also cannot ~only~ allow full admins to administer certain tabs and/or certain values within the tabs. Said another way, not only can we not control which full admin can edit the statuses tab, but we can't control which full admins can edit individual values, like status for example.
Below is a table of the PPM related configurations that are most often used by clients, with a guide on which items are shared vs which items can be customized as needed for each group. It is worth noting that all of the items below only have a single tab in TDAdmin to manage them, but in many cases, can be granularly differentiated.
For items that do require governance, naming conventions are a common tactic.
| Items (in no order) |
Shared/Able to be customized per group |
Misc Information |
| Priorities |
Shared across all groups, needs governance |
Actually also shared across all ticketing apps as well |
| Statuses |
Shared across all groups, needs governance |
Baked in values are usually helpful, but are often customized |
| Issue Attributes/Statuses |
Shared across all groups, needs governance |
n/a |
| Risk Attributes/Statuses |
Shared across all groups, needs governance |
n/a |
| Notification Templates |
Shared across all groups, needs governance |
n/a |
| Reports/Desktops |
Able to be customized/hidden as needed |
n/a |
| Automation Rules |
Able to be customized per group |
n/a |
| Project Request Workflows/Workflow Template |
The template screen is shared across all groups, but not all of the steps need to be included in each workflow. Groups can create workflows from a subset of the steps |
Workflow steps can be configured to pull in certain scorecards as needed. |
| Project Visibility in TDNext/TDClient |
Project membership dictates if a user can see that project. If a PM does not want a user to see the project, access can be restricted to accomplish this. Everyone uses the same apps, but only those who have the right access to the projects will see the projects in these areas. |
n/a |
| Scorecard Criteria/Scorecards |
Able to be customized per group |
Scorecards are comprised of scorecard criteria, and you can create as many scorecards as needed for the different groups. |
| Organization Risks |
Shared across all groups, needs governance |
Assumes you don't use scorecard criteria for your entire scoring model |
| Goals |
Shared across all groups, needs governance |
Assumes you don't use scorecard criteria for your entire scoring model |
| Request Forms/Service in TDClient |
Able to be customized per group |
n/a |
| Types |
Shared across all groups, needs governance, but can be suppressed with group permissions |
It is common for each 'dept' using PPM in TDX to have their own type, and then use group permissions to hide them as needed.
|
| Type Categories |
Shared across all groups, needs governance |
Actually also shared across all ticketing apps as well |
| Project/Request Sections |
Shared across all groups, needs governance |
n/a |
| Portfolios/Programs |
Able to be customized per group |
n/a |
| Project Attributes |
Able to be customized per group |
This is possible because attributes are associated to project types, which can be granularly configured per group. |
| Time Types |
Able to be customized per group |
This is possible because time types are associated to project types, which can be granularly configured per group. |
| Project Templates |
Shared across all groups, needs governance |
Assumes you want more than just the project template owner to be able to see the template (very likely clients will want this) |
| Security Roles |
Able to be customized per group |
Each user can be assigned a different role, so group A might have permissions turned on that group B does not. |