Disincentives for communicating risk: a risk paradox
Section snippets
IntroductionRisks, real risks, tend not to simper delicately into view and call ‘coo-ee!’. Given the chance, they are far more likely to creep up while you are not looking, then whack you with a sandbag [1, p. 47].
Risks, real risks, tend not to simper delicately into view and call ‘coo-ee!’. Given the chance, they are far more likely to creep up while you are not looking, then whack you with a sandbag [1, p. 47].
The risk principle:
If you do not actively attack the risks, they will actively attack you [2, p. 73].
However it is expressed, most sources agree: software project risks must be actively and explicitly managed. Yet software projects continue to fail in large numbers where the risks should have been—or were—foreseen, but where the participants for a range of reasons failed to manage these risks. The paradox is that the participants in software projects often have strong incentive at the early
A procurement fable
It is rarely the case that any stakeholders want their project to fall prey to the risks that are inevitable in any significant project. Yet, projects may fail because of risks that should have been managed by all the stakeholders from the project's initial conception. Why do the stakeholders not always cooperate to manage risk? The following fable suggests some answers.
Once upon a time in a Client organisation, a Middle Manager came up with an idea for a software System that would have
Case study of a government projectExperience is that marvelous thing that enables you recognize a mistake when you make it again. F.P. Jones
Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. From “Last Chance to See”, Douglas Adams.
Experience is that marvelous thing that enables you recognize a mistake when you make it again. F.P. Jones
Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. From “Last Chance to See”, Douglas Adams.
This section outlines a case study, undertaken by the authors, of a medium-sized system development project for an Australian government department. The project was brought to our attention when we were approached jointly by the government department and the prime contractor for the project. The project was nearing the expected completion date (about six years from inception), and both the client and the contractor recognised that the project had suffered significant problems and setbacks
Project management issuesNow the boundary… is revealed, and everything unknown is held to be glorious. Tacitus, c. AD 55.
Where observation is concerned, chance favours only the prepared mind. Louis Pasteur, 1854.
Now the boundary… is revealed, and everything unknown is held to be glorious. Tacitus, c. AD 55.
Where observation is concerned, chance favours only the prepared mind. Louis Pasteur, 1854.
Ideally, the outcome of any project should be that ‘everyone is a winner’. The clients get a cost-effective, appropriate solution to their problem; the contractor is rewarded financially (and perhaps with some positive publicity); and participants at all levels can report job satisfaction and suitable financial compensation.
In our case study, we observed clients who were unlikely to get a suitable solution to the problem in an adequate time and a contractor whose staff were decidedly unhappy
Contractual issuesHe is all fault who hath no fault at all. From “The Last Tournament”, Tennyson.
He is all fault who hath no fault at all. From “The Last Tournament”, Tennyson.
Some clients attempt to reduce risk—and thus, eliminate much of the need for the risk management techniques outlined in the previous section—using contracting practices. These practices often involve fixed-price contracts, where a potential supplier or contractor submits a bid price in a competitive situation and is awarded a contract to build a system at that price.
Tendering issuesDear Mr Architect: Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have between two and forty-five bedrooms. Just make sure the plans are such that bedrooms can be easily added or deleted. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one. From “If Architects were Software Engineers”, author unknown.
Dear Mr Architect: Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have between two and forty-five bedrooms. Just make sure the plans are such that bedrooms can be easily added or deleted. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one. From “If Architects were Software Engineers”, author unknown.
Some of the preceding contracting problems can—and should—be addressed in the tendering process. The objective is to set up a more forgiving environment where there are greater rewards for being open than for hiding problems. A great deal of ‘finger-pointing’ and acrimony later in the project can be avoided if all parties are open and honest.
Just as it is unrealistic to expect a tenderer to make reasonable estimates of the cost of software at a stage when the requirements have not been clearly
Conclusions
The risk sharing principle:
The real professional is one who knows the risks, their degree, their causes, and the action necessary to counter them, and shares this knowledge with his colleagues and clients [2, p. 74].
Risk management is a critical part of any software-intensive project, and is particularly crucial in large projects, projects where there is high uncertainty, or projects which are on the leading edge of technology. Our assertion is that risk must be recognised and managed from
Acknowledgements
We are grateful to the government agency and the contractor involved for providing access to personnel and documents for the purposes of our case study. We would also like to thank the referees for their helpful feedback on our article.
References (20)
- et al.
Risk Management for Software Projects
(1994) Principles of Software Engineering Management
(1988)- R.P. Higuera, A.J. Dorofee, J.A. Walker, R.C. Williams, Team risk management: a new model for customer-supplier...
Engineering Risk Analysis and Management
(1989)Practical Risk Assessment for Project Management. Wiley Series in Software Engineering Practice
(1995)Managing Risk: Methods for Software Systems Development. SEI Series in Software Engineering
(1998)Assessment and Control of Software Risks
(1994)- M. Myerson, Risk Management Processes for Software Engineering Models. Artech House,...
Strategies for Software Engineering: The Management of Risk and Quality. Software Engineering Series
(1990)Software risk management: principles and practices
IEEE Software
(January, 1991)
Cited by (9)
Adaptation strategies for port infrastructure and facilities under climate change at the Kaohsiung port
2020, Transport PolicyCitation Excerpt :Enterprises that have adopted risk management therefore periodically implement risk monitoring. Schmid et al. (1999) defined the chief elements of risk management as risk identification, risk assessment, risk analysis, risk reduction, and risk monitoring. Williams (1993) suggested that the process of risk management includes the aspects of risk identification, risk analysis, risk reduction, transfer, acceptance and risk monitoring.
Management competences, not tools and techniques: A grounded examination of software project management at WM-data
2007, Information and Software TechnologyStudents' perceptions of software risks
2017, ASEE Annual Conference and Exposition, Conference ProceedingsIntegration of supportive processes with elementary processes for making current practices of software project risk management more effective
2016, 2015 International Symposium on Mathematical Sciences and Computing Research, iSMSC 2015 - ProceedingsPAPRS The Impact of Residual Risk and Resultant Problems on Information Systems Development Project Performance
2016, Project Management JournalAnalyzing differences in risk perceptions between developers and acquirers in OTS-based custom software projects using stakeholder analysis
2012, International Symposium on Empirical Software Engineering and Measurement