Scope of a Risk Management Plan

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.

NOTE

Companies typically have C-level executives, such as CCOs, CEOs, CFOs, CIOs, CSOs, and CTOs. CCO is short for chief compliance officer, CEO is short for chief executive officer, CFO is short for chief financial officer, CIO is short for chief information officer, CSO is short for chief security officer (also referred to as a CISO, chief information security officer), and CTO is short for chief technology officer.

Scope Creep in Application Development

Scope creep is a common problem in application development. Programmers often see how a program can be improved by tweaking it a little here or there. Although the programmers are well intentioned, sometimes these changes can have far-reaching effects.

In one project, a programmer added an additional capability to a program, which allowed the user to search through data. This change was clearly outside the scope of the project, and the change was not evaluated and authorized by a CCB. However, programming it didn’t take much time, and the change was added without notice to anyone. The application was then shipped to the customer with the new capability.

The customer used the program successfully for a few months. Later, the format of the data was changed. The change of the format didn’t affect the primary purpose of the program; it still worked as required. However, the additional search feature no longer worked.

Who’s responsible for fixing the problem? The application developer is responsible.

A change that originally looked like added value actually became added liability. Even though the search capability was outside the scope of the project, it became part of the application. This added capability would have to be maintained just as any other part of the application would need to be maintained. The developer didn’t have much choice. If the developer refused to fix the problem, the perceived usability of the program would be affected.

At this point, the added capability wasn’t easy to remove. It looked and behaved like a feature. Although it would not have been missed if it had never been added, it would now be missed if it were removed.

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.

Scope Example: Website

The purpose of the risk management plan is to secure the Acme Widgets website. The scope of the plan includes:

  • Security of the server hosting the website
  • Security of the website itself
  • Availability of the website
  • Integrity of the website’s data

Stakeholders for this project include:

  • Vice president of sales
  • Information technology (IT) support department head

Written approval is required for all activities outside the scope of this plan.

Scope Example: HIPAA Compliance

The purpose of the risk management plan is to ensure compliance with HIPAA for Mini Acme’s data. The scope of the plan includes:

  • Identifying all health data
  • Storing health data
  • Using health data
  • Transmitting health data

Stakeholders for this project include:

  • CIO
  • Human resources (HR) department head

Written approval is required for all activities outside the scope of this plan.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.146.152.71