Risk management is the process of identifying, analysing, responding to, and managing risks in a project (CFI, n.d.). When developing a software project, there are many potential risks that need to be considered before development starts. Awareness of risks can help to mitigate the chances of the project going off track, blowing out the project budget & timeframes. The risk management process should include quantitative and qualitative analysis and can be divided into categories of critical, high, medium, or low (Bright Hub PM, 2009). The impact of that risk, then needs to be assessed in terms of cost as well as time taken to mitigate, and or avoid that risk.
OutlineBelow is an outline of the various types of risks and possible solutions that could arise on a software project:
There are various issues that could arise when planning out the project including, inaccurate estimations of the project’s timeframe as well as the project scope. This can cause issues between developers and vendors/users, and this can also lead to higher costs than initially planned (Chien, 2020). A solution to this could be to triage work and only work on the most important tasks first. Another solution would be to make use of project management tools such as a work breakdown structure, workflows, Gantt charts and such. Financial risks include the possibility that the project budget can be exceeded due to lack of proper detailed requirements, extensive planning, guarding against scope creep, gold plating or improper tracking of finances (BrightHub PM).
Scope Creep occurs when unplanned or un-scoped features are added to the software and cause the work to go beyond the agreed-upon scope. Though scope creep should be kept to a minimum, it is usually inevitable that some degree of scope creep will happen in a project as changes will almost always occur in software development. (Larson & Larson, 2009).
Gold PlatingRelated to Scope Creep is gold plating, which is when developers add unspecified/luxury/nice-to-have features to the software. Often gold plating can stem from not having thorough requirements and the onset of the project. It can even stem from developers’ passion for using new technology that may have come to market that they may want to incorporate into the project (Polegoda, 2020).
Risk Mitigation StrategiesA risk mitigation strategy is to have a proper change control system. Any changes to the project will have to be assessed for time, cost, and quality impacts then need to be formally signed off on, so that at each stage, no matter how large or small the change, the client or vendor is aware of what is being added (Larson & Larson, 2009). Likewise, if the vendor or client wishes to make changes, all requests will need to be formally signed off on and timelines updated so that developers and the technical team is aware of the new requirements. In the initial planning stages, people such as business analysts can gather detailed requirements from clients, and this can, in turn, can help to create a robust plan from the initial onset of the project and keep changes to a minimum.
Further Technology Issues and Mitigation Strategies
Further issues can arise when poor quality code is being written, which would lead to unnecessary defects, rework, and client dissatisfaction, as well as cost and time overruns.
Other risks related to software include a lack of expertise to build a system; issues that may be caused by this are lack of modularisation of code. If there are a lot of long functions written into the code, it becomes harder at the testing phase and can further blow out timelines (Rubens, 2014). Using libraries that are not adequate or are vulnerable to security risks can present risks to the timeline, budget, and overall security of the project. It is best to use “industry-standard encryption libraries’ so that you are not having to reinvent the wheel. (Rubens, 2014, para.14).
Moreover, technological risks that need to be considered include digital decay, which is the “wear and tear of binary code” (Haslop, Schnabel & Aydin, 2016). Some software updates can cause certain files to become unreadable and current systems, and libraries you are using may also potentially become obsolete. (MerlinOne, n.d.). To minimise data risk exposure, the 3-2-1 rule should be applied to data security and storage in a project. The 3-2-1 rule states that you need to have three copies of data, on two different media devices, and one of those copies needs to be off-site (Vanover, R 2021). Further issues with this may arise if your project is using legacy systems, which is the use of hardware and software that “was once widely used but has long since been replaced” (Alvarez Group, n.d.). Legacy systems can pose a risk to the overall project budget, timeline, and security as a lot of the new software updates that help to save time and costs and that notify you of security updates are not compatible with legacy systems (Alvarez Group, n.d.).
If a project is making use of cloud computing technology, potential risks associated with this include security and data protection. All data and privacy laws will need to be met, and a reputable third party for cloud hosting should be used. (Queensland Government, n.d.) Location is also a crucial factor, and you will need to ensure that security and privacy laws are applied to your data when it is kept by cloud hosting providers who reside outside your country of project development.