"If a project has no risks, don't do it." - WaltzingWithBears by TomDeMarco and TimothyLister
is balancing the amount of risk we want to take with the amount of risk our project exposes us to.
varies over the length of a project.
therefore must be a continuous iterative process even if our project lifecycle is not.
(re)discover the risks that might impact the project
break new risks into resolvable components - RiskTree
estimate the probability and lifetime of each new risk
create a ContingencyPlan for each new problem
cost any mitigation required by the ContingencyPlan
decide on a strategy for each risk
add RiskMitigation tasks and a RiskReserve to the schedule
as risks materialise, start their ContingencyPlan s
remove risks once they have materialised or expired
at regular intervals return to the discovery phase
of software projects should number among our identified risks. They are:
inherent schedule flaw
For more on
A common risk is lack of skills. For example, when developers who have written nothing but Visual Basic are expected to crank out production Java code. In this situation:
is feedback. If we don't act on it, we have wasted our time collecting it.
is a common
takes time and resources like any other part of
. Once we have our
for each risk, we can sort our risks and manage only the
 acceptance means accepting a portion of the impact equal to the probability and padding the cost/schedule accordingly; this is in contrast to evasion, where we trust to luck that the impact will not occur.
, and others
EnterpriseRiskManagement ? framework summary 2004 http://www.coso.org/Publications/ERM/COSO_ERM_ExecutiveSummary.pdf
of this page
(last edited EditText March 5, 2014)
or FindPage with title or text search