The document lists 16 risks for a project along with the likelihood and impact of each risk. It then assigns a risk score and proposes ways to manage each risk, such as avoiding, mitigating, or accepting the risk. The highest risks include failed architecture (risk score of 40), constant requirements changes (56), and tension between developers and customers (40).
The document lists 16 risks for a project along with the likelihood and impact of each risk. It then assigns a risk score and proposes ways to manage each risk, such as avoiding, mitigating, or accepting the risk. The highest risks include failed architecture (risk score of 40), constant requirements changes (56), and tension between developers and customers (40).
The document lists 16 risks for a project along with the likelihood and impact of each risk. It then assigns a risk score and proposes ways to manage each risk, such as avoiding, mitigating, or accepting the risk. The highest risks include failed architecture (risk score of 40), constant requirements changes (56), and tension between developers and customers (40).
The document lists 16 risks for a project along with the likelihood and impact of each risk. It then assigns a risk score and proposes ways to manage each risk, such as avoiding, mitigating, or accepting the risk. The highest risks include failed architecture (risk score of 40), constant requirements changes (56), and tension between developers and customers (40).
Executive whether Michelle Receive sign-off on Support likes the project the project from plan) Michelle before beginning
Poorly Defined 0.3 (Depends on 0.4 12 Mitigate-
Requirements the requirements Define gathering requirements techniques) through proper requirement elicitation techniques and consult all stakeholders
Scope Creep 0.5 (Depends on 0.2 10 Accept-
(Unrealistic how the project Accept that this Deadlines) plays out over could happen, but time) try to follow the project schedule as closely as possible and track resources
Inadequate 0.3 (Depends on 0.4 12 Mitigate-
Stakeholder requirements Consult with all Engagements gathering stakeholders when techniques) gathering requirements and check in with them throughout the duration of the project
Failed 0.5 0.8 40 Mitigate- Perform
Application and extensive research System on options for Architecture application and system architecture; Inquire about recommendations from professionals that have built a similar system
Failure to 0.3 0.9 27 Mitigate- Meet
Manage End with some current User customers and ask Expectations about what their expectations of an online system/app would be
Inadequate 0.2 0.9 27 Mitigate- Perform
Security extensive research Features Built on what similar into the System solutions have used for security and how they implemented those solutions
Insufficient 0.3 0.8 24 Avoid- Do not
Software Testing release the application until adequate testing has been completed and Michelle has signed off on the product. Even if schedule becomes pushed out because of additional testing, do not decrease the intensity of the tests.
Poor Project 0.3 0.6 18 Mitigate-
Team Dynamic Encourage interactive team management in order to address issues when they arise; encourage collaborative, open communication among team members
Constant 0.7 0.8 56 Mitigate- Come up
Changes in the with a change Requirements management process; Develop the product in increments, allowing for testing and sign-off after each sprint
Technical 0.4 0.9 36 Mitigate- Interview
Inablity and hire developers that meet the required technical requirements
Gold Plating- 0.3 0.5 15 Avoid- Make sure
Unnecessary the requirements Features contain only the Developed bare minimum features needed to release the application and that Michelle signs off on those requirements; Make sure the developers are very clear on the requirements and do not attempt to implement unnecessary, flashy features
Tension between 0.5 0.8 40 Mitigate-
Developers and Prototypes will Customers/Mich help with aligning elle the developers and Michelles vision; Provide Michelle with weekly deliveries that allow her to assess the state of the project
High Workload 0.5 0.7 35 Mitigate- When
on Developers hiring developers, make sure it is clear what is being asked of them and that they feel their abilities are up to par