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 |
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.
