Disincentives for communicating risk: a risk paradox

https://doi.org/10.1016/S0950-5849(99)00011-7Get rights and content

Abstract

Problems with the risk management in medium to large software projects have been well documented. For major software projects to be completed successfully, an open and cooperative attitude towards risk must be maintained. Despite this significant incentive, project stakeholders frequently conceal risks. This article identifies reasons in three key areas for such behaviour, and suggests approaches that reduce the motivation for this behaviour thereby providing a basis for effective risk management. Examples drawn from a study, undertaken by the authors, of a medium-sized industry project are used to illustrate many of these issues.

Section snippets

Introduction

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 project

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 issues

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 issues

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 issues

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)

  • A. Down et al.

    Risk Management for Software Projects

    (1994)
  • T. Gilb

    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...
  • R.N. Charette

    Engineering Risk Analysis and Management

    (1989)
  • S. Grey

    Practical Risk Assessment for Project Management. Wiley Series in Software Engineering Practice

    (1995)
  • E.M. Hall

    Managing Risk: Methods for Software Systems Development. SEI Series in Software Engineering

    (1998)
  • C. Jones

    Assessment and Control of Software Risks

    (1994)
  • M. Myerson, Risk Management Processes for Software Engineering Models. Artech House,...
  • M.A. Ould

    Strategies for Software Engineering: The Management of Risk and Quality. Software Engineering Series

    (1990)
  • B.W. Boehm

    Software risk management: principles and practices

    IEEE Software

    (January, 1991)
There are more references available in the full text version of this article.

Cited by (9)

  • Adaptation strategies for port infrastructure and facilities under climate change at the Kaohsiung port

    2020, Transport Policy
    Citation 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.

  • Students' perceptions of software risks

    2017, ASEE Annual Conference and Exposition, Conference Proceedings
  • Integration 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 - Proceedings
View all citing articles on Scopus
View full text