This is your individual assignment for the course. It’s where you explore some of the many well-known issues in software project management, and describe how agile practices could attempt to address or avoid them.
Everyone has been randomly assigned five common software project risk factors. See the table at the bottom of this page. You will need to analyze three of them.
These risk factors are from the Software Engineering Institute’s 1993 Taxonomy of Software Risks Download the Software Engineering Institute’s 1993 Taxonomy of Software Risks. This was part of a major project to categorize and detect potential risks to large software projects. While much has changed in our understanding of how to develop software, the risks that projects face have remained largely the same.
Only the appendices matter for this assignment. You do not need to read the entire report.
For more background on the taxonomy, see Section 3 of the report.
Step 1: Read about the five risk factors you’ve been assigned
There are three appendices with useful information on the risk. For each of your risks:
Find which column the risk is in in Appendix A, Figure A-1, page A-2 (page 38 in the PDF):
Column A has risks relevant to the product requirements, design, etc.
Column B has risks relevant to the development environment.
Column C has risks relevant to project organizational factors.
Then read the descriptive paragraph for the risk in Appendix A.
Then review the questions in Appendix B that you should ask about a project to see if the risk factor seems likely and/or of high impact. These questions can help clarify what the risk is and the kinds of projects where it might occur.
Finally, if there are terms in the risk description you don’t understand, such as “Orange book” and “non-developmental software”, check Appendix C.
Be careful! Several terms appear in more than one place in the taxonomy. Be sure you are addressing the correct one.
Do not stray from the original risk definition’s intent. Do not generalize. The whole point of the taxonomy was to separate risks into more specific categories.
If you’re unsure about what a risk factor means, post a question to the risk advisor discussion thread.
Step 2: Pick three risks to address
Of the five risks assigned to you, pick three that make the most sense and/or remind you of personal experience and/or you see some obvious agile connections.
Step 3: Address each risk in a separate risk analysis slide
Make a copy of the Agile Risk Advisor templateLinks to an external site..
This template was designed by Samantha Wang (MPD 405 Fall 2016).
Use one slide for each risk. At the top of each slide, put
the taxonomic label and title of the risk, e.g., C.1.b Staff
the short SEI definition from Appendix A
a one-line interpretation of that definition in your own words
It helps to start your interpretation with “the risk that …”
Now it’s time to fill in the rest of the slide
Recommended Analysis Process
After filling in the title and two definitions, I recommend the following order for analysis.
1. Start with an Example. It should be short, specific, and relevant to the risk category. It should be a real case, not hypothetical. It can be personal or something you’ve read about. If you’re not sure if an example fits the risk, email me. A personal experience is best, because then you know the causes and what solutions might be feasible. Examples involving software projects are good but not required. Examples from your team’s class project are OK, but be careful not to force it.
The Example in this edited student risk analysisLinks to an external site. though based on personal experience is a bit generic. It’s the weakest part of this submission. It would have been much better if it said what type of product was involved and what claims the prototype didn’t support, e.g., “The PRD for a new feminine razor didn’t mention that advertising would focus on sturdiness. As a result, the engineer developed a prototype that was lightweight and cheaper to manufacture.”
2. Write your analysis of that example in the Analysis box. Focus on causality. What specific features of the situation led to the problem? The causality you give will be needed to justify the advice you propose.
The Analysis in the example risk analysis is good. It focuses on the incomplete PRD as being the result of marketing misjudging what was important for engineering to know.
3. Collect and enter your References. Three is good. At least one or two should be focused on the advice you will give. Another might talk about the risk situation itself, e.g., a page on scope creep. If your example was something you read about, give a link to a page that describes the case and supports your causal analysis. At most one of the references should be to materials given in class, like my slides or the book.
The References in the example risk analysis are very good. There’s one to the textbook on exactly the point about communication over documentation and there are two external links, both directly relevant to the advice.
Look for resources that discuss a single agile practice or risk. Avoid lengthy overview sites that cover many topics. Avoid references that repeat each other.
Caution: These days, everyone says they’re agile. There are many pages, especially on project management sites, relabeling old ideas as agile. Be suspicious of advice that seems to contradict what you’ve seen in the course and textbook. Be very suspicious when little else on that page and the site in general refers to agile other than the title.
Use clickable links in References where possible. Give the title or shortened form of it, like the example does. Don’t just say “link 1” and “link 2”. Don’t use the URL as the link text.
4. Finally, give your Advice. Apply the agile idea in your references to the problem you’ve analyzed. Explain briefly how it helps address the failure raised in your example. In a few cases, agile may question if there was any failure at all.
The Advice in the example risk analysis is very good. It makes the connection between user stories as a token for conversation and the PRD. The advice aligns with agile’s emphasis on collaboration and communication over documentation.
Don’t lecture! Avoid laundry lists. Less is more. One agile practice per risk factor is usually best. Watch out for un-agile advice recommending top-down control or high-effort documentation.
B.4.a Monitoring, B.4.b Personnel Management, B.5.a Quality Attitude, C.3.a Customer, C.3.b Associate
