By spending the time to follow the steps in this article you should be able to identify over 80% of the risks on your project. Risk = Probability * Impact All projects have risks. Proactively addressing those risks will save you much needed time and energy when you need it most. This is a guide detailing the most useful methods of identifying risks on your software project, regardless of whether you are guided by a Waterfall approach, Agile, Six Sigma, PMI or PRINCE2. 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 Misunderstanding of the requirements Lack of commitment and support management Lack of adequate user involvement Failure to gain user commitment Failure to manage end user expectation Changes to requirements Lack of an effective project management methodology This study by lists 70 such risks that you can cross reference, with 745 assigned strategies concerned with risks categorised by Process (56%) and People (44%) Kloppenborg, T. J. & Tesch, D. (2004) Risk Identification Techniques Interview Initial one on one interviews (formal or informal) always highlight project insights beyond the common shared knowledge that should be documented in the Business Case / Project Charter documents. Come prepared to these interviews with leading structured questions and take note of not just the risks, but also of any business drivers, assumptions and constraints (for use in CAA process (below)). Questionnaire This basic questionnaire ( ) below follows to identify risks and work through mitigation strategies. While I find this questionnaire the most useful there are others of note from , an international study by and one from all of which have been nicely documented in a research paper by . full questionnaire Boehm Top 10 Software risks suggested Wallace & Keil Schmidt et. al Han & Huang Tharwon Arnuphaptrairong 1. Personnel shortfalls Are the required number of skilled skills available for the project time frame? Question: Staffing with top talent, job matching, team building, key personnel agreements, cross training Mitigation: 2. Unrealistic schedules and budgets Were all requirements & tasks estimated by the team undertaking the work? Question: Have all dependencies between tasks been identified and accounted for? Question: Detailed milestone cost and schedule estimation, design to cost, incremental development, software reuse, requirements scrubbing Mitigation: 3. Developing the wrong functions and properties 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? Question: Organizational analysis, mission analysis, operations-concept formulation, user surveys and user participation, prototyping, early users’ manuals Mitigation: 4. Developing the wrong user interface Has the user interface been prototyped and tested on sample user groups? Question: Are user interface goals defined, documented? Question: Prototyping, scenarios, task analysis, user participation Mitigation: 5. Gold plating Is there a history of unneeded functionality being added during project development? Question: Focus on MVP, Requirements scrubbing, prototyping, cost-benefit analysis, designing to cost Mitigation: 6. Continuing stream of requirements changes 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? Question: High change threshold information hiding, incremental development (deferring changes to later increments) Mitigation: 7. Shortfalls in externally furnished components Are there any delivery risks identified with projects to which this one is dependent? Question: Benchmarking, inspections, reference checking, compatibility analysis Mitigation: 8. Shortfalls in externally performed tasks Is this project or any of its tasks dependent upon the completion of external project development efforts? Question: Reference checking, pre-award audits, award-fee contracts, competitive design or prototyping, team building Mitigation: 9. Real-time performance shortfalls 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? Question: Simulation, benchmarking, modeling, prototyping, instrumentation, tuning Mitigation: 10. Straining computer-science capabilities Has the organization delivered a similar system using similar ? Question: tools Technical analysis, cost-benefit analysis, prototyping, reference checking Mitigation: 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 to plan your approach to your Brainstorming session and utilise these . link best practices Constraints and Assumptions Analysis (CAA) Every project has known assumptions, documented or not. Every time a requirement, function, task or User Story is sized it is built upon underlying . In order to analyse the work to be undertaken you should note your dependencies and business and technical . The exercise to turn these into risks is straight forward. Simply state that each of these assumptions and constraints are false. This is the Risk. Now describe the consequence. This is the Impact. Whether to deal with the impact or mitigate the risk in the first place will be dealt with in a later article. assumptions constraints An example could be: : The ACME payment solution provider will be used to take payment on the site. Assumption : The ACME payment solution provider will not be used to take payment on the site. Inverted Assumption Why would this have happened? Examples could be that the contract will not be signed in time, or your market currency is not supported. Maybe there are legal issues preventing deployment or ACME’s rates are too high. There are many potential issues (which could be brainstormed) that could arise. Each one is a potential risk. Identifying them early allows you to take the necessary steps to investigate their likelihood and/or take steps to mitigate them. 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 behind it, but can simply be explained as this: In three point ( ) 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. complex logic PERT 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 (+2) Pessimistic estimate: = 12 (+9, +7) The PERT formula is: in Excel the PERT formula is: (O+P+4×M)/6, =ROUND(((A1+(B1*4)+C1)/6),0) Conditional Formatting screenshot The Standard Deviation (SD) or σ is , in Excel I use this formula coupled with Conditional Formatting to ‘raise a red flag’ if SD is greater than ‘1’: σ = (P — O)/6 =IF((C1-A1)/6<1,””,((C1-A1)/6)) Force Field Analysis (FAA) Your project already has known objectives and driving forces. Weaken the focuses behind them, identify why they may have weakened and identify the impact on the project. How can you mitigate against this? A much more detailed overview of FAA is found . here Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis Identify the strengths and weaknesses of the end-product in the market and translate these all to risks. If you are not convinced to undertake the academic analysis, are some compelling reasons why you should. here Fishbone/ Ishikawa Diagram (Cause and Effect) Diagramming is usually used during Risk Analysis, but introducing this during the Risk Identify stage can help identify root causes as well as various factors leading to the risk. For this reasons the (Cause and Effect) earns its great reputation as a method to determine the root cause of the problem. This can be useful when converging on a risk. Once the root cause has been identified, the risk can be mitigated. Fishbone Diagram Cyclomatic complexity The of a software program indicates how complex the source code is. This method determined the number of independent paths through a program’s source code. It can guide you, post implementation, as to whether or not a program may contain problems. cyclomatic complexity Failure Mode Effects Analysis (FMEA) is a step by step process used to identify possible failures in design, engineering or deployment of a software product. You start by identifying each function of the software and then identify the modes in which it can fail. Later you look to address them. This process requires a cross functional team for best results. FMEA Delphi Technique Having run a Brainstorming session, you may be wondering if using the Delphi Technique is overkill. The answer is no. The reasons are many but key to them is that fact that you have relevant skilled experts in the room, the technique is formal and structured and their feedback is anonymous. To start a Delphi Technique you ask your panel of experts to openly discuss the project, defining the problems. Based on this, provide them with survey or questionnaire to get their anonymous feedback, collate & publish their results, solicit feedback and repeat until you have everything you need. A good step by step guide can be found . Just remember to act on your findings! here Observational gaps in Risk Breakdown Structures RBS as a Pivot Table It is advisable to represent your risks in a (RBS). ( ) This is achieved by categorising risks based on Scope, Schedule, Quality and Cost. I go a step further and create a sub-category related to the major areas / themes within the project. However, I then use this not to observe what is represented in the structure, but rather what is not. If I get the sense that the schedule is the riskiest part of the project, but that is not represented on the RBS, then I know I have gaps. Similarly, if I sense that a certain theme is the riskiest but that is not obvious from the RBS, then I know that I have to spend more time brainstorming on risks related to that Theme. Risk Breakdown Structure I automate this as a Pivot table in Excel. Residual Risks & Secondary Risks Having dealt with original risk, a secondary risk can arise as a direct result of your risk response. You need to cautiously watch out for these as they can sometimes be worse the initial risk. The most cited example is putting out an animal trap in order to protect your home (risk), but a family member gets caught in it instead (secondary risk). If you had caught the wild animal in the trap, this could now attract other unwanted animals, this is a residual risk. Brainstorming should tease out these types of risks. I have also publishing a Risk Identification article, which you may enjoy more as you weren’t planning on spending this much time trying to uncover loads of risks. Next time, we will review the various analysis techniques that can be used to size and prioritise the risks that you have found. less detailed

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Everything your competitor knows about Risk Identification on Software projects

Too Long; Didn't Read

David OBrien

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Everything your competitor knows about Risk Identification on Software projects

Too Long; Didn't Read

David OBrien

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES