Benefits Administration Guide

Audience

This guide is intended for system administrators, meaning users who have the system role assigned to their user account. To check if you are, logged into Cora PPM, on the far left of the page, look for this icon:

If you don't see this icon then this article will not be of any benefit to you. 

Please Note: If you are an Administrator, before you get started, to note any suggestion herein should always be done on a test environment first, do not perform any of these suggestions directly in your Live production environment first. As for many of these administration guides, usually enabling these features is an 'opt-in' feature, and once enabled is not easily switched off, or not available to be switched off altogether. Cora PPM Benefits Management is just once such case, as enabling it requires the database to enable new features and tablespaces, which whilst it can be 'hidden', it cannot ever be completely removed if enabled. We also recommend that you contact the Cora Customer Success Team, someone from the Cora Delivery Team, or your assigned Cora Account Manager first before embarking on implementation of any new module.    

Before you start

Before getting started, it is important to consider what benefits are going to be managed in Cora PPM, or more importantly, how they are planned to be managed. Often we witness this benefit management module is switched on without a plan on how these benefits will be managed, what data will be captured, who will identify, analyze, review, update and realise these benefits. It is important to know that you are not limited to this module in Cora PPM to manage benefits, and here are some other options to choose from with some examples;

1. Project Register: In some cases the 'profile' of the benefit is not important to your organisation, meaning that the graphic representation of the benefits's planned and actual performance plotted over time is not a requirement, however full control over the data (or benefit attributes) that is being captured about each benefit, the business process on how that benefit is managed, and the volume of benefits expected is of most importance. This then the Project Register module is probably an option to consider first before considering Cora PPM Benefits Management.
2. Project Progress: In some cases the complete opposite is required, where ONLY the benefit profile is of importance, meaning that the graphic representation of the benefits's planned and actual performance plotted over time. In this case, using the Project Progress module should be considered first before considering Cora PPM Benefits Management.

Only once at least these alternative options has been ruled out, should you continue to enable the Benefits Management module on your UAT environment. 

Prerequisites

Step 01: Firstly, you should check to see if the Benefits Management module has already been implemented. Run the following tests:

Fist go to MANAGEMENT => Benefit Management in the top right of the window.

Secondly, if you do not see the first step, go to ADMINISTRATION => SYSTEM => MY INSTALLATION and then click on "Features". Check to see if "Benefits" is enabled. 

If the Benefits checkbox is not enabled, it will most likely be greyed out. To enable this, you should send a request to the support desk with the URL you want this feature to be enabled. 

Step 02: In order to see the Benefits Management page under the management menu, you first need to have the Role of Benefit Manager. 

To note, you cannot create a "Custom Role" and assign yourself a custom role of Benefit Manager, this needs to be the system role of Benefits Manager.

General "other" areas for the administration of Benefits

For almost all changes and updates to the administration of Benefits Management, you will commonly go to here: 

This guide will therefore focus on this administration section, however to note as an Administrator, you may need to visit 'other' pages on the administration screen of Cora PPM outside of ADMINISTRATION => BUSINESS PLANNING => BENEFITS MANAGEMENT. Before going into the administration of benefits in detail, the 'other' areas you should be aware of when completing the configuration of benefits are; 

Dependency Maps

The dependency map in Cora PPM is where users will link Benefits to optional Strategies, Objectives, Outcomes and Themes. A benefits map which is also sometimes referred to as a success map is a common task of visually displaying the logical links between the projects, business objectives and project strategies. This map can be used as a guide showing where the value and benefits of the project really lie.

You will need to consult with the benefits owners to decide which of the mapping points should be included, with options for Strategies; Objectives; Outcomes; and Themes. To note these are localisable to your preferred nomenclature. 

As a minimum Benefits and the Projects (projects being either an enabler for the benefit, or a business change for the benefit) they are assigned to are a minimum requirement. As soon as you press save, the optional mapping points will appear or disappear from the Benefits Management page, therefore update with care. 

Who can add benefits 

At this point you need to define who has the rights to add benefits. This differs from customer to customer, whilst some may rely on the general project audience to identify benefits, you should avoid situations where duplicated benefits are created. If you enable this box "Allow users to add benefits directly to projects", anyone with Project Profile ID 46 and 47 can then add a benefit directly to the project they have this project access. 

If there are processes in place to avoid the duplication of benefit identification, you can then consider if the general project audience with profile IDs 46 and 47 can edit the benefit characteristics. Again this will differ from customer to customer. However, these users who either add or edit the benefits from the Project Benefits page on their respective projects may not necessarily have access to all benefits on the Benefits Management page (Benefit Map), and even if they do, they may not have access to see the benefit on the benefit map if they are not assigned to the benefit group of the benefit. Therefore these 2 checkboxes should be thoroughly tested and workshopped first. 

Localisation

As mentioned in the previous section, you can localise the names of the labels on the Dependency Map screen. Simply look at what name you see on the map, look for the name in the corresponding localisation page, and change the name as required. 

 Note that in most cases for reporting purposes you will need to define the singular and plural for the labels.

Fields

Fields, or commonly referred as Benefit Attributes, are the fields that will be presented when a user who has access to the Benefits Management page (system role of Benefits Manager discussed earlier) and has the User Group rights to add a new or edit an existing benefit (discussed later), will be presented to fill in about each benefit.  As a system administrator, you need to decide what fields are presented, what labels to use, what type of field (e.g.: text, checkbox, dropdown etc.), the order in which they appear on the form, and if the form can be saved without a value on that field (i.e.: mandatory or not). 

All fields configuration have minimum system fields that must appear on the form, which you can rename, there are 9 of these system fields, and they are;

1. Benefit Name: which is used as the title of the benefit and used as a point to open the benefit for editing. 
2. Benefit Owner: Every benefit must be assigned to a benefit, which is the person adding the benefit when first creating the benefit.
3. Roll Up: When the benefit is looked at over a collection of sub projects, what method of aggregation is used
4. Improvement Direction: This is merely indicative, it describes to the audience if higher numbers are good or bad, i.e.: a benefit or dis-benefit
5. Profiled By: Provides the 'buckets' of time sequencing for updating baseline, forecast and actuals. Available options are Daily; Weekly; Monthly; Quarterly; and Yearly. 
6. Unit Of Measure:Discussed earlier, see Unit of Measure.
7. Start Date: The date at which the "Profiled By" above (5) starts
8. Finish Date: The date at which the "Profiled By" above (5) ends
9. User Group: The user group (see further about user security) which has access to edit this benefit. Whilst project owners (project managers) can update the baseline, forecast and actual profile of the benefit on their respective projects, the user group selection defines who can edit this benefit in addition to yourself. Only users assigned to this user group that you assign to the benefit will have the required permission to edit this benefit. For all others the option to edit the benefit will be removed as they won't see the benefit at all. 

Now you can add additional fields to the configuration using the ADD button on the top left. Make sure you add these in UAT first, then test them by adding a test benefit, and ensuring that the label, field type and order in which your new field appears is logical and intuitive so that benefit adders can add or update benefit as they answer the characteristics about a benefit based on the order and label that they appear on the form.

Always test your new fields using a use case that resembles a real world scenario, starting from the very left of the benefits map, right through to profiling a project with baseline; forecast and actual.