So this project seems great. You have completed and re-checked all the calculations, covered all types of assessment, applied all categories of expenses and arrived at numbers which appear to be most realistic and accurate. You firmly believe that both top management and your client are definitely going to give you the thumbs up for the project. But is it enough? Are there reasons strong enough to jeopardize the success of the project? These questions are critical and as an estimator, it is your responsibility to tackle them soundly. You are not just entrusted to estimate the software project accurately but to also estimate possible causes of project failure in the long run. Loss estimation signifies risk assessment of the software project.
How can you Assess Risk Associated with Software Estimation?
Assessing risk along with the software estimation process does not have to involve undertaking separate tasks or allocating separate time for each process. It boils down to the software estimation process. As an estimator you are responsible for assessing your project to evaluate its feasibility and associated risks which can hamper success. Project analysis would determine if there has been a past experience of handling a similar project.
1. Studying the past mix of projects would enable the analysis. Evaluating duration, required team size and team mix, required qualitative technical competency, probable technical and project handling issues, cost of resource deployment (cost of resource in a technically complex project would be more as compared to less technical one), etc will assess project feasibility and the risk associated in case of project failure.
2. A feasibility study will land you to the second assessment level – Are you as an organization equipped to handle the project? Technical and strategic expertise of every software project varies. The organization should do an inward analysis of its capability – if the required technical competency is not present in the team then what? Is the cost of hiring outside help justifiable with the project success? Will the cost of hiring high cost resources for the project be in sync with the client’s budget? Do remember there may be other organizations in the industry landscape already possessing the technical expertise and experience in a particular project of certain level of complexity. They may be willing to offer a lower cost estimate and time estimate – as handling several complex projects in the past lends greater confidence and lowers the threshold ease (time) and may not have to spend extra to hire experts in related field(cost).
3. Once you arrive at certain level of confidence, you need to quickly work out the overall estimates – Do not aim to compute all calculations manually as complex projects have variable criteria and you may not wish to spend extra time and inflate budget (hiring technical experts for estimation). Your goal is to do quick estimation and any developer in the team should be capable of doing it. Employing estimation software for the purpose sounds feasible as now you can focus your energy and effort in identifying potential risks. Identifying the risks, classifying them in order of priority and doing contingency planning for the identified risks should be the primary objective of risk assessment.
Broader Risk Definition – Software Project Risks
Software project risks could be due to the following reasons –
Scheduled related risks – Project success might get jeopardized if there has been an incorrect time and scope estimation. Incapability of the team to identify critical complexities associated with functionalities on time and deploy specific technical resources to mitigate those complexities would negatively affect the project stage schedules.
Project related risks – These risks might crop up due to a misunderstanding/poor definition of user requirements or a narrow focus on the software project issues, ignoring the effect on distribution channels and the business in general. Other risks include lack of technical understanding and functional understanding related to the project, incapability to manage – change, user commitment/involvement, management commitment and support; poor resource competency, project complexity, improper cost estimation, improper milestone setting and organizational issues (unstable environment, changes, restructuring, etc). 
Macro-factors related risk – Various external factors beyond control can create risks which are difficult to comprehend and mitigate. Technology related risks are one of them – These risks could be due to a lack of advanced technology in an area of expertise, or a change in existing technology which might make project implementation and testing more complex as the particular project might require the new/advanced (budding) technology. Another macro factor such as change in product related user expectation and priority, market development, government rule change/new rule implementation – can give risk to new dynamics in risk assessment.
Many researchers have listed various dimensions to understanding and categorizing risks to software project success. Broadly speaking, risks to software project success are classified into six major dimensions (as per Wallace et al) – Users, requirements, project complexity, project planning and control, team mix, organizational and macro/environmental factors. 
Estimation of the probability of occurrence of risk factor and assessment of the impact is equally important. The project manager has to rank the various types of risk in order of priority, after its identification. Scenarios, assessment of past or similar situations, discussion with team and related parties – these methods assume that the project manager has the requisite expertise to deal with the risks which might not always be true. The procedures might also be time consuming and costly. Checklists can be used to prevent overlooking a particularly important risk element. Another stream of research is focused on doing factor research and process research to identify elements of risk which affect implementation. Risk associated with requirement determination and software estimation processes are in the top of the list of various risk elements. 
This necessitates treating software estimation as an important element of the overall software development process. As mentioned above, employing an estimation tool for software estimation to produce quick and accurate estimates is of prime importance. We are venturing into this field by developing a unique product for software estimation and handling your estimation related risk. It helps establish a standardized and flexible procedure for estimation and lends high degree of certainty and accuracy. You need to create exact requirements and rest will be taken care of by itself!
To have a glimpse of our product, please register and receive an invite at Quick FPA.
“Top Ten Lists of Software Project Risks :Evidence from the Literature Survey.” Proceedings of the International Multiconference of Engineers and Computer Scientists 2011 Vol1. Hong Kong: IMECS, 2011.
Schmidt, Roy, et al.
“Identififying Software Project Risks: An International Delphi Study.”Journal of Management Information Systems/Spring 2001 Vol 17, No-4 (2001): 8,28. 
L. Wallace and M. Keil.
“Software Project Risk and their Effect on Outcomes” Communication for the ACM vol 47 number 4, pp. 68-73, 2004