Download document 23077569

Identifying and Managing Risk
Definition: The term risk is defined as “the hazard or chance of an untoward,
negative effect that affects the basic functioning of a system.” In the word of
technology development projects, the term is more succinctly and pragmatically
defined as “Anything that happens during a given project’s life cycle that impedes
the project to the degree that it does not complete on time, within budget,
and/or with promised/expected functionality.” In HL7’s world, risks can impact
specification development, approval, implementation, and/or evolution as well
as the health or reputation of the HL7 organization.
Measuring Risk: Risks are somewhat subjective and discipline-specific. As such,
a given project most productively addresses the issues of risk management
through multi-disciplined assessments of the project’s risk throughout its life
cycle as multi-discipline risk identification tends to “smooth out” some of the
purely qualitative aspects of risk identification.
Risk Identification: Several key points are essential in order for a project to
reliably identify its risks, a critical requirement for effective risk management:
1. Risk identification must be done on a regular basis throughout the entire
lifecycle of a project, i.e. performing a risk assessment once or twice over
the course of a project’s life cycle is not sufficient to manage the project’s
risks. Thus, inadequate attention to regular risk identification leaves the
project vulnerable to risks which were not identified and therefore not
managed. The single most important aspect of effective risk management
is regular – weekly, bi-weekly, etc. – assessment of a project’s current
risk profile. The term “current” is particularly important because risks
can emerge or fade away as a project passes through its life cycle.
2. Risks should be described using a semi-quantitative scale that includes –
at minimum – team assessments of both the:
a. likelihood that a risk will occur (usually expressed as a percentage)
b. impact that the risk will have on the project if it does occur (usually
graded on a 4- or 5-level scale similar to that used in ranking
software bugs, e.g.
i. critical – impedes standards development, acceptance or
adoption - no workaround available
ii. serious – temporary workaround available, not sustainable
iii. significant –workaround available - sustainable
iv. low – may be fixed at some point in the future, workaround
not necessary
3. In addition to the above metrics, it is often helpful to categorize risks as
belonging to one of the following types:
a. Requirements – project requirements are vague, changing,
conflicting, or not well-defined in terms of “knowing when a
project is done and whether it has succeeded.”
b. Technology – project depends on tools/technologies in order to
produce expected results
i. Internal - within HL7
ii. External - external to HL7 organization
c. Resources – project may face shortages financial, physical, and/or
skill-set-appropriate resources
i. Capacity - clinical/domain expertise must be recruited
ii. Capability - lack of required skills
d. Social-political – there may be forces that cannot be controlled by
the project
i. Internal - within HL7
ii. External - external to HL7 organization
4. Finally, it is important to document the following minimum meta-data
about each risk identified:
a. Date identified
b. Identifier (person or discipline)
c. Internal/External (risks which are internal to a given project team
are obviously more easily managed/mitigated then those outside
of the team’s direct control.
Managing Risk: Risk management is proactive monitoring for trends, e.g.
increasing likelihood or impact (or both). When a risk is “trending” in the
“wrong” direction, the project team must take appropriate action to mitigate the
risk. Thus, part of risk management is the development of a risk mitigation plan
in at least outline form for every risk on the project’s “risk radar.” If either the
likelihood or the impact of a given risk begins to increase, the team must develop
a more finely granulated risk mitigation plan and start to manage to that plan so
as to avoid the occurrence of the risk and subsequent disruption of the project’s
planned trajectory.
In addition, if a given risk is trending in the “wrong” direction, the project team
needs to develop at least an outline of a contingency plan which will be
implemented should the risk mitigation plan fail to prevent the occurrence of the
risk.
Summary: The discipline of doing regular, multi-disciplinary/team-wide risk
identification and description using the meta-data defined above in combination
with the development and execution of risk mitigation plans for those risks
trending in the “wrong” direction in the risk profile enables a team to avoid most
– if not all – of the untoward “surprises” that so often hinder a project’s smooth,
effective, and efficient life cycle execution.