Risk 1: Inherent schedule flaws

Explanation: Software development, given the intangible nature and uniqueness of software, is inherently difficult to estimate and schedule.

Waltzing...Solution: Get the team more involved in planning and estimating. Get early feedback and address slips directly with stakeholders.

Agile Practice: On agile projects the team is heavily involved in planning and estimating through activities such as XP's planning game and Wideband Delphi workshops. By working in short increments the true velocity of the team quickly emerges and is visible to all stakeholders who are now more closely involved in the project. In short, the true progress is hard to hide and quickly revealed, giving feedback to the stakeholders.

Risk 2: Requirements Inflation

Explanation: As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten estimates and timelines.

Waltzing...Solution: Constant involvement of customers and developers.

Agile Practice: Agile projects plan in the regular trade-off discussions about features and estimates at every iteration boundary. Changes and requirements inflation are accepted as a fact of software projects. Rather than utilising change-suppression mechanisms, prioritisation sessions are scheduled that allow worthwhile changes to proceed and initially envisioned features to be superseded if the business gives their authorisation. It has never been possible to squeeze a pint into a quart cup, but now at least we anticipate the likely issue and have mechanisms in place to address the matter as part of the project from its early stages.

Risk 3: Employee Turnover

Explanation: Key personnel leave the project taking critical information with them that significantly delays or derails the project.

Waltzing...Solution: Increased collaboration and information sharing on the team.

Agile Practice: Agile projects practice information sharing techniques such as pair programming, common code ownership, and frequent reporting at daily stand-ups specifically to reduce the "bus-factor". When this "bus factor" (the impact to the project of a key member being hit by a bus) is reduced multiple team members share key information and the risk due to employee turnover is small. Also, often overlooked, is the fact that when working in an engaging, rewarding, empowered, collaborative environment such as agile projects, people are far less likely to want to move elsewhere so the risk is often avoided as well as reduced.

Risk 4: Specification Breakdown

Explanation: When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements.

Waltzing...Solution: Use a dedicated Product Manager to make critical trade off decisions.

Agile Practice: Agile projects utilise the concept of an ambassador user, subject matter expert, or customer proxy to play the product manager role. The idea is that someone (or some group) need to be readily available to answer questions and make decisions on the project. Traditional projects suffer specification breakdown when no one will own the role and conflicting assumptions or decisions are made. Agile projects have some form of product owner role central to their core team composition to ensure decisions are made in a timely fashion.

Risk 5: Poor Productivity

Explanation: Given long project timelines, the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained.

Waltzing...Solution: Short iterations, right people on team, coaching and team development.

Agile Practice: Agile methods recognise Parkinson's Law and the Student Syndrome apply to software projects. Parkinson's Law says that: "Work expands to fill the time available" and Student Syndrome: "Given a deadline, people tend to wait until the deadline is nearly here before starting work." By having short iterations, work is timeboxed into a manageable iteration (typically 1-4 weeks) and there is always a sense of urgency. Agile methods do not specifically address getting the right people on team, coaching and team development, but these are core leadership roles applicable to both agile and traditional projects.

Categories of risks:

Schedule Risk:

Project schedule get slip when project tasks and schedule release risks are not addressed properly.

Schedule risks mainly affect on project and finally on company economy and may lead to project failure.

Schedules often slip due to following reasons:

Wrong time estimation

Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.

Failure to identify complex functionalities and time required to develop those functionalities.

Unexpected project scope expansions.

Budget Risk:

Wrong budget estimation.

Cost overruns

Project scope expansion

Operational Risks:

Risks of loss due to improper process implementation, failed system or some external events risks.

Causes of Operational risks:

Failure to address priority conflicts

Failure to resolve the responsibilities

Insufficient resources

No proper subject training

No resource planning

No communication in team.

Technical risks:

Technical risks generally leads to failure of functionality and performance.

Causes of technical risks are:

------------

Continuous changing requirements

No advanced technology available or the existing technology is in initial stages.

Product is complex to implement.

Difficult project modules integration.

Programmatic Risks:

These are the external risks beyond the operational limits. These are all uncertain risks are outside the control of the program.

These external events can be:

Running out of fund.

Market development

Changing customer product strategy and priority

Government rule changes.

are Project Risks

Can you give me an example of risk management in the software industry?

Software and Risk

· Considering the rate of failure in the software project industry

· You would expect risk management to be more advanced

· One way to reduce risk, and cost

· Is to adopt commercial off-the-shelf software

· Known as COTS for short

· However, few COTS products fit requirements exactly

· Some customization is necessary

· Making risk management an essential activity

Adopting COTS products

· Using COTS software

· Decreases some risks

· Such as will our purpose-built solution work?

· But increases others

· Such as will the COTS software work for us and in our environment?

· As always with project risk management

· The objective is to

· Identify, track, manage and mitigate those risks

Customer Satisfaction

· The risks must be established

· Within the context of the customer's organization

· The problem with COTS software is

· Compromises must be made

· Which may or may not be acceptable to the users

· Hence, a close working relationship with the customer and the actual users is essential

· The following slides suggest some technical risk issues to consider

Technical Risks - 1

The following are both positive and negative

· When comparing COTS versus fully custom-built software

· Using COTS software makes for easier and surer project estimating

· Depending on the ratio between COTS and custom building

· Rapid prototyping is easier with COTS software

· To test the proposed system's concept and usability

· It can also be done earlier in the software development cycle

· When alternative approaches can also be compared

Technical Risks - 2

· So, in general, a COTS solution is much cheaper

· Because a lot of the development and testing work has been done

· And the product should be available sooner

· While successful commercial software requires less testing

· Compared to all-custom built products

· Integrating several such products requires more testing

· COTS software usually has support available

· But coordinating multiple sources complicates maintenance and support

· And may stretch beyond the support available

Technical Risks - 3

· Successful commercial software provides a de facto standard

· Reducing risk of user rejection of the interface

· But the customer is at the mercy of the COTS software supplier

· And every upgrade that comes along

· And consequent rework and testing every time

· Worse, if the supplier abandons support

· The customer is left with a legacy application

· Controlling the technology is also difficult

· Especially if proprietary protection is a concern

Customer risk issues - 1

Specific risk issues for the customer to consider

· Staff's comfort and stress level

· Especially if the interface is unfamiliar

· Performance evaluation and incentives

· The new software/system may require less qualified people

· People's jobs and job security

· Especially in the systems department

Customer risk issues - 2

· Training and education effort

· Changing the demands on the personnel department

· Organizational changes

· Leading to changes in the management structure

· Managerial power and influence

· That may be lost or gained

Summary - 1

Benefits of the COTS approach

· More sources

· Better quality

· Newer technology

· Cheaper implementations

· Faster availability

· Easier interconnection

Summary - 2

Disadvantages of the COTS approach

· Exactly the right solution may be elusive

· The COTS product may be subject to changes

· Driven by other users

· Or market forces

· A newer and better product arrives

· That essentially serves the same purpose

· But requires a reworking of the custom system

· Shelf-life is typically limited

· And product support is abandoned by the supplier

Definition: Risk identification is the process of determining risks that could potentially prevent the program, enterprise, or investment from achieving its objectives. It includes documenting and communicating the concern.

Keywords: risk, risk identification, risk management

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) working on government programs are expected to identify risks that could impact the project and program. They are expected to write and review risk statements that are clear, unambiguous, and supported by evidence [1].

Background

Risk identification is the critical first step of the risk management process depicted in Figure 1.

Figure 1. Fundamental Steps of Risk Management [2]Figure 1. Fundamental Steps of Risk Management [2]

The objective of risk identification is the early and continuous identification of events that, if they occur, will have negative impacts on the project's ability to achieve performance or capability outcome goals. They may come from within the project or from external sources.

There are multiple types of risk assessments, including program risk assessments, risk assessments to support an investment decision, analysis of alternatives, and assessments of operational or cost uncertainty. Risk identification needs to match the type of assessment required to support risk-informed decision making. For an acquisition program, the first step is to identify the program goals and objectives, thus fostering a common understanding across the team of what is needed for program success. This gives context and bounds the scope by which risks are identified and assessed.

Identifying Risks in the Systems Engineering Program

There are multiple sources of risk. For risk identification, the project team should review the program scope, cost estimates, schedule (to include evaluation of the critical path), technical maturity, key performance parameters, performance challenges, stakeholder expectations vs. current plan, external and internal dependencies, implementation challenges, integration, interoperability, supportability, supply-chain vulnerabilities, ability to handle threats, cost deviations, test event expectations, safety, security, and more. In addition, historical data from similar projects, stakeholder interviews, and risk lists provide valuable insight into areas for consideration of risk.

Risk identification is an iterative process. As the program progresses, more information will be gained about the program (e.g., specific design), and the risk statement will be adjusted to reflect the current understanding. New risks will be identified as the project progresses through the life cycle.

Best Practices and Lessons Learned

Operational Risk. Understand the operational nature of the capabilities you are supporting and the risk to the end users, their missions, and their operations of the capabilities. Understanding of the operational need/mission (see the Concept Development topic of the Systems Engineering Guide) will help you appreciate the gravity of risks and the impact they could have to the end users. This is a critical part of risk analysis�realizing the real-world impact that can occur if a risk arises during operational use. Typically operational users are willing to accept some level of risk if they are able to accomplish their mission (e.g., mission assurance), but you need to help users to understand the risks they are accepting and to assess the options, balances, and alternatives available.

Technical maturity. Work with and leverage industry and academia to understand the technologies being considered for an effort and the likely transition of the technology

over time. One approach is to work with vendors under a non-disclosure agreement to understand the capabilities and where they are going, so that the risk can be assessed.

Non-Developmental Items (NDI). NDI includes commercial-off-the-shelf and government-off-the-shelf items. To manage risk, consider the viability of the NDI provider. Does the provider have market share? Does the provider have appropriate longevity compared to its competitors? How does the provider address capability problems and release fixes, etc.? What is the user base for the particular NDI? Can the provider demonstrate the NDI, preferably in a setting similar to that of your customer? Can the government use the NDI to create a prototype? All of these factors will help assess the risk of the viability of the NDI and the provider. Seek answers to these questions from other MITRE staff that have worked the area or have used the NDI being assessed.

Acquisition drivers. Emphasize critical capability enablers, particularly those that have limited alternatives. Evaluate and determine the primary drivers to an acquisition and emphasize their associated risk in formulating risk mitigation recommendations. If a particular aspect of a capability is not critical to its success, its risk should be assessed, but it need not be the primary focus of risk management. For example, if there is risk to a proposed user interface, but the marketplace has numerous alternatives, the success of the proposed approach is probably less critical to overall success of the capability. On the other hand, an information security feature is likely to be critical. If only one alternative approach satisfies the need, emphasis should be placed on it. Determine the primary success drivers by evaluating needs and designs, and determining the alternatives that exist. Is a unique solution on the critical path to success? Make sure critical path analyses include the entire system engineering cycle and not just development (i.e., system development, per se, may be a "piece of cake," but fielding in an active operational situation may be a major risk).

Use capability 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 criticality. It may be that the need could be postponed, and the development community should assess when it might be satisfied in the future. Help users and developers gauge how much risk (and schedule and cost impact) a particular capability should assume against the requirements to receive less risky capabilities sooner. In developing your recommendations, consider technical feasibility 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 by trading near-term easy successes for a future of multiple

high-risk requirements that may be essential to overall success.

Key Performance Parameters (KPPs). Work closely with the users to establish KPPs. Overall risk of program cancelation can be centered on failure to meet KPPs. Work with the users to ensure the parameters are responsive to mission needs and technically feasible. The parameters should not be so lenient that they can easily be met, but not meet the mission need; nor should they be so stringent that they cannot be met without an extensive effort or pushing technology�either of which can put a program at risk. Seek results of past operations, experiments, performance assessments, and industry implementations to help determine performance feasibility.

External and internal dependencies. Having an enterprise perspective can help acquirers, program managers, developers, integrators, and users appreciate risk from dependencies of a development effort. With the emergence of service-oriented approaches, a program will become more dependent on the availability and operation of services provided by others that they intend to use in their program's development efforts. Work with the developers of services to ensure quality services are being created, and thought has been put into the maintenance and evolution of those services. Work with the development program staff to assess the services that are available, their quality, and the risk that a program has in using and relying upon the service. Likewise, there is a risk associated with creating the service and not using services from another enterprise effort. Help determine the risks and potential benefits of creating a service internal to the development with possibly a transition to the enterprise service at some future time.

Integration and Interoperability (I&I). I&I will almost always be a major risk factor. They are forms of dependencies in which the value of integrating or interoperating has been judged to override their inherent risks. Techniques such as enterprise federation architecting, composable capabilities on demand, and design patterns can help the government plan and execute a route to navigate I&I risks. Refer to the Enterprise Engineering section of the Systems Engineering Guide for articles on techniques for addressing I&I associated risks.

Information security. Information security is a risk in nearly every 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 cyber attacks. Creating defensive capabilities to cover the spectrum of attacks is challenging and risky. Help the government develop resiliency approaches (e.g., contingency plans, backup/recovery,

etc.). Enabling information sharing across systems in coalition operations with international partners presents technical challenges and policy issues that translate into development risk. The information security issues associated with supply chain management is so broad and complex that even maintaining rudimentary awareness of the threats is a tremendous challenge.

Skill level. The skill or experience level of the developers, integrators, government, and other stakeholders can lead to risks. Be on the lookout for insufficient skills and reach across the corporation to fill any gaps. In doing so, help educate government team members at the same time you are bringing corporate skills and experience to bear.

Cost risks. Programs will typically create a government's cost estimate that considers risk. As you develop and refine the program's technical and other risks, the associated cost estimates should evolve, as well. Cost estimation is not a one-time activity.

Historical information as a guide to risk identification. Historical 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. Customers often have repositories of these to access. Government leaders normally will communicate their strategic needs and challenges. Understand and factor these into your assessment of the most important capabilities needed by your customer and as a basis for risk assessments.

Historical data to help assess risk is frequently available from the past performance assessments and lessons learned of acquisition programs and contractors. In many cases, MITRE staff will assist the government in preparing performance information for a particular acquisition. The AF has a Past Performance Evaluation Guide (PPEG) that identifies the type of information to capture that can be used for future government source selections [3]. This repository of information can help provide background information of previous challenges and where they might arise again�both for the particular type of development activity as well as with the particular contractors.

There are numerous technical assessments for vendor products that can be accessed to determine the risk and viability of various products. One MITRE repository of evaluations of tools is the Analysis Toolshed that contains guidance on and experience with analytical tools. Using resources like these and seeking others who have tried products

and techniques in prototypes and experiments can help assess the risks for a particular effort.

How to write a risk�—a best practice [2]. A best-practice protocol for writing a risk statement is the Condition-If-Then construct. This protocol applies to risk management processes designed for almost any environment. It is a recognition that a risk, by its nature is probabilistic and one that, if it occurs, has unwanted consequences.

What is the Condition-If-Then construct? The Condition reflects what is known today. It is the root cause of the identified risk event. Thus, the Condition is an event that has occurred, is presently occurring, or will occur with certainty. Risk events are future events that may occur because of the Condition present. Below is an illustration of this protocol.

The If is the risk event associated with the Condition present. It is critically important to recognize the If and the Condition as a dual. When examined jointly, there may be ways to directly intervene or remedy the risk event's underlying root (Condition) such that the consequences from this event, if it occurs, no longer threaten the project. The If is the probabilistic portion of the risk statement.

The Then is the consequence, or set of consequences, that will impact the engineering system project if the risk event occurs. An example of a Condition-If-Then construct is illustrated in Figure 2.

Figure 2. Writing a Risk�—The 'Condition-If-Then' Best PracticeFigure 2. Writing a Risk�—The "Condition-If-Then" Best Practice

Encourage teams to identify risks. The culture in some government projects and programs discourages the identification of risks. This may 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 identifying risks and the inability to manage it all in your heads (e.g., determine priority, who needs to be involved, mitigation actions). Assist the government teams in executing a process that balances management investment with value to the outcomes of the project. In general, a good balance is being achieved when the project scope, schedule, and cost targets are being met or successfully mitigated by action plans, and the project team believes risk management activities provide value to the

project. Cross-team representation is a must; risks should not be identified by an individual, or strictly by the systems engineering team (review sources of risk above).

Consider organizational and environmental factors. Organizational, cultural, political, and other environmental factors, such as stakeholder support or organizational priorities, can pose as much or more risk to a project than technical factors alone. These risks should be identified and actively mitigated throughout the life of the project. Mitigation activities could include monitoring legislative mandates or emergency changes that might affect the program or project mission, organizational changes that could affect user requirements or capability usefulness, or changes in political support that could affect funding. In each case, consider the risk to the program and identify action options for discussion with stakeholders. For additional information, see the Risk Mitigation Planning, Implementation, and Progress Monitoring article.

Include stakeholders in risk identification. Projects and programs usually have multiple stakeholders that bring various dimensions of risk to the outcomes. They include operators, who might be overwhelmed with new systems; users, who might not be properly trained or have fears for their jobs; supervisors who might not support a new capability because it appears to diminish their authority; and policy 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 inadvertently overlooked, can pose major risks later in the program. Stakeholders may be keenly aware of various environmental factors, such as pending legislation or political program support that can pose risks to a project that are unknown to the government or MITRE project team. Include stakeholders in the risk identification process to help surface these risks.

Write clear risk statements. Using the Condition-If-Then format helps communicate and evaluate a risk statement and develop a mitigation strategy. The root cause is the underlying Condition that has introduced the risk (e.g., a design approach might be the cause), the If reflects the probability (e.g., probability assessment that the If portion of the risk statement were to occur), and the Then communicates the impact to the program (e.g., increased resources to support testing, additional schedule, and concern to meet performance). The mitigation strategy is almost always better when based on a clearly articulated risk statement.

Expect risk statement modifications as the risk assessment and mitigation strategy is developed. It is common to have risk statements refined once the team evaluates the

impact. When assessing and documenting the potential risk impact (cost, schedule, technical, or timeframe), the understanding and statement of the risk might change. For example, when assessing a risk impact of software schedule slip, the risk statement might be refined to include the need-by date, and/or further clarification of impact (e.g., if the xyz software is not delivered by March 2015, then there will not be sufficient time to test the interface exchanges prior to Limited User Test).

Do not include the mitigation statement in the risk statement. Be careful not to fall into the trap of having the mitigation statement introduced into the risk statement. A risk is an uncertainty with potential negative impact. Some jump quickly to the conclusion of mitigation of the risk and, instead of identifying the risk that should be mitigated (with mitigation options identified), they identify the risk as a sub-optimal design approach. For example, a risk statement might be: If the contractor does not use XYZ for test, then the test will fail. The concern is really test sufficiency. If the contractor does not conduct the test with measurable results for analysis, then the program may not pass limited user test. Use of XYZ may be a mitigation option to reduce the test sufficiency risk.

Do not jump to a mitigation strategy before assessing the risk probability and impact. A risk may be refined or changed given further analysis, which might affect what the most efficient/desired mitigation may be. Engineers often jump to the solution; it is best to move to the next step discussed in the Risk Impact Assessment and Prioritization article to decompose and understand the problem first. Ultimately this will lead to a strategy that is closely aligned with the concern.

Executive Support

1. Executives fail to support project

The project team may lack the authority to achieve project objectives. In such cases, executive management support is fundamental to project success. When this doesn't materialize the project fails.

2. Executives become disengaged with project

Executive management disregards project communications and meetings.

3. Conflict between executive stakeholders disrupts project

Members of executive management are combative to the project or there is a disagreement over project issues at the executive level.

4. Executive turnover disrupts project

A key executive leaves the company, the resulting disruption becomes a project issue.

Scope

5. Scope is ill defined

The general risk of an error or omission in scope definition.

6. Scope creep inflates scope

Uncontrolled changes and continuous growth of scope.

7. Gold plating inflates scope

The project team add their own product features that aren't in requirements or change requests.

8. Estimates are inaccurate

Inaccurate estimates is a common project risk.

9. Dependencies are inaccurate

Dependencies dramatically impact the project schedule and costs.

10. Activities are missing from scope

Required activities are missing from scope definition.

Cost Management

11. Cost forecasts are inaccurate

Inaccurate cost estimates and forecasts.

12. Exchange rate variability

When costs are incurred in foreign currencies exchange rates can have a dramatic impact.

Change Management

13. Change management overload

A large number of change requests dramatically raises the complexity of the project and distracts key resources.

14. Stakeholder conflict over proposed changes

Change requests may be the source of stakeholder conflict.

15. Perceptions that a project failed because of changes

Large numbers of high priority change requests may lead to the perception that the project has failed. When the schedule and budget are continually extended — stakeholders may feel the project missed its original targets.

16. Lack of a change management system

Identify any lack of critical tools as a risk.

17. Lack of a change management process

Change management at the organizational or departmental level is critical to project success. Otherwise, the project will have limited visibility into changes that impact the project.

18. Lack of a change control board

A change control board is essential to managing change for large projects.

19. Inaccurate change priorities

When non-essential changes are prioritized impacting critical schedules.

20. Low quality of change requests

Change requests that are low quality (e.g. ambiguous).

21. Change request conflicts with requirements

Change requests that make no sense in the context of the requirements.

Stakeholders

22. Stakeholders become disengaged

When stakeholders ignore project communications.

23. Stakeholders have inaccurate expectations

Stakeholders develop inaccurate expectations (believe that the project will achieve something not in the requirements, plan, etc).

24. Stakeholder turnover

Stakeholder turnover can lead to project disruptions.

25. Stakeholders fail to support project

When stakeholders have a negative attitude towards the project and wish to see it fail.

26. Stakeholder conflict

Disagreement between stakeholders over project issues.

27. Process inputs are low quality

Inputs from stakeholders that are low quality (e.g. business case, requirements, change requests).

Communication

28. Project team misunderstand requirements

When requirements are misinterpreted by the project team a gap develops between expectations, requirements and work packages.

29. Communication overhead

When key project resources spend a high percentage of their time engaging stakeholders on project issues and change requests their work may fall behind.

30. Under communication

Communication is a challenge that's not to be underestimated. You may need to communicate the same idea many times in different ways before people remember it.

31. Users have inaccurate expectations

The risk that users believe the project is building an apple when you're really building an orange (i.e. users don't understand the product that's coming their way).

32. Impacted individuals aren't kept informed

A stakeholder is missing in your communication plan. Anyone who isn't informed but is impacted has an excellent reason to throw up project roadblocks. For example, if you build a system but fail to consult the operations group that will be responsible for support.

Resources & Team

33. Resource shortfalls

Inability to secure sufficient resources for the project.

34. Learning curves lead to delays and cost overrun

When your project team need to acquire new skills for the project there's a risk that productivity will be low.

35. Training isn't available

Quality training for certain skills can be difficult to secure.

36. Training is inadequate

Training is often a poor substitute for professional experience. Projects shouldn't assume that resources will be fully productive in a new skill.

37. Resources are inexperienced

Resources who are just out of school or who are new to your industry or profession tend to make more mistakes and be less productive.

38. Resource performance issues

Resources who perform below expectations.

39. Team members with negative attitudes towards the project

Resources who are negative towards the project may actively or passively sabotage project efforts.

40. Resource turnover

Resource turnover leads to delays and cost overrun.

41. Low team motivation

Your team lacks motivation. This is a particularly common risk for long running projects.

42. Lack of commitment from functional managers

In a matrix organization your team may report to functional managers. These functional managers are important stakeholders whose support is critical.

Architecture

43. Architecture fails to pass governance processes

Plan for any architectural or technology governance processes that the project may need to pass.

44. Architecture lacks flexibility

The architecture is incapable of supporting change requests and needs to be reworked.

45. Architecture is not fit for purpose

The architecture is low quality.

46. Architecture is infeasible

The architecture is impossible to implement, excessively costly or doesn't support the requirements.

Design

47. Design is infeasible

The design isn't possible, is excessively costly or doesn't support the requirements.

48. Design lacks flexibility

A poor design makes change requests difficult and costly.

49. Design is not fit for purpose

The design is low quality.

50. Design fails peer review

It's a good idea to have peers or architectural experts review your designs.

Technical

51. Technology components aren't fit for purpose

Technology components are low quality.

52. Technology components aren't scalable

Components that can't be scaled to meet performance demands.

53. Technology components aren't interoperable

Components that lack standard interfaces.

54. Technology components aren't compliant with standards and best practices

Non-standard components that violate best practices.

55. Technology components have security vulnerabilities

Security vulnerabilities are key technology risks.

56. Technology components are over-engineered

A component that's bloated with unneeded functionality and design features.

57. Technology components lack stability

Components that crash.

58. Technology components aren't extensible

Components that are difficult to extend with new capabilities.

59. Technology components aren't reliable

Components that fail after a short time.

60. Information security incidents

The risk of a a security incident during the project (e.g. information is leaked).

61. System outages

Critical systems such as your test environments go down.

62. Legacy components lack documentation

Integration with undocumented legacy components is a high risk activity.

63. Legacy components are out of support

Integration with legacy components that are no longer in support.

64. Components or products aren't maintainable

Technology components, tools or platforms that are difficult to maintain (e.g. lacking documentation, rare skills, complex or experimental).

65. Components or products can't be operationalized

Technology operations may have criteria for operationalization of new systems that need to be met.

66. Project management tool problems & issues

Technical problems with the project management tools themselves.

Integration

67. Delays to required infrastructure

Delays to infrastructure such as hardware or software.

68. Failure to integrate with business processes

The risk that your product will fail to fit into the existing business.

69. Failure to integrate with systems

The risk that your product will fail to integrate with existing systems.

70. Integration testing environments aren't available

The risk that environments won't be available to test integration.

71. Failure to integration with the organization

The risk that your project fails to integrate with the organization. This happens when the project is focused on delivering something specific and fails to look at the organization as a whole. For example, you deliver a sales system but your organization doesn't have a sales team.

72. Failure to integrate components

The risk that product components will fail to integrate with each other. This can represent a significant risk when you've outsourced work to a large number of vendors.

73. Project disrupts operations

The last thing you want is for your project to disrupt business operations and damage the firm's financial results. Think about risks beyond project failure.

74. Project disrupts sales

The risk that the project disrupts sales effectiveness.

75. Project disrupts compliance

The risk that the project disrupts compliance processes such as audits and reporting.

Requirements

76. Requirements fail to align with strategy

Your requirements conflict with the firm's strategy. If you sense that this is the case, list it as a risk.

77. Requirements fail to align with business processes

The requirements make no sense in the context of the business.

78. Requirements fail to align with systems

The requirements fail to align with other systems (e.g. they duplicate functionality).

79. Requirements have compliance issues

If you have any doubt that requirements comply with the law list it as a risk.

80. Requirements are ambiguous

Requirements are unclear and open to interpretation.

81. Requirements are low quality

Requirements aren't fit for purpose.

82. Requirements are incomplete

You can spot obvious holes in the requirements.

Decisions & Issue Resolution

83. Decision delays impact project

Establish guidelines for decision turnaround time. Identify the risk that guidelines will be exceeded.

84. Decisions are ambiguous

Stakeholders may have a tendency to make decisions that are intentionally ambiguous (a responsibility avoidance technique). This can be identified as a risk and managed.

85. Decisions are low quality

Decisions aren't fit for purpose.

86. Decisions are incomplete

Issue resolutions that don't address the issue or create more issues.

Procurement

87. No response to RFP

The risk that there is limited response to an RFP. This occurs when the RFP terms are unacceptable to vendors or if your firm has a bad reputation amongst vendors.

88. Low quality responses to RFP

Half hearted responses to your RFP that are unusable.

89. Failure to negotiation a reasonable price for contracts

Inability to negotiate a reasonable price for contracts. This occurs when the requirements or contract terms make vendors nervous.

90. Unacceptable contract terms

Inability to negotiate acceptable contract terms.

91. Conflict with vendor leads to project issues

The relationship with vendor turns to conflict and project issues mount.

92. Conflict between vendors leads to project issues

Your vendors develop conflict with each other and cooperation breaks down.

93. Vendors start late

The risk of a late start.

94. Vendor components fail to meet requirements

A vendor misunderstands requirements or delivers components that are completely off the mark.

95. Vendor components are low quality

Vendor components aren't fit for purpose.

96. Infrastructure is low quality

Your infrastructure fails or is not fit for purpose.

97. Service quality is low

Services you procure such as consulting are not fit for purpose.

98. Vendor components introduce third party liability

Vendor components introduce liability (e.g. they violate patents).

99. Loss of intellectual property

Vendors spy on you.

Authority

100. Project team lack authority to complete work

If you lack specific authorities required to deliver the project list this as a risk.

101. Authority is unclear

It's unclear who has the authority to accomplish a project objective.

Approvals & Red Tape

102. Delays to stakeholder approvals impact the project

The risk that approval deadlines will be exceeded.

103. Delays to financial approvals impact the project

The risk of delays to financial approvals and processes to release funds.

104. Delays to procurement processes impact the project

Many organizations have specific procurement processes that must be followed. These processes can be time consuming and highly variable. Document the risk that procurement process will exceed deadlines.

105. Delays to recruiting processes impact the project

If your project involves recruiting resources, this will typically take many months and is highly variable.

106. Delays to training impact the project

If your training budget requires separate approvals (e.g. from functional managers or HR) document the risk that this will be slow.

Organizational

107. The project fails to match the organization's culture

A culture fit issue between your product and the organization. If the organization's culture calls for employees to bring their own mobile devices to work (BYOD) and you build a user interface that only works on a specific device.

108. An organizational restructuring throws the project into chaos

If your project has a large footprint it may be extremely sensitive to organizational changes.

109. A merger or acquisition disrupts the project

Mergers & acquisitions may represent significant organizational changes.

External

110. Legal & regulatory change impacts project

If your project spans areas that are compliance-sensitive you may want to list regulatory change as a risk.

111. Force Majeure (e.g. act of nature) impacts project

Major disruptions such as acts of nature.

112. Market forces impact project

Market changes impact project (e.g. a market crash).

113. Technical change impacts project

A technology innovation changes your industry and impacts the project.

114. Business change impacts project

A business innovation changes your industry and impacts the project.

Project Management

115. Failure to follow methodology

If your organization asks you to streamline your project management methodology, that can be documented as a risk.

116. Lack of management or control

A lack of project management should be documented as a risk. For example, if resource constraints cause the project to skip certain project management best practices.

117. Errors in key project management processes

Errors in project management such as schedule errors.

Secondary Risks

118. Counterparty risk

The risk you get back when you transfer a risk.

User Acceptance

119. Users reject the prototype

One of the key methods of improving user acceptance is to get regular prototypes in front of users. There's always a risk that these prototypes will be rejected (require significant rework).

120. User interface doesn't allow users to complete tasks

The risk that the user interface doesn't allow users to complete end-to-end tasks.

121. User interface is low quality

The user interface is buggy, slow or difficult to use.

122. User interface isn't accessible

In many jurisdictions, user interfaces must be accessible (e.g. employment or consumer law). Many organizational cultures require accessible user interfaces.

123. Project reduces business productivity

Users identify your product(s) as reducing their productivity.

124. Project reduces innovation

Users identify your product(s) as a roadblock to innovation.

125. Product disrupts business metrics (measurements of objectives)

Your product launch causes business KPIs to worsen. For example, if you launch a new ERP and Supply Chain Cycle Times jump.

126. Users reject the product

The general risk that users will reject your product.

Commercial

The following risks may apply to new product development projects.

127. Product doesn't sell

Demand risk for the new product.

128. Product incurs legal liability

The product has quality issues that harm your customers.

129. Product negatively affects brand

The product has quality issues that damage your brand.

130. Product negatively affects reputation

The product generates negative publicity and/or damages customer relationships.

Lists of risks

Product size risks

Estimated size of the product in LOC or FP?

Degree of confidence in estimated size estimate?

Estimated size of product in number of programs, files, transactions?

Percentage deviation in size of product from average for previous products?

Size of database created or used by the product?

Number of users of the product?

Number of projected changes to the requirements for the product? Before delivery? After delivery?

Amount of reused software?

Business impact risks

Affect of this product on company revenue?

Visibility of this product by senior management?

Reasonableness of delivery deadlines?

Number of customers who will use this product and the consistency of their needs relative to the product?

Number of other products/systems with which this product must be interoperable?

Sophistication of end users?

Amount and quality of product documentation that must be produced and delivered to the customer?

Governmental constraints on the construction of the product?

Costs associated with late delivery?

Costs associated with a defective product?

Customer related risks

Have you worked with he customer in the past?

Does the customer have a solid idea of what is required?

Has the customer taken the time to write this down?

Will the customer agree to spend time in formal requirements gathering meetings to identify project scope?

Is the customer willing to establish rapid communication links with the developer?

Is the customer willing to participate in reviews?

Is the customer technically sophisticated in the product area?

Is the customer willing to let your people do their job that is, will the customer resists looking over your shoulder during technically detailed work?

Does the customer understand the software engineering process?

Developement environment risks

Is a software project management tool available?

Is a software process management tool available?

Are tools for analysis and design available?

Do analysis and design tools deliver methods that are appropriate for the product to be built?

Are compilers or code generators available and appropriate for the product to be built?

Are testing tools available and appropriate for the product to be built?

Are software configuration management tools available?

Does the environment make use of a database or repository?

Are all the software tools integrated with one another?

Have members of the project teams received training in each of the tools?

Are local experts available to answer questions about the tools?

Is on-line help and documentation for the tools adequate?

Process issue risks

Does your senior management support a written policy statement that emphasizes the importance of a standard process for software development?

Has your organization developed a written description of the software process to be used on this project?

Are staff members signed-up to the software process as it is documented and willing to use it?

Is the software process used for other projects?

Has your organization developed or acquired a series of software engineering training courses for managers and technical staff?

Are published software engineering standards provided for every software developer and software manager?

Have document outlines and examples been developed for all deliverables defined as part of the software process?

Are formal technical reviews of the requirements specification, design, and code conducted regularly?

Are formal technical reviews of test procedures and test cases conducted regularly?

Are 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 project conforms with software engineering standards?

Is configuration management used to maintain consistency among system/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, software requirements specification, and software development plan for each subcontract?

Is a procedure followed for tracking and reviewing the performance of subcontractors?

Staff size and experience

Are the best people available?

Do the people have the right combination of skills?

Are enough people available?

Are staff committed for entire duration of the project?

Will some staff be working only part time on this project?

Do staff have the right expectations about the job at hand?

Have staff received necessary training?

Will turnover among staff be low enough to allow continuity?

Technical issue risks

Are facilitated application specification techniques used to aid in communication between the customer and developer?

Are specific methods used for software analysis?

Do you use a specific method for data and architecture designs?

Is more then 90% of your code written in a high order language?

Are specific conventions for code documentation defined and used?

Do you use a specific method for test case design?

Are software tools used to support software planning and tracking activities?

Are configuration management software tools used to control and track change activity throughout the software process?

Are software tools used to support the software analysis and design process?

Are tools used to create software prototypes?

Are software tools used to support the testing process?

Are software tools used to support the production and management of documentation?

Are quality metrics collected for all software projects?

Are productivity metrics collected for all software projects?

Technology risks

Is the technology to be built new to your company?

Do the customer requirements demand the creation of new algorithms, input or output technology?

Does the software interface with new or unproven hardware?

Does the software to be built interface with a database system whose function and performance have not been proven in this application area?

Does the software to be built interface with vendor supplied software products that are unproven?

Is a specialized user interface demanded by product requirements?

Do requirements for the product demand the creation of program components that are unlike any previously developed by your organization?

Do requirements demand the use of new analysis, design, or testing methods?

Do requirements demand the use of unconventional software development methods,

such as formal methods, AI-based approaches, artificial neural networks?

Do requirements put excessive performance constraints on the product?

Is the customer uncertain that the functionality requested is "do-able"?

Other potential risks

Schedule, resources, and product definition have all been dictated by the customer or upper management and are not in balance

Schedule is optimistic, "best case," rather than realistic, "expected case"

Schedule omits necessary tasks · Schedule was based on the use of specific team members, but those team members were not available

Cannot build a product of the size specified in the time allocated

Product is larger than estimated (in lines of code, function points, or percentage of previous project's size)

Effort is greater than estimated (per line of code, function point, module, etc.)

Re-estimation in response to schedule slips is overly optimistic or ignores project history

Excessive schedule pressure reduces productivity

Target date is moved up with no corresponding adjustment to the product scope or available resources

A delay in one task causes cascading delays in dependent tasks

Unfamiliar areas of the product take more time than expected to design and implement Organization and management

Project lacks an effective top-management sponsor

Project languishes too long in fuzzy front end

Layoffs and cutbacks reduce team's capacity

Management or marketing insists on technical decisions that lengthen the schedule

Inefficient team structure reduces productivity

Management review/decision cycle is slower than expected

Budget cuts upset project plans

Are the best people available

Do the people have the right kind of skills

Are enough people available

Are staff committed for the duration

Will some staff be working part-time

Do staff have the right expectations about the job at hand

Has the staff received the necessary training

Will staff turnover be low enough to allow continuity

Management makes decisions that reduce the development team's motivation

Non-technical third-party tasks take longer than expected (budget approval, equipment purchase approval, legal reviews, security clearances, etc.)

Planning is too poor to support the desired development speed

Project plans are abandoned under pressure, resulting in chaotic, inefficient development

Management places more emphasis on heroics than accurate status reporting, which undercuts its ability to detect and correct problems Development environment

Facilities are not available on time

Facilities are available but inadequate (e.g., no phones, network wiring, furniture, office supplies, etc.)

Facilities are crowded, noisy, or disruptive

Development tools are not in place by the desired time

Development tools do not work as expected; developers need time to create workarounds or to switch to new tools

Development tools are not chosen based on their technical merits, and do not provide the planned productivity

Is a software project management tool available

Is a software process management tool available

Are tools for analysis and design available

Do analysis and design tools deliver methods that are appropriate for the project to be built

Are compilers or code generators available and appropriate for the product to be built

Are software configuration management tools available

Does the environment make use of a database or repository

Are all software tools integrated with each other

Have members of the project team received training in each of the tools

Are 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 ultimately finds product to be unsatisfactory, requiring redesign and rework

End-user does not buy into the project and consequently does not provide needed support

End-user input is not solicited, so product ultimately fails to meet user expectations and must be reworked Customer

Customer insists on new requirements

Customer review/decision cycles for plans, prototypes, and specifications are slower than expected

Customer will not participate in review cycles for plans, prototypes, and specifications or is incapable of doing so-resulting in unstable requirements and time-consuming changes

Customer communication time (e.g., time to answer requirements-clarification questions) is slower than expected

Customer insists on technical decisions that lengthen the schedule

Customer micro-manages the development process, resulting in slower progress than planned

Customer-furnished components are a poor match for the product under development, resulting in extra design and integration work

Customer-furnished components are poor quality, resulting in extra testing, design, and integration work and in extra customer-relationship management

Customer-mandated support tools and environments are incompatible, have poor

performance, or have inadequate functionality, resulting in reduced productivity

Customer will not accept the software as delivered even though it meets all specifications

Customer has expectations for development speed that developers cannot meet

Have you worked with the customer in the past

Does the customer have a solid idea of what is required

Will the customer agree to spend time in formal requirements gathering meetings to identify project scope

Is the customer willing to participate in reviews

Is the customer technically sophisticated in the product area

Is the customer willing to let your people do their job - that is will the customer resist looking over your shoulder and make changes as you go

Does the customer understand the software process Contractors

Contractor does not deliver components when promised

Contractor delivers components of unacceptably low quality, and time must be added to improve quality

Contractor does not buy into the project and consequently does not provide the level of performance needed

Requirements have been baselined but continue to change

Requirements are poorly defined, and further definition expands the scope of the project

Additional requirements are added

Vaguely specified areas of the product are more time-consuming than expected Product and product size

Error-prone modules require more testing, design, and implementation work than expected

Unacceptably low quality requires more testing, design, and implementation work to correct than expected

Development of the wrong software functions requires redesign and implementation

Development of the wrong user interface results in redesign and implementation

Development of extra software functions that are not required (gold-plating) extends the schedule

Meeting product's size or speed constraints requires more time than expected, including time for redesign and reimplementation

Strict requirements for compatibility with existing system require more testing, design, and implementation than expected

Requirements for interfacing with other systems, other complex systems, or other systems that are not under the team's control result in unforeseen design, implementation, and testing

Pushing the computer science state-of-the-art in one or more areas lengthens the schedule unpredictably

Requirement to operate under multiple operating systems takes longer to satisfy than expected

Operation in an unfamiliar or unproved software environment causes unforeseen problems

Operation in an unfamiliar or unproved hardware environment causes unforeseen problems

Development of a kind of component that is brand new to the organization takes longer than expected

Dependency on a technology that is still under development lengthens the schedule

Estimated size of the product in LOC or FP

Degree of confidence in estimated size estimate

Estimates size of product in number of programs, files, transactions

Percentage deviation in size of product from average for previous products

Size of data base created or used by the product · Number of users of the product

Number of projected changes to the requirements for the product before delivery after delivery

Amount of reused software Business impact risks

Effect of this product on company revenue

Visibility of this product to senior management

Reasonableness of delivery deadline

Number of customers who will use this product and the consistency of their needs relative to the product

Number of other products/systems with which this product must be interoperable

Sophistication of end users

Amount and quality of product documentation that must be produced and delivered to the customer

Governmental constraints on the construction of the product

Costs associated with late delivery

Costs associated with a defective product External environment

Product depends on government regulations, which change unexpectedly

Product depends on draft technical standards, which change unexpectedly Technology risks

Is the technology to be built new to your organization

Do the customers requirements demand the creation of new algorithms or input and output technology

Does the software with new or unproven hardware

Does the software interface with vender supplied software

Does the software interface with unproven database technology

Is a specialized user interface demanded by product requirements

Do requirements for the product demand the creation of program components that are unlike any previously developed by your organization

Do requirements demand the use of new analysis, design, or testing methods

Do requirements demand the use of unconventional software development methods

Do requirements put excessive performance constraints on the product

Is the customer uncertain that the functionality requested is doable Personnel

Hiring takes longer than expected

Task prerequisites (e.g., training, completion of other projects, acquisition of work permit) cannot be completed on time

Poor relationships between developers and management slow decision making and

follow through

Team members do not buy into the project and consequently does not provide the level of performance needed

Low motivation and morale reduce productivity

Lack of needed specialization increases defects and rework

Personnel need extra time to learn unfamiliar software tools or environment

Personnel need extra time to learn unfamiliar hardware environment

Personnel need extra time to learn unfamiliar programming language

Contract personnel leave before project is complete

Permanent employees leave before project is complete

New development personnel are added late in the project, and additional training and communications overhead reduces existing team members' effectiveness

Team members do not work together efficiently

Conflicts between team members result in poor communication, poor designs, interface errors, and extra rework

Problem team members are not removed from the team, damaging overall team motivation

The personnel most qualified to work on the project are not available for the project

The personnel most qualified to work on the project are available for the project but are not used for political or other reasons

Personnel with critical skills needed for the project cannot be found

Key personnel are available only part time

Not enough personnel are available for the project

People's assignments do not match their strengths

Personnel work slower than expected

Sabotage by project management results in inefficient scheduling and ineffective planning

Sabotage by technical personnel results in lost work or poor quality and requires rework Design and implementation

Overly simple design fails to address major issues and leads to redesign and reimplementation

Overly complicated design requires unnecessary and unproductive implementation overhead

Inappropriate design leads to redesign and reimplementation

Use of unfamiliar methodology results in extra training time and in rework to fix first-time misuses of the methodology

Product is implemented in a low level language (e.g., assembler), and productivity is lower than expected

Necessary functionality cannot be implemented using the selected code or class libraries; developers must switch to new libraries or custom-build the necessary functionality

Code or class libraries have poor quality, causing extra testing, defect correction, and rework

Schedule savings from productivity enhancing tools are overestimated

Components developed separately cannot be integrated easily, requiring redesign and rework Process

Amount of paperwork results in slower progress than expected

Inaccurate progress tracking results in not knowing the project is behind schedule until late in the project

Upstream quality-assurance activities are shortchanged, resulting in time-consuming rework downstream

Inaccurate quality tracking results in not knowing about quality problems that affect the schedule until late in the project

Too little formality (lack of adherence to software policies and standards) results in miscommunications, quality problems, and rework

Too much formality (bureaucratic adherence to software policies and standards) results in unnecessary, time-consuming overhead

Management-level progress reporting takes more developer time than expected

Half-hearted risk management fails to detect major project risks

Software project risk management takes more time than expected

Does senior management support a written policy statement that emphasizes the

importance of a standard process for software development

Has your organization developed a written description of the software process to be use on this project

Are staff members "signed up" to the software process as it is documented and willing to use it

Is the software process used for other projects

Has your organization developed or acquired a series of software engineering training courses for managers and technical staff

Are published software engineering standards provided for every software developer and software manager

Have documentation outlines and examples been developed for all deliverables defined as part of the software process

Are formal technical reviews of the requirements specification, design, and code conducted regularly

Are formal technical reviews of test procedures and test cases conducted regularly

Are the results of formal reviews documented, including errors found and resources used

Is there some mechanism for ensuring that work conducted on a project conforms with software engineering standards

Is configuration management used to maintain consistency among system 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

Are facilitated application specification techniques used to aid in communication between the customer and developer

Are specific methods used for software analysis

Do you use a specific method for data and architectural design

Is more than 90 percent of your code written in a high order language · Are specific conventions for code documentation defined and used

Do you use specific methods for test case design

Are software tools used to support planning and tracking activities

Are configuration management software tools used to control and track change activity throughout the software process ·

Are software tools used to support the software analysis and design process

Are tools used to create software prototypes

Are software tools used to support the testing process

Are software tools used to support the production and management of documentation

Are quality metrics collected for all software projects

Are productivity metrics collected for all software projects