This information was taken from an internal newsletter of The Knowledge Partnership LLP (T

Question

This information was taken from an internal newsletter of The Knowledge Partnership LLP (TKP), a company which offers project and software consultancy work for clients based in Zeeland. The newsletter was dated 2 November 2014 and describes two projects currently being undertaken by the partnership.

Project One

In this project, one of our clients was just about to place a contract for a time recording system to help them monitor and estimate construction contracts when we were called in by the Finance Director. He was concerned about the company supplying the software package. ‘They only have an annual revenue of $5m’, he said, ‘and that worries me.’ TKP analysed software companies operating in Zeeland. It found that 200 software companies were registered in Zeeland with annual revenues of between $3m and $10m. Of these, 20 went out of business last year. This compared to a 1% failure rate for software companies with revenues of more than $100m per year. We presented this information to the client and suggested that this could cause a short-term support problem. The client immediately re-opened the procurement process. Eventually they bought a solution from a much larger well-known software supplier. It is a popular software solution, used in many larger companies.

The client has now asked us to help with the implementation of the package. A budget for the project has been agreed and has been documented in an agreed, signed-off, business case. The client has a policy of never re-visiting its business cases once they have been accepted; they see this as essential for effective cost control. We are currently working with the primary users of the software – account managers (using time and cost data to monitor contracts) and the project support office (using time and cost data to improve contract estimating) – to ensure that they can use the software effectively when it is implemented. We have also given ‘drop in’ briefing sessions for the client’s employees who are entering the time and cost data analysed by the software. They already record this information on a legacy system and so all they will see is a bright new user interface, but we need to keep them informed about our implementation. We are also looking at data migration from the current legacy system. We think some of the current data might be of poor quality, so we have established a strategy for data cleansing (through offshore data input) if this problem materialises. We currently estimate that the project will go live in May 2015.

Project Two

In this project, the client is the developer of the iProjector, a tiny phone-size projector which is portable, easy to use and offers high definition projection. The client was concerned that their product is completely dependent on a specialist image-enhancing chip designed and produced by a small start-up technology company. They asked TKP to investigate this company. We confirmed their fears. The company has been trading for less than three years and it has a very inexperienced management team. We suggested that the client should establish an escrow agreement for design details of the chip and suggested a suitable third party to hold this agreement. We also suggested that significant stocks of the chip should be maintained. The client also asked TKP to look at establishing patents for the iProjector throughout the world. Again, using our customer contacts, we put them in touch with a company which specialises in this. We are currently engaged with the client in examining the risk that a major telephone producer will launch a competitive product with functionality and features similar to the iProjector.

The iProjector is due to be launched on 1 May 2015 and we have been engaged to give advice on the launch of the product. The launch has been heavily publicised, a prestigious venue booked and over 400 attendees are expected. TKP have arranged for many newspaper journalists to attend. The product is not quite finished, so although orders will be taken at the launch, the product is not expected to ship until June 2015.

Further information:

TKP only undertakes projects in the business culture which it understands and where it feels comfortable. Consequently, it does not undertake assignments outside Zeeland.

TKP has $10,000,000 of consultant’s liability insurance underwritten by Zeeland Insurance Group (ZIG).

Required:

(a) Analyse how TKP itself and the two projects described in the scenario demonstrate the principles of effective risk management. (15 marks)

(b) Describe the principle of the triple constraint (scope, time and cost) on projects and discuss its implications in the two projects described in the scenario. (10 marks)

Answer 1

正确答案：

(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.