Select Two (Multi-Select) Questions

The name of the software used for tracking

Why it fails: Prioritisation criteria are probability, impact and urgency, or the resulting exposure rating; the tracking tool's product name describes the register's platform, not the risk. It is tempting because tooling appears in risk management plans and reporting procedures, and would be correct if the question asked which system records or generates the dashboard.

The birth date of the risk owner

Why it fails: Dashboard prioritisation uses probability, impact and proximity or urgency, or an aggregate exposure score; a risk owner's birth date carries no bearing on likelihood or consequence. It is tempting because owner details appear in risk registers for accountability, and would be correct if the criterion were the owner's authority or availability to action the risk.

Personnel vacation schedule

Why it fails: Vacation schedules affect resource availability and timing, not the magnitude of a risk's consequences on objectives. It is tempting because staffing genuinely influences risk exposure, and it would be correct when assessing probability or response capacity rather than impact severity.

Office supply availability

Why it fails: Office supply availability is an operational procurement concern, not a risk-impact dimension such as cost, schedule or scope. It tempts because resource availability can affect project delivery, so it would be relevant when assessing a risk tied to supplier shortages or workplace logistics.

The office address.

Why it fails: An office address is a static administrative detail with no bearing on likelihood or impact of a risk event. It is tempting because project documentation often records location data, yet qualitative scoring uses probability and impact scales; address would only matter if location itself were a defined risk driver.

The age of the project manager.

Why it fails: A project manager's age is a personal attribute unrelated to any risk's probability or impact. It is tempting because experience is sometimes loosely associated with risk judgement, but qualitative analysis scores the risk event itself against defined likelihood and consequence criteria, not the tenure of the person managing it.

Detailed historical log of all meeting minutes

Why it fails: Meeting minutes are governance records kept separately; the register holds discrete risks with probability, impact, owner and response. It is tempting because decisions about risks are taken in meetings, but the register stores the resulting risk entries, not a chronological transcript of every discussion.

Project team member CVs

Why it fails: CVs evidence individual qualifications and belong in resource or staffing files; the register documents risks with their causes, impacts, owners and responses. It is tempting because team competence affects risk exposure, yet the register tracks the risk event, not the résumé of the person managing it.

Vendor contact information

Why it fails: A risk register records each risk's cause, probability, impact, owner and response; vendor contact details sit in procurement or contract records instead. It is tempting because vendor dependencies can generate risks, but the register captures the risk itself, not the supplier's phone number.

The color preference category.

Why it fails: Colour preference is a personal aesthetic choice carrying no uncertainty about project objectives, so it cannot form an RBS category. Standard RBS branches are technical, external, organisational, and project management. It is tempting because any list can be labelled a category, but an RBS must map sources of risk to objectives.

The lunch break category.

Why it fails: A Risk Breakdown Structure organises risk sources by hierarchical categories such as technical, external, organisational, and project management. Lunch breaks are scheduling logistics, not a risk source, so they cannot head an RBS branch. It is tempting because breaks appear in schedules, but an RBS classifies uncertainty origins, not daily timetable items.

Square distribution.

Why it fails: No square distribution exists in risk simulation; distributions are defined by continuous probability density functions such as triangular, normal, lognormal, beta and uniform. It is tempting because uniform distributions produce a flat, rectangular probability shape, which candidates mislabel as square, but uniform is the actual named distribution.

Linear distribution.

Why it fails: Linear distribution is not a recognised probability distribution for risk simulation; the standard set comprises triangular, normal, lognormal, beta, uniform and discrete distributions. It is tempting because uniform density plots as a straight horizontal line, so candidates describe it as linear, but uniform is the correct term.

Circular distribution.

Why it fails: Circular distributions describe directional statistics, not the continuous probability distributions used to model risk variables in Monte Carlo simulation, such as triangular, normal, lognormal, beta or uniform. It is tempting because risk data can be cyclical, but simulation inputs require unbounded or bounded linear probability densities, not angular ones.

Keeping all risk information to themselves to avoid unnecessary noise.

Why it fails: Withholding risk information prevents stakeholders from contributing mitigations and destroys the shared risk ownership that leadership requires. It is tempting because limiting communication can reduce alarm and noise, which suits low-impact administrative risks where broad escalation adds no value.

Blaming team members when a risk event happens.

Why it fails: Blaming individuals after a risk event suppresses reporting, so future risks stay hidden until they materialise. It is tempting because assigning accountability feels like decisive ownership, which would be appropriate when a documented process was deliberately ignored.

Taking full responsibility for all risks, even those assigned to others.

Why it fails: Absorbing every risk removes the named owners' accountability and leaves the leader unable to track mitigation across the portfolio. It is tempting because visible ownership builds confidence, which suits a single critical risk where no owner has been assigned.

The current market inflation rate.

Why it fails: Inflation is an external economic indicator, not a per-risk input, so it cannot parameterise a risk event in the simulation. It is tempting because inflation affects cost estimates generally, and it is used in cost-risk modelling as a global factor, but event modelling requires probability, impact range and correlation data.

The risk owner's contact information.

Why it fails: Contact details identify who owns the risk but carry no numerical range or probability, so they cannot feed a simulation. It is tempting because ownership is recorded for every risk, and it matters for reporting and escalation, yet quantitative modelling needs probability distributions, impact estimates and dependency data.

Try to hide the failure until the project ends.

Why it fails: Concealing the failure prevents the risk owner and sponsor from authorising revised responses, so exposure continues unmanaged until closure. It is tempting when escalation feels career-damaging, yet transparent reporting is precisely what lets the team re-plan; hiding it is the opposite of the monitoring and control the process requires.

Fire the risk owner immediately.

Why it fails: Dismissing the owner addresses a person rather than the response, leaving the ineffective plan in place and no accountable owner for the revised one. It is tempting when a single individual repeatedly neglects monitoring duties, where reassigning ownership through proper change control would be the legitimate route.

Ignoring the stakeholder and working around them.

Why it fails: Ignoring the stakeholder and working around them leaves their risk exposure unmanaged and breaches inclusive engagement expectations. Working around a stakeholder is acceptable only when they are genuinely outside the risk scope and hold no relevant influence or impact.

Threatening to lower their performance rating if they do not participate.

Why it fails: Threatening a performance rating is coercive and breaches the PMI Code of Ethics, damaging trust and likely entrenching the stakeholder's reluctance. Escalation to a functional manager is legitimate only when normal engagement channels have genuinely failed and authority is needed.

Removing the stakeholder from all future project communications.

Why it fails: Removing the stakeholder from communications directly contradicts the goal of engaging hesitant participants, eliminating the feedback channel risk management depends on. It is tempting because disengagement feels efficient when someone resists, and exclusion is legitimate for stakeholders who pose a security or confidentiality risk — but not for mere hesitancy.

Assigning new risks to owners

Why it fails: A risk audit evaluates how the risk management process is performing against its documented plan; assigning owners to newly identified risks is risk identification and response planning work, not audit evidence gathering. It is tempting because audits often surface new risks, but the audit's output is findings and recommendations, with ownership assignment occurring afterwards in the risk register update.

Updating the project budget for all contingencies

Why it fails: Risk audits examine the effectiveness of risk processes and responses; they do not authorise contingency reserve spending or revise the budget baseline. It is tempting because audit findings can trigger reserve draws, but that is a subsequent Perform Integrated Change Control action, whereas the audit itself produces documented findings, corrective actions and lessons learned for the risk register.

The length of time they have been with the company.

Why it fails: Tenure is irrelevant to risk reporting needs.

The age of the stakeholder.

Why it fails: Age carries no bearing on how a stakeholder perceives or needs risk information; tailoring depends on influence, interest and risk attitude. It is tempting because demographics are easy to record, and age might matter for accessibility formats, but it is not among the two most important factors for communication planning.

The number of emails the stakeholder receives daily.

Why it fails: Email volume is an inbox-management detail, not a determinant of risk communication content, format or frequency; stakeholder influence and interest are. It is tempting because overloaded recipients may need concise messages, and volume could affect channel selection, but it is not among the two most important tailoring factors.

Sensitivity Analysis

Why it fails: Sensitivity analysis tests how variations in one variable affect a model's outcome, so it ranks existing risks rather than discovering new ones during initiation. It is tempting because it belongs to quantitative risk analysis, where it correctly identifies which uncertain inputs most influence the project's results.

Decision Tree Analysis

Why it fails: Decision tree analysis quantifies outcomes and probabilities of already-identified risks, so it cannot generate the risk list initiation requires. It is tempting because it supports risk response selection and expected monetary value comparisons, where it is the right tool once risks are known and you must choose between alternatives.

Monte Carlo Simulation

Why it fails: Monte Carlo simulation quantifies the combined effect of identified risks on cost or schedule; it does not generate a risk list. It is tempting because it is a core quantitative risk-analysis technique, and would be correct during risk analysis, not during initiation-phase risk identification.

Activity constraint report.

Why it fails: An activity constraint report lists scheduling constraints applied to activities; it supports schedule review, not risk communication. Primavera Risk Analysis outputs such as the tornado diagram and cumulative probability distribution convey risk results. The constraint report is tempting because it is a Primavera report, but it contains no risk simulation data.

Project meeting minutes.

Why it fails: Meeting minutes record discussions, decisions and actions; they are not a Primavera Risk Analysis output report and contain no quantitative risk distribution data. Sponsors need outputs such as the tornado diagram or cumulative probability distribution. Minutes are tempting as a communication artefact, but they do not present modelled risk results.

Resource utilization histogram.

Why it fails: A resource utilisation histogram displays labour or equipment loading over time; it derives from schedule data, not from Monte Carlo risk simulation. Sponsors need risk outputs such as the tornado diagram or probability-impact scatter plot. The histogram is tempting because Primavera generates it, but it communicates resourcing, not risk exposure.

Participation of all company employees

Why it fails: Quantitative analysis requires a small team of risk specialists with modelling expertise, not every employee. Company-wide participation tempts because broad input improves risk identification, but that belongs to qualitative workshops; quantitative work needs calibrated data and statistical competence.

Unlimited project budget

Why it fails: Quantitative analysis needs reliable data, sound models and skilled practitioners; unlimited budget guarantees none of these. It tempts because funding enables tooling and expertise, but budget is a constraint, not an analytical input, and cannot substitute for data quality or validated assumptions.

The project office moving locations

Why it fails: An office relocation is a discrete organisational event, not a symptom or warning sign that a specific identified risk is about to materialise. It tempts because moves disrupt projects and can create risks, but a trigger must be the observable condition defined in the risk register that prompts the response plan.

The end of the fiscal year

Why it fails: The fiscal year end is a recurring calendar event, not a condition indicating that a risk is about to occur, so it cannot trigger a specific risk response. It tempts because budget cycles genuinely create risk exposure, but a trigger must be an observable event or threshold tied to one identified risk.

The project manager's birthday

Why it fails: A birthday is a personal calendar event with no causal link to any project risk, so it cannot serve as an indicator that a risk event is imminent. It tempts because triggers are often dates, but the date must correspond to a condition documented in the risk register for that specific risk.

The cost of the audit consultant

Why it fails: Consultant fees are a procurement cost line, not audit content; the report must present risk process compliance, response effectiveness and residual risk exposure to governance. Cost data is tempting because audits consume budget and governance approves spend, but financial tracking belongs in cost reports, not risk audit findings.

The internal team's lunch schedule

Why it fails: Lunch schedules are administrative logistics, not risk information; a risk audit report documents risk process effectiveness, response adequacy and residual exposure for governance oversight. It is tempting because team welfare and resourcing do affect morale and risk culture, but that belongs in resource or HR reporting, not the audit's findings.

The project office's desk arrangement.

Why it fails: Desk arrangement has no bearing on how risk processes are selected, since methodology choice turns on project size, complexity, risk exposure and organisational culture. Physical seating is tempting because co-location aids communication, but it never determines the risk framework adopted.

The project manager's favorite color.

Why it fails: Personal colour preference cannot influence methodology selection, which depends on factors such as project scale, uncertainty, stakeholder tolerance and industry regulation. Individual taste is tempting as a human factor, yet it carries no bearing on process rigour or tailoring decisions.

Execute the risk response

Why it fails: Executing risk responses belongs to the Implement Risk Responses process, which happens after analysis and planning are complete. It is tempting because it is a genuine risk management activity, and it would be the right answer when asked which process carries out agreed response plans, but qualitative analysis only assesses probability and impact to prioritise risks.

Perform a Monte Carlo simulation

Why it fails: Monte Carlo simulation is a quantitative risk analysis technique that models numerical ranges and probability distributions, not a qualitative step. It is tempting because it is a recognised risk analysis method, and it would be correct when the question asks how to quantify overall project cost or schedule contingency, rather than ranking risks by probability and impact.

The use of a GUI-based interface.

Why it fails: A GUI merely changes how the simulation is configured and launched; the underlying sampling and aggregation logic is unchanged. Graphical tools are appropriate for building and reviewing models, but convergence depends on iteration counts, input ranges and correlation settings, not the interface.

Assigning too many resources to a task.

Why it fails: Resource over-allocation distorts duration and cost inputs, but non-convergence stems from unbounded or circular logic, not staffing levels. Assigning many resources is legitimate when modelling effort-driven schedules; it would be the right answer only if the stem asked about resource-levelling conflicts rather than simulation stability.

Using a modern, high-speed processor.

Why it fails: Processor speed affects how quickly each iteration completes, not whether the model's output distribution stabilises. Fast hardware is desirable when running large iteration counts, but non-convergence stems from model structure, input distributions or insufficient iterations, not compute throughput.