My name is Svitlana, I’m a Head of Business Analysis at Fulcrum Rocks (we are a development agency based in Kyiv 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 project risks.

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 important?

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.

So, the project manager determines the possible risks > documents their characteristics > creates a plan to mitigate them > creates an action plan.

For example:

Project Risks in App Development example

The problem: security issues & hacker attacks.

How to identify risk: regular security checkups & control in AWS Load balancer.

A mitigation plan: alarms for RPS, RAM, and server’s load.

An action plan: creating rate limits for Login/Pass recovery; urgent fixing actions; secure validation for Passwords.

These steps help to 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
What is risk identification and why is it important?

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 guys from management, tech, finance, and marketing. Talk to stakeholders and outside specialists.

Among the working techniques to identify risks are:

  • 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

The management process consists of 5 key steps.

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:

project risks impact graphic.

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 5 main types of project hazards:

  • Management risks
  • Tech risks
  • Release risks
  • Product risks

We have already discussed the tricky Discovery stage and its dangers. Now, let’s take a closer look at four other perils.

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.

Name Mitigation Ways Action Plan
Vacation of a team member 1 - Plan vacations in advance
2 - Add vacation of a team member to a roadmap
1 - Review the roadmap
2 - Ask another developer for part-time work
3 - Notify the client about changes
A team member decides to quit 1 - Regular review, 1-1
2 - Build team on project
1 - Review the roadmap
2 - Add another developer if possible
3 - Open position
4 - Notify the client about changes
Team member gets sick - 1 - Review the roadmap
2 - Ask another developer for part-time work
3 - Notify the client about changes
Changes in scope 1 - Plan scope before sprint start
2 - Approve scope with the client and the team
3 - Communicate to a client the changelog and how changes can affect the scope
1 - Review the change, its importance
2 - Review the scope, what is possible to take out
3 - If possible take into this sprint or plan into the next one
The conflict between stakeholders about the functionality 1 - Regular calls, reports about project status with all stakeholders
2 - Stakeholders list and responsibilities identification
3 - A plan of Discovery
4 - Show intermediate results to receive feedback
1 - Review the change, its importance
2 - Review the scope what is possible to take out
3 - If possible take into this sprint or plan into the next one
Delays in feedback/approval from client-side 1 - Discovery and communication plan
2 - Clearly say how delays will affect us
1 - Reminders
2 - Simplification if possible (split into several parts)
3 - Set up calls to go over the materials together

Tech risks examples

Name Mitigation Ways Action Plan
Major changes in environments/ dependencies/ rules/ 3-ty part application of publishing  1 - Regular checking the changes and updates
2 - Adding the tasks for update dependencies, etc. to a roadmap
1 - Evaluate the time needed for implementation changes
2 - Agree on the new release date
Complex internal system to integrate with 1 - Add a task in Discovery for analysis of the current system, infrastructure
2 - Set up calls with the tech expert from client-side
3 -- Request existing documentation on the internal system
1 -- Consultation with tech expert from client-side
2 -- Review current situation to evaluate changes and update roadmap
Created architecture is not scalable when developing a product 1 - Discuss with tech lead vision of the product, short-term and long-term
2 - Add time before the start of development for creating the product architecture
1 - Review current architecture and how it should be changed
2 - Add changes to roadmap before scaling

Release risks examples

Name Mitigation Ways Action Plan
The app was rejected in PlayMarket / AppStore 1 - Checking app for following the publication rules before a release
2 - Checking the test accounts
3 - Add a photo/video of how it works
1 - Cover the reason of rejection with a high priority
2 - Provide SMOKE testing
3 - Send app for review again
Review pass longer than expected 1 - Send apps for review with buffer for publishing 1 - Agree postponed publishing date
2 - Request fast review
After release users found bugs/crash 1 - SMOKE testing before release for 2 environments
2 - High-load testing before release
3 - Acceptance testing by clients and PM
1 - Evaluate the priority and severity of the task
2 - If a bug is critical, add to the current Sprint
3 - Roll-out according to roll-out plan
4 - Push hotfix if it’s possible to back-end or web

Product risks examples

Name Mitigation Ways Action Plan
Not enough end-users after the release (defined time frames) 1 - Define TA and calculate the approximate number of it
2 - Plan the user attraction before the release
3 - Start user attraction before the release
1 - Add more marketing activities
2 - If possible attract another TA
3 - Conduct interviews with users, who have stopped using the product
4 - Review the feature list
Users do not use the core functionality 1 - Define users needs
2 - Test prototype with core functionality
3 - Set up analytics to track what is being used
1 - Conduct interviews
2 - Define what functionality is mostly used
3 - Change the product vision or create another prototype with updated flows and test it
Competitors released faster 1 - Market and competitors research
  2 - Define competitive advantage
3 - Release with small parts of functionality
4 - Start marketing activities before the release to have the user base
1 - Analyse competitors solution and what can be done better
2 - Make emphasis on this part and release the product
3 - Review the marketing activities
Regulation has changed (depends on the product) 1 - Review relevant regulations
2 - Request consultation with an expert
3 - Monitor news about relevant regulations
  4 - Prepare tasks/roadmap of changes to the product
1 - Review how it affects the product
2 - Ideally to implement changes before this
  3 - 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) 1 - Verify the supplier
2 - Sign contract with rules of termination it
3 - Be notified in advance
1 - Agree on some time until we find another one
2 - Start searching for another supplier
3 - Review how it affects product 4 - Think about a workaround with the dependant features
Bad feedback about the product 1 - Testing before the release to fix critical bugs
2 - A soft launch to find and fix bugs + receive user feedback early
1 - Answer user feedback
2 - Fix problem
3 - Reward a person, who found an issue (if a problem is in some issue) and make marketing out of this

Use a risk analysis template to simplify everything

Be a dream team – notify the client of all possible risks and explain the importance of their mitigation. A risk analysis template will simplify the perception. 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. Of course, we can’t predict everything. Still, 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.

Where to start? If you already have an idea of a splendid project on your mind, don’t hesitate to leave us an email or fill in a contact form on a website. We will validate the idea, evaluate the risks, and come back ASAP :)