| Technology development projects will usually have a scope management process (often called configuration management) to control the version of the hardware and software that is tested and then distributed to users. It is beyond the scope of this book to try to describe a technology scope management process that would be suitable for use in all circumstances and can supplant those systems already in use. What is described here should be suitable for change control in general projects and should be broadly compatible with most technology change control protocols. The focus of this process is on managing changes to the project as defined in the project scope statement. Such changes might include changes in the following: -
Target completion date for the project. -
Project costs. -
Quantity, quality and performance of the project deliverables, i.e. changes to the user needs. Changes to project risks are addressed here only insofar as the risk management process may generate risk management actions that require changes in timing, costs or deliverables. When the project scope statement is authorized, the scope of the project is frozen. Any information which implies that the actual project and that defined in the project scope statement will be materially different should trigger the scope management process. The general process should run as follows: -
Whenever an action is proposed, consider whether it constitutes a change to the project scope. This is easier to do if you carry a copy of the project charter and scope statement with you wherever you are. -
Get a written description of the proposed change, with as much clarity as possible. Ideally, the originator should describe the new objectives but you will often find that you will be the one writing down someone else's idea. If this is the case, try to remain neutral and try not to let your views colour what you write. You may find it helpful to list exactly which paragraphs of the project scope statement would need to be altered, and to provide an alternative text. Check this summary with the originator to confirm that it captures their idea, but make clear when doing so that this does not mean that the idea is accepted. Some proposed changes will come from your own analysis of the state of the project and the actions necessary to keep the project in line with the target. Treat these in the same way as other proposed changes. -
Go back to the project management plan and work out the consequences of accepting or not accepting the change. Focus on timescales, costs, performance of deliverables, and risk. If there are many suggested changes then it will be impractical to repeat this exercise for every one. Under these circumstances, group the suggested changes logically and produce project scenario plans in which one or more of the groups can be actioned independently. It may become clear at this stage that some suggested changes clash with project priorities. For example, they may imply accepting a delay in project completion that is incompatible with hitting a target launch date that is controlled outside the firm. If this is the case, then such changes should be rejected. A good compromise, if they are otherwise good ideas, is to record them and revisit them once the core project is finished with a view to initiating possible spin-off projects. -
Discuss the results of the replanning exercise with the originator of the idea and ensure that they understand the consequences of their request. If the originator decides not to pursue the request at this point, then record the decision and move on. If the suggestion would lead to an improvement in the project (lower cost, shorter time, better deliverables, etc.) without any other drawback, then you would expect the requested change to be approved for implementation by the Change Control Board (CCB). The project manager is then required to update and reissue the necessary documents, making sure that everyone involved knows about the change. But usually the suggestion will have a drawback. Discuss this with the project sponsor in the same way as when generating the project charter. If the requested change would mean that the project still makes commercial sense then, depending on procedures in your organization and the authority of the CCB, it may be able to authorize an extension to the work. If a major alteration is required, a revision to the charter may need to be submitted to the programme board for reapproval. The revised project charter should make clear: -
the new view of likely business benefits, with or without the change. -
the new view of requirements for resourcing, funding and time, both with and without the change. -
The programme board will compare the revised charter, and the business payoff implied by the figures with and without the change, with other ways in which the firm can spend its money and resources. If the change is justified then it will be authorized. Sometimes, when the change is a recovery plan that will increase the cost and time of the project beyond that originally planned, the realistic choice for the board is between accepting the change or cancelling the project. -
If your project gets through this stage and is re-authorized, you can be assured that the firm is committed to the new project, together with the funding and resourcing required. If a change is accepted, then relaunch the project. Ensure that all team members and all stakeholders know of the new objectives and plan. It would be worth publishing the revised plans so everyone is given the opportunity to see the changes. | |
