Benefits Review Plan 1.0.0

Scope

The project’s value consists in its ability to fulfil the stated benefits that are evaluated against costs and risks being confronted with each presented alternatives.

The benefits need clear and sound baseline’ measures for gauging the single outputs. Therefore, this document specifies the benefits – as stated in the Business Case – into functions. For each of them, it supplies all necessary references for setting the properties of each function to be delivered.

Starting from the requirements, it is possible to proceed with the following actions:

  1. Planning the production (i.e. associating the skilled resources with the suggested schedules)
  2. Delving into the dependencies that will form among the tasks. These are some useful criteria:
    1. Technical interfaces (e.g. middleware).
    2. Resources over-allocation (when skills are needed for tackling “at the same time” issues.
    3. Suppliers’ needs and plans.
  3. Analyzing risks related to both production’s area (e.g. schedules and resources availability) and profitability (e.g. marketing).

Detailing the “Acceptance Criteria”; that will form the lattice of Quality. Therefore, a review of Risk Analysis will be necessary.

If the project is part of a program, the Benefits Review Plan may be contained within the programme’s benefits’ realization plan and executed at the program level.  Post-project, the Benefits Review Plan is maintained and executed by corporate or program management.

Quality

  1. It Covers all the benefits in the Business Case, including the “options”
  2. The benefits are measurable and baseline measures have been recorded using shared measurement units.
  3. It Supplies the references (i.e. ID) for planning the Quality check, which will be detailed in the Quality plan.
  4. It describes suitable reasons for the control either from user’s user’s viewpoint or the reasons stated in the Business Case.
  5. It helps in the process of identification of the resources – either skills or machinery (e.g. server with the same capacity workload) that will be needed to carry out the measurements.
  6. This document will be linked to all the relevant documents (e.g. plans, quality, acceptance criteria etc.).

RACI (who does what)

Operation desc./Roles Owner Spr PM SME BA Stkhd
Analysis of the Business Case, looking for benefits’ options. C A R C C C
Verifying that all necessary information is consisted with the company’s current standards. I A C I R I
Decomposing the described product into its main features. For each of them, find the suitable metrics. I A R C C C
Compiling the “Benefit Review Plan” C A R I I C
Approving it A R C C
Updating whenever the board authorizes it C A R I I C

Document structure

Distribution list

This kind of information can be considered highly important. Therefore, it is suggested to inform all the interested stakeholders as described in the “Communication Management Strategy”. Any update has to be reflected on all the plans (including Quality Plan).

Registrar section

These are the key fields

Benefits Review Plan

ID To link to any relevant document
Benefit Description As stated in the Business Plan. It also includes whether it is the chosen option or not.
Owner The person who will receive the written mandate from the Project Manager (who remains accountable throughout the project) to deliver the specified function; usually it can be contained in the work-package plan.
Proposed delivery date giving priority / dependencies to each of the listed functions When the functions have to be delivered for obtaining the maximum advantage. This request will be negotiated with the production in order to set the priorities that form the schedule.
Prioritized list of functions A reasonably articulated description of what is requested. For each element is necessary to attach – whenever is feasible – visual indications about the expected results.
Measurements [i] to be used for validating each function. The definition of result(s) will include both the values forming the thresholds (e.g. system responding time) and its measurement unit (e.g. sec. and number of connected users).

These are some examples:

  1. Appearance
  2. Personnel level required to use/operate the product
  3. Performance levels
  4. Capacity
  5. Accuracy
  6. Availability
  7. Reliability (mean/maximum time to repair, mean time between failures).
Development  / implementation costs These figures represent the basis for calculating the required budget and the necessary allowances.
Safety and security requirements Listing all specific needs (e.g. restricted areas accesses, back up and disaster recovery).
Recommendations Any useful note for easing the planning (scheduling and staffing) of each function (e.g. quality, risk, management etc.)
Approved by Project Owner / Sponsor

[i] Any reference to the supposed delivery date and specific criteria for testing the function will be detailed in the Quality Plan in relation with the Product Description.

Technical domains

1)      Project Mandate

Financial / Commercial domains

1)      Project Brief

Notes


[i] Any reference to the supposed delivery date and specific criteria for testing the function will be detailed in the Quality Plan in relation with the Product Description.