Business Finance - Management QSO 435 Homeworks ( week 7)

In responding to your peers, you will take on the role of a proponent for risk management in support of the waterfall methodology. Make comments and respond to at least two of your peers, providing feedback and challenging what they posted regarding risk management in Agile.

To complete this assignment, review the Discussion Rubric PDF document.

______________________________________________________________

Michael Burkholder

Hello Class – Documenting, discussing, and addressing risk is an important part of any project. Managing risk enables the team to improve project deliverables, keep costs down and meet deadlines. In a traditional waterfall approach to a project risk is anticipated and identified during the planning phase. This requires knowledge and familiarity with all aspects of the project. Generally, the team lists out risks that are known and even some that could happen. These risks are ranked by probability and impact. Risks that are more likely or will have a high impact are generally planned for and addressed during phases. This type of planning does not allow for additional change without impact to the project. Risks that were not identified or quantified can become too large and changes need to be made to the scope or team. In other words, the risk identification is actually a risk itself.

In an agile approach to project management, risk is embraced and used for better output. The team is aware of the risks but they do not become limiting like a waterfall project. Risk is not planned out as an action that needs accomplished or dealt with if the impact is a larger than anticipated. Since agile uses iterations or sprints to accomplish requirements. The risk is found and addressed during the work. The advantage of this is that the team does not address or find the risk after they have completed an entire phase. By addressing risk during the sprint the team learns by doing. If they cannot eliminate the risk it is listed as a user story for the next sprint. This allows the team to build on the actions they have already taken to address the risk. This consistent collaborative approach to risk mitigates the impact to the project. Instead of a risk register being another box to check the team can eliminate the risk while working the project. As example, imagine a new wing-tip light was being developed for a Boeing 737. In a traditional project the team would list energy consumption and compatibility as risks to the project. In this case the risk can be planned for but the team may not have complete and working deliverable until they have invested a considerable amount of time. At this point those risks cannot be tested until the project is too far along for change. With the agile approach the team creates working and tested deliverables per iteration. If they discover an issue it can addressed during

the development iteration or address at the next sprint. The investment and project are paced to iteration, so investment is lower and the change or risk is not as impactful.

Resource:

Home. PMI Portland Chapter. (n.d.). Retrieved April 12, 2023, from https://pmi-portland.org/news-and-content/675-risk-management-agile-v-waterfall#:~:text=Risk% 20management%20in%20Agile%20takes,don't%20change%20that%20often.

_________________________________________________________________________

Travis Grimm

I have learned that risks come in different type and sizes. There are times when we can predict when a risk could happen and other times, they happen with little to no notice. I have learned from other classes that the risk assessment is done at the beginning of the project and a good PM would expect most outcomes. However, over the last 7 weeks, I have learned there are other methods to predicting risks. Learning that with Agile risk assessments happen through out the entire project and not just the beginning. For most of this class, I was thinking this was a “simpler” idea and it would be more efficient. I think Agile handles risks a little more thoroughly but throughout my reading, I have learned it is a little more complicated than that.

When working with agile, there needs to be a risk assessment at the beginning. Call outs and possible issues which the team could encounter. This becomes helpful because the entire team meets and during their initial phases, they can put the risks on a list which they have seen from the past. Then throughout the sprints, they would talk about what’s going well and what could have gone better. With these conversations, they should be talking about possible issues which they think they could encounter.

For a scenario, I would think during the initial phases, they would talk about the platform and what they want to accomplish. This is when the developers would have the input to talk about the possible challenges. These challenges could be around never using a certain platform or software. They knew they would be finding themselves in a situation where they would make mistakes learning this new platform. Of maybe, they would have used a platform before and knew there were a lot of issues writing code for it. All this boils down to the team working

together and calling out their feelings and experience to ensure they are identifying possible risks which they could encounter. We need to speak up and not keep quite!