Your organization uses a 'Risk Management Information System' (RMIS). During planning, you are configuring the system to track risk data. Which parameter is critical to define to ensure meaningful risk reporting?
Standardised probability and impact scales give every risk a common scoring basis, so the RMIS can aggregate, compare and rank risks consistently. Without this shared calibration, reporting thresholds and heat maps become meaningless, defeating the system's purpose during planning.
Why this answer
A Risk Management Information System (RMIS) aggregates risk data across projects and portfolios, and meaningful reporting requires that all inputs use consistent, standardized probability and impact scoring scales. Without a common scale (e.g., 1–5 for probability, 1–5 for impact with defined monetary or schedule thresholds), risk scores from different projects cannot be compared, aggregated, or trended — the RMIS would produce apples-to-oranges data. Defining these scales is a foundational configuration step in the risk management plan and a prerequisite for quantitative and qualitative analysis.
Exam trap
The trap is selecting a project-specific detail (completion date, salary, vendor list) when the question asks about a *system-wide configuration parameter* — candidates must recognize that RMIS value comes from cross-project comparability, which requires standardized scoring scales.
How to eliminate wrong answers
Option B is wrong because the project completion date is a schedule attribute, not a risk data parameter — it does not affect how risks are scored, compared, or reported in the RMIS. Option C is wrong because the project manager's salary is a cost/HR detail with no relevance to risk scoring or reporting; it would never be a configuration parameter for risk data. Option D is wrong because a vendor list is a procurement artifact, not a risk scoring input — while vendors may be risk sources, listing them does not standardize risk reporting.