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
  1. The problem: security issues & hacker attacks.
  2. How to identify risk: set up regular security checkups & control in AWS Load balancer.
  3. A mitigation plan: alarms for RPS, RAM, and server’s load.
  4. 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:

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


5 key steps of risk management process

  1. Risk Identification – to find out what, when, where, why, and how can affect app development.
  2. Risk Analysis – to figure out how likely the risk events might occur and what outcome they can have.
  3. Risk evaluation – to measure the magnitude of each event and rank them according to probability and impact.
  4. Risk treatment or Risk Response Planning – to come up with mitigation strategies, and preventative care.
  5. 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.


RiskMitigation waysAction plan
Vacation of a team memberPlan 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 projectReview 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 scopePlan scope before sprint start, approve scope with the client & team, notify the client about the changelog and how changes affect the roadmapReview 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 feedbackReview 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 usReminders, simplification if possible (split into several parts), set up calls to go over the materials together

Tech Risks Examples

RisksMitigation WaysAction 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 roadmapEvaluate 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 systemConsultation 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 architectureReview current architecture and how it should be changed, add changes to roadmap before scaling

Release Risks Examples

RiskMitigation waysAction plan
The app was rejected in PlayMarket / AppStoreChecking app for following the publication rules before a release, checking the test accounts, adding a photo/video of how it worksCover 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 PMEvaluate 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

RiskMitigation waysAction 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 releaseAdd 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 usedConduct 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 baseAnalyse 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 productReview 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 advanceAgree 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 earlyAnswer user feedback, fix problem, reward a person, who found an issue (if a problem is in some issue) and make marketing out of this
We stay dedicated and laser-focused on your demands no matter the distance
Book a Call

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.