Software Project Risk Management Practice in Oman

Oman is a member of Gulf Cooperation Council (GCC). It is located in Southwest Asia and it has strategic significant boundaries, Overlooking the Arabian Sea, Gulf of Oman, and the Persian Gulf. It is the 80th in Global Innovation Index in 2019 and 63 in E-Government Development Index in 2018. Oman is an effective member of the Greater Arab Free Trade Agreement (GAFTA) and the World Trade Organization (WTO). Furthermore, Oman's government has continued efforts to develop local and foreign investments by signing a Free Trade Agreement (FTA) with the USA. Oman plays a significant role in investments due to its strategic location connected to the markets in the Gulf, the Middle East, Asia, and Africa. Oman's vision is to involve all new technologies to be always beside the developed countries. To achieve that, Oman established The Government Innovation Initiative to encourage government entities in creativity and introduce their suggestions to enhance governmental performance and enhance the efficiency in different fields. This is realized by involving modern technologies like the Internet of Things (IoT), Artificial Intelligence (AI), Cloud Computing, Virtual Reality Applications, and Blockchain. In Oman, the risk management approach is a core technique. Three major stages are applied systematically in risk management in software projects. These stages involve a) identifying the risk; b) analyzing and assessing the risk, and c) reaction to the risk. There is no doubt that the high risk belonged to business will have negative impacts on all of its participants. Wherefore, this paper sheds the light on that knowledge area. The aim of this paper is to review the present literature on risk management processes implemented in software projects. There is a dearth in the literature which covers the risk management area knowledge in Oman's organizations. This paper target finding out the commonly used frameworks or mechanisms in risk management in software projects. It also tries to collect the responses to state the various types of risk origins in the existing profit and non-profit organizations in Oman and to recognize the coming research trends in this area. Keywords— Risk Management; Software projects; Oman; Risk Management process; Risk


INTRODUCTION
To have a clear vision of what is the meaning of the concept risks, risk can be defined as the sudden event that may cause a loss/gain or the probability of occurring a loss/gain multiplied by its corresponding magnitude [1].Risks can be categorized as, known, and unknown.
Known risks could be identified and then analysed, which means risk planning, and having preregistered responses is possible for this type. In contrast, it is impossible to proactively plan for an Unknown risk. Thus, such risks should be anticipated, and provide a risk reserve becomes needful and vital [2].Each risk should have an appropriate International Journal of Electrical, Electronics and Computers, 5 (6) Nov-Dec, 2020 | Available: http://eecjournal. response like reduce, manage, transfer, or accepted but cannot be condoned [3].From the project's perspective, risks are the actions, events, situations, or conditions that happen suddenly without previous planning. Their constructive or damaging impact, if they occur, affects one or all of the project objectives such as work range, timeline, budget, and excellence. Risks could be caused by one or more reasons, and they could have an effect or more. The reason could be a demand, constraint, presumption, or even a situation that activates the potential of passive or favourable results [4].Such as, the necessity to have an ecological license to start the job is one of the most prominent project risk cases along with having an insufficient workforce for a large project.To obtain the desired permission, it could take a long time even more than the project schedule. Such reasons lead to direct impacts on the work range, expenses, timeline, value of the project, or execution. Danger conditions may involve organizational resistances, like immature practices of the project steering committee, poor project management systems, competing projects, or outside resources that are out of control [4] [5]. The core issue is the uncertainty that existing in all of the projects. The known risks can be identified and analyzed, which make easy planning for these types of risks. It is of utmost importance to have emergency reserve for all uncommon dangers that are lacking in risk management due to inability to control them proactively [4].Organizations consider the risks as the uncertainty effect on the organization's projects and objectives. It is always the will of the hosting organization and the interested parties to experience some levels of risks based on the perspective they have on. There are three main factors that affect the risk attitudes of the stakeholders and the organization [4]: • Risk appetite: the degree of uncertainty in which it can be accepted as a reason for expecting acompensation. • Risk tolerance: refers to the level, volume, or the much of danger which the institution is going on. • Risk threshold: Is the level of risk effects in which the stakeholders will have interests. Below this limit, the corporation will not consent to the risk and the opposite.
To assure the project success, the organization should adhere to addressing the project risk management proactively and throughout the project lifecycle. Moving forward without concentrating proactively on controlling danger will absolutely lead to more issues that arise from unmanaged menaces [4] [5].
Figure1 provides a summary of the six Project Risk Management processes. The next subsections demonstrate the six stages of risk management briefly.

Plan Risk Management
It is defined as the realizing procedure of the way to apply the activities of risk management for the project. The principal advantage of it is to guarantee the suitability of risk management level, kind and visibility along with the project's importance and risks to the organization. To ensure that risk management operation will be supported and implemented effectively along the project lifecycle, it is crucial to communicate with all stakeholders and obtain their comments and approval [4]. Figure 2 shows the inputs, materials, and outcomes. [4].

Identify Risks
In this process, the risks which could impact the project are determined and document their specifications. The main advantage of this stage is to notarize the current dangers and the scholarships and capability which it offers for the group to expect the events.
The main participants of risk identification are project manager, team, customers, subject experts, end-users, stakeholders, and risk management experts. The process of identifying risks should also include other employees [4].

Perform Qualitative Risk Analysis
It is the process of identifying the risk priorities for more analysis through evaluating and combine their potential apparition and effect. The key purpose of this stage is to qualify the responsible risk owner to minimize the uncertainty scale and concentrate on high priority risks [4].

Perform Quantitative Risk Analysis
It is the technique of performing numeric risk analysis for those which impacts which affect the all-inclusive goals of the project. The process main output is numeric risk information that supports the decision making thus reduce uncertainty in the project [4].

Fig.5: Perform Quantitative Risk Analysis [4].
This analysis is conducted for the risks that their priorities had been identified as high and highly expected to affect the project's competing needs. It is often used to evaluate the total impact of all project risks [4].
This kind of analysis come after the Qualitative one. in some cases, this type of analysis is not serious due to the lack of available information, thus the project manager should involve experts' judgment to determine the need for this analysis and its viability. The Quantitative Risk Analysis should be repeated, as needed, to evaluate and monitor if the total risks decreased satisfactorily. The indications will help to decide whether to increase or decrease the focus on suitable risk management activities [4].

Plan Risk Responses
It is the operation of promoting risks' choices and procedures to maximize the chances and minimize the impedances. The main gain is handling the risks based on their priorities and input the resources and tasks in the financial plan, timeline, and project control scheme as required [4].  [4].
Once deciding to use this process, should have the Quantitative Risk Analysis. Each risk response requires understanding the right mechanism to address them. This mechanism is used to evaluate whether the risk response plan will have the required effect. it includes identifying and assigning one person (risk response owner) to carry the responsibility of each agreed-upon and funded response for risks. The risk responses should be appropriate depending on risk importance, cost-effective to overcome the challenge, reasonable in reality, agreed by all stakeholders, and owned by the in charge of individual [4].
This process provides the popular techniques used for planning the risk responses.

Control Risks
The Control Risks process means performing the danger reaction plans, following-up the determined dangers, observing the rest dangers, defining the abrupt risks, and assessing the productiveness of risks processes management. The main gain of this stage is to improve the competence of the risk tactic during the project lifecycle to constantly enhance the risk restraint [4].  [4].
During the project workflow, the outlined danger responses registered in the danger log are conducted, but there must be constant observation on the process of the project to address abrupt, altered, and outdated dangers.In this process, the performance information which had been collected throughout the project phases are utilized to conduct variance and trend analysis.
In this process, the performance information which had been collected throughout the project phases are utilized to conduct variance and trend analysis.The Managing Dangers process objectives are as follow, but not limited to [4]: • The goodness of the project assumptions are still going on. • The analysis displays that the estimated risks have changed or stopped. • The risk procedures and approaches are followed.

Specify if
• The contingency reserve of expense or timeline should be amended based on the present danger evaluation. Managing dangers may include update the assets in the organization, such as the learned lessons and risk management templates, for future projects use [4].
The most important current life projects are software development projects. A software development project is a complex venture conducted by two or more technical members depending on the resources and schedule. Its outcome is new or developed computer code that plays a significant value in the hosting business organization by speeding or simplifying the existing business processes.
The following sections will shed the light on this area of knowledge.

II. MAJOR RISKS IN SOFTWARE DEVELOPMENT PROJECTS
Software development projects' risks pose a great predicament for project managers. Defining the techniques of mitigating particular risks may support to define the techniques to be applied during the development. Based on a survey study conducted by Jiang & Klein, to Project Management Institute (PMI®) members to identify the major risks that impede the software development projects success, the results identified the following risks [6].
• Project complexity: Software projects are complex and their results often uncertain. This had been confirmed throughout many previous studies in different software projects. The profile of the history of software projects confirms that software projects as complex undertakings. There are different measurement techniques to measure the characteristics of software projects like size and complexity. Performance, stability, compliance, capability, and improvement are the measurement techniques of the five processes of the project respectively. But they are not applicable and not enough to be implemented for the total project measurement based on the rule "in complex systems the whole is more than the sum of parts". Thus, complexity could not be measured unless holistically [7].
The most issue is that the term "complex" is understood in various ways based on context and personal experience. Definitely there is no formal definition for what project complexity really is.Complexity is defined in the dictionary as something difficult to understand but consists of a group of connected and related elements [7].
Project size is a very important feature that could captivate project complexity. Size is one of the program characteristics, in most cases related to the required effort, team productivity, the quality needed, etc.The perfect used approaches for software sizing are accounting the codes lines (LOC), analyse the function point (FPA), use case points (UCP), etc [7].
Baccarini in his study defined two faces for project complication namely the organizational and the technical one [8].The first one means the degree of discrimination that present in the internal elements which make up the organization. One of its important features is the competence or not of the organizational elements to interact [7].
While technical complexity means the degree of differentiation of task in which it has variety in some sides, and the connectivity between tasks inside the grid, between teams, etc [8].
Geraldi and Williams have pointed out in their study the three dimensions of software project complexity namely, faith complexity "CoFaith", fact complexity "CoFact", and Interaction complexity "CoInteraction" [7]. CoFaith is the same as uncertainty because the projects aim to create something adorable or solve hot issues. Generally, at the start of each project, there will be uncertainty on many sides like resources, required effort and etc. The CoFaith reduces during the project progress, thus shifted to fact complexity. Although there is a quantitative way to measure the CoFaith, it is considered as not objective as based on personal views. CoFact is similar to structure complexity. The key issue in measuring CoFact is its connectivity with many interrelated information.
CoInteraction is the connection between interfaces in the applications, systems, and websites [7]. • Technology acquisition : The extremely rapid technological change is a core challenge for project success and hence leads to business death if not be aligned with. The current technological exploding era is mindboggling and can cause firms failure. It creates alternative products, new businesses, new abilities, and improved hacking techniques that do not exist before. As a result, economic changes are born in alignment with technological changes. These cause sudden major risks, especially in software development. Project stakeholders should be always technologically updated to avoid or even mitigate risks when happen. Today, change is fast and software companies compete in chaotic air [9].
External environment alteration leads to internal organizational changes, and as much the former fast the internal be more urgent. In the past two decades, technical people focus to apply many techniques to accelerate the required internal changes. It includes speed the marketing time, reengineering the business processes, software development, supply chain management, quality management, and empowerment methods. Yet nothing is sufficient [10].
Furthermore, instead of implementing smooth internal change, technological paranoia, and urgent change needs have led to crossorganizational internal competitions. This turbulent environment requires a very flexible process that guides the turbulence and combines the competition needs across the organizations in alignment with the strategic trends and priorities of the organization [10].
• Insufficient resources: Once you notice that the project resources cannot cover what had been planned in the project, identify the context. Resources are things utilized to implement the project like staff, equipment, and materials. The reasons for insufficient resources can be [11]: o planning before executing the project or a poor one, major risks could occur and disasters.
To manager project resources two steps are done [11]: o Identify the case and its effect: Once identifying the causes of resource lack, the second part is to define the impacts. without this knowledge, the issue impossible to be solved. o Utilizing the Control Board to change: First, transferring the situation and impact to cost, time, scope, and quality. Next, providing different solutions for the board to get their recommendations. After their approval, apply the solution and during implementation could be modified if needed.
• Lack of team expertise: It refers to a lack of team experience towards the project knowledge areas which absolutely increases the percentage of uncertainty in the project. For example, loss of development experience in the team (LDE), lack of experience related to the desired application in the team, lack of knowledge regarding the assigned tasks, and lack in general experience. All these will result in producing a product or service which does not meet the wished quality [12].
• Lack of user support: User involvement plays a vital role in software development projects.It is considered one of the success factors of project success for many reasons such as [13]: o Firstly, in software development projects the developers, especially at the initial study which called a feasibility study need to understand the current system and its existing issues to be able to gain a deep understanding of the Recently, the wide scope of quality assurance in programming leads to the born of a new term called user experience (UX). User experience (UX) is considered one of the success factors of software development projects' success. Many programming firms face challenges with UX. Although the various definitions of UX all of them are the same in concept. It is the user's comprehensive vision and draws of functionality and quality features of a specific program. Generally, academic and industrial literature differ in their UX perspectives, the former focus on the emotional aspects while the other concentrates on the functionality and usability issues [14].
Nevertheless, often the UX is neglected and still not mature in software development projects. In order to improve the right product, it must be understood the challenges the users face in their daily works. To realize this, firstly must analyse the relations between UX, usability, and another program quality correctly. Thus, the lack of user experience is a risk in software development as they will not be able to discuss their challenges and requirements [14].

• Lack of clear role definition:
Lack of clear roles definition may cause negative impacts on the full firm, particularly at the aspects related to projects. Each project should have a clear list of team members roles like [15]: o What to do is clear for everyone:All responsibilities must be well assigned, and clear, every member knows how to attitude, what to achieve, and how to realize the team's objectives. o Everything gets done: When it is a limited time, small parts of the project could be overlooked especially if no specific one assigned for these tasks. Unlike the projects with well-assigned roles, all tasks will be done even at critical cases. o All team members work better together when understanding their roles: Less competition for the position, and perfect teamwork. o Less energy consumption: In general, when there is a lack of visibility people will waste their energy in unimportant things, negotiate in aspects that do not matter, fail to focus on the crucial areas, and miss out on the chances. Clear roles definition and assign lead to reserve more amount of energy for other purposes. • Intensity of conflicts.
Conflicts happen in our daily life. They could be simple or huge life-threatening. Project managers always face acute disputes that may relate to team building, social variations, preferences, or individual problems that kill the achievement of project objectives. The conflicts are defined in Oxford dictionary as: " Fighting, quarrel, struggle, disagreement, a difference of opinion" and "a clash between hostile or opposing elements or ideas" [16].
Almost all projects use a structural matrix to execute the work, and automatically the conflicts occur due to this structure. A disaster will occur insomuch as the project manager ignores to conduct a resumption session to let team members know each other, especially in large projects. In order to reduce the conflicts, the project manager must motivate and develop his team continuously to realize the desired project objectives [16].
• Common product-related risks: It includes the following: o Gold-plating: This term refers to the team is willing to add unrequired, and unnecessary requirements to satisfy the customer [13]. o Scope creeping: Often the users, especially untechnical, will add more requirements to the scope along the project lifecycle which causes the additional effort to developers and confuse them most of the time as well as delaying the project delivery [17].

III. THE RESEARCH HYPOTHESES DEVELOPMENT
Risk management approach supports project managers to monitor and avoid unmatched project results [18] and gives a share in the project's success.Defeat in managing the risks may could Coase intense consequence on projects and may even result in a complete project failure [19].However, despite the significance and the constant interest of the academia in risk management, literature demonstrate that the implementation of a formal risk management practice is still awkward and not firm [20][21] [22].
Information technology projects are relatively vital and core in Oman, but it is foreseeable that the case will be the same or with little difference. Thence, the researcher sets the posterior hypotheses: Risk management frameworks contain the base steps to be followed while disaster like identification of the risk, analysis, reduction or response, monitoring and control [26][27] [28].Project managers if welling to apply risk management they only implement one of these steps. Someof them execute risk identification without completing the next stages as analysis and response or mitigation. perfect project managers adhere to implement all the steps [29] [30].A recent study done by Bass in 2016 find proof of the effect of risk evaluation on extensive software projects [31].The study demonstrates that mitigation step is specified for every known risk. The 3rd hypothesis is consequently put as: H03:The risk management implementation covers all the sex stages from identification until the monitoring, and control.
H13:The risk management implementation does not cover all the sex stages from identification until the monitoring, and control.
The authors have a consensus that proper risk management is one of the critical success factors of projects.In their research, Zwikael and Ahn (2011) point out that mild risk management designing can reduce the influence of risks and achieve considerable outcomes in project success [23].recognition and planning for known risks that may occur in a project can frequently perfect the opportunity for project prosperity [20] [24].A study done by Microsoft in 1997 shows that a plurality of programming projects does not involve any risk management practices and stuck in the negative results. The study proposes that to invest on risk management can have magnitude effect toward the project success. The analyses present that even 5% of the budget if reserved for risk management can maximize the chance of completing project on time and within budget by 50% -75% [25].Thence, the final hypothesis is determined as: H04:There is a positive relationship between the implementation of risk management practice and the success of software projects.
H14:There is no relationship between the implementation of risk management practice and the success of software projects.

Data Collection
A survey tool was used to gather data with purposive sampling.The survey was designed in such conveniently allow the participant to be able hidden their identity. To encourage the participants to answer the questions honestly, It was obviously mentioned that the personal details will remain secret and hidden. The purposive sampling allows the researcher to collect the responses from right and knowledgeable participants.
Thus, the required information will be efficient more than the one produced from only random sampling. Therefore, the entrants were from the employees using software systems.
Google Forms was used to design the online questionnaire. Google Forms are suitable for the targeted participants because those candidates are belonged to organizations which strictly believe on security. Consequently, Google forms was humbly accepted by respondents as most of the agencies do not block Google applications in their grid. All of the questions included open ended, dichotomous or yes/no, multiple choice and Likert scale question types. All questions involve the answer of 'Other' space to give the respondents more freedom with the chance to replay with their own respond that may not appear in the list of choices. The research instrument is included in the Appendix.Among all targeted organizations, 55 project managers have answered the survey.

Data Analysis
The data gathered from the survey through Google Forms was released to Ms. Excel and then exported to the statistical software SPSS. Excel program was user friendly and helped the author to analyze the gathered data and offering brief information via tables and charts. SPSS has also supported the researcher through the statistical calculations along with graphical interfaces. The statistical tests were conducted to produce data analyzation. The researcher calculated the percentage of successful projects using the budget, project specification and schedule questions. The mean score was computed and used to analyze the risk dimensions and resources which mostly influencing the projects. The researcher tested the statistical significance of risk management practice and risk occurrences using the T-Test test of a single sample. Fisher's exact test was applied to test the relationship between the formal risk management practice and project success.

Demographic Profile
Organization Type My study involved fourteen point five per cent (8) of participants who work in banks, the other 41.8% are from non-profit organizations, the remaining are from profit organizations and universities or collegeswith 23.6% and 20.1% respectively. 63.6% of respondents are working in organizations which contain above 500 employees, while 21.8% of respondents showed that their working place have between 100 and 500 workers. The remaining 14.6% said that they are employed in small agencies.
The type of the project Most of the projects under this discussion (47.3%) were of New software development. While 21.8% of the projects were considered as off-the-shelf software customizations.
Upgrade of an existing program accounted to 30.9%. 41.8% of the projects were developed by outsource local vendors and the rest of 16.4% were outsourced to universal vendors. The remaining 34.5% were developed internally. And 7.3 of the projects were developed by outsourced local and international vendors.
Project Budget Allocation Budget wise, 26 of the projects (47.3%) consumed more than 1000 OR. Five projects (9.1%) wereless than 1000 OR. Eight participants were not sure about the budget allocated to their projects, while sixteen (29.1) respondent replayed no specific budget specified to his project.

The Practice of Risk Management
The practice of risk management is specified as the lowest priority in project management. Unfortunately, many agencies do not consider it in their software projects [32].
But our study found opposite results in Oman software projects.
The T-test was done and the result showed the t Critical one-tail value of 1.674, test statistic value t=-173.395, and p-value of 3.791. Since the test out came with the value of p> alpha value (0.05) and the test statistic value less than t Critical one-tail value , it means the hypothesis H11 is to be refuted, while H01 is raised to confirm that Oman's organizations practice risk management in their software projects (Question 13 was used to test these hypotheses).
60% of the organizations confirmed the use of risk management practice, 56.3% of them implemented the formal models. IEEE framework is the most used one among these firms. 16.4% of the replies assured the use of this model. 14.5% implemented Boehm's risk management framework. 14.5 of organizations conducted the Riskit model.
test statistic value t=-76.943, and p-value of 3.54. Thus, the H02 hypothesis is to be confirmed to say that the formal practice of software project risk management is applied in Oman.
The remaining 16.2% of participants reported that they applied only one or more steps of risk management as their customized model. However, 61.2% of the organizations adhered to all steps from identification through analysis, ending with the proper response and continuous monitoring. The studies also present that it is typical to ignore the application of risk management, unsuccess to implement all risk management steps is also popular [29].
Only 67.3% of participants carry out the risk identification. The rest of 14.5% confirmed that they disregard the step of the identification but keep monitoring the projects during implementation in order to catch the occurrence of any risk. 49 of respondents analyzed and prioritized the risks after identification. 61.2% of repliers specified that they considered the steps of reduction and reaction policy to hold out the risks and their effects. Overall, 61.2% of organizations conduct all risk management steps. The outcome is greater than 50%, so the H03 could be raised but could not confirm hypothesis number H13 thus it could be said that all risk management steps are applied in Oman's organizations.
There were also some participants who were not sure if they apply risk management processes or not. In addition, 18.2% of the respondents were uncertain whether the risk was identified in their projects or not.11.5%of the project managers were not certain whether he prioritized the identified risks or not.

Project Success
If the project completed on time, within the budget, and met all requirements then it is to say that the project is done successfully [33].
Studies suggest that the iron triangle criteria are the most common items used for long time to evaluate the success of a particular project [34].
However, meeting those criteria does not grantee the success of the project [35] [36]. Due to the time limitation, this study considered only these three to categorize the projects as successful or not based on the results. Thus, all the projects which finished on time, within the budget, and comply with all requirements were counted as successful and in contrast, the rest of the projects were perceived as failed.
Most of the projects under the study were perfect in completion. 52.7 of them were completed as scheduled in the preplanned and the remaining 12.7 showed delay in their schedule.
Budget wise, 27.3% of the projects confirmed their alignment with the planned budget. While 20% have overridden their preplanned budget value.29.1% of participants were not sure about the budget were spent for their projects. Out of the total projects, 40% of them were completed on time and within the budget.
25.5 of the projects complied with the initial specifications. Consequently, 6of the projects under the study are successful.

The Link between the implementation of Risk Management and Success
Risk is considered as a principle that could effect in the project success [37] [38] and managing this risk is considered as fateful approach to project success [39] [40]. In this study, the relationship between project success and practicing risk management as displayed in table 1 confirms that there is a positive relation between them. This study assures that no one of the projects which ignore the practice of risk management was successes, and 6 out of 55 from the projects which applied risk management practice success.
Fisher's exact test was implemented to examine the connection between risk management application and project success.
The outcome of this test was a p value of 0.228, which is greater than 0.05 thus it is not statistically significant. Thus, it could not be inferred that project's success influnced by the risk management. In addition, the hypothesis number H14 could nor rejected.

VI. DISCUSSION
Although there is no doubt of the significancy of applying risk management practice, a very low ration of implementing its formal models was noticed. The same perception was found in another study. In their research, Wet and Visser (2013) outcome with a low average of official risk management implementation in programming projects [41].It could be because of set of reasons. The first cause could be the lacking knowledge in formal risk management frameworks amongst project managers in developed countries. Secondly, the intricacy of these frameworks could be a barrier from its implementation. Thirdly, it could because the personal grasp of project managers to the risk management. The same indicated in our findings. Two of respondents reported that they execute the mitigation or response plans without the risk identification. However, they keep monitoring their project and consider it as risk management practice throughout the project stages. This is a signation of non-enough science among project leaders in risk management. The literature presents that limited knowledge in project management is one of project success barriers [42] [43].
In addition, it was demonstrated that most managers implement risk identification, but not proceed to risk analyzation or perform mitigation and response plan. A similar condition was confirmed by Adeleye et al. (2004) were 48.5% of responses assure the risk identification, but only conducted the response and control plans [44]. A similar condition is noticed in African study where 40% out of 35 software projects comply with one or more stages of IEEE framework [41].Further, many project managers were uncertain if their working place implement risk identification or not. This may also confirm the indication of lack of knowledge in the scope of project management. In contrast, this uncertainty may be due to the deficiency in monitoring of the projects. All in all, software projects need to have enhanced management.
This study shows high portion of failed projects which is similar finding in many developed countries [45] [46]. Literature proposes that the participation of risk management allow the project stakeholders to hold the risks on time and with suitable response, thus, maximizes the chance of project success [47] [48].
While our findings show non-significant relationship between the success of the project and the implementation of risk management practice. It is an enough indication of the existence of other project success factors. However, it is out the scope of our study, and future research could explore the other factors lead to Oman's software projects failure.

Limitations
This study conducted in Oman and although the researcher tried to involve all organizations, but not all of them included due to the limited time. Though all the included participants practicing the management of software projects, but the researcher could not relay on their responses to generalize the same in other agencies in Oman. Further study can be done to examine the risk management practices in the business domains in Oman that did not involve in this study.

VII. CONCLUSION
Risk management practice is a crucial item in software project management. However, non-much research focus on this area of knowledge, and from author's review, none conducted in Omani context. This research seeks to give a share in academia by filling this shortage.
A very low per cent of projects was adopted official risk management. It could be as indicator to shed the light by the Oman government on this space of science. However, the project managers emphasized that they implement the practice of risk management through monitor the projects throughout their stages without the need to follow the exact formal steps of risk identification, mitigate or response to them.
Another important result in this study was the doubt of project managers whether they perform or not the risk management. This could be considered as lack of the skills of managing the projects by project managers. The factors affecting the effective management of software projects is a hot topic for future studies in the Omani context.
The examination of the other factors which play significant role in project success could be another chance for the future research due to the finding of low relation between project success and implementing risk management in this study.