Everything you should know about Risk Identification on Software projects

By spending just a few minutes to follow the steps in this article you should be able to identify 80% of the risks on your project.

All projects have risks. Proactively addressing those risks will save you much needed time and energy when you need it most. But first, lets define the term risk, as it gives us a greater understanding of our later activities:

Risk is an uncertain event or condition that, if it occurs, has an effect on at least one [project] objective

This statement can be expressed in the following way

Risk = Probability * Impact

For every risk, we will need to understand the probability or likelihood of it occurring and the impact that it would have on a project, if it were to occur.

This is a quick guide, so lets get started in identifying your project risks.

Of note: Common risk areas

Most of your project risks are likely to arise out of the following prioritised areas (according to a study from Tharwon Arnuphaptrairong):

1. Misunderstanding of the requirements
2. Lack of management commitment and support
3. Lack of adequate user involvement
4. Failure to gain user commitment
5. Failure to manage end user expectation
6. Changes to requirements
7. Lack of an effective project management methodology

Risk Identification Techniques

Questionnaire

Use this (reduced) questionnaire (full questionnaire) to identify risks and work through suggested mitigation strategies, from Boehm Top 10 Software risks:

1. Personnel shortfalls

Question: Are the required number of skilled skills available for the project time frame?

Mitigation: Staffing with top talent, job matching, team building, key personnel agreements, cross training

2. Unrealistic schedules and budgets

Question: Were all requirements & tasks estimated by the team undertaking the work?

Question: Have all dependencies between tasks been identified and accounted for?

Mitigation: Detailed milestone cost and schedule estimation, design to cost, incremental development, software reuse, requirements scrubbing

3. Developing the wrong functions and properties

Question: Are the requirements for the system clear and understandable and stable?

Question: Is there a history of misinterpretation or miscommunication between developers and those defining product requirements?

Mitigation: Organizational analysis, mission analysis, operations-concept formulation, user surveys and user participation, prototyping, early users’ manuals

4. Developing the wrong user interface

Question: Has the user interface been prototyped and tested on sample user groups?

Question: Are user interface goals defined, documented?

Mitigation: Prototyping, scenarios, task analysis, user participation

5. Gold plating

Question: Is there a history of unneeded functionality being added during project development?

Mitigation: Focus on MVP, Requirements scrubbing, prototyping, cost-benefit analysis, designing to cost

6. Continuing stream of requirements changes

Question: Has past history with customer shown that requirements change often?

Question: Does the team have a good understanding of what the customer/user wants in the system?

Mitigation: High change threshold information hiding, incremental development (deferring changes to later increments)

7. Shortfalls in externally furnished components

Question: Are there any delivery risks identified with projects to which this one is dependent?

Mitigation: Benchmarking, inspections, reference checking, compatibility analysis

8. Shortfalls in externally performed tasks

Question: Is this project or any of its tasks dependent upon the completion of external project development efforts?

Mitigation: Reference checking, pre-award audits, award-fee contracts, competitive design or prototyping, team building

9. Real-time performance shortfalls

Question: Have requirements for system response time been defined?

Question: Have requirements for data storage, memory & processing speed been defined?

Question: Have user support (number of) requirements been defined?

Mitigation: Simulation, benchmarking, modeling, prototyping, instrumentation, tuning

10. Straining computer-science capabilities

Question: Has the organization delivered a similar system using similar tools?

Mitigation: Technical analysis, cost-benefit analysis, prototyping, reference checking

Brainstorming

Gather the various stakeholders into a room to try to generate as many risks as possible. There are no bad suggestions. Initially, you are looking for as many risks to be mentioned as possible (divergent thinking) before focusing in on some risks and building on them (convergent thinking). If the group get stuck, then steer them towards the various project objectives (schedule, scope, quality, budget) and tasks (requirements, testing etc.)

You may want to use this link to plan your approach to your Brainstorming session and utilise the best practices for brainstorming .

Constraints and Assumptions Analysis (CAA)

Your project already has known constraints and is built on multiple assumptions. Take all of these and invert them or flip them on their head. Now, each one of these should be rewritten as if they failed. You have now identified a material set of risks. For example, if your initial assumption is that your new website will use a certain Payment Provider, then invert this to say that you are now unable to use that Payment Provider. Why would this have happened and what can you do to deal with this?

Standard deviation from Three Point Estimates

Some practices are just learned through experience. This one is mine. I identify so many potential risks based on this method. There is complex logic behind it, but can simply be explained as this: In three point (PERT) estimation, if the difference between the smallest number (optimistic) and the largest number (pessimistic) is large, then you have uncovered a risk. This usually happens without the person estimating the task even realising it.

No Risk identified

• Optimistic estimate = 3
• Most Likely Estimate = 5 (+2)
• Pessimistic estimate: = 7 (+4, +2)

Risk identified

• Optimistic estimate = 3
• Most Likely Estimate = 5
• Pessimistic estimate: = 12 (+9, +7)

I have also publishing a more detailed Risk Identification article for your peers & competitors. You may also enjoy if you wish to dig deeper to uncover more complex risks. Next time, we will review the various analysis techniques that can be used to size and prioritise the risks that you have found.