Tailoring PRINCE2 to the project environment | Project-level time and cost tolerances will be defined by the programme. The number and length of management stages will be influenced by the programme plan. It may be desirable or necessary to align end stage assessments to programme milestones (for example, the end of a tranche). The programme may even define a set of standard management stages that all projects within the programme comply with. 221 project should maintain its own Risk Register. If the latter is chosen the project's Risk Management Strategy should define how programme-level risks that are identified and captured by the project are promoted to the programme Risk Register. Likewise, the programme's Risk Management Strategy should define mechanisms for project risks that are identified and captured by the programme level to be demoted to the project Risk Register. 19.4.2 Processes Within OGC's MSP framework, the Delivering the Capability process within Managing the Tranches is entirely focused on starting, monitoring and closing projects within the programme. This process does not need to be tailored when working with PRINCE2. The PRINCE2 process most affected by working in a programme will be Starting up a Project. This process could be undertaken almost entirely by the programme. The programme will: appoint the Executive and Project Manager, review previous lessons, design and appoint the project management team, and probably prepare the Project Brief. The Project Manager will, however, be responsible for preparing the Initiation Stage Plan. In this context, it is not so much that the Starting up a Project process is not done, just that it is now done mainly by the programme. 19.5 PRojECT sCalE PRINCE2 can be used regardless of the scale of the project. A project's scale is relative to the size and experience of the organization hosting the project ­ e.g. a £10 million project could be a simple project to one organization or a daunting project to another. Scale is related not just to the size of the project (often measured in terms of time, money and people) but also to the context of the project's complexity, risk and importance. Organizations should consider calibrating the scale of their projects. Table 19.2 illustrates a simple approach to categorizing projects and provides some suggestions about how PRINCE2 could be tailored. Section 19.5.1 provides guidance on tailoring PRINCE2 for a simple project. 19.5.1 simple project As has been stated above, the scale of a project is relative to the organization and context. Nevertheless, there are some pointers that are useful to consider for a project that an organization considers is simple. A question often asked is: which elements of PRINCE2 can be relaxed on simple projects? There is no easy answer to this. Even simple projects vary enormously in type and style. First of all, it is important to remember that even simple projects should adhere to the seven PRINCE2 principles if the project is to be managed using PRINCE2. It is in the way the themes, processes and management products are used that PRINCE2 is `tailored'. Overall, the purpose of PRINCE2 can be regarded as reducing the risk of project failure. Thus, whenever any element of PRINCE2 is relaxed, this should be regarded as taking a risk. 19.4.3 management products Confusingly, there are numerous management products that exist for both the project and programme, for example a Quality Management Strategy. When in a programme environment, it may be desirable to prefix the management product with `project' and `programme' to distinguish the difference. Another consideration is to make the project and programme document templates look very different in style so that it is immediately obvious where they apply. Consideration should be given to whether the project's logs and registers will be maintained locally to the project, or centrally by the programme. For example, a choice needs to be made as to whether there is a single Risk Register, administered by the programme for the programme-level risks and all the risks for each project within the programme, or whether each