RMMM Table

Categor
Sno. Risks y Probability Impact RMMM
1 Size estimate is very low PS 60% 3
2 Requirements are changed at a later stage PD 60% 3
Project team unable to keep up with
3 schedule PR 55% 2
4 Staff may be inexperienced ST 50% 3
5 Staff size may be too small ST 50% 2
Lack of training on project development
6 tools DE 50% 2
The existing hospital system not ready for
7 technological change BU 40% 5
8 Budget may be too low BU 40% 4  
The models may not be well designed
leading to increased cost of reviewing and
9 changes in the code TR 30% 3
The users of the app may not have
10 technical background CU 30% 2
Unable to combine core functionality to
11 additional functionality TE 30% 2
The code built is not flexible to incorporate
12 changes TE 25% 2
13 Complex User Interface TE 25% 2
All requirement specifications may not be
14 satisfied PD 20% 2
The performance of the application may
15 not good TE 15% 1
App may not be functional or compatible
16 on user devices TE 10% 4
17 Not many hospitals register on the app BU 10% 4
Loss of centralized blood bank data due to
18 storage failure TE 5% 5
LEGEND
PS Product Size
PD Product Definition
PR Project Risk
BU Business impact risk
ST Staff Risk
TR Technical Risk
TE Technological Risk
CU Customer Risk
DE Development Environment
 RMMM Plan (For risks above cutoff line)
1. Size estimate is very low
a. Mitigation:
i. Estimation should be done using good estimation technique
ii. More than one method of estimation should be used
iii. Should not use estimates of past projects as final estimates for the project
iv. Estimation should not be based on guess work
v. Decomposition should be done to correctly estimate the size
b. Monitoring:
i. Estimates of each decomposed part should be verified again
ii. Monitor that requirements are not changed frequently
iii. Check whether decomposition is done correctly
c. Management:
i. Re-estimate the size using different methods
ii. Adjust budget and cost using new estimates

2. Requirements are changed at a later stage

a. Mitigation:
i. Do not proceed to development before freezing the requirements
ii. Discourage requirements change at later stage
iii. Communicate with the stakeholder to give all the requirements
b. Monitoring:
i. Monitor any changes in requirements
c. Management:
i. Plan the changes so that no major cost is incurred in the new requirements
ii. Deny new requirements

3. Project team unable to keep up with schedule

a. Mitigation:
i. Make a realistic schedule
ii. Take the software team’s experience and skills into consideration when making
schedule
b. Monitoring:
i. Monitor the timeliness of work products
ii. Monitor the efficiency of project team
iii. Monitor the frequency of missed deadlines
c. Management:
i. Speak to the software team and get review as to why the deadlines are getting
missed
ii. Adjust the deadlines according to project team skills
 iii. Divide the work if required

4. Staff may be inexperienced

a. Mitigation:
i. Proper training to be given through workshops and presentation
ii. Ensure at least one experienced member in every team to guide the others
b. Monitoring:
i. Monitor the productivity of the team
ii. Monitor the quality of the work-products
c. Management:
i. Reassign work and teams based on experience
ii. Hold more training session to give hands-on experience

5. Staff size too small

a. Mitigation:
i. Ensure the size of the staff is enough to handle the estimated project size
ii. Ensure proper working environment to reduce turnover
b. Monitoring:
i. Monitor whether deadlines are being missed or not
ii. Constantly monitor the employee turnover rate
c. Management:
i. Increase the staff
ii. Modify the working environment to ensure the low turnover

6. Lack of training/knowledge of project development tools

a. Mitigation:
i. Encourage software teams to use project development tools
ii. Regularly hold training sessions to get hands-on experience on project development
tools
b. Monitoring:
i. Monitor how efficiently and timely each work product is delivered
ii. Check the tools used by various teams
c. Management:
i. Encourage the use of open source project development tools
ii. Hold training sessions where experienced developers train the inexperienced team
members

7. The existing hospital system not ready for technological change

a. Mitigation:
i. Ensure proper marketing of the product
 ii. Propagate the importance of this new blood bank system through workshops and
sessions
iii. Hold meetings with various big hospitals and make them aware of the advantages of
the product
iv. Take surveys whether the hospital and user are ready for such kind technological
change
b. Monitoring:
i. Monitor the number of hospitals registering in the system
c. Management:
i. Hold meetings with uninterested hospitals to know the reason of their reluctance
and try to convince them
ii. Take feedback from hospitals in order to incorporate desired changes in the product
iii. Decide whether giving future support to project is feasible and that product is viable
or not. If the product is not viable enough then remove support.
8. The budget and allocated resources may be too low
a. Mitigation:
i. Estimate budget using reliable historical data
ii. Take the estimated cost of risk handling also into budget consideration
iii. Take the estimated cost of error removal and detection into consideration
iv. Allocate budget and resources depending on task size of individual teams
b. Monitoring:
i. Monitor whether all teams are able to produce the work-products without excessive
budget drain
ii. Monitor any changes in the requirements that may disturb the budget
c. Management:
i. Re-estimate budget using different techniques
ii. Analyze the short comings of the budget and take feedback from project team
members
iii. Re-allocate resources to various teams according to their needs