Jimali Software Engineering

Articles

Title	Author(s)	Notes
Create a risk contingency budget using Expected Monetary Value	Tom Mochal	Tom Mochal describes a mechanism for allocating risk contingency budget that can be used in the event of a risk occurring.
Critical risks in outsourced IT projects: the intractable and the unforeseen	Hazel Taylor	This article presents the findings of a survey into the failure of IT projects, and highlights some critical risks that should be mitigated.
Denver International Airport Automated Bagges System	Daniel Stearns	By all accounts Denver International Airport's automated baggage handling system was a disastrous project that was very late and very much over budget. There were numerous software and hardware problems with the project, but essentially it appears to be a risk management failure. The contractor and the client appear to have spent insufficient time and energy on identifying project risks which in turn meant that they couldn't be addressed. Had more time been spent on risk management the outcome might have been different. More information can be found in Tom DeMarco's book Waltzing with bears.
Design by Contract: The Lessons of Ariane	Jean-Marc Jézéquel, Bertrand Meyer	This case study is about a software failure that caused the Arianne 5 rocket to destroy itself on its maiden flight. This was a failure caused by software re-use. ESA's accident report is also available.
DoD/DAU Risk Guidebook	Unknown
Heroes: Carrying a Double-Edged Sword	Paul Kimmerly	This article talks about the impact that "heroes" have on projects and an organisation. A "hero" in this context is the person(s) who know most about a particular system, and without whom the system cannot operate properly. A system in this case is a software system, but the principle applies to other areas too. Heroes often have knowledge learned through experience that is not written down, and is applied implicitly by the hero in their day to day work. People without this knowledge are not able to perform the tasks of the hero, increasing the dependence upon the hero. Having heroes is a risk to an organisation because they can become choke points to getting work done. Organisations that rely on heroes are often severely impacted when the hero is unable to work (for whatever reason). The article cites examples where heroes have actually caused significant problems for an organisation. The article then discusses options for reducing the dependence upon heroes by leveraging their knowledge to implement appropriate processes. Capturing the hero's implicit knowledge and teaching it to others, allows the heroes to focus on things that they are good at, and allows others to take over some of their responsibilities.
Liability risks in reusing third-party software	Wilhelm Hasselbring, Matthias Rohr, Jurgen Taeger, Daniel Winteler	This article discusses the risks that are applicable in certain parts of the world which result from the use of third party software within a system.
Optimizing Software Process Based On Risk Assessment and Control	XU Ru-Zhi, NIE Pei-Yao, SAI Ying, QU Le-Hong, LEE Yun-Ting,	This article presents a technique for utilising risk management to help improve software development. By analysing the risk of individual tasks, the project manager can make informed decisions how and where to spend money to reduce the risk of project failure.
Risk ManagementHands-On Workshop	Mark Fantasia	This workshop conducted by the US DOD provides a decent background for setting up and running a risk management programme. The workshop does not go into great detail.
See effect of dependent risk by using decision tree	Tom Mochal	This article discusses the use of decision trees to analyse dependent risks and identify courses of action to reduce overall project risk including financial impacts.
The politics of IT project estimations	Charles Seybold	This simple article contrasts two different methods of agreeing estimates with a stakeholder. One gives a fixed point in time, the other gives a time range with confidence values. The latter seems to be the better option, its a shame we don't use it often enough.
The top 4 things project managers do to destroy software quality	Robert Bogue	This article talks about the things that project managers do while trying to bring a project in on time and budget; but which are counter productive to software development and software quality.
Three tips for avoiding project estimating mistakes	Erik Eckel	This article suggests things that a project team can do to minimise the risk of producing incorrect cost and time estimates. The tips range from confirming all assumptions through to ensuring that everything is documented.
Up-front Design	Rebecca J. Wirfs-Brock	This article discusses the need for doing software design "up front" in a project. Wirfs-Brock argues that there are times when doing some design up front is beneficial to the project. Typically this occurs when the team is entering "uncharted waters". In other words, when the risk of not doing it is too high. Whilst Wirfs-Brock argues that it can be beneficial, she is NOT arguing that it be applied to every project, nor for that matter is she arguing that the whole design be done first. She is arguing that it should be considered and applied judiciously to help the project succeed. Up front design is not for all teams or situations; however to blindly label it as unnecessary is unwise. There are valid reasons for and against up front design. Sound engineering judgment is required to decide whether to use the technique. Up front design can be a risk mitigation strategy and worth considering.
What’s so hard about sticking to the plan?	Shannon Kalvar	A blog about how managing risks often leads to difficulties sticking with the plan.

Case Studies

The case studies listed below generally discuss projects where there has been a failure of risk management to some degree.

Title	Author(s)	Notes
Denver International Airport Automated Bagges System	Daniel Stearns	By all accounts Denver International Airport's automated baggage handling system was a disastrous project that was very late and very much over budget. There were numerous software and hardware problems with the project, but essentially it appears to be a risk management failure. The contractor and the client appear to have spent insufficient time and energy on identifying project risks which in turn meant that they couldn't be addressed. Had more time been spent on risk management the outcome might have been different. More information can be found in Tom DeMarco's book Waltzing with bears.
Design by Contract: The Lessons of Ariane	Jean-Marc Jézéquel, Bertrand Meyer	This case study is about a software failure that caused the Arianne 5 rocket to destroy itself on its maiden flight. This was a failure caused by software re-use. ESA's accident report is also available.