The deliver stage is the first of three PLC stages sometimes associated with the project 'termination phase' indicated in Table 2.1. As for earlier PLC stages, the PLC decomposition provided by Chapter 2 is useful in terms of discussing how risk management should adapt to being introduced very late in the PLC.
The deliver stage involves commissioning and handover. The 'basic deliverable verification' step of Table 2.1 involves verifying what the product of the project will do in practice (i.e., its actual performance as a whole system, as distinct from its design performance or its performance on a component-by-component basis during the execute stage). It is too late for 'co-ordinate and control' in the execute stage sense.
If the product of the project does not meet a contract performance specification, it is usually too late to introduce a meaningful RMP for the first time, unless most of the project's senior staff are first relieved of their posts. Corporate sacred cows and individual reputations can get in the way of the radical thinking that will be required if an RMP is initiated at this stage because serious problems are becoming self-evident.
There are exceptions that prove the rule. For example, if most of the problems were caused by the client or third parties, a contractor who has not previously used risk management may find it very useful to introduce a 'forensic RMP' at this stage to demonstrate why they should be paid very much more than the obvious direct cost increases that have been generated by feedback loops within the project environment (see Examples 8.4, 8.5, and 8.7). For example, a late design change for Channel Tunnel rolling stock due to the goal posts being moved by government safety inspectors, together with no delay in the required delivery date by the client, induced an increase in parallel working. This in turn made the cost of subsequent redesign even more expensive and required an increase in staffing, which in turn meant that staff on average were less experienced and more likely to make mistakes, and so on. The methodology for this kind of 'forensic RMP' is quite different to the SHAMPU process discussed in Part II in terms of its emphasis. In terms of the SHAMPU focus phase, the risk analysis at this late stage in the PLC has to be designed to serve quite different purposes. It is not concerned with making effective decisions. It is concerned with explaining why effective decisions on the part of the contractor were not enough, given the behaviour of the client and third parties.
If project abort or not is the issue in a project's deliver stage, a quite different approach to the SHAMPU focus phase is appropriate, akin to those discussed earlier in the design and conceive stage contexts. However, prevention is better than cure. In particular, if risk management was introduced back in the define or design stage, performance will be defined in terms of 'targets', 'expected values', and 'commitments'. Modification of product performance achievement may be possible and effective, but modification of performance criteria can also be addressed within a framework that facilitates trade-offs because it was used to establish commitments in the first place. In particular, client/contractor negotiations may involve 'user groups' within the client organization in useful dialogues that go well beyond which 'commitments' to relax, considering where ambitious 'targets' might be approached or exceeded to capture opportunities. For example, it may not be possible to achieve a maximum weight specification for a weapon system, but given the extra weight, it may be possible to make it so much more effective that a smaller number of weapons on the same platform offers much better overall performance than the client expected. In such a case the defence procurement executive involved should want to encourage the capture of such opportunities, even if the contract involves a fixed price, highperformance penalty approach.
Was this article helpful?