Project Risks in App Development: How to Identify and Mitigate Them?

My name is Svitlana, I’m a Head of Business Analysis at Fulcrum Rocks development agency, and we have created tons of cool apps so far. What I usually do is make sure each development project finds its product-market fit. And thus I also take care of reducing project risks.

Table of contents

First thing first, everyone seems to think that project risks are a negative factor. Not really. Everything has risks and before any projects starts you need to foresee those.

What is risk identification and why is it crucial for your product development

Risk identification is the most important stage in project risk management. It determines the possible hazards that can affect the successful launch and development of the project. For example, it can be:

IT security threats (malware and ransomware)
Long app reviewing time
Rejection of AppStore/PlayMarket
Leaving of a team member
Natural disasters, etc

The project manager determines the possible risks → documents their characteristics → creates a plan to mitigate them → creates an action plan. For example:

The roadmap of managing project risks

The problem: security issues & hacker attacks.
How to identify risk: set up regular security checkups & control in AWS Load balancer.
A mitigation plan: alarms for RPS, RAM, and server’s load.
An action plan: create the rate limits for Login/Pass recovery; urgent fixing actions; secure validation for Passwords.

These steps will help mitigate the impact of negative risks on the success of the project.

When to identify risks

At the beginning of the project
Before the development phase
Before the release
After each critical milestone
During roadmap planning

Manage the risks at different stages of product lifecycle

Due to lack of information, vulnerability to hazards is the greatest at the beginning. Hence, experienced project managers identify risks thoroughly at the early stages of development. At Fulcrum, we identify risks during the Discovery phase.

How to identify risks

The idea of this stage is to find as many “What if” cases as possible. Hence, involve as many people as possible. Discuss possible dangers with the pros from management, tech, finance, and marketing. Talk to stakeholders and outside specialists.

Here are the proven techniques to identify risks:

Data gathering using interviews, brainstorming workshops, and checklists.
Data analysis using root cause, SWOT, assumption & constraint, or document analysis.
Prompt lists.
Meetings with a team, stakeholders, and a client.
Expert judgment.

5 key steps of risk management process

Risk Identification – to find out what, when, where, why, and how can affect app development.
Risk Analysis – to figure out how likely the risk events might occur and what outcome they can have.
Risk evaluation – to measure the magnitude of each event and rank them according to probability and impact.
Risk treatment or Risk Response Planning – to come up with mitigation strategies, and preventative care.
Risk monitoring – to keep track of the known risks and be able to prevent the unknown ones. This is, by the way, a never-ending process.

What project risks can occur

A bumpy road of app development helped us at Fulcrum highlight four main types of project hazards:

Management risks
Tech risks
Release risks
Product risks

Previously we’ve discussed the tricky Discovery stage and its dangers. Now, let’s take a closer look at four other perils and our, Fulcrum, action plan.

Management risks examples

What if your team member unexpectedly takes a vacation, gets sick, or decides to quit? What would you do in case of changes in scope, a conflict between stakeholders, or delays in approval from a client?

Here are a few hints.

Risk	Mitigation ways	Action plan
Vacation of a team member	Plan vacations in advance, add vacation of a team member to a roadmap.	Review the roadmap, ask another developer for part-time work, notify the client about changes
A team member decides to quit	Regular reviews, 1-1, build friendly team relationships on project	Review the roadmap, add another developer if possible, open the new position, notify the client about changes
Team member gets sick	-	Review the roadmap, ask another developer for part-time work, notify the client about changes
Changes in scope	Plan scope before sprint start, approve scope with the client & team, notify the client about the changelog and how changes affect the roadmap	Review the importance of the change, review if anything can be taken out of the scope. If possible, plan the change in the next or current sprint
The conflict among stakeholders regarding the functionality	Regular calls, reports about project status with all stakeholders, stakeholders list and responsibilities identification, a plan of Discovery, show intermediate results to receive feedback	Review the change, its importance, review the scope what is possible to take out. If possible, take into this sprint or plan into the next one
Delays in feedback/approval from client-side	Discovery and communication plan, clearly say how delays will affect us	Reminders, simplification if possible (split into several parts), set up calls to go over the materials together

Tech Risks Examples

Risks	Mitigation Ways	Action Plan
Major changes in environments/ dependencies/ rules/ 3rd party application of publishing	Regularly checking the changes and updates, adding the tasks for update dependencies, etc. to a roadmap	Evaluate the time needed for implementation changes, agree on the new release date
Complex internal system to integrate with	Add a task in Discovery for analysis of the current system, infrastructure, set up calls with the tech expert from client-side, request existing documentation on the internal system	Consultation with tech expert from client-side, review current situation to evaluate changes and update roadmap
Created architecture is not scalable when developing a product	Discuss the vision of the product with a project Tech Lead, short-term and long-term \| Plan for extra time before the start of development for creating the product architecture	Review current architecture and how it should be changed, add changes to roadmap before scaling

Release Risks Examples

Risk	Mitigation ways	Action plan
The app was rejected in PlayMarket / AppStore	Checking app for following the publication rules before a release, checking the test accounts, adding a photo/video of how it works	Cover the reason of rejection with a high priorit, provide SMOKE testing, send app for review again
Review pass longer than expected	Send app for review with buffer for publishing	Agree postponed publishing date, request fast review
After release users found bugs/crash	SMOKE testing before release for 2 environments, high-load testing before release, acceptance testing by clients and PM	Evaluate the priority and severity of the task, if a bug is critical, add to the current Sprint, roll-out according to roll-out plan. push hotfix if it’s possible to back-end or web

Product risks examples

Risk	Mitigation ways	Action plan
Not enough end-users after the release (defined timeframes)	Define TA and calculate the approximate number of it, plan the user attraction before the release, start user attraction before the release	Add more marketing activities; if possible attract another TA, conduct interviews with users, who have stopped using the product, review the feature list
Users do not use the core functionality	Define users needs, test prototype with core functionality, set up analytics to track what is being used	Conduct interviews, define what functionality is mostly used, change the product vision or create another prototype with updated flows and test it
Competitors released faster	Market and competitors research, define competitive advantage, release with small parts of functionality, start marketing activities before the release to have the user base	Analyse competitors solution and what can be done better, make emphasis on this part and release the product, review the marketing activities
Regulation has changed (depends on the product)	Review relevant regulations, request consultation with an expert, monitor news about relevant regulations, prepare tasks/roadmap of changes to the product	Review how it affects the product, ideally to implement changes before this, If not, redo the roadmap to implement changes to comply with regulations (there is a probability of not being possible to be live until that)
Suppliers rejected to work with us (if there are suppliers)	Verify the supplier, sign contract with rules of termination it, be notified in advance	Agree on some time until we find another one, start searching for another supplier, review how it affects product, think about a workaround with the dependent features
Bad feedback about the product	Testing before the release to fix critical bugs, a soft launch to find and fix bugs + receive user feedback early	Answer user feedback, fix problem, reward a person, who found an issue (if a problem is in some issue) and make marketing out of this

LET'S DEVELOP A GREAT PRODUCT TOGETHER We stay dedicated and laser-focused on your demands no matter the distance

Use a risk analysis template to simplify everything

It’s easy to manage all possible risks and measure the importance of their mitigation. A risk analysis template will simplify the perception. Here’s a cool example:

You can also add:

Impact (1-10)
Probability (1-10)
Consequences (described impact)

It will help prioritize risks. Those with the highest priority should be mitigated first.

Forewarned is forearmed. We can’t predict everything, but we can get prepared for as many unforeseen events as possible. Believe us, it’s way easier to deal with project hazards when you have a plan.

So, where to start? If you already have an idea of a splendid project on your mind and you search for a development agency with a strong product development expertise, simply contact us.