Assurance components
Learn about the components that affect assurance for risk in Projects.
Risk scoring factors
Risk scoring factors are attributes that have an impact on the achievement of objectives within an organization. Each risk scoring factor can have one name and assigned weight, and be associated with one scale.
Default and custom risk scoring factors
There are two default risk scoring factors:
- Impact
- Likelihood
Each default risk scoring factor is associated with a 3-point scale:
- 1 Point - Low
- 2 Points - Medium
- 3 Points - High
You can re-label the default risk scoring factors and modify the point scale associated with each risk scoring factor.
Optionally, you can also define up to eight custom risk scoring factors, assign a weight to each, and specify a custom scale. Since not all risk scoring factors may be equally important, you can specify a weight to reflect the perceived importance of the risk scoring factor. The higher the value of the weight, the more important the risk scoring factor is to your organization, and the more the risk scoring factor will contribute to the overall inherent risk score.
You cannot modify the weight of the default risk scoring factors (Likelihood and Impact), which is set at 100%.
Defining risk scoring factors
Project Admins can define risk scoring factors under Manage project types > Risks and Controls tab.
For more information, see Customizing terms, fields, and notifications.
Scoring risks
Professional Managers and Professional Users can score risks when they add or edit risks.
For more information, see Defining risks and controls.
Risk scoring factors in Projects vs. Strategy
Risk scoring factors in Projects contribute to the assurance score displayed in Projects and on the Assurance tab in Strategy (if Projects objectives have been linked to risks in Strategy).
Risk scoring factors in Strategy contribute to the inherent and residual risk scores displayed in Strategy.
Weight
Defining a control weight allows you to express the percentage of the risk that the control mitigates.
How it works
You can define a control weight between 0-100%. The default control weight is 100%. The sum of control weights can add up to any number.
Determining a control weight
Determining a control weight depends on the risk and your environment. Some organizations or departments use discretionary methods, while others use historic data or data analysis techniques to determine a control weight.
Defining a control weight
You can define the weight for each control when you associate risks and controls.
For more information, see Defining risks and controls.
Tests
As you perform walkthroughs and tests or execute procedures, Projects automatically aggregates testing results and issues, and calculates assurance in real-time. As controls pass, assurance increases, and as controls fail, assurance decreases.
Performing walkthroughs and tests or executing procedures
Depending on the project workflow, the following testing tasks are available:
| Workflow | Task | Information |
|---|---|---|
| Internal Control | Test the design of controls using the Walkthroughs page. | Executing procedures and testing controls |
| Test the effectiveness of controls using the Test page. | ||
| Workplan | Execute procedures using the Execute Procedure page. |
Noting whether an execute procedure, walkthrough, or testing round passes or fails
Depending on the project workflow, there are different options for noting whether an execute procedure, walkthrough, or testing round passes or fails.
| Workflow | Test type | Option | Pass or Fail |
|---|---|---|---|
| Internal Control | Walkthrough | Designed Appropriately | Pass |
| Design Failure | Fail | ||
| Testing Round | Operating Effectively | Pass | |
| Exception(s) Noted | Fail | ||
| Workplan | Execute Procedure | No issues | Pass |
| Issues noted | Fail |
When does a control pass or fail, and when is it considered "Not Tested"?
Projects automatically calculates when a control passes or fails based on the following logic:
| Control status | Logic |
|---|---|
| Pass |
the associated walkthrough or execute procedure passed OR at least one of the control's applicable testing rounds passed (the other testing rounds must not be tested) |
| Fail |
the associated walkthrough or execute procedure failed OR at least one of the control's applicable testing rounds failed |
| Not tested |
the associated walkthrough has not been tested AND all of its applicable testing rounds have not been tested OR the associated execute procedure has not been tested |
Scenarios
The following table shows a few different scenarios that illustrate when a control passes or fails. The table illustrates a project that contains one walkthrough and two applicable testing rounds per control:
| Control | Walkthrough | Interim Test | Final Test | Does the control pass or fail? |
|---|---|---|---|---|
| Control 1 | Pass | Pass | Pass | Pass |
| Control 2 | Fail | Fail | Fail | Fail |
| Control 3 | Pass | Pass | Fail | Fail |
| Control 4 | Pass | Pass | Not Tested | Pass |
| Control 5 | Fail | Pass | Pass | Fail |
| Control 6 | Not Tested | Pass | Pass | Pass |
| Control 7 | Not Tested | Pass | Fail | Fail |
| Control 8 | Not Tested | Not Tested | Not Tested | Not Tested |
