]
]
) A typical project course already has some inbuilt risk mitigation measures - but that should not stop you from applying your own. It is important that you identify risks early, analyze them and continuously try to mitigate them.
Things you will have to consider include:
Here are some tips on how to common project risks, explained in rather general terms.
Risk: You may not understand the project requirements correctly, and waste time developing the wrong product.
Mitigation: If a specification document has been given to you, make sure you understand it in its entirety. Discuss doubtful parts of the specification with every team member who will be affected by how you interpret that part. If in doubt, don't assume, always clarify with the lecturer/supervisor/domain expert. You wouldn't believe how many bug explanations start with "Oh, we assumed ..."
Risk: Some team member might fail to contribute as expected, or behave in other ways detrimental to the project.
Mitigation: Be aware of such potential behavior, make the culprit aware of how his/her behavior is hurting the team, and take remedial actions as soon as possible (see here for more info). Clearly assign responsibilities to each member (you can use the guru concept here).
Risk: Some members might lack the skills required for the project.
Mitigation: While external resource (tutorials, books etc.) and lectures/labs might help here, it's also important for the whole team to work together so that you can help each other when needed. For example, if you do your early coding together, you can help each other on usage of the programming language and other tools. You could also try pair programming to get each other up-to-speed, to get used to each others' way of work, and learn tips and tricks from each other.
Risk: One sub-group might do an inferior job, bringing the whole team down at the end.
Mitigation: Try to balance the sub-groups in terms of skills, commitment etc. Also try cross-testing (i.e., one sub-group does the system testing for the other sub-group).
Risk: You might not achieve the required quality levels.
Mitigation: First, be clear about which qualities are expected, and the relative importance of each quality. For example, correctness may be the most important quality, and performance could be the 2nd most important. Second, try to build these qualities into the product from earlier on, rather than an afterthought. For instance, allocate time/resources for correctness/performance testing from early stages of the project.
Risk: Your design/algorithms may not work as expected
Mitigation: Try them out sooner rather than later. E.g., you can try out an uncertain part of the product (at a smaller scale) during the prototyping stage.
Risk: You might overshoot the deadline, and fail to deliver a working a product.
Mitigation: Have a working product at all times (huh?). This quality is already built in to iterative software processes. This way, if you overshoot a deadline, you can always submit the most recent intermediate product, which should support at least some of the expected functionality. The effectiveness of this risk mitigation strategy depends on how short your iterations are. If you did weekly iterations, overshooting a deadline will mean at most you miss submitting the work scheduled for the last week.
Risk: Unforeseen events (such as a team member falling ill/ dropping out) could jeopardize your "perfect" project plan
Mitigation: Build "buffers" into the project plan. Do not rely heavily on a particular team member. While a team member might have her/his own part of the system to work on, it's a good idea for at least one other member to have some idea about that part. If the original author is unavailable, the other member can fill in as required.
Risk: Certain tasks may take longer than expected (i.e., because of your unfamiliarity with tasks of that nature, you are not sure whether you allocated enough time for it)
Mitigation: Try to do such "unfamiliar" tasks earlier in the project, rather than later. At least attempt a similar task at a smaller scale during prototyping stage so that you get a better idea of how much time to allocate to it.
Obviously, mitigating risks has its own rewards. But some evaluators give additional credit for explicitly tackling risks. Its advisable that you document your risk mitigation measures, and include them in the report/presentation, even if it wasn't asked for. You can include the following information when documenting risks.
The risk: What problem do you anticipate? What is the
probability, and the impact of the risk (you can use a rating system here, e.g.
rate risks 1 to 5).
Mitigation strategy: How do you plan to mitigate this risk? Who
will be in charge of monitoring this risk?
Actual response (to be filled in later): Did the anticipated
problem actually materialize? How did to react to it? Why did your mitigation
strategy fail?
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
 |
Sharing this book helps too! |
---| This page is a part of the online book Tips to Succeed in Software Engineering Student Projects V1.8, 3rd Sept 2008, Copyrights: Damith C. Rajapakse |---