Rapid Risk Identification

If you have read my earlier post on Risk Management in Software Testing , you would know that the risk management process includes Risk Identification, Risk Prioritization (or Risk Assessment) and Risk Treatment. You will now see how you can identify the relevant risks in your software testing project quickly. See my short video, How to Identify Risks? Risk Management Video or read on...

You may have seen some rapid risk identification in action already. During management reviews of projects. During my career, I have been positively surprised  many times when the management was able to identify potential problems (risks) after just listening to the project progress. In fact, risk management is a critical management skill. Other critical management skills being strategic planning, organizing and communication. If you are not management but want to identify risks in your project fast, here is what you can do.

Use a risks checklist. Here is a checklist that I have based on few common problems in software testing projects. Note that a Yes response to each question indicates the expected state, a No response indicates a risk. You should build your own checklist according to your specific project, client, company and industry needs as well as past learning. Using your checklist would enable you to identify open risks in any software testing project quickly.

Personnel Risks
1. Are the required people available for the duration of the project? Are they available at the required project sites?
2. Are the required people committed to the success of the project?
3. Do the available people have the required skill set and required prior experience? If not, can the skill set and experience be first built and then used within the project time frame?
4. Are the people tracked and managed?
5. Is the management committed to this project?
6. Are the down-stream users available for reviews?
7. Is the team communicating within itself and with other groups? Is the team free from unresolved conflicts?

Schedule Risks
8. Are the effort and duration estimates realistic? Are these estimates acceptable?
9. Is the scope frozen?
10. Is the project free from late changes to the test requirements?
11. Is the project free from external delays?
12. Are the schedule activities and deliverables on track?

Budget Risks
13. Is the funding for the project secure?
14. Have the costs of the required project assets remained the same (i.e. not increased or become nonviable)?

Scope Risks
15. Is the scope of test defined and agreed?
16. Are the test requirements frozen?

Quality Risks
17. Are the software requirements well-understood?
18. Is the software test strategy capable of meeting the objectives of the business, the users and the project?
19. Is there a well-understood process for software test?
20. Are reviews by the users (including administrators), clients and management positive?

Technical Risks
21. Have the pre-project activities found to be viable?
22. Are the test automation tools well-understood?
23. Is the test environment available? Is it sufficient for each test requirement?
24. Are the software test deliverables (e.g. test cases, test scripts, test environments, bug reports and test reports) reviewed and accepted?
25. Is the test management system well-understood?