Risk 1: Inherent schedule flaws

Explanation: Software development, given the intangible nature and uniqueness of

software, is inherentl difficult to estimate and schedule!
"alt#ing!!!Solution: $et the team more involved in planning and estimating! $et earl
feedback and address slips directl with stakeholders!
%gile &ractice: 'n agile pro(ects the team is heavil involved in planning and estimating
through activities such as )&*s planning game and "ideband +elphi workshops! ,
working in short increments the true velocit of the team quickl emerges and is visible
to all stakeholders who are now more closel involved in the pro(ect! In short, the true
progress is hard to hide and quickl revealed, giving feedback to the stakeholders!
Risk -: Requirements Inflation
Explanation: %s the pro(ect progresses more and more features that were not identified
at the beginning of the pro(ect emerge that threaten estimates and timelines!
"alt#ing!!!Solution: .onstant involvement of customers and developers!
%gile &ractice: %gile pro(ects plan in the regular trade/off discussions about features and
estimates at ever iteration boundar! .hanges and requirements inflation are accepted
as a fact of software pro(ects! Rather than utilising change/suppression mechanisms,
prioritisation sessions are scheduled that allow worthwhile changes to proceed and
initiall envisioned features to be superseded if the business gives their authorisation! It
has never been possible to squee#e a pint into a quart cup, but now at least we
anticipate the likel issue and have mechanisms in place to address the matter as part of
the pro(ect from its earl stages!
Risk 0: Emploee 1urnover
Explanation: 2e personnel leave the pro(ect taking critical information with them that
significantl delas or derails the pro(ect!
"alt#ing!!!Solution: Increased collaboration and information sharing on the team!
%gile &ractice: %gile pro(ects practice information sharing techniques such as pair
programming, common code ownership, and frequent reporting at dail stand/ups
specificall to reduce the 3bus/factor3! "hen this 3bus factor3 4the impact to the pro(ect of
a ke member being hit b a bus5 is reduced multiple team members share ke
information and the risk due to emploee turnover is small! %lso, often overlooked, is the
fact that when working in an engaging, rewarding, empowered, collaborative
environment such as agile pro(ects, people are far less likel to want to move elsewhere
so the risk is often avoided as well as reduced!
Risk 6: Specification ,reakdown
Explanation: "hen coding and integration begin it becomes apparent that the
specification is incomplete or contains conflicting requirements!
"alt#ing!!!Solution: 7se a dedicated &roduct 8anager to make critical trade off
decisions!
%gile &ractice: %gile pro(ects utilise the concept of an ambassador user, sub(ect matter
expert, or customer prox to pla the product manager role! 1he idea is that someone
4or some group5 need to be readil available to answer questions and make decisions on
the pro(ect! 1raditional pro(ects suffer specification breakdown when no one will own the
role and conflicting assumptions or decisions are made! %gile pro(ects have some form
of product owner role central to their core team composition to ensure decisions are
made in a timel fashion!
Risk 9: &oor &roductivit
Explanation: $iven long pro(ect timelines, the sense of urgenc to work in earnest is
often absent resulting to time lost in earl pro(ect stages that can never be regained!
"alt#ing!!!Solution: Short iterations, right people on team, coaching and team
development!
%gile &ractice: %gile methods recognise &arkinson*s :aw and the Student Sndrome
appl to software pro(ects! &arkinson*s :aw sas that: 3"ork expands to fill the time
available3 and Student Sndrome: 3$iven a deadline, people tend to wait until the
deadline is nearl here before starting work!3 , having short iterations, work is
timeboxed into a manageable iteration 4tpicall 1/6 weeks5 and there is alwas a sense
of urgenc! %gile methods do not specificall address getting the right people on team,
coaching and team development, but these are core leadership roles applicable to both
agile and traditional pro(ects!
.ategories of risks:
Schedule Risk:
&ro(ect schedule get slip when pro(ect tasks and schedule release risks are not
addressed properl!
Schedule risks mainl affect on pro(ect and finall on compan econom and ma lead
to pro(ect failure!
Schedules often slip due to following reasons:
"rong time estimation
Resources are not tracked properl! %ll resources like staff, sstems, skills of
individuals etc!
;ailure to identif complex functionalities and time required to develop those
functionalities!
7nexpected pro(ect scope expansions!
,udget Risk:
"rong budget estimation!
.ost overruns
&ro(ect scope expansion
'perational Risks:
Risks of loss due to improper process implementation, failed sstem or some external
events risks!
.auses of 'perational risks:
;ailure to address priorit conflicts
;ailure to resolve the responsibilities
Insufficient resources
<o proper sub(ect training
<o resource planning
<o communication in team!
1echnical risks:
1echnical risks generall leads to failure of functionalit and performance!
.auses of technical risks are:
////////////
.ontinuous changing requirements
<o advanced technolog available or the existing technolog is in initial stages!
&roduct is complex to implement!
+ifficult pro(ect modules integration!
&rogrammatic Risks:
1hese are the external risks beond the operational limits! 1hese are all uncertain risks
are outside the control of the program!
1hese external events can be:
Running out of fund!
8arket development
.hanging customer product strateg and priorit
$overnment rule changes!
are &ro(ect Risks
.an ou give me an example of risk management in the software industr=
Software and Risk
> .onsidering the rate of failure in the software pro(ect industr
> ?ou would expect risk management to be more advanced
> 'ne wa to reduce risk, and cost
> Is to adopt commercial off/the/shelf software
> 2nown as .'1S for short
> @owever, few .'1S products fit requirements exactl
> Some customi#ation is necessar
> 8aking risk management an essential activit
%dopting .'1S products
> 7sing .'1S software
> +ecreases some risks
> Such as will our purpose/built solution work=
> ,ut increases others
> Such as will the .'1S software work for us and in our environment=
> %s alwas with pro(ect risk management
> 1he ob(ective is to
> Identif, track, manage and mitigate those risks
.ustomer Satisfaction
> 1he risks must be established
> "ithin the context of the customer*s organi#ation
> 1he problem with .'1S software is
> .ompromises must be made
> "hich ma or ma not be acceptable to the users
> @ence, a close working relationship with the customer and the actual users is
essential
> 1he following slides suggest some technical risk issues to consider
1echnical Risks / 1
1he following are both positive and negative
> "hen comparing .'1S versus full custom/built software
> 7sing .'1S software makes for easier and surer pro(ect estimating
> +epending on the ratio between .'1S and custom building
> Rapid prototping is easier with .'1S software
> 1o test the proposed sstem*s concept and usabilit
> It can also be done earlier in the software development ccle
> "hen alternative approaches can also be compared
1echnical Risks / -
> So, in general, a .'1S solution is much cheaper
> ,ecause a lot of the development and testing work has been done
> %nd the product should be available sooner
> "hile successful commercial software requires less testing
> .ompared to all/custom built products
> Integrating several such products requires more testing
> .'1S software usuall has support available
> ,ut coordinating multiple sources complicates maintenance and support
> %nd ma stretch beond the support available
1echnical Risks / 0
> Successful commercial software provides a de facto standard
> Reducing risk of user re(ection of the interface
> ,ut the customer is at the merc of the .'1S software supplier
> %nd ever upgrade that comes along
> %nd consequent rework and testing ever time
> "orse, if the supplier abandons support
> 1he customer is left with a legac application
> .ontrolling the technolog is also difficult
> Especiall if proprietar protection is a concern
.ustomer risk issues / 1
Specific risk issues for the customer to consider
> Staff*s comfort and stress level
> Especiall if the interface is unfamiliar
> &erformance evaluation and incentives
> 1he new softwareAsstem ma require less qualified people
> &eople*s (obs and (ob securit
> Especiall in the sstems department
.ustomer risk issues / -
> 1raining and education effort
> .hanging the demands on the personnel department
> 'rgani#ational changes
> :eading to changes in the management structure
> 8anagerial power and influence
> 1hat ma be lost or gained
Summar / 1
,enefits of the .'1S approach
> 8ore sources
> ,etter qualit
> <ewer technolog
> .heaper implementations
> ;aster availabilit
> Easier interconnection
Summar / -
+isadvantages of the .'1S approach
> Exactl the right solution ma be elusive
> 1he .'1S product ma be sub(ect to changes
> +riven b other users
> 'r market forces
> % newer and better product arrives
> 1hat essentiall serves the same purpose
> ,ut requires a reworking of the custom sstem
> Shelf/life is tpicall limited
> %nd product support is abandoned b the supplier
+efinition: Risk identification is the process of determining risks that could potentiall
prevent the program, enterprise, or investment from achieving its ob(ectives! It includes
documenting and communicating the concern!
2ewords: risk, risk identification, risk management
8I1RE SE Roles B Expectations: 8I1RE sstems engineers 4SEs5 working on
government programs are expected to identif risks that could impact the pro(ect and
program! 1he are expected to write and review risk statements that are clear,
unambiguous, and supported b evidence C1D!
,ackground
Risk identification is the critical first step of the risk management process depicted in
;igure 1!
;igure 1! ;undamental Steps of Risk 8anagement C-D;igure 1! ;undamental Steps of
Risk 8anagement C-D
1he ob(ective of risk identification is the earl and continuous identification of events
that, if the occur, will have negative impacts on the pro(ect*s abilit to achieve
performance or capabilit outcome goals! 1he ma come from within the pro(ect or from
external sources!
1here are multiple tpes of risk assessments, including program risk assessments, risk
assessments to support an investment decision, analsis of alternatives, and
assessments of operational or cost uncertaint! Risk identification needs to match the
tpe of assessment required to support risk/informed decision making! ;or an acquisition
program, the first step is to identif the program goals and ob(ectives, thus fostering a
common understanding across the team of what is needed for program success! 1his
gives context and bounds the scope b which risks are identified and assessed!
Identifing Risks in the Sstems Engineering &rogram
1here are multiple sources of risk! ;or risk identification, the pro(ect team should review
the program scope, cost estimates, schedule 4to include evaluation of the critical path5,
technical maturit, ke performance parameters, performance challenges, stakeholder
expectations vs! current plan, external and internal dependencies, implementation
challenges, integration, interoperabilit, supportabilit, suppl/chain vulnerabilities, abilit
to handle threats, cost deviations, test event expectations, safet, securit, and more! In
addition, historical data from similar pro(ects, stakeholder interviews, and risk lists
provide valuable insight into areas for consideration of risk!
Risk identification is an iterative process! %s the program progresses, more information
will be gained about the program 4e!g!, specific design5, and the risk statement will be
ad(usted to reflect the current understanding! <ew risks will be identified as the pro(ect
progresses through the life ccle!
,est &ractices and :essons :earned
'perational Risk! 7nderstand the operational nature of the capabilities ou are
supporting and the risk to the end users, their missions, and their operations of the
capabilities! 7nderstanding of the operational needAmission 4see the .oncept
+evelopment topic of the Sstems Engineering $uide5 will help ou appreciate the
gravit of risks and the impact the could have to the end users! 1his is a critical part of
risk analsisEreali#ing the real/world impact that can occur if a risk arises during
operational use! 1picall operational users are willing to accept some level of risk if the
are able to accomplish their mission 4e!g!, mission assurance5, but ou need to help
users to understand the risks the are accepting and to assess the options, balances,
and alternatives available!
1echnical maturit! "ork with and leverage industr and academia to understand the
technologies being considered for an effort and the likel transition of the technolog
over time! 'ne approach is to work with vendors under a non/disclosure agreement to
understand the capabilities and where the are going, so that the risk can be assessed!
<on/+evelopmental Items 4<+I5! <+I includes commercial/off/the/shelf and
government/off/the/shelf items! 1o manage risk, consider the viabilit of the <+I
provider! +oes the provider have market share= +oes the provider have appropriate
longevit compared to its competitors= @ow does the provider address capabilit
problems and release fixes, etc!= "hat is the user base for the particular <+I= .an the
provider demonstrate the <+I, preferabl in a setting similar to that of our customer=
.an the government use the <+I to create a prototpe= %ll of these factors will help
assess the risk of the viabilit of the <+I and the provider! Seek answers to these
questions from other 8I1RE staff that have worked the area or have used the <+I being
assessed!
%cquisition drivers! Emphasi#e critical capabilit enablers, particularl those that have
limited alternatives! Evaluate and determine the primar drivers to an acquisition and
emphasi#e their associated risk in formulating risk mitigation recommendations! If a
particular aspect of a capabilit is not critical to its success, its risk should be assessed,
but it need not be the primar focus of risk management! ;or example, if there is risk to a
proposed user interface, but the marketplace has numerous alternatives, the success of
the proposed approach is probabl less critical to overall success of the capabilit! 'n
the other hand, an information securit feature is likel to be critical! If onl one
alternative approach satisfies the need, emphasis should be placed on it! +etermine the
primar success drivers b evaluating needs and designs, and determining the
alternatives that exist! Is a unique solution on the critical path to success= 8ake sure
critical path analses include the entire sstem engineering ccle and not (ust
development 4i!e!, sstem development, per se, ma be a 3piece of cake,3 but fielding in
an active operational situation ma be a ma(or risk5!
7se capabilit evolution to manage risk! If particular requirements are driving
implementation of capabilities that are high risk due to unique development, edge/of/the/
envelope performance needs, etc!, the requirements should be discussed with the users
for their criticalit! It ma be that the need could be postponed, and the development
communit should assess when it might be satisfied in the future! @elp users and
developers gauge how much risk 4and schedule and cost impact5 a particular capabilit
should assume against the requirements to receive less risk capabilities sooner! In
developing our recommendations, consider technical feasibilit and knowledge of
related implementation successes and failures to assess the risk of implementing now
instead of the future! In deferring capabilities, take care not to fall into the trap of
postponing ultimate failure b trading near/term eas successes for a future of multiple
high/risk requirements that ma be essential to overall success!
2e &erformance &arameters 42&&s5! "ork closel with the users to establish 2&&s!
'verall risk of program cancelation can be centered on failure to meet 2&&s! "ork with
the users to ensure the parameters are responsive to mission needs and technicall
feasible! 1he parameters should not be so lenient that the can easil be met, but not
meet the mission needF nor should the be so stringent that the cannot be met without
an extensive effort or pushing technologEeither of which can put a program at risk! Seek
results of past operations, experiments, performance assessments, and industr
implementations to help determine performance feasibilit!
External and internal dependencies! @aving an enterprise perspective can help
acquirers, program managers, developers, integrators, and users appreciate risk from
dependencies of a development effort! "ith the emergence of service/oriented
approaches, a program will become more dependent on the availabilit and operation of
services provided b others that the intend to use in their program*s development
efforts! "ork with the developers of services to ensure qualit services are being
created, and thought has been put into the maintenance and evolution of those services!
"ork with the development program staff to assess the services that are available, their
qualit, and the risk that a program has in using and reling upon the service! :ikewise,
there is a risk associated with creating the service and not using services from another
enterprise effort! @elp determine the risks and potential benefits of creating a service
internal to the development with possibl a transition to the enterprise service at some
future time!
Integration and Interoperabilit 4IBI5! IBI will almost alwas be a ma(or risk factor! 1he
are forms of dependencies in which the value of integrating or interoperating has been
(udged to override their inherent risks! 1echniques such as enterprise federation
architecting, composable capabilities on demand, and design patterns can help the
government plan and execute a route to navigate IBI risks! Refer to the Enterprise
Engineering section of the Sstems Engineering $uide for articles on techniques for
addressing IBI associated risks!
Information securit! Information securit is a risk in nearl ever development! Some of
this is due to the uniqueness of government needs and requirements in this area! Some
of this is because of the inherent difficulties in countering cber attacks! .reating
defensive capabilities to cover the spectrum of attacks is challenging and risk! @elp the
government develop resilienc approaches 4e!g!, contingenc plans, backupArecover,
etc!5! Enabling information sharing across sstems in coalition operations with
international partners presents technical challenges and polic issues that translate into
development risk! 1he information securit issues associated with suppl chain
management is so broad and complex that even maintaining rudimentar awareness of
the threats is a tremendous challenge!
Skill level! 1he skill or experience level of the developers, integrators, government, and
other stakeholders can lead to risks! ,e on the lookout for insufficient skills and reach
across the corporation to fill an gaps! In doing so, help educate government team
members at the same time ou are bringing corporate skills and experience to bear!
.ost risks! &rograms will tpicall create a government*s cost estimate that considers
risk! %s ou develop and refine the program*s technical and other risks, the associated
cost estimates should evolve, as well! .ost estimation is not a one/time activit!
@istorical information as a guide to risk identification! @istorical information from similar
government programs can provide valuable insight into future risks! Seek out information
about operational challenges and risks in various operation lessons learned, after action
reports, exercise summaries, and experimentation results! .ustomers often have
repositories of these to access! $overnment leaders normall will communicate their
strategic needs and challenges! 7nderstand and factor these into our assessment of
the most important capabilities needed b our customer and as a basis for risk
assessments!
@istorical data to help assess risk is frequentl available from the past performance
assessments and lessons learned of acquisition programs and contractors! In man
cases, 8I1RE staff will assist the government in preparing performance information for a
particular acquisition! 1he %; has a &ast &erformance Evaluation $uide 4&&E$5 that
identifies the tpe of information to capture that can be used for future government
source selections C0D! 1his repositor of information can help provide background
information of previous challenges and where the might arise againEboth for the
particular tpe of development activit as well as with the particular contractors!
1here are numerous technical assessments for vendor products that can be accessed to
determine the risk and viabilit of various products! 'ne 8I1RE repositor of evaluations
of tools is the %nalsis 1oolshed that contains guidance on and experience with
analtical tools! 7sing resources like these and seeking others who have tried products
and techniques in prototpes and experiments can help assess the risks for a particular
effort!
@ow to write a riskEGa best practice C-D! % best/practice protocol for writing a risk
statement is the .ondition/If/1hen construct! 1his protocol applies to risk management
processes designed for almost an environment! It is a recognition that a risk, b its
nature is probabilistic and one that, if it occurs, has unwanted consequences!
"hat is the .ondition/If/1hen construct= 1he .ondition reflects what is known toda! It is
the root cause of the identified risk event! 1hus, the .ondition is an event that has
occurred, is presentl occurring, or will occur with certaint! Risk events are future
events that ma occur because of the .ondition present! ,elow is an illustration of this
protocol!
1he If is the risk event associated with the .ondition present! It is criticall important to
recogni#e the If and the .ondition as a dual! "hen examined (ointl, there ma be was
to directl intervene or remed the risk event*s underling root 4.ondition5 such that the
consequences from this event, if it occurs, no longer threaten the pro(ect! 1he If is the
probabilistic portion of the risk statement!
1he 1hen is the consequence, or set of consequences, that will impact the engineering
sstem pro(ect if the risk event occurs! %n example of a .ondition/If/1hen construct is
illustrated in ;igure -!
;igure -! "riting a RiskEG1he *.ondition/If/1hen* ,est &ractice;igure -! "riting a RiskE
G1he 3.ondition/If/1hen3 ,est &ractice
Encourage teams to identif risks! 1he culture in some government pro(ects and
programs discourages the identification of risks! 1his ma arise because the risk
management activities of tracking, monitoring, and mitigating the risks are seen as
burdensome and unhelpful! In this situation, it can be useful to talk to the teams about
the benefits of identifing risks and the inabilit to manage it all in our heads 4e!g!,
determine priorit, who needs to be involved, mitigation actions5! %ssist the government
teams in executing a process that balances management investment with value to the
outcomes of the pro(ect! In general, a good balance is being achieved when the pro(ect
scope, schedule, and cost targets are being met or successfull mitigated b action
plans, and the pro(ect team believes risk management activities provide value to the
pro(ect! .ross/team representation is a mustF risks should not be identified b an
individual, or strictl b the sstems engineering team 4review sources of risk above5!
.onsider organi#ational and environmental factors! 'rgani#ational, cultural, political, and
other environmental factors, such as stakeholder support or organi#ational priorities, can
pose as much or more risk to a pro(ect than technical factors alone! 1hese risks should
be identified and activel mitigated throughout the life of the pro(ect! 8itigation activities
could include monitoring legislative mandates or emergenc changes that might affect
the program or pro(ect mission, organi#ational changes that could affect user
requirements or capabilit usefulness, or changes in political support that could affect
funding! In each case, consider the risk to the program and identif action options for
discussion with stakeholders! ;or additional information, see the Risk 8itigation
&lanning, Implementation, and &rogress 8onitoring article!
Include stakeholders in risk identification! &ro(ects and programs usuall have multiple
stakeholders that bring various dimensions of risk to the outcomes! 1he include
operators, who might be overwhelmed with new sstemsF users, who might not be
properl trained or have fears for their (obsF supervisors who might not support a new
capabilit because it appears to diminish their authoritF and polic makers, who are
concerned with legislative approval and cost! In addition, it is important to include all
stakeholders, such as certification and accreditation authorities who, if inadvertentl
overlooked, can pose ma(or risks later in the program! Stakeholders ma be keenl
aware of various environmental factors, such as pending legislation or political program
support that can pose risks to a pro(ect that are unknown to the government or 8I1RE
pro(ect team! Include stakeholders in the risk identification process to help surface these
risks!
"rite clear risk statements! 7sing the .ondition/If/1hen format helps communicate and
evaluate a risk statement and develop a mitigation strateg! 1he root cause is the
underling .ondition that has introduced the risk 4e!g!, a design approach might be the
cause5, the If reflects the probabilit 4e!g!, probabilit assessment that the If portion of
the risk statement were to occur5, and the 1hen communicates the impact to the
program 4e!g!, increased resources to support testing, additional schedule, and concern
to meet performance5! 1he mitigation strateg is almost alwas better when based on a
clearl articulated risk statement!
Expect risk statement modifications as the risk assessment and mitigation strateg is
developed! It is common to have risk statements refined once the team evaluates the
impact! "hen assessing and documenting the potential risk impact 4cost, schedule,
technical, or timeframe5, the understanding and statement of the risk might change! ;or
example, when assessing a risk impact of software schedule slip, the risk statement
might be refined to include the need/b date, andAor further clarification of impact 4e!g!, if
the x# software is not delivered b 8arch -H19, then there will not be sufficient time to
test the interface exchanges prior to :imited 7ser 1est5!
+o not include the mitigation statement in the risk statement! ,e careful not to fall into
the trap of having the mitigation statement introduced into the risk statement! % risk is an
uncertaint with potential negative impact! Some (ump quickl to the conclusion of
mitigation of the risk and, instead of identifing the risk that should be mitigated 4with
mitigation options identified5, the identif the risk as a sub/optimal design approach! ;or
example, a risk statement might be: If the contractor does not use )?I for test, then the
test will fail! 1he concern is reall test sufficienc! If the contractor does not conduct the
test with measurable results for analsis, then the program ma not pass limited user
test! 7se of )?I ma be a mitigation option to reduce the test sufficienc risk!
+o not (ump to a mitigation strateg before assessing the risk probabilit and impact! %
risk ma be refined or changed given further analsis, which might affect what the most
efficientAdesired mitigation ma be! Engineers often (ump to the solutionF it is best to
move to the next step discussed in the Risk Impact %ssessment and &rioriti#ation article
to decompose and understand the problem first! 7ltimatel this will lead to a strateg
that is closel aligned with the concern!
Executive Support
1! Executives fail to support pro(ect
1he pro(ect team ma lack the authorit to achieve pro(ect ob(ectives! In such cases,
executive management support is fundamental to pro(ect success! "hen this doesn*t
materiali#e the pro(ect fails!
-! Executives become disengaged with pro(ect
Executive management disregards pro(ect communications and meetings!
0! .onflict between executive stakeholders disrupts pro(ect
8embers of executive management are combative to the pro(ect or there is a
disagreement over pro(ect issues at the executive level!
6! Executive turnover disrupts pro(ect
% ke executive leaves the compan, the resulting disruption becomes a pro(ect issue!
Scope
9! Scope is ill defined
1he general risk of an error or omission in scope definition!
J! Scope creep inflates scope
7ncontrolled changes and continuous growth of scope!
K! $old plating inflates scope
1he pro(ect team add their own product features that aren*t in requirements or change
requests!
L! Estimates are inaccurate
Inaccurate estimates is a common pro(ect risk!
M! +ependencies are inaccurate
+ependencies dramaticall impact the pro(ect schedule and costs!
1H! %ctivities are missing from scope
Required activities are missing from scope definition!
.ost 8anagement
11! .ost forecasts are inaccurate
Inaccurate cost estimates and forecasts!
1-! Exchange rate variabilit
"hen costs are incurred in foreign currencies exchange rates can have a dramatic
impact!
.hange 8anagement
10! .hange management overload
% large number of change requests dramaticall raises the complexit of the pro(ect and
distracts ke resources!
16! Stakeholder conflict over proposed changes
.hange requests ma be the source of stakeholder conflict!
19! &erceptions that a pro(ect failed because of changes
:arge numbers of high priorit change requests ma lead to the perception that the
pro(ect has failed! "hen the schedule and budget are continuall extended G
stakeholders ma feel the pro(ect missed its original targets!
1J! :ack of a change management sstem
Identif an lack of critical tools as a risk!
1K! :ack of a change management process
.hange management at the organi#ational or departmental level is critical to pro(ect
success! 'therwise, the pro(ect will have limited visibilit into changes that impact the
pro(ect!
1L! :ack of a change control board
% change control board is essential to managing change for large pro(ects!
1M! Inaccurate change priorities
"hen non/essential changes are prioriti#ed impacting critical schedules!
-H! :ow qualit of change requests
.hange requests that are low qualit 4e!g! ambiguous5!
-1! .hange request conflicts with requirements
.hange requests that make no sense in the context of the requirements!
Stakeholders
--! Stakeholders become disengaged
"hen stakeholders ignore pro(ect communications!
-0! Stakeholders have inaccurate expectations
Stakeholders develop inaccurate expectations 4believe that the pro(ect will achieve
something not in the requirements, plan, etc5!
-6! Stakeholder turnover
Stakeholder turnover can lead to pro(ect disruptions!
-9! Stakeholders fail to support pro(ect
"hen stakeholders have a negative attitude towards the pro(ect and wish to see it fail!
-J! Stakeholder conflict
+isagreement between stakeholders over pro(ect issues!
-K! &rocess inputs are low qualit
Inputs from stakeholders that are low qualit 4e!g! business case, requirements, change
requests5!
.ommunication
-L! &ro(ect team misunderstand requirements
"hen requirements are misinterpreted b the pro(ect team a gap develops between
expectations, requirements and work packages!
-M! .ommunication overhead
"hen ke pro(ect resources spend a high percentage of their time engaging
stakeholders on pro(ect issues and change requests their work ma fall behind!
0H! 7nder communication
.ommunication is a challenge that*s not to be underestimated! ?ou ma need to
communicate the same idea man times in different was before people remember it!
01! 7sers have inaccurate expectations
1he risk that users believe the pro(ect is building an apple when ou*re reall building an
orange 4i!e! users don*t understand the product that*s coming their wa5!
0-! Impacted individuals aren*t kept informed
% stakeholder is missing in our communication plan! %none who isn*t informed but is
impacted has an excellent reason to throw up pro(ect roadblocks! ;or example, if ou
build a sstem but fail to consult the operations group that will be responsible for
support!
Resources B 1eam
00! Resource shortfalls
Inabilit to secure sufficient resources for the pro(ect!
06! :earning curves lead to delas and cost overrun
"hen our pro(ect team need to acquire new skills for the pro(ect there*s a risk that
productivit will be low!
09! 1raining isn*t available
Nualit training for certain skills can be difficult to secure!
0J! 1raining is inadequate
1raining is often a poor substitute for professional experience! &ro(ects shouldn*t assume
that resources will be full productive in a new skill!
0K! Resources are inexperienced
Resources who are (ust out of school or who are new to our industr or profession tend
to make more mistakes and be less productive!
0L! Resource performance issues
Resources who perform below expectations!
0M! 1eam members with negative attitudes towards the pro(ect
Resources who are negative towards the pro(ect ma activel or passivel sabotage
pro(ect efforts!
6H! Resource turnover
Resource turnover leads to delas and cost overrun!
61! :ow team motivation
?our team lacks motivation! 1his is a particularl common risk for long running pro(ects!
6-! :ack of commitment from functional managers
In a matrix organi#ation our team ma report to functional managers! 1hese functional
managers are important stakeholders whose support is critical!
%rchitecture
60! %rchitecture fails to pass governance processes
&lan for an architectural or technolog governance processes that the pro(ect ma need
to pass!
66! %rchitecture lacks flexibilit
1he architecture is incapable of supporting change requests and needs to be reworked!
69! %rchitecture is not fit for purpose
1he architecture is low qualit!
6J! %rchitecture is infeasible
1he architecture is impossible to implement, excessivel costl or doesn*t support the
requirements!
+esign
6K! +esign is infeasible
1he design isn*t possible, is excessivel costl or doesn*t support the requirements!
6L! +esign lacks flexibilit
% poor design makes change requests difficult and costl!
6M! +esign is not fit for purpose
1he design is low qualit!
9H! +esign fails peer review
It*s a good idea to have peers or architectural experts review our designs!
1echnical
91! 1echnolog components aren*t fit for purpose
1echnolog components are low qualit!
9-! 1echnolog components aren*t scalable
.omponents that can*t be scaled to meet performance demands!
90! 1echnolog components aren*t interoperable
.omponents that lack standard interfaces!
96! 1echnolog components aren*t compliant with standards and best practices
<on/standard components that violate best practices!
99! 1echnolog components have securit vulnerabilities
Securit vulnerabilities are ke technolog risks!
9J! 1echnolog components are over/engineered
% component that*s bloated with unneeded functionalit and design features!
9K! 1echnolog components lack stabilit
.omponents that crash!
9L! 1echnolog components aren*t extensible
.omponents that are difficult to extend with new capabilities!
9M! 1echnolog components aren*t reliable
.omponents that fail after a short time!
JH! Information securit incidents
1he risk of a a securit incident during the pro(ect 4e!g! information is leaked5!
J1! Sstem outages
.ritical sstems such as our test environments go down!
J-! :egac components lack documentation
Integration with undocumented legac components is a high risk activit!
J0! :egac components are out of support
Integration with legac components that are no longer in support!
J6! .omponents or products aren*t maintainable
1echnolog components, tools or platforms that are difficult to maintain 4e!g! lacking
documentation, rare skills, complex or experimental5!
J9! .omponents or products can*t be operationali#ed
1echnolog operations ma have criteria for operationali#ation of new sstems that need
to be met!
JJ! &ro(ect management tool problems B issues
1echnical problems with the pro(ect management tools themselves!
Integration
JK! +elas to required infrastructure
+elas to infrastructure such as hardware or software!
JL! ;ailure to integrate with business processes
1he risk that our product will fail to fit into the existing business!
JM! ;ailure to integrate with sstems
1he risk that our product will fail to integrate with existing sstems!
KH! Integration testing environments aren*t available
1he risk that environments won*t be available to test integration!
K1! ;ailure to integration with the organi#ation
1he risk that our pro(ect fails to integrate with the organi#ation! 1his happens when the
pro(ect is focused on delivering something specific and fails to look at the organi#ation
as a whole! ;or example, ou deliver a sales sstem but our organi#ation doesn*t have
a sales team!
K-! ;ailure to integrate components
1he risk that product components will fail to integrate with each other! 1his can represent
a significant risk when ou*ve outsourced work to a large number of vendors!
K0! &ro(ect disrupts operations
1he last thing ou want is for our pro(ect to disrupt business operations and damage
the firm*s financial results! 1hink about risks beond pro(ect failure!
K6! &ro(ect disrupts sales
1he risk that the pro(ect disrupts sales effectiveness!
K9! &ro(ect disrupts compliance
1he risk that the pro(ect disrupts compliance processes such as audits and reporting!
Requirements
KJ! Requirements fail to align with strateg
?our requirements conflict with the firm*s strateg! If ou sense that this is the case, list it
as a risk!
KK! Requirements fail to align with business processes
1he requirements make no sense in the context of the business!
KL! Requirements fail to align with sstems
1he requirements fail to align with other sstems 4e!g! the duplicate functionalit5!
KM! Requirements have compliance issues
If ou have an doubt that requirements compl with the law list it as a risk!
LH! Requirements are ambiguous
Requirements are unclear and open to interpretation!
L1! Requirements are low qualit
Requirements aren*t fit for purpose!
L-! Requirements are incomplete
?ou can spot obvious holes in the requirements!
+ecisions B Issue Resolution
L0! +ecision delas impact pro(ect
Establish guidelines for decision turnaround time! Identif the risk that guidelines will be
exceeded!
L6! +ecisions are ambiguous
Stakeholders ma have a tendenc to make decisions that are intentionall ambiguous
4a responsibilit avoidance technique5! 1his can be identified as a risk and managed!
L9! +ecisions are low qualit
+ecisions aren*t fit for purpose!
LJ! +ecisions are incomplete
Issue resolutions that don*t address the issue or create more issues!
&rocurement
LK! <o response to R;&
1he risk that there is limited response to an R;&! 1his occurs when the R;& terms are
unacceptable to vendors or if our firm has a bad reputation amongst vendors!
LL! :ow qualit responses to R;&
@alf hearted responses to our R;& that are unusable!
LM! ;ailure to negotiation a reasonable price for contracts
Inabilit to negotiate a reasonable price for contracts! 1his occurs when the
requirements or contract terms make vendors nervous!
MH! 7nacceptable contract terms
Inabilit to negotiate acceptable contract terms!
M1! .onflict with vendor leads to pro(ect issues
1he relationship with vendor turns to conflict and pro(ect issues mount!
M-! .onflict between vendors leads to pro(ect issues
?our vendors develop conflict with each other and cooperation breaks down!
M0! Oendors start late
1he risk of a late start!
M6! Oendor components fail to meet requirements
% vendor misunderstands requirements or delivers components that are completel off
the mark!
M9! Oendor components are low qualit
Oendor components aren*t fit for purpose!
MJ! Infrastructure is low qualit
?our infrastructure fails or is not fit for purpose!
MK! Service qualit is low
Services ou procure such as consulting are not fit for purpose!
ML! Oendor components introduce third part liabilit
Oendor components introduce liabilit 4e!g! the violate patents5!
MM! :oss of intellectual propert
Oendors sp on ou!
%uthorit
1HH! &ro(ect team lack authorit to complete work
If ou lack specific authorities required to deliver the pro(ect list this as a risk!
1H1! %uthorit is unclear
It*s unclear who has the authorit to accomplish a pro(ect ob(ective!
%pprovals B Red 1ape
1H-! +elas to stakeholder approvals impact the pro(ect
1he risk that approval deadlines will be exceeded!
1H0! +elas to financial approvals impact the pro(ect
1he risk of delas to financial approvals and processes to release funds!
1H6! +elas to procurement processes impact the pro(ect
8an organi#ations have specific procurement processes that must be followed! 1hese
processes can be time consuming and highl variable! +ocument the risk that
procurement process will exceed deadlines!
1H9! +elas to recruiting processes impact the pro(ect
If our pro(ect involves recruiting resources, this will tpicall take man months and is
highl variable!
1HJ! +elas to training impact the pro(ect
If our training budget requires separate approvals 4e!g! from functional managers or
@R5 document the risk that this will be slow!
'rgani#ational
1HK! 1he pro(ect fails to match the organi#ation*s culture
% culture fit issue between our product and the organi#ation! If the organi#ation*s culture
calls for emploees to bring their own mobile devices to work 4,?'+5 and ou build a
user interface that onl works on a specific device!
1HL! %n organi#ational restructuring throws the pro(ect into chaos
If our pro(ect has a large footprint it ma be extremel sensitive to organi#ational
changes!
1HM! % merger or acquisition disrupts the pro(ect
8ergers B acquisitions ma represent significant organi#ational changes!
External
11H! :egal B regulator change impacts pro(ect
If our pro(ect spans areas that are compliance/sensitive ou ma want to list regulator
change as a risk!
111! ;orce 8a(eure 4e!g! act of nature5 impacts pro(ect
8a(or disruptions such as acts of nature!
11-! 8arket forces impact pro(ect
8arket changes impact pro(ect 4e!g! a market crash5!
110! 1echnical change impacts pro(ect
% technolog innovation changes our industr and impacts the pro(ect!
116! ,usiness change impacts pro(ect
% business innovation changes our industr and impacts the pro(ect!
&ro(ect 8anagement
119! ;ailure to follow methodolog
If our organi#ation asks ou to streamline our pro(ect management methodolog, that
can be documented as a risk!
11J! :ack of management or control
% lack of pro(ect management should be documented as a risk! ;or example, if resource
constraints cause the pro(ect to skip certain pro(ect management best practices!
11K! Errors in ke pro(ect management processes
Errors in pro(ect management such as schedule errors!
Secondar Risks
11L! .ounterpart risk
1he risk ou get back when ou transfer a risk!
7ser %cceptance
11M! 7sers re(ect the prototpe
'ne of the ke methods of improving user acceptance is to get regular prototpes in
front of users! 1here*s alwas a risk that these prototpes will be re(ected 4require
significant rework5!
1-H! 7ser interface doesn*t allow users to complete tasks
1he risk that the user interface doesn*t allow users to complete end/to/end tasks!
1-1! 7ser interface is low qualit
1he user interface is bugg, slow or difficult to use!
1--! 7ser interface isn*t accessible
In man (urisdictions, user interfaces must be accessible 4e!g! emploment or consumer
law5! 8an organi#ational cultures require accessible user interfaces!
1-0! &ro(ect reduces business productivit
7sers identif our product4s5 as reducing their productivit!
1-6! &ro(ect reduces innovation
7sers identif our product4s5 as a roadblock to innovation!
1-9! &roduct disrupts business metrics 4measurements of ob(ectives5
?our product launch causes business 2&Is to worsen! ;or example, if ou launch a new
ER& and Suppl .hain .cle 1imes (ump!
1-J! 7sers re(ect the product
1he general risk that users will re(ect our product!
.ommercial
1he following risks ma appl to new product development pro(ects!
1-K! &roduct doesn*t sell
+emand risk for the new product!
1-L! &roduct incurs legal liabilit
1he product has qualit issues that harm our customers!
1-M! &roduct negativel affects brand
1he product has qualit issues that damage our brand!
10H! &roduct negativel affects reputation
1he product generates negative publicit andAor damages customer relationships!
:ists of risks
&roduct si#e risks
Estimated si#e of the product in :'. or ;&=
+egree of confidence in estimated si#e estimate=
Estimated si#e of product in number of programs, files, transactions=
&ercentage deviation in si#e of product from average for previous products=
Si#e of database created or used b the product=
<umber of users of the product=
<umber of pro(ected changes to the requirements for the product= ,efore deliver=
%fter deliver=
%mount of reused software=
,usiness impact risks
%ffect of this product on compan revenue=
Oisibilit of this product b senior management=
Reasonableness of deliver deadlines=
<umber of customers who will use this product and the consistenc of their needs
relative to the product=
<umber of other productsAsstems with which this product must be interoperable=
Sophistication of end users=
%mount and qualit of product documentation that must be produced and delivered to
the customer=
$overnmental constraints on the construction of the product=
.osts associated with late deliver=
.osts associated with a defective product=
.ustomer related risks
@ave ou worked with he customer in the past=
+oes the customer have a solid idea of what is required=
@as the customer taken the time to write this down=
"ill the customer agree to spend time in formal requirements gathering meetings to
identif pro(ect scope=
Is the customer willing to establish rapid communication links with the developer=
Is the customer willing to participate in reviews=
Is the customer technicall sophisticated in the product area=
Is the customer willing to let our people do their (ob that is, will the customer resists
looking over our shoulder during technicall detailed work=
+oes the customer understand the software engineering process=
+evelopement environment risks
Is a software pro(ect management tool available=
Is a software process management tool available=
%re tools for analsis and design available=
+o analsis and design tools deliver methods that are appropriate for the product to
be built=
%re compilers or code generators available and appropriate for the product to be built=
%re testing tools available and appropriate for the product to be built=
%re software configuration management tools available=
+oes the environment make use of a database or repositor=
%re all the software tools integrated with one another=
@ave members of the pro(ect teams received training in each of the tools=
%re local experts available to answer questions about the tools=
Is on/line help and documentation for the tools adequate=
&rocess issue risks
+oes our senior management support a written polic statement that emphasi#es the
importance of a standard process for software development=
@as our organi#ation developed a written description of the software process to be
used on this pro(ect=
%re staff members signed/up to the software process as it is documented and willing
to use it=
Is the software process used for other pro(ects=
@as our organi#ation developed or acquired a series of software engineering training
courses for managers and technical staff=
%re published software engineering standards provided for ever software developer
and software manager=
@ave document outlines and examples been developed for all deliverables defined as
part of the software process=
%re formal technical reviews of the requirements specification, design, and code
conducted regularl=
%re formal technical reviews of test procedures and test cases conducted regularl=
%re the results of each formal technical review documented, including defects found
and resources used=
Is there some mechanism for ensuring that work conducted on a pro(ect conforms
with software engineering standards=
Is configuration management used to maintain consistenc among sstemAsoftware
requirements, design, code, and test cases
Is a mechanism used for controlling changes to customer requirements that impact
the software=
Is there a documented statement of work, software requirements specification, and
software development plan for each subcontract=
Is a procedure followed for tracking and reviewing the performance of subcontractors=
Staff si#e and experience
%re the best people available=
+o the people have the right combination of skills=
%re enough people available=
%re staff committed for entire duration of the pro(ect=
"ill some staff be working onl part time on this pro(ect=
+o staff have the right expectations about the (ob at hand=
@ave staff received necessar training=
"ill turnover among staff be low enough to allow continuit=
1echnical issue risks
%re facilitated application specification techniques used to aid in communication
between the customer and developer=
%re specific methods used for software analsis=
+o ou use a specific method for data and architecture designs=
Is more then MHP of our code written in a high order language=
%re specific conventions for code documentation defined and used=
+o ou use a specific method for test case design=
%re software tools used to support software planning and tracking activities=
%re configuration management software tools used to control and track change
activit throughout the software process=
%re software tools used to support the software analsis and design process=
%re tools used to create software prototpes=
%re software tools used to support the testing process=
%re software tools used to support the production and management of
documentation=
%re qualit metrics collected for all software pro(ects=
%re productivit metrics collected for all software pro(ects=
1echnolog risks
Is the technolog to be built new to our compan=
+o the customer requirements demand the creation of new algorithms, input or output
technolog=
+oes the software interface with new or unproven hardware=
+oes the software to be built interface with a database sstem whose function and
performance have not been proven in this application area=
+oes the software to be built interface with vendor supplied software products that are
unproven=
Is a speciali#ed user interface demanded b product requirements=
+o requirements for the product demand the creation of program components that are
unlike an previousl developed b our organi#ation=
+o requirements demand the use of new analsis, design, or testing methods=
+o requirements demand the use of unconventional software development methods,
such as formal methods, %I/based approaches, artificial neural networks=
+o requirements put excessive performance constraints on the product=
Is the customer uncertain that the functionalit requested is 3do/able3=
'ther potential risks
Schedule, resources, and product definition have all been dictated b the customer or
upper management and are not in balance
Schedule is optimistic, 3best case,3 rather than realistic, 3expected case3
Schedule omits necessar tasks > Schedule was based on the use of specific team
members, but those team members were not available
.annot build a product of the si#e specified in the time allocated
&roduct is larger than estimated 4in lines of code, function points, or percentage of
previous pro(ect*s si#e5
Effort is greater than estimated 4per line of code, function point, module, etc!5
Re/estimation in response to schedule slips is overl optimistic or ignores pro(ect
histor
Excessive schedule pressure reduces productivit
1arget date is moved up with no corresponding ad(ustment to the product scope or
available resources
% dela in one task causes cascading delas in dependent tasks
7nfamiliar areas of the product take more time than expected to design and
implement 'rgani#ation and management
&ro(ect lacks an effective top/management sponsor
&ro(ect languishes too long in fu## front end
:aoffs and cutbacks reduce team*s capacit
8anagement or marketing insists on technical decisions that lengthen the schedule
Inefficient team structure reduces productivit
8anagement reviewAdecision ccle is slower than expected
,udget cuts upset pro(ect plans
%re the best people available
+o the people have the right kind of skills
%re enough people available
%re staff committed for the duration
"ill some staff be working part/time
+o staff have the right expectations about the (ob at hand
@as the staff received the necessar training
"ill staff turnover be low enough to allow continuit
8anagement makes decisions that reduce the development team*s motivation
<on/technical third/part tasks take longer than expected 4budget approval,
equipment purchase approval, legal reviews, securit clearances, etc!5
&lanning is too poor to support the desired development speed
&ro(ect plans are abandoned under pressure, resulting in chaotic, inefficient
development
8anagement places more emphasis on heroics than accurate status reporting, which
undercuts its abilit to detect and correct problems +evelopment environment
;acilities are not available on time
;acilities are available but inadequate 4e!g!, no phones, network wiring, furniture,
office supplies, etc!5
;acilities are crowded, nois, or disruptive
+evelopment tools are not in place b the desired time
+evelopment tools do not work as expectedF developers need time to create
workarounds or to switch to new tools
+evelopment tools are not chosen based on their technical merits, and do not provide
the planned productivit
Is a software pro(ect management tool available
Is a software process management tool available
%re tools for analsis and design available
+o analsis and design tools deliver methods that are appropriate for the pro(ect to be
built
%re compilers or code generators available and appropriate for the product to be built
%re software configuration management tools available
+oes the environment make use of a database or repositor
%re all software tools integrated with each other
@ave members of the pro(ect team received training in each of the tools
%re local experts available to answer questions about the tools
Is on/line help and documentation for the tools available End users
End/user insists on new requirements
End/user ultimatel finds product to be unsatisfactor, requiring redesign and rework
End/user does not bu into the pro(ect and consequentl does not provide needed
support
End/user input is not solicited, so product ultimatel fails to meet user expectations
and must be reworked .ustomer
.ustomer insists on new requirements
.ustomer reviewAdecision ccles for plans, prototpes, and specifications are slower
than expected
.ustomer will not participate in review ccles for plans, prototpes, and specifications
or is incapable of doing so/resulting in unstable requirements and time/consuming
changes
.ustomer communication time 4e!g!, time to answer requirements/clarification
questions5 is slower than expected
.ustomer insists on technical decisions that lengthen the schedule
.ustomer micro/manages the development process, resulting in slower progress than
planned
.ustomer/furnished components are a poor match for the product under
development, resulting in extra design and integration work
.ustomer/furnished components are poor qualit, resulting in extra testing, design,
and integration work and in extra customer/relationship management
.ustomer/mandated support tools and environments are incompatible, have poor
performance, or have inadequate functionalit, resulting in reduced productivit
.ustomer will not accept the software as delivered even though it meets all
specifications
.ustomer has expectations for development speed that developers cannot meet
@ave ou worked with the customer in the past
+oes the customer have a solid idea of what is required
"ill the customer agree to spend time in formal requirements gathering meetings to
identif pro(ect scope
Is the customer willing to participate in reviews
Is the customer technicall sophisticated in the product area
Is the customer willing to let our people do their (ob / that is will the customer resist
looking over our shoulder and make changes as ou go
+oes the customer understand the software process .ontractors
.ontractor does not deliver components when promised
.ontractor delivers components of unacceptabl low qualit, and time must be added
to improve qualit
.ontractor does not bu into the pro(ect and consequentl does not provide the level
of performance needed
Requirements have been baselined but continue to change
Requirements are poorl defined, and further definition expands the scope of the
pro(ect
%dditional requirements are added
Oaguel specified areas of the product are more time/consuming than expected
&roduct and product si#e
Error/prone modules require more testing, design, and implementation work than
expected
7nacceptabl low qualit requires more testing, design, and implementation work to
correct than expected
+evelopment of the wrong software functions requires redesign and implementation
+evelopment of the wrong user interface results in redesign and implementation
+evelopment of extra software functions that are not required 4gold/plating5 extends
the schedule
8eeting product*s si#e or speed constraints requires more time than expected,
including time for redesign and reimplementation
Strict requirements for compatibilit with existing sstem require more testing, design,
and implementation than expected
Requirements for interfacing with other sstems, other complex sstems, or other
sstems that are not under the team*s control result in unforeseen design,
implementation, and testing
&ushing the computer science state/of/the/art in one or more areas lengthens the
schedule unpredictabl
Requirement to operate under multiple operating sstems takes longer to satisf than
expected
'peration in an unfamiliar or unproved software environment causes unforeseen
problems
'peration in an unfamiliar or unproved hardware environment causes unforeseen
problems
+evelopment of a kind of component that is brand new to the organi#ation takes
longer than expected
+ependenc on a technolog that is still under development lengthens the schedule
Estimated si#e of the product in :'. or ;&
+egree of confidence in estimated si#e estimate
Estimates si#e of product in number of programs, files, transactions
&ercentage deviation in si#e of product from average for previous products
Si#e of data base created or used b the product > <umber of users of the product
<umber of pro(ected changes to the requirements for the product before deliver after
deliver
%mount of reused software ,usiness impact risks
Effect of this product on compan revenue
Oisibilit of this product to senior management
Reasonableness of deliver deadline
<umber of customers who will use this product and the consistenc of their needs
relative to the product
<umber of other productsAsstems with which this product must be interoperable
Sophistication of end users
%mount and qualit of product documentation that must be produced and delivered to
the customer
$overnmental constraints on the construction of the product
.osts associated with late deliver
.osts associated with a defective product External environment
&roduct depends on government regulations, which change unexpectedl
&roduct depends on draft technical standards, which change unexpectedl
1echnolog risks
Is the technolog to be built new to our organi#ation
+o the customers requirements demand the creation of new algorithms or input and
output technolog
+oes the software with new or unproven hardware
+oes the software interface with vender supplied software
+oes the software interface with unproven database technolog
Is a speciali#ed user interface demanded b product requirements
+o requirements for the product demand the creation of program components that are
unlike an previousl developed b our organi#ation
+o requirements demand the use of new analsis, design, or testing methods
+o requirements demand the use of unconventional software development methods
+o requirements put excessive performance constraints on the product
Is the customer uncertain that the functionalit requested is doable &ersonnel
@iring takes longer than expected
1ask prerequisites 4e!g!, training, completion of other pro(ects, acquisition of work
permit5 cannot be completed on time
&oor relationships between developers and management slow decision making and
follow through
1eam members do not bu into the pro(ect and consequentl does not provide the
level of performance needed
:ow motivation and morale reduce productivit
:ack of needed speciali#ation increases defects and rework
&ersonnel need extra time to learn unfamiliar software tools or environment
&ersonnel need extra time to learn unfamiliar hardware environment
&ersonnel need extra time to learn unfamiliar programming language
.ontract personnel leave before pro(ect is complete
&ermanent emploees leave before pro(ect is complete
<ew development personnel are added late in the pro(ect, and additional training and
communications overhead reduces existing team members* effectiveness
1eam members do not work together efficientl
.onflicts between team members result in poor communication, poor designs,
interface errors, and extra rework
&roblem team members are not removed from the team, damaging overall team
motivation
1he personnel most qualified to work on the pro(ect are not available for the pro(ect
1he personnel most qualified to work on the pro(ect are available for the pro(ect but
are not used for political or other reasons
&ersonnel with critical skills needed for the pro(ect cannot be found
2e personnel are available onl part time
<ot enough personnel are available for the pro(ect
&eople*s assignments do not match their strengths
&ersonnel work slower than expected
Sabotage b pro(ect management results in inefficient scheduling and ineffective
planning
Sabotage b technical personnel results in lost work or poor qualit and requires
rework +esign and implementation
'verl simple design fails to address ma(or issues and leads to redesign and
reimplementation
'verl complicated design requires unnecessar and unproductive implementation
overhead
Inappropriate design leads to redesign and reimplementation
7se of unfamiliar methodolog results in extra training time and in rework to fix first/
time misuses of the methodolog
&roduct is implemented in a low level language 4e!g!, assembler5, and productivit is
lower than expected
<ecessar functionalit cannot be implemented using the selected code or class
librariesF developers must switch to new libraries or custom/build the necessar
functionalit
.ode or class libraries have poor qualit, causing extra testing, defect correction, and
rework
Schedule savings from productivit enhancing tools are overestimated
.omponents developed separatel cannot be integrated easil, requiring redesign and
rework &rocess
%mount of paperwork results in slower progress than expected
Inaccurate progress tracking results in not knowing the pro(ect is behind schedule until
late in the pro(ect
7pstream qualit/assurance activities are shortchanged, resulting in time/consuming
rework downstream
Inaccurate qualit tracking results in not knowing about qualit problems that affect
the schedule until late in the pro(ect
1oo little formalit 4lack of adherence to software policies and standards5 results in
miscommunications, qualit problems, and rework
1oo much formalit 4bureaucratic adherence to software policies and standards5
results in unnecessar, time/consuming overhead
8anagement/level progress reporting takes more developer time than expected
@alf/hearted risk management fails to detect ma(or pro(ect risks
Software pro(ect risk management takes more time than expected
+oes senior management support a written polic statement that emphasi#es the
importance of a standard process for software development
@as our organi#ation developed a written description of the software process to be
use on this pro(ect
%re staff members 3signed up3 to the software process as it is documented and willing
to use it
Is the software process used for other pro(ects
@as our organi#ation developed or acquired a series of software engineering training
courses for managers and technical staff
%re published software engineering standards provided for ever software developer
and software manager
@ave documentation outlines and examples been developed for all deliverables
defined as part of the software process
%re formal technical reviews of the requirements specification, design, and code
conducted regularl
%re formal technical reviews of test procedures and test cases conducted regularl
%re the results of formal reviews documented, including errors found and resources
used
Is there some mechanism for ensuring that work conducted on a pro(ect conforms
with software engineering standards
Is configuration management used to maintain consistenc among sstem software
requirements, design, code, and test cases
Is a mechanism used for controlling changes to customer requirements that impact
the software
Is there a documented statement of work, a software requirements specification and a
software development for each subcontract
Is a procedure followed for tracking and reviewing the performance of subcontractors
%re facilitated application specification techniques used to aid in communication
between the customer and developer
%re specific methods used for software analsis
+o ou use a specific method for data and architectural design
Is more than MH percent of our code written in a high order language > %re specific
conventions for code documentation defined and used
+o ou use specific methods for test case design
%re software tools used to support planning and tracking activities
%re configuration management software tools used to control and track change
activit throughout the software process >
%re software tools used to support the software analsis and design process
%re tools used to create software prototpes
%re software tools used to support the testing process
%re software tools used to support the production and management of documentation
%re qualit metrics collected for all software pro(ects
%re productivit metrics collected for all software pro(ects