--Tom Gilb (in Principles of Software Engineering Management)
4.1 Attack risks early and continuously
While project courses usually have in-built risk mitigation measures, this should not stop you from applying your own. It is important that you identify risks early, analyse them and continuously try to mitigate them.
Things you will have to consider include:
- What can go wrong? i.e. the risk identification
- What is the likelihood that it would go wrong? i.e. the risk probability
- What are the consequences? i.e. the impact
- How can we avoid things going wrong? If things do go wrong, how do we minimise the impact? i.e. mitigation strategies
- What are our alternative risk mitigation strategies?
- What are the trade-offs between those alternatives?
This section offers tips on how to manage common project risks, explained in rather general terms. Note that there will be additional project-specific risks that you need to manage. Obviously, mitigating risks has its own rewards. With that said, some evaluators give additional credit for explicitly tackling risks.
4.2 Document risks
It is advisable that you document your risk mitigation measures, and include them in the project documentation/presentation, even if it was not 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 materialise? How did you react to it? Why did your mitigation strategy fail?
'HOW TO' SIDEBAR 4A: How to tackle common project risks
4.3 Building the wrong product
Risk: You may not understand the project requirements correctly, and waste time developing the wrong product.
Mitigation: Early, and continuous validation is critically important. If a specifications document has been given to you, discuss doubtful parts of the specification with every team member who will be affected by how you interpret that part. If in doubt, do not assume, always clarify with the instructor. You would not believe how many bug explanations start with "Oh, we assumed ..."
If the project was defined by you, you need to establish a clear vision for the product, ensure this vision is shared by everyone in the team, and have a solid justification as to why this vision will produce a successful product. If the product is targeted for real users, you can validate the product concept by using small-scale early releases. If the product has a specific client, you should continuously get client feedback to ensure the validity of the product.
4.4 Problematic team members
Risk: Some team members might fail to contribute as expected, or behave in other ways detrimental to the project.
Mitigation: Be aware of such potential behaviour, make the culprit aware of how his behaviour is hurting the team, and take remedial actions as soon as possible (see chapter 5 for more on this topic). Clearly assign responsibilities to each member (you can use the guru concept here - see tip 9.14). Implement ways of tracking each teammate's contribution. For example, you can use a GoogleDocs spreadsheet for everyone to enter project work they did and the estimated time it took.
4.5 Lack of skills
Risk: Some members might lack the skills required for the project.
Mitigation: While external resources (tutorials, books, etc.) and lectures/labs might help here, it is 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 to master the basic usage of the programming language and other tools. You could also try pair programming [http://tinyurl.com/PairIntro] to get each other up-to-speed, to get used to each other's way of work, and learn tips and tricks from each other.
4.6 Sub-standard sub-groups
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. You can also enforce cross-testing (i.e. one sub-group does the system testing for the other sub-group).
4.7 Missing the quality boat
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 second most important. Second, try to build these qualities into the product from early on, rather than as an afterthought. For instance, allocate time/resources for correctness/performance testing from early stages of the project.
4.8 Going down the wrong path
Risk: Your design might not work as expected.
Mitigation: Try it out sooner rather than later. E.g. you can try out uncertain parts of the product (perhaps, on a smaller scale) during the prototyping stage.
4.9 Overshooting the deadline
Risk: You might overshoot the deadline, and fail to deliver a working product.
Mitigation: Have a working product at all times. This mitigation measure is already included in iterative software processes. If you overshoot a deadline while using an iterative process, 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, which should not be much.
4.10 Unexpected delays
Risk: Unforeseen events (such as a team member falling ill/ dropping out) could jeopardise 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 his own part of the system to work on, it is 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.
4.11 Bad estimates
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 (it is said that when forced to eat frogs, one should eat the biggest frog first). At least, attempt a similar task on a smaller scale during prototyping stage so that you get a better idea of how much time to allocate to it.
Giving feedback
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 from the free online book Practical Tips for Software-Intensive Student Projects V3.0, Jul 2010, Author: Damith C. Rajapakse |---