Risk Mitigation [Technique]. A Risk Response Planning Technique* associated with threats that seek to reduce the probability of occurance or impact of a risk to below an acceptable threshhold.
PMBOK 3rd Edition, page 373
Wow, what does that mean exactly? The information on page 262 is a little more informative, but let me take a moment to describe what it means to me.
This week I find myself devoting time and energy to mitigating two risks in my quest for the perfect project. My risks are unrelated to each other. The first risk is that hardly anyone took the time to review the functionality delivered in Iteration 1. I personally reviewed it and sent my comments in. The Information Security Office reviewed it at my request and performed some penetration testing. In both reviews the software was found to be of fairly good quality and performed as expected. This is good and what we hoped for.
My problem is that only one person from the business side actually took the time to review the software. This is troubling for me because I don't think we could have made it any easier for them. Detailed instructions were developed that told them how to performed the review. A list of user names and passwords was generated and deployed with the instructions. Test scripts based on the Use Cases were created. All a user had to do was follow the instructions, go into the system and perform the steps identified in the Use Case. A column was established for any notes or comments. Unfortunately only one person tested and he chose to not use the Test Script.
The risk in this area is adoption. If users of the application don't get in there and work on it, then they can't tell me which adjustments I need to make to help the application to fit better in their business process. The risk is that the project gets to the finish line and nobody has taken the time to look at it prior and they don't like it in the end. If that happens then there will be no money left to transform it into what they need and want. I hope to mitigate this by discussing the issue in the status meeting today as well as the next requirements meeting. I also plan to share the artifacts from my review with the team so that they have a model to go by for the next time.
The other risk I'm dealing with right now is in user authentication. We have a Department-Wide service that we are required to use. The problem is that establishing that connection is tricky. There are two distinct use cases for this segment. The first is in establishing a new user in the system or changing the role of a current user. In the agency we have developed an application that handles that process. There is a risk that it may not be supported and I'm working to shore that up. The other use case is when a user wants to log into the application. We send them over to the authentication service, but then what comes across the wire is a little nebulous right now. So we have to figure this one out. The good news is that I think we know what we don't know. (Does that make sense?) We know which information we are lacking and we know what we need to do to get it.
I think that the work I am doing will help to mitigate both these risks. I'll let you know.
No comments:
Post a Comment