Targets

The following are the classical project targets in PRINCE2:

• Scope
• Time
• Cost
• Quality
• Benefits
• Risk

Targets are used to measure the performance of the project. For a Stage, for example, these are the monitoring and controlling activities:

1. “budgets” are set before the Stage is started, and is part of the Stage Plan. For example, the stage should be done in 3 months, with €50K. Note: “budget” refers to all target values, not only the cost target.
2. “tolerances” are also set along with the budgets: 3 months ± 2 weeks, €50K ± €10K
3. during the stage, the performance is measures by calculating the “at completion” values for targets: e.g. when do we forecast the stage to finish, and how much will it cost?
4. if there’s any deviation between the targets and the forecasts, we should immediately design a corrective action to recover it. If the deviation is below the tolerance, the Project Manager should decide, and if it’s outside the tolerance, the Project Board will decide.

The same process is used for other levels; e.g., between the Project Manager and Team Managers for the Work Packages.

The zero-tolerance problem

Tolerance is not an acceptable range of values with a warning, as it is in engineering or daily life. PRINCE2 tolerances are only used according to the Manage by Exception principle to make it clear who should decide on the recovery method. Any deviation from the target values should be recovered, even if it’s inside the tolerance level.

PRINCE2 Agile mentions that when you want to fix a target, you should set its tolerance to zero. This is based on the common language use of the term “tolerance” rather than its PRINCE2 definition. A zero tolerance means that any small deviation should be escalated all the way to the Project Board, and the Project Manager, Team Managers, and developers cannot try to fix it themselves.

Fix or Flex

PRINCE2 Agile uses the phrase “fix or flex” to discuss which targets should be fixed, and which should be dynamic. This is important, because different targets are fixed in Agile environments compared to predictive ones.

• Time
  • Fix/flex: Fix
  • Tolerance: Zero!
  • Notes:
    • Time is always fixed in the iteration level, but the higher levels of stage and project doesn’t have to be fixed-duration, because the number of iterations doesn’t have to be limited and predefined. This is the DSDM approach to fix the project duration, and it’s adopted in PRINCE2 Agile as well.
    • “Tolerance” is used incorrectly in this PRINCE2 Agile topic.
• Cost
  • Fix/flex: Fix
  • Tolerance: Zero!
  • Notes:
    • The cost of each iteration of IT development projects is usually limited to the cost of the developers. Since the composition of the teams are kept fixed during the iterations, there would be a constant relationship between cost and time. Therefore, everything said about time also applies to cost.
    • “Tolerance” is used incorrectly in this PRINCE2 Agile topic.
• Quality
  • Fix/flex: fix and flex
  • Tolerance: zero for the fixed part
  • Notes:
    • PRINCE2 originally uses MoSCoW Prioritization for quality criteria, which means that some of them are not negotiable (must-have criteria), some of them are necessary, but workarounds can be used if they are not passed (should-have criteria), and some of them are nice-to-have (could-have criteria).
    • “Tolerance” is used incorrectly in this PRINCE2 Agile topic.
• Scope
  • Fix/flex: fix and flex
  • Tolerance: zero for the fixed part
  • Notes:
    • A MoSCoW Prioritization can be used for the scope, which means that some parts are fixed, and some are “flex”.
    • “Tolerance” is used incorrectly in this PRINCE2 Agile topic.
• Risk
  • Fix/flex: fix or flex
  • Tolerance: zero if fixed
  • Notes:
    • Not different from original PRINCE2.
    • “Tolerance” is used incorrectly in this PRINCE2 Agile topic.
• Benefit
  • Fix/flex: fix or flex
  • Tolerance: zero if fixed
  • Notes:
    • Not different from original PRINCE2.
    • “Tolerance” is used incorrectly in this PRINCE2 Agile topic.

See Also

• Quality theme

Written by Nader K. Rad

This is (and will be) a work in progress: More details will be added in the future, depending on the feedback.

This wiki is developed and managed by an accredited trainer, independent of AXELOS. While aligned with their guidelines, it’s not an official resource.