The document discusses methods for identifying and assessing risk in software projects. It lists common risks like project size, business impact, customer characteristics, and development environment. It then provides 11 questions to assess overall project risk, focusing on factors like management commitment, user involvement, requirements stability, team skills, and resource adequacy. The degree of project risk is said to be directly proportional to the number of negative answers to these questions.

1. Risk Management

2. Risk Identification One method for identifying risk is to create a risk item checklist(in this we have included predictable risks for generic subcategories) Product Size – risk associated with the overall size of the s/w to be built. Business impact – risk associated with constraints imposed by management or the marketplace . Customer characteristics – risk associated with the communication of customer and the developer's ability. Process definition – risk associated with the degree to which the software process has been defined. Development environment – risk associated with the availability and quality of the tool to be used to build a product. Technology to be build – risk associated with the complexity of the system to be built. Staff size and experience – risk associated with the overall technical and project experience of the s/w engineers who will do the work.

3. Assessing overall project Risk Following questions arranged in the relative importance to the success of a project :- 1) Have top software and customer managers formally committed to support the project ? 2) Are end-users enthusiastically committed to the project and the system/product to be build? 3) Are requirement fully understood by the software engineering team and its customers? 4) Have customer been involved fully in the definition of requirement ? 5) Do end-users have realistic expectations? 6) Is project scope stable ? 7) Does the software engineering team have the right mix of skills? 8) Are project requirement stable ? 9) Does the project team have experience with the technology to be implemented? 10) Is the number of people on the project team adequate to do the job? 11) Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built? “ The degree to which the project is at risk is directly proportional to the number of negative response to these questions”