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 Misunderstanding of the requirements Lack of t commitment and support managemen 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 Risk Identification Techniques Questionnaire Use this (reduced) questionnaire ( ) to identify risks and work through mitigation strategies, from : full questionnaire suggested Boehm Top 10 Software risks 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 the for brainstorming . link best practices Constraints and Assumptions Analysis (CAA) Your project already has known and is built on multiple . 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? constraints assumptions 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 Pessimistic estimate: = 12 (+9, +7) I have also publishing a 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. more detailed

Too Long; Didn't Read

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

Everything you should know about Risk Identification on Software projects

Too Long; Didn't Read

Company Mentioned

David OBrien

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Everything you should know about Risk Identification on Software projects

Too Long; Didn't Read

Company Mentioned

David OBrien

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES