Embedded Software Engineering | Project Management | Project Assessments & Framework | Business Analysis | Project Staffing | Offshore Services
About | Business Analysis | Solution Analysis | Business Analysis | Technology Analysis | Risk Analysis | Financial Analysis | Development Planning

Example Risks

 


Technology Risks

At the heart of most new software projects is technology usually very new, perhaps even immature technology. Technology comes in many shapes and sizes. Proposed technology for a project may include incorporating a new Visual Basic component, or it may include integrating a beta version of an enterprise-wide object-oriented database. New technology usually provide the most features and functionality, but at an increased risk. The complexity of the technology also increases risk. What is the risk of implementing a specific technology? Can the same functionality be provided using more mature technology? Equally important, what are the risks of keeping existing technology in place? It may be that implementing that beta version of the new Object oriented database may pale in comparison to that of keeping the legacy system intact. When assessing the risk associated with the technology pieces of the proposed system, Inish uses 1-10 scale to measure such things as technology maturity, the supporting company, the complexity of the technology, and the impact on the proposed system should the technology not pan out.

Vendor Risks

As important as considering the risks associated with third-party technology are assessing the risks of the companies providing the technology. While many risks associated with a particular company are quantifiable such as company financials, many are not. Many varieties of risk are qualitative. Vendor risks include:

  • Company finances
  • Vendor's role in industry
  • Services provided
  • Alliances and affiliations
  • Packages available
  • Future direction
  • Functionality/features and business scope coverage of package
  • Technical capabilities and constraints
  • User and market statistics
  • Industry references

Organizational Risks

Assessment of organizational risk is determined by key stakeholders within the organization and their view of the proposed alternative. Organizational risk can be determined by, but is not limited to:

  • Redistribution of power is the single greatest element that will increase organizational risk.
  • Project lacks an effective executive sponsor
  • Possible layoffs and cutbacks will reduce team's capacity
  • Inefficient team structure
  • Management review/decision cycles is slower than expected
  • Budget cuts
  • Methodology and processes are abandoned under schedule or cost pressures
  • 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
  • Excessive reliance on individual heroics to meet schedule pressures
  • Motivation-reducing management decisions

Financial Risks

Financial risks are any risks that could ultimately cause the company to pay unexpected expenses. These risks are usually thought of in dollar amounts when considering the impact. Financial risk can result from, but are not limited to:

  • Cost overruns
  • Outlays to settle legal disputes
  • Hardware or software failure and replacement
  • Costs of lost data and information
  • The potential cost of reliance upon a sngle vendor without cost controls

Operational Risks

Operational risk is the degree to which a proposed project alternative solves business problems or takes advantage of business opportunities. Will it do what it is expected to do? The business case for any project can be enhanced if it can be linked to the overall strategic plan or the information management plan at the Administration or field level. Alternatives with broader impacts on existing organizational structures or procedures are more risky than those with lesser or more narrow impacts.

  • Excessive administrative overhead
  • Inaccurate progress tracking results in not knowing project issues and problems until late in the project
  • Initial quality-assurance activities are neglected
  • Inaccurate quality tracking results in not knowing quality issues and problems until late in the project
  • Too little formality (lack of adherence to software policies and standards)
  • Too much formality (bureaucratic adherence to technology policies and standards)
  • Facilities are not available
  • Inadequate risk management
  • Facilities are crowded, noisy, or disruptive
  • Facilities are available but inadequate (e.g., no phones, network wiring, furniture, office supplies, etc.)
  • Development tools do not work as expected; developers need time to create workarounds or to switch to new tools
  • Development tools are not in place by the desired time
  • Product depends on government regulations, which change unexpectedly
  • Development tools are not chosen based on their technical merits, and do not provide the planned productivity
  • Product depends on draft technical standards, which change unexpectedly

Legal & Contractual Risks

Legal and Contractual risks refer to the project ramifications that result from the construction of a building, purchase of a machine or service, or development of an information system. Risks may include, but are not limited to:

  • Copyright infringements
  • Non-disclosure
  • Foreign trade regulations (ex: limiting encryption techniques)
  • Antitrust (ex: limiting information sharing)
  • Labor Laws
  • Malpractice
  • Non-disclosure with partner
  • Financial reporting standards
  • Software ownership in joint ventures
  • License agreements