(a) The first stages of risk management are the identification, descriptions and assessment of the risk. This assessment is primarily concerned with the likelihood of them occurring and the severity of impact on the organisation or project should they occur. Sometimes the likelihood is a subjective probability, the opinions of experienced managers or experts in the field. On other occasions, there is some statistical evidence on which to base the assessment. For example, in project 1, TKP identified that 20 IT software companies with annual revenues between $3m and $10m went out of business last year. This represented 10% of the total number of software companies reporting such revenues. Its report to the client suggested that there was a 10% chance of the current preferred supplier (who had a turnover of $5m) ceasing business and this would have a significant short-term support implication. This compared to a business failure rate of 1% for software companies with an annual revenue exceeding $100m. The client felt that the probability of supplier failure was too high, so eventually bought a software solution from a much larger, well-known, software supplier. In this case, the likelihood of the risk led the client to changing its procurement decision. The risk itself does not go away, large companies also fail, but the probability of the risk occurring is reduced.

The avoidance (or prevention) of a risk is a legitimate risk response. In project 1, the client could avoid the risk ‘failure of the supplier’ by commissioning an in-house bespoke solution. Similarly, TKP itself avoids the risks associated with trading in different cultures, by restricting its projects to clients based in Zeeland.

There are three further responses to risks.

Risk mitigation (or risk contingency) actions are what the organisation will do to counter the risk, should the risk take place. Mitigation actions are designed to lessen the impact on the organisation of the risk occurring. In project 2, TKP recommends that the producers of the iProjector should establish an escrow agreement with the company which produces the chip which enhances the quality of the projected image. It was agreed that design details of this chip should be lodged with a third party who would make them available to the producers of the iProjector should the company which owned the enhanced image technology cease trading. This is a mitigation approach to the risk ‘failure of the supplier’. The supplier is relatively high risk (less than three years of trading, inexperienced management team), and the product (the iProjector) is completely dependent upon the supply of the image enhancing chip. The failure of the business supplying the chips would have significant impact on iProjector production. If the escrow agreement had to be enacted, then it would take the producers of the iProjector some time to establish alternative production. Consequently (and TKP have suggested this), it might be prudent to hold significant stocks of the chips to ensure continued production. In such circumstances, the need to mitigate risk is more important than implementing contemporary just-in-time supply practices. In some instances a mitigation action can be put in place immediately. In other instances risk mitigation actions are only enacted should the risk occur. The risk has been recognised and the organisation has a rehearsed or planned response. For example, in project 1, TKP has identified ‘poor quality of current data’ as a risk associated with the migration of data from the current systems to the proposed software package solution. It has established a strategy for data cleansing if that risk actually materialises. Importantly, the client knows in advance how to respond to a risk. It avoids making a hasty, ill-thought out response to an unforeseen event.

Risk transfer actions are concerned with transferring the risk and the assessment and consequences of that risk to another party. This can be done in a number of ways. TKP itself has liability insurance which potentially protects the company from the financial consequences of being sued by clients for giving poor advice. TKP has identified this as a risk, but is unlikely to be able to assess either the probability of that risk occurring or establishing meaningful mitigation measures to minimise the effect of that risk. Consequently, the responsibility for both of these is transferred to an insurance company. They establish the risk, through a series of questions, and compute a premium which reflects the risk and the compensation maximum which will have to be paid if that risk occurs. TKP pays the insurance premiums. TKP itself also transfers risks in project 2. It is unsure about how to establish patents and so it refers the client to another company. Transferring avoids the risk associated with ‘establishing the patent incorrectly’ and the financial consequences of this.

Finally, risk may be identified but just accepted as part of doing business. Risk acceptance is particularly appropriate when the probability of the risk is low or the impact of that risk is relatively insignificant. Risks may also be accepted when there are no realistic mitigation or transfer actions. In project 2, the producers of the iProjector are concerned that there is ‘a risk that a major telephone producer will launch a product with features and functionality similar to ours’. This is a risk, but there is little that can be done about it. Risks of competition are often best accepted.

The discussion above is primarily concerned with deciding what action to take for each risk. Once these actions are agreed, then a plan may be required to put them into place. For example, establishing an escrow agreement will require certain activities to be done.

Risks must also be monitored. For example, in project 2, the risk of supplier failure can be monitored through a company checking agency. Many of these companies offer a continuous monitoring service which evaluates financial results, share prices and other significant business movements. Reports are produced, highlighting factors which may be of particular concern. Risks will also disappear once certain stages of the project have been completed and, similarly, new ones will appear, often due to changes in the business environment. Many organisations use a risk register or risk log to document and monitor risks and such logs often specify a risk owner, a person responsible for adequate management of the risk.

(b) Every project is constrained in some way by its scope, time and cost. These limitations are often called the triple constraint. The scope concerns what has to be delivered by the project, time is when the project should deliver by, and cost is concerned with how much can be spent on achieving the deliverable (the budget). Quality is also an important feature of projects. Some authors include quality in their triple constraint (instead of scope), others add it as a further constraint (quadruple constraint), whilst others believe that quality considerations are inherent in setting the scope, time and cost goals of a project. How a particular project is managed depends greatly on the pressures in the triple constraint.

In project 1, the reluctance of the company to re-visit the business case means that the budget (or cost) of the solution is fixed. The implementation date might be desirable, but it does not seem to be business critical. It is an internal system and so any delays in implementation will not affect customers. It will also be a relatively seamless transition for most employees in the company. They already record the time record details which the new system will collect and so all they will see is a changed user interface. Only the direct users of the output (account managers and the project office) will be affected by any delay. The scope of the software package is also pre-defined. If it fails to meet requirements, then the users will have to adjust their expectations or business methods. There is no money to finance customisation or add-on systems, so in this sense the scope of the solution is also fixed. The quality of the software, in terms of its reliability and robustness, should also be good, as it is a popular software solution used in many large companies.

In project 2, the launch date is fixed. It has been heavily publicised, the venue is booked and over 400 attendees are expected, including newspaper journalists. Thus the time of the project is fixed. However, although orders will be taken at the launch, the product is not expected to ship until a month after launch. Thus the scope of the product shown at the launch date might be restricted and inherent quality problems might not yet be solved. Any defects can be explained away (this is a pre-production model) or, more effectively, they may be avoided by ensuring that the product is demonstrated to attendees, not used by them. The project manager must ensure that key functionality of the product is available on launch date (such as producing an image of a certain quality), but other functionality, not central to the presentation (for example, promised support for all image file formats) could be delayed until after the presentation. The company should make extra funds available to ensure that the launch date is successful.