MSD Project Risk Assessment Template

ID / Risk Item / Effect / Cause / Likelihood / Severity / Importance / Action to Minimize Risk / Owner
Describe the risk briefly / What is the effect on any or all of the project deliverables if the cause actually happens? / What are the possible cause(s) of this risk? / Scale of
1-5 / Scale of
1-5 / L*S / What action(s) will you take (and by when) to prevent, reduce the impact of, or transfer the risk of this occurring? / Who is responsible for following through on mitigation?
1 / Navigation sensors don’t provide desired range and/or granularity / Robot may injure pedestrians or damage itself / Improper selection of sensors/Faulty sensors / 1 / 3 / 3 / Be sure to look at available sensor options. Compare them and select the most suitable. Proper testing before implementation to ensure reliability. / Corey Provencher
2 / Failure getting SBC Operating System Bootable and Functional / Control system is inoperable / Incompatibility of OS with SBC / 1 / 3 / 3 / Test run of several operating systems to ensure compatibility before MSD II / Maha Alam
3 / Incompatibility of support software, drivers, libraries / Certain peripheral devices will be inoperable / Incompatibility of devices with selected OS / 1 / 2 / 2 / Include functional testing of peripheral devices at time of OS survey / Marcus Gwillim
4 / Not getting all required parts on time / Desired features cannot be tested and implemented on time / Long lead times, not ordering parts in advance, reliability of shipping / 1 / 3 / 3 / Purchase sensors/SBC/other necessary items early. Try to avoid parts with long lead times. Ship to one central location to minimize confusion. / Maha Alam
5 / Insufficient time to finish requirements / Poorly implemented features or inoperable features. / Poor time-management. Heavy workload. Not sticking to project plan. / 2 / 2 / 4 / Stick to project plan. Designate dedicated working time in our personal schedules. Frequent meetings to communicate work status and stay on track. Utilization of other team members for help or to cover when one cannot fulfill a task. / Maha Alam
6 / Inability to accomplish customer requirements with current system design / Many hacks or workarounds that could lead to inoperable/unreliable features. Increase difficulty of expanding robot in the future / Improper survey of requirements of sensors, SBC, embedded systems. / 2 / 2 / 4 / Hold thorough design reviews. Be sure to document concerns. Revise system architecture as needs become clear. / Nicolas Bouret
7 / Running out of money from budget / Replacement parts (if necessary) cannot be purchased. Inadequate parts have to be purchase for favor of price. / Purchasing too much of a part. Failure to gauge required resources. / 1 / 3 / 3 / Plan budget wisely. Order enough parts for development, but not too much, that parts are not being utilized. Keep receipts and return unused components. / Alan Olson
8 / Incompatible interfaces between locomotion and navigation subsystems / Inability for navigation system to control locomotion / Improper documentation of protocol. Lack of communication between Navigation and Locomotion team. / 2 / 3 / 6 / Schedule regular meetings between team project and technical leads. Document protocol for both teams. / Corey & Maha
9 / Hardware failure due to exposure to elements / Hardware failure, overheating, short-circuiting / Improper thermal monitoring. Improper environment sealing in the Robot. / 2 / 3 / 6 / Ensure OS provides thermal monitoring. Ensure hardware is protected in weatherproof enclosure. / Nicolas Bouret
10 / Robot not able to reposition itself accurately from GPS information / Robot may wander outside of allocated area and not be able to find home position. / GPS accuracy isn’t as high as needed. GPS interface is not robust. GPS signal is lost. / 2 / 2 / 4 / Algorithm shouldn’t rely solely on GPS information. Incorporate other position tracking methods (e.g. Odometry) / Marcus Gwillim
11 / Improper fixtures for hardware/sensors / Stress on hardware, cabling. Bad sensor placement can lead to inefficient navigation and limited visibility / Lack of communication on planning required fixtures for hardware and sensors. / 2 / 3 / 6 / Meet with team during regular meetings to ensure correct fixtures are in place. / Alan Olson
12 / Robot drops wireless connection/can’t connect to RIT network / Can no longer transmit status information. Not host controllable. / Poor antenna design, poor WiFi coverage in wandering area / 2 / 2 / 4 / Periodically send out heartbeat signal (ping and status info) to host. / Marcus Gwillim
13 / Robot is not able to provide optimal sunlight for plant / Plant receives insufficient sunlight/shade and is in danger of ailing / Bad weather, inappropriate location, poor sunlight/shade seeking algorithms, Faulty light sensor / 1 / 3 / 3 / Ensure wandering area offers sunny and shady locations. Retrieve robot in bad weather. / Team
14 / Robot runs out of water for plant / Plant receives insufficient hydration and is in danger of ailing / Leak in reservoir, failure to monitor water level, overuse of water (overwatering) / 1 / 3 / 3 / Water level sensor in reservoir. Strict control over water dispensing based on time intervals and humidity levels. / Corey Provencher
15 / Robot is subject to an outside wireless attack / Systems are compromised. Control system may be overridden / Lack of wireless security. Lack of a strong, dynamic password. / 2 / 3 / 6 / Use WPA2 encryption on WiFi. Strong non-lexical passwords. Password should be changed frequently. / Marcus Gwillim
16 / Robot wanders off of pavement / Could lose stability and tip over. Could be damaged. Could build up foreign objects in wheels. / Faulty navigation. Inability to sense variation in terrain / 1 / 3 / 3 / Use low-mounted ground sensor (Sonar or IR sensor) to detect changes in terrain / Nicolas Bouret
17 / Robot vandalized or stolen / Robot gets damaged or robot is missing. / Robot wanders in high-traffic area. Utilizing robot after dark. / 2 / 3 / 6 / Robot periodically sends GPS location. If robot is brought >50m away from wandering area it sends out an audible cry. Robot has accelerometer to detect being picked-up or tipped. / Alan Olson
18 / Embedded System ceases to function properly (i.e. freezes) / Navigation and plant monitoring functions fail / Processor hangs, interrupts not handled properly. Incorrect pointer operations… / 2 / 3 / 6 / Give SBC control of hard reset signal on Embedded Systems, to allow SBC to attempt to resolve embedded system failure / Corey Provencher
19 / SBC crashes / Robot ceases to function / OS kernel panic, thermal constraints exceeded, electrical failure / 1 / 3 / 3 / Ensure proper cooling of SBC. Debug software thoroughly to minimize risk of kernel panic. / Maha Alam
20 / Sensor locations are not chosen properly / Robot is not receiving proper information / Miscalculations of sensor placement / 3 / 2 / 2 / Ensure proper communication with Locomotion team, and keep up to date with planning / Nicolas Bouret
21 / Not being able to detect objects low to ground / Possibility of robot crashing into an object / Improper mounting of proximity sensors / 2 / 3 / 1 / Mount proximity sensors to the skirt of the chassis / Alan Olson
22 / Output power for speakers may not be sufficient for outdoor environment / Robot not being able to “interact” with environment / Selecting a incapable speaker / 2 / 1 / 1 / Purchase sample speakers and test suitability outdoors / Nicolas Bouret
23 / GPS does not fit with embedded sensor interface / Improper GPS functionality / Embedded systems are bogged down with other sensors / 2 / 3 / 2 / Have GPS interface directly with SBC / Marcus Gwillim
24 / WHO_AM_I register provides a false sense of embedded systems well-being / SBC not knowing whether embedded systems are functional / WHO_AM_I register always being set to the same value / 2 / 3 / 3 / Implement a periodic counter in the WHO_AM_I register. The embedded controllers update their WHO_AM_I registers periodically and SBC checks the registers periodically. / Corey Provencher
25 / Cannot discern problems with software crashes / Difficulty with debugging embedded and robotic software / Not logging errors / 3 / 3 / 3 / Implement logging of information (debugging and non) / Maha Alam
Corey Provencher
26 / Robot cannot discern correct heading / Robot cannot navigate to destinations / Using a simplistic algorithm for heading / 2 / 3 / 3 / Use a weighted average scheme for heading from the compass, GPS and odometry. Compass holds highest weight (most accurate). / Marcus Gwillim
27 / Robot might zigzag around objects rather than avoid them / Robot may swerve into objects / Scheme for obstacle avoidance may not route robot around objects efficiently / 2 / 3 / 3 / Investigate potential-field navigation algorithm or define a reasonable time that the robot continues moving away from an object before trying to re-approach destination. / Marcus Gwillim
28 / Navigation might be constrained / Robot cannot navigate to a destination properly / Destination is defined by a single point / 2 / 3 / 2 / Since robot only cares about finding sunlight and shade, specify destination as a heading rather than combination of a heading and a point / Marcus Gwillim
29 / Future software development is constrained / Third-party software cannot be developed for the Robot outside of the Java programming language. / Using Java serialized objects for Wireless Architecture / 2 / 1 / 1 / Temporarily use Serialized Objects scheme, and then work with Software Engineers and switch to expandable scheme later / Maha Alam
Likelihood scale / Severity scale
1 - This cause is unlikely to happen / 1 - The impact on the project is very minor. We will still meet deliverables on time and within budget, but it will cause extra work
2 - This cause could conceivably happen / 2 - The impact on the project is noticeable. We will deliver reduced functionality, go over budget, or fail to meet some of our Engineering Specifications.
3 - This cause is very likely to happen / 3 - The impact on the project is severe. We will not be able to deliver, or what we deliver will not meet the customer's needs.
“Importance Score” (Likelihood x Severity) – use this to guide your preference for a risk management strategy
Prevent / Action will be taken to prevent the cause(s) from occurring in the first place.
Reduce / Action will be taken to reduce the likelihood of the cause and/or the severity of the effect on the project, should the cause occur
Transfer / Action will be taken to transfer the risk to something else. Insurance is an example of this. You purchase an insurance policy that contractually binds an insurance company to pay for your loss in the event of accident. This transfers the financial consequences of the accident to someone else. Your car is still a wreck, of course.
Accept / Low importance risks may not justify any action at all. If they happen, you simply accept the consequences.