In addition to the objectives, identifying the scope of a risk management plan is also important. The scope identifies the boundaries of the plan. The boundaries can include the entire organization or a single system or process. Without defined boundaries, the plan can get out of control.

A common problem with many projects is scope creep. Scope creep comes from uncontrolled changes. As the changes creep in, the scope of the project grows. Changes bring in additional requirements, and uncontrolled changes result in cost overruns and missed deadlines.

For example, in the HIPAA compliance example mentioned earlier, the objective of this project is to bring Mini Acme into compliance with HIPAA. Suppose more unprotected data, such as financial data, research data, or user data, is found.

If this data is rolled into the project, it would expand the project because threats and vulnerabilities would need to be identified, the costs of the data loss would need to be calculated, and additional recommendations and their costs would need to be identified. Doing all of this would take more time and money.

To say that the scope of a project should never change is unrealistic. The key is to control the changes. A risk management project manager should work with stakeholders to identify which changes are acceptable. These changes would ideally go through a change control board (CCB), a committee that includes discipline experts and project stakeholders who evaluate such changes and then decide whether to accept the changes.

A stakeholder is an individual or a group that has a stake, or interest, in the success of a project. A key stakeholder is one who has authority to make decisions about the project, including the ability to grant additional resources. Examples of key stakeholders would be a company executive, such as a chief information officer or chief financial officer; a vice president who will “own” the project upon completion; or a chief compliance officer who is an expert in a particular discipline, for example, HIPAA compliance.

Stakeholders should be involved in drafting a scope statement. Their involvement can be anything from drafting the statement to approving it. Stakeholders should have ownership of the project, which is also referred to as buy-in for the project.

A true stakeholder has a vested interest in the project and wants to see it succeed. On the other hand, a stakeholder named as a figurehead without a stake in the project sees it as a nuisance. A project without a true stakeholder will often die from lack of support: Resources aren’t allocated, decisions aren’t made, and team members realize the project is not supported and eventually stop contributing.

For example, from the HIPAA example regarding finding unprotected data unrelated to HIPAA, if a risk management team discovered unprotected financial data, the team could present its concerns to the project manager (PM). The PM can evaluate the data and determine that none of it is HIPAA related but realize it is important. The PM can pass the information on to a stakeholder as an issue of concern. A stakeholder may direct the PM to include the data in the plan. At that point, it is a controlled change.

Examples of scope statements for the website and HIPAA compliance projects are provided in the following sections.