Risk analysis is a critical step in the pre-development phase when undergoing a software development project. At this point, you've already scoped the project and written user stories. During the risk analysis phase, you want to work closely with your development partner to identify risks and effect each may have on timeline, cost, etc.
The Importance of Performing Risk Analysis
It may seem like a waste of time and money to dedicate resources on a risk analysis phase before development begins. But, by identifying and planning for risks early, you're giving yourself a safety net should disaster strike later. Risks can affect your project in many ways, from causing heavy delays to wasting money.
How to Perform Risk Analysis
During the analysis phase, you want your development partner to give you estimates of the timeline and cost of each task, and qualify each estimate with any potential risks. Then for each risk, your development partner should list the party responsible for the risk, the effect of the risk on overall timeline and cost, the effect of the risk on other tasks, and any mitigation actions that can be taken.
A dependency in risk analysis occurs when certain tasks are required to be completed before you can start another task. When you are performing risk analysis, dependent tasks should always be identified together on a chain of linked tasks, also know as a path.
The Critical Path
The critical path of a project is the path that contains the longest sequence of dependent tasks. Throughout your project, you'll have several chains of tasks, but the critical path is the one that could cause the worst delays. Since the critical path must be completed in a set order, any issues that arise at earlier stages of the path will impact all subsequent tasks. You want to identify this path in the analysis phase and make sure to clearly highlight and plan for the potential impacts.
Be Prepared
No matter how much you plan for risks, unforeseen delays are inevitable in many software development projects. There are numerous factors that developers can not control that can affect your project. Below are a few common external risk factors for developers that are partially out of your control.
iOS App Store
If your product is an iOS app, you have to allocate time for App Store reviews. App Store reviews are always performed by humans, so they may take some time to complete especially during times like the COVID-19 pandemic.
For example, if you submit your app to the App Store on Monday, it may not be approved until Tuesday night. According to Apple's Developer resources, they review 90% of apps within 48 hours. If they reject your app, you'll have to fix the issue that reviewers identified before re-submitting your app for review.
For iOS beta releases in TestFlight, your first beta release also has to go through the App Store review process. Subsequent beta releases, however, will not require a review.
Our rule of thumb is: don't push an app update within a week of a major launch event or press release. If you need to have the app in the App Store for a launch party, anticipate the review process. A week of buffer to allow for the review process should be enough.
Google Play Store (Android)
If your product is an Android app, you have to account for Play Store reviews. It's a little more opaque on how Play Store reviews happen. Many developers believe the reviews automated rather than reviewed by humans. This should result in faster review times than the iOS App Store, but according to Google's support page, exceptional cases can result in as long as 7 days for a review.
The same rule goes for Android apps—you should not update your app within a week of a launch event. Build in some buffer to allow for the review process as well as possible rejected submissions that will require some fixes.
Third-Party APIs and Services
Your product is very likely to use multiple third-party APIs and services. Including, but not limited to social logins, a cloud hosting provider, or APIs that provide information to your product. If any of these services experiences an interruption or otherwise limits your usage to the service, there isn't much you can do.
For example, AWS might have an outage, or the API you use to get real-time weather data might cut off your access. There isn't too much you can do to prepare for these types of risks. It helps to be aware of the possibilities so you can have a backup solution ready.
Conclusion
This only scratches the surface of possible sources of risk and is in no way meant to be a comprehensive list of risks to a software product. We hope this guide was helpful in preparing for the risks that come with a software development project. If you have any questions or need help performing risk analysis for your project, don't hesitate to reach out at resources@aloa.co!
For more on Risk Analysis and how we structure our development process to mitigate risks, download our free e-book here.
