Risk Assessment
Purpose
The purpose of this document is to provide a plan to identify and manage risks. Risk
management is an important part of project management and is one of the nine knowledge areas.
Management Plan
To manage risks, we will use the following procedure:
1.
2.
3.
4.
5.
6.
7.
8.
Identify the risk
Identify the phase that the risk is in.
Enter the risk into our team’s online risk management plan.
Determine the risk’s probability of occurring and the severity to the project if the risk
occurs.
Enter the risk probability and severity.
Determine a strategy for managing the risk from the Risk Management Strategy section.
Mitigate or otherwise deal with the risk.
Track the risk
We will deal with the risks by using the most appropriate risk management strategy. These
strategies are:
1. Acceptance – If this strategy is chosen, we simple simply accept the consequence of a
risk if it does occur. This strategy will be chosen if the cost to deal with the risk is
greater than the cost of the risk occurring. This will also be the default strategy for any
risk that occurs that we have not identified.
2. Avoidance – If this strategy is chosen, we will take steps to avoid the risk what-so-ever.
So if there is a risk with a chosen OS, then we may decide just switch to an OS that
doesn’t have that risk characteristic.
3. Transference – If this strategy is chosen, we will transfer the risk to a third party. This is
the strategy that we have chosen for designing the main board of our prototype.
4. Mitigation – If this strategy is chosen, we will take steps to decrease either the severity of
the risk and/ or the probability that the risk will occur. We can accomplish this by
making contingency plans.
Risks that may impact our project:
P
r
o
b
a
b
i
l
i
t
81-100%
61 - 80%
41 - 60%
1
21-40%
4
1-20%
y
5
1
2
3
2
3
4
5
Impact: 1(Low) - 5(high)
Risk Matrix
No corporate buy-in
(access to UPC
1
database)
2
Access to credit card
info
3 Hardware malfunction
4 Software malfunction
5 Insulting to employee
1.
No corporate buy-in: The most threatening risk to the project is that the retail stores won’t
update the software on their Point Of Sale Terminals. The software needs to be updated in order
to send the UPCs over the phone lines when a card with C3P is scanned. The current software at
the POS will not send the UPCs over the phone line, and the project will not be innovative
enough without this feature. However, if the stores will not share their UPC databases, the team
can construct a UPC database from scratch.
Mitigation Action: Marketing to the vendors will be the best way to mitigate this risk. The team
will have to show the vendors that they will receive more business when using the new software
and participating in C3P. Also, if the vendors do not provide their databases, the team can
construct a database of all UPCs.
2.
Access to credit card info: Without buy-in from the customer, the credit card companies, the
project will not exist. Not only will the project not make money, but customer buy-in is essential
for the operation of the project. The credit card company needs to be comfortable with the
interception of card-holder data by the C3P intermediary servers. Without this buy-in from the
card companies, the project will not be able to check UPCs and MCCs from the C3P database.
Mitigation Action: The only way to deal with system failures is to test the product. This will
begin when a prototype has been developed in phase 2 and thoroughly tested. Actions taken upon
finding a defect in testing will depend greatly upon what the identified defect is.
3.
Hardware malfunction: Hardware always has a chance of failing. Since the solution is not
hardware centered, much of this risk is out of the control of Green Team Innovations. If the
servers go down, the project cannot function, and soft customers cannot purchase their goods.
Mitigation Action: Proven and high quality hardware will be chosen for servers, and there will
be back up servers as well. Only top-shelf hardware will be used to ensure 99.9% up-time of the
project.
4.
Software Malfunction: Software also is always prone to failure. If the software on the server
side or POS side of this project fails, no transactions can be made or checked. This temporarily
shuts down the entire project and again, consumers cannot make their purchases.
Mitigation Action: This risk will be mitigated by thoroughly and accurately testing the software.
The POS and purchase restricting software will have to be tested.
5.
Insulting to Employee: The concept of the project may be insulting to the employee. He may
think his corporation does not trust him enough to give him unrestricted funding.
Mitigation Action: Employees will be briefed and marketed in a way that they will be ensured
this card is not given to them out of a lack of trust. This scenario is one in which a small number
of people ruin a good thing for everyone, and this will be told to the employees.