Managing Business Change

Foreword

This document has been produced in response to perceived weaknesses in our organisational performance in the areas of project, programme and general change management. It covers a number of related areas, namely: -

• Ideas, pilot studies and pre-project work
• Project start-up 1 - Project proposal; Business Case; Approvals process; Creating the team
• Project start-up 2 - Business Case Update; Risk Log ; Project Initiation Document (PID)
• Procurement

• Consultancy and the use of external advisers

• Project & Programme management - Organisation & structure; project financial management
• Project Planning and Control
• Project completion - Implementation & Business Change

• Post-Implementation Review (PIR)

The purpose of this guide is to identify the best practice principles that underpin our approach to managing business change. It provides advice on general principle only. Detailed guidance on specific topics can be found in the range of publications referred to throughout this guide. A list of publications is provided in the Appendix.

Contents

1. The Pre-project Stage

1.1 Ideas into Action
All projects begin with an idea. Someone, somewhere thinks about some aspect of the business and comes up with an idea as to how it might be improved. But not all ideas become projects. Many ideas relate to local issues and conditions and can be developed and implemented locally. They do not require the formality of a project structure.

Where the idea has a wider impact or the potential to change processes or systems across team and unit boundaries, then its development requires a more disciplined approach. It is now a project candidate.

The decision as to whether the idea is developed and implemented as a project now rests on three major factors.

• Complexity - the idea involves complex change
• Timescale - the idea will be developed and implemented over a significant period (ie) greater than 3 months
• Cost - the cost to develop and implement is likely to exceed £100,000. These costs should include an estimated internal resource commitment to deliver the change.

The responsibility for reviewing ideas and deciding if they should be considered for project status rests with the Director of the division in which the idea originates. Where the Director decides that a proposed development should be considered as an Agency project they will commission the preparation of a Project Proposal. At this stage the Director should ensure that the idea does not cut across any other initiative currently underway (or under consideration). This proposal will be submitted to the Business Change Group (BCG) who will consider the proposal and make a recommendation to the Management Board.

1.2 Project Proposal (Mandate)
The Project Proposal is the first, formal, project document. Strictly speaking it is not a project document as it is prepared before the proposal has achieved project status. Nevertheless for those proposals which go on to become projects, this document should be the first recorded in the project file. Therefore some care should be taken in preparing the document, including the use of version control.

There is no mandatory format for Project Proposals. They should however, contain the following minimum information.

• Background Statement - The purpose of the background statement is to put the proposal in context. It should describe the current situation, identify the issue or issues the proposal will address and make reference to any related process or environmental factors relevant to the proposal.
• Description - The description should set out the objective(s) of the proposal, identify the methodology proposed including indicative internal and external resource requirements, indicate timescales and include an initial budget estimate. The proposal should include an Outline Business Case (see 1.4 below). Where appropriate, the description should include reference to any pilot studies carried out. Alternatively it may recommend that pilot work be included as a first phase of the proposal.

The Programme Office will provide guidance in the preparation of the initial documentation.

1.3 Feasibility & Pilot Studies
Project proposals do not always benefit from or require piloting. However in circumstances where the technical or process benefits of change are not completely clear or where competing technologies or processes are involved, pilots can provide valuable additional information. Pilot studies may be commissioned by divisional Directors in order to explore or clarify alternative approaches or ideas. Approval for major pilot work, together with the necessary budget approval must be obtained at Management Board level. In practice the Management Board may agree to delegate this approval to the BCG. Directors however retain the right to sponsor smaller pilot exercise within their divisions, provided they have resources and funding available. Alternatively pilot studies may be recommended by the BCG on receipt of a proposal and before project approval or be included as the first phase of an approved project.

Pilot studies must be planned, managed and executed efficiently under the direction of the initiating Director. In particular the pilot study plan should set out clear objectives/deliverables, establish the resources available, identify the pilot study team and their individual roles and responsibilities, set out the agreed timetable and define clear lines of communication to the sponsoring individual or body. The aims and objectives of the pilot must be clearly understood and should not be extended without the formal approval of the sponsor. Above all the pilot remains a pilot. If at some stage the pilot team or sponsor wishes to develop the pilot into a full project, then they must obtain the necessary approvals through the project management process.

1.4 Outline Business Case
Developing a full Business Case is resource intensive and therefore expensive. It is recognised therefore that full Business Cases should not be prepared until after project approval in principle. However in order to inform the approval process, an outline Business Case is mandatory. Appropriate technical, finance or other input should be obtained before the outline Business Case is presented. The outline Business Case should set out as follows: -

• The current cost of the system or process which is to be subject to change, including where appropriate an estimate of how that cost is likely to change over the relevant timescale. Costs should be based upon a total cost of ownership model.
• A cost estimate of the project in sufficient detail to distinguish project costs from costs associated with the ongoing operation of the revised system or process; also some indication about the nature and timing of expenditure. Ongoing costs should be constructed on the basis of total cost of ownership.
• A high-level investment appraisal comparing the current cost with the cost of the new system/process, taking into account capital investment, revenue projections, cost of risk and cost of capital.
• A financial and business impact assessment based upon the investment appraisal.
• An option appraisal (which includes 'do nothing') together with a recommendation.
• The reason(s) for undertaking the project.

It is recognised that some outline Business Cases will be constructed in an environment where 'do nothing' is not a viable option. In such a circumstance the 'do nothing’ option can be omitted, subject to a detailed explanation of the circumstances being provided with the Business Case.

1.5 Approval to Proceed
When the project proposal, together with the outline Business Case and the output from the pilot study (if any) have been completed, they are submitted to BCG. The BCG will review the proposal and prepare a covering report and submit it, together with a recommendation, to the Management Board. The Management Board will then consider the proposal together with the BCG's report and approve or disapprove the proposal. In the event that the proposal is disapproved, the BCG, on behalf of the Management Board, will give reasons in writing to the sponsoring Director and his team. In the event that the proposal is approved, the Management Board will authorise a budget for the project based on the figure contained in the outline Business Case.

It is important to note that this approval is for the project to be set up. Final approval for the project to proceed will not be granted until the full Business Case, Risk Log and PID have been prepared and submitted to the BCG.

2. Project Start-Up

2.1 Creating the Team

2.1.1 The Project Team
The process of building a project team begins with the appointment of a Project Manager. A Project Manager designate may have been identified at an earlier stage and indeed may have been the officer responsible for preparing and carrying out the pre-project work. In any event the appointment of a Project Manager is the responsibility of the sponsoring Director, now known as the Senior Responsible Owner (SRO) for the project.

The appointment should be made or confirmed in consultation with Human Resources (HR) staff. HR and the SRO are jointly responsible for ensuring that the Project Manager has the appropriate training and experience, relative to the size and complexity of the project. It is recognised that it may be appropriate to appoint an officer with no previous project management experience to take charge of a small-scale project. However such officers should always have previous experience of project work as members of a project team and have received full training in PRINCE 2 project management techniques.

The Project Manager in consultation with the SRO and HR should then select team members. In normal circumstances this will be done by internal trawl and interview against pre-determined person specifications. However in order to ensure that the team contains all the skills required it may on occasion be necessary to appoint members without open competition.

Given the wide range of size, complexity and content of projects it is not possible to be definitive as regards team membership. However all project teams must contain the following roles: -

2.1.3 The Project Board
All projects must be managed by and report to a Project Board. The Senior Responsible Owner (SRO) will chair the Board and be responsible for appointing its members, in consultation with appropriate Directors. Again given the diversity of the project environment it is not possible to prescribe Board membership. However the following roles are mandatory

The Project Board will be responsible for appointing Project Assurance resource. In addition the Board will also appoint a Secretary to service the Board and produce Board minutes and other documents. This resource will be supplied by the Programme Office. The Project Manager will attend the Board to submit his/her report but will not be a member of the Board itself. Project Boards should be as small as practicable and in no case should they exceed 6 members.

Guidance on the set-up of the Project Structure will be provided by the Programme Manager where required.

2.2 The Business Case
Developing a full Business Case is an essential first step. Without a robust and comprehensive Business Case, final approval for the Project will not be forthcoming. Again because of the variation in the project environment it is impossible to give detailed advice on the preparation of a Business Case. As with Outline Business Cases, technical, financial and other reviews should be included as part of the process. Large, complex and expensive projects will require more detailed Business Cases. However all Business Cases must include

• A detailed and comprehensive description of the business process (e.g.) which are the subject of the project and how these are to change.
• A full explanation of the business issues driving change and the business benefits which will accrue.
• Option appraisal covering the range of business, technical and procurement options.
• Risk assessment.
• A financial analysis sufficient to allow a reasonable judgement to be made as to the financial viability of the project.

(The extent and complexity of this analysis will vary dependant upon the size and complexity of the project. Large-scale projects will require a full investment appraisal including detailed estimates of full life-cycle costs, cost of capital computation, revenue impact analysis etc.. They will also require detailed and justified estimates of any cost savings claimed for the project again expressed in full life-cycle terms. Small-scale projects by contrast will require less detailed financial analysis but nevertheless this must be sufficient to support the cost-justification of the project and must always be expressed in full life-cycle terms.)

2.3 The PRINCE 2 Approach
The Agency has adopted PRINCE 2 as its Project and Programme Management methodology. Originally developed in the construction industry, PRINCE 2 has been refined and adapted by the Government Central Computer and Telecommunications Agency (CCTA). Detailed guidance on PRINCE 2 is available in the publication 'Managing Successful Projects with PRINCE 2' published by CCTA (now Office of Government Commerce 'OGC') and available within the Agency.

While PRINCE 2 forms the basis of our approach, its design enables it to cope with very large projects. It is accepted that the approach may be modified to suit the circumstances and the budget of smaller projects. Project Boards will be expected to guide Project Managers with regard to the application of PRINCE 2. Project Boards in turn may seek guidance from the Programme Manager and the staff of the Programme Office. Key to the success of the application of the methodology is to ensure that it is applied sensibly but consistently across the projects.

Certain elements of the PRINCE 2 approach are considered mandatory.

• The Project and Programme structure, including the establishment of the roles listed elsewhere in this guide. Roles may be combined but they may not be omitted.
• The preparation and regular updating of an adequate Business Case which supports the project
• The compilation and maintenance of a project Risk Log. This document should include the measures taken to control and manage risks and highlight any change in the risk profile of the project.
• The preparation and updating of a detailed Project Plan setting out the deliverables and project timetable. In larger projects, staging and product centred planning may be used to break down projects into manageable sections. The creation and application of a quality assurance plan, which ensures continuous quality control throughout the project life cycle. The adoption of configuration management to achieve a controlled and traceable product evolution through properly authorised specification, design, software, hardware and reports.
• The adoption of a change control procedure to record desired change to, or some failure in, the projects deliverables.

2.4 Formal Project Approval
When the project team have completed the full Business Case together with the initial Risk Log and the Project Plan (usually prepared in the form of a (PID), the Project Board will submit these to the BCG, who have delegated authority from the Management Board to grant formal approval to the project.

The BCG will review the submission against the original proposal, Business Case and budgetary approval and where it is satisfied that the project remains within its original Terms of Reference, is supported by a sound Business Case and remains within the budget guideline approved by Management Board, it will grant formal approval.

For projects which have a significant capital expenditure (over £500,000) formal approval to proceed from the Management Board should be secured.

If BCG has any doubt about Terms of Reference or Business Case it may request clarification from the Project Board. If after clarification BCG is still dissatisfied it will prepare a report for Management Board, recommending a course of action. This may range from recommending changes to the project to complete abandonment.

Where significant change to the project budget emerges from the full Business Case, this will in all cases be referred to the Management Board for a decision. Formal approval cannot be granted until the Management Board has approved the project budget.

3. Procurement

3.1 Public Procurement - basic principles
The Agency's Procurement Policy is that value-for-money (VFM) must be achieved when our finite resources are used to procure all goods and services needed to perform our statutory and other duties

Value-for-money is defined as the optimum combination of whole-life cost and quality (or fitness for purpose) to meet the user's requirement.

Please be mindful that the definition talks about 'whole-life-costs' not just the cost of acquisition. All non-acquisition costs; e.g. the costs associated with support and/or maintenance of applications or equipment, have therefore, to be included in VFM evaluations.

The procedures followed in reaching this goal must accord with best professional practices and ethical codes of conduct as detailed in the Procurement Manual and its Appendices. Compliance with both the spirit and the letter of the Procurement regulations is expected.

3.2 Procurement Regulations
The regulations for undertaking procurement are set out in full in the Procurement Manual.

A further user guide is available entitled ‘The Rough Guide to Procurement’ for those seeking a plain guide of how the rules are applied and interpreted, what to do, why it is so and how to do it.

In considering any Procurement Project it is essential that contact is made with the procurement team at the inception of the project. Full contact names and details are available from the Procurement web page. The reference for this is:

3.3 Procurement within a project - buying goods & services
The Agency is currently introducing a new system of identifying expenditure related directly to projects. For each project a unique identifier will be established in discussion with the Finance Department to allow expenditure to be tracked throughout the life of the project. Please contact the procurement team for further details.

3.4 Procuring advice & consultancy
Where a Business Case has been made and consideration is being given by the Agency whether or not to hire management consultants, an additional prescribed requirement has to be addressed and met. It must be established if the cost of the consultancy is likely to exceed £10,000 (ex VAT). If it is likely to exceed this threshold then the Business Case must be presented, via the Keeper's Office, to the appropriate Minister at the Scottish Executive and written approval to proceed must be secured prior to awarding any contract for the consultancy.

For the purposes of this Manual, external consultancy is defined as follows:
"Investigating problems, providing analysis or advice, or assisting with the development of new systems, new structures or new capabilities within the Agency"

N.B. Consultancy does not include staff substitutions, research, or contracted professional or technical services of a more routine nature. If in doubt contact the Procurement Department.

The Budget for the authorisation of consultancy services is held by the Director of Finance. Permission must be sought from the Director when consideration is being given to the appointment of consultants.

4. Consultants and External Advisers

4.1 The use of consultants
Using consultants effectively requires four things:_

• Careful selection of the consultant based upon the appropriateness of their technical expertise and experience, a measurable track record and compatibility with the Agency's culture and values.
• Ensuring the consultant you get is the one you thought you were getting. Insist that you have the CVs of and interview the staff who will actually carry out the assignment.
• A clear and concise agreement of requirements including measurable deliverables and quality standards to be applied, an agreed timescale and a common understanding of the overall goal.
• Continuing management of the consultant by a single Agency officer who has the authority to negotiate on behalf of the Agency.

Again owing to the variation in project requirements it is difficult to give definitive advice regarding the circumstances in which consultants should be considered. However the following general guidance is offered.

Consultants should be considered where: -

• The Agency requires specialist technical expertise or skills. Examples include the use of E2 on the Finance Project and the use of Hillier Parker on accommodation issues.
• The Agency would clearly benefit from independent scrutiny and advice. The recent Post-implementation Review exercise is an example.
• The Agency does not have the resources or the resources are required for a short period. Consultants may be used to provide additional resource, either because the Agency cannot recruit and retain the resource or because it is required for only a short time.
• The Agency wishes to undertake a project where a wide range of skills and expertise are required and consultants provide the most cost-effective route for obtaining the resource.

Even where consultants are retained it should not be assumed that they will be self-managing. Effective management of consultants from within the Agency remains a prime requirement for success.

4.2 External Advisers
External Advisers differ from consultants in that they are a resource that is retained for the duration of a project but used on an 'as required' basis. The commonest advisers are those providing legal, commercial, financial or technical advice. Advisers are available from a number of sources including the Scottish Executive, OGC, other government Agencies e.g. PACE, and a range of private sector organisations including the major management consultancies, smaller specialist consultants, professional firms, etc.

Choosing advisers is never easy. In certain circumstances it may even be appropriate to consider using consultants to help select advisers. However the following general advice is applicable: -

4.3 External Project Management
External Project Management remains an option. However it should be borne in mind that while this may provide extra resource, the Agency is still responsible for managing that resource effectively. In deciding to utilise external Project Management, the Project Board must be satisfied that the brief given to the external manager is detailed and unambiguous and that throughout the project the performance of the external manager is managed and evaluated.

5. Programme Management

5.1 Organisation & Structure - Roles & Responsibilities

5.1.1 Management Board
The Management Board has ultimate responsibility for all policy issues and strategic decision making. It is also the only body entitled to authorise budgets. It will set the Business Strategy and approve the detailed operational and support strategies which deliver the business strategy. As such it will approve the Business Change Programme and the individual projects which go to make up that Programme. Once projects have been approved and budgets set, the Management Board will delegate the monitoring and reporting function to the BCG, working through the Programme Board.

5.1.2 Business Change Group
The BCG will monitor and report on the programme on behalf of the Management Board. It will receive quarterly reports from the Programme Board, detailing programme activities and the progress of individual projects. It will however meet monthly and will accept exception reports from the Programme Board highlighting any matter of immediate concern. It will ensure that the programme is run as an integrated whole and that adequate resources are devoted to crosscutting issues. It will also actively promote communication of business change. From time to time it may also commission work designed to investigate change options, prior to making recommendations to the Management Board.

5.1.3 Programme Manager
The Programme Manager is responsible for the operational management of the programme. This involves the forward planning of programme activities, the co-ordination of projects that make up the programme, the management of interface and overlap issues, the resolution of resource conflicts and the provision of advice to the BCG on programme resourcing, priorities and performance. The programme consists of all those projects formally established by the project approval process. The programme may include generic initiatives - which bring together a number of smaller projects under a collective management structure.

The Programme Manager reports to the BCG. The role in turn manages the Programme Office, which provides the necessary executive and administrative resources to enable the Programme Manager to monitor and report on the content of the Programme.

The Programme Manager also chairs the Programme Board, which provides the operational forum for the management of the Programme

5.1.4 Programme Board
The Programme Board provides the operational framework for the management of the programme. It is chaired by the Programme Manager and its members are the Project Managers of the projects in the programme, together with the IT Development Manager and the Programme Officer. It meets monthly and reviews the programme, focussing upon three areas: -

The aim of the Programme Board is to co-ordinate project planning and execution so as to:-

5.1.5 Programme Office
The Programme Office provides the executive and administrative support required to manage the programme. It in turn is managed by the Programme Manager and staffed initially by a Programme Officer, Programme Support Manager and support resource (shared with the Business Change Team 'BCT').

The Programme Office will provide support to individual Projects in the form of Administrative support, configuration management, management of project records, provision of standard documentation &c.

The Programme Office, in conjunction with the BCT, will be responsible for the communication of the Programme.

5.1.6 Business Change Manager
The Business Change Manager is responsible for the implementation of business change and for embedding change into the structure and practice of the Agency. This is a key role. The Agency is aware that a major weakness in past performance has been its inability to translate the outcomes of change projects into established reality within the organisation. The focus for this process will now be the role of Business Change Manager. The role will be a full-time, senior, appointment in order to achieve the continuity required to manage change successfully. The Business Change Manager will work through Business Change Teams (BCT’s). These teams will be set up to manage specific changes. Each BCT will have individual, time-bound objectives relating to the implementation and embedding of a specific change initiative. The organisation and membership of BCTs will vary, depending upon the nature and scope of the change initiative.

Most but not all change initiatives will arise from projects. To provide continuity, the BCT will contain at least one member of the project team that delivered the business change now being implemented. This member will usually be the only full-time member of the BCT. Other members will reflect the nature and scope of the project. BCTs will be selected by the Business Change Manager, on the advice of the relevant Director. More detailed advice on the role and contribution of the Business Change Manager and BCTs will be published in due course.

6. Project Management

6.1 Organisation & Structure - Roles & Responsibilities

6.1.1 Business Change Group
The role of the BCG is set out in Section. 5.1.2 . In relation to project management its role is confined to managing the formal approval process and providing a forum for the discussion and agreement of project strategy in the context of the Agency's change programme. SROs, in their role as Project Board Chairs, are members of the BCG and contribute to developing proposals for business change strategy, in the context of the ongoing Programme.

6.1.2 Programme Board
As described in Section 5.1.4, the Programme Board is responsible for providing the operational framework within which the programme is managed. Each Project Manager is a member of the Programme Board and the Board plans and executes the programme of projects, addresses issues of common or conflicting interest, promotes communication and common understanding and makes recommendations on issues such as priority and resources.

6.1.3 Project Board
The Project Board is responsible for the delivery of the project. The project sponsor, known as the Senior Responsible Owner, chairs the Project Board. This officer has accountability for the delivery of the project within his or her personal responsibility plan. The other mandatory members of the Project Board are: -

• Senior User - representing the interests of the user community
• Senior Supplier - representing the interest of IT

In some circumstances, where for example the project affects more than one user community, there may be more than one Senior User.

In addition the Board may appoint advisers. These may be permanent or temporary Board members, or simply attend Board in an advisory capacity. In all cases Board should be kept as small as practicable and should not exceed 6 members including the chair.

The Project Manager will report to the Board but will not be a member of it. This allows the Board to discuss the performance of the project and the Project Manager without inhibition.

The Board will meet as frequently as is required for the effective discharge of its duties. The general presumption is that it will meet monthly. Meetings will be convened by the Chair and all papers for the Board will be available at least 5 working days before the meeting. This should allow members to request any clarification required so that it might be available at the meeting.

The Project Board will minute its discussion and the Project Board Minutes will be available to all members of the BCG. Exception reports should initially be prepared by the Project Manager for the Project Board. Depending on the scale of the exception, the Project Board Chair may take further action i.e. reporting to the BCG on an exception basis, in respect of any material change to the prognosis for the project. These Reports should include any material change to the timescale, budget or deliverables. It will only be necessary for the SROs to report to the BCG on the progress of the projects if an issue arises and then it should be communicated to the BCG by way of the said exception process.

6.1.4 Project Manager
The Project Manager (PM) is tasked with delivering the project. This accountability is included in their personal responsibility plan. The PM manages all the project resources in accordance with the Prince 2 methodology. In the main the presumption is that Project Managers will be appointed on a full-time basis. To achieve this, smaller projects may be grouped under a single PM. If by exception a part-time PM is appointed care is required to ensure that they have the available time and that it is managed effectively

It is Mandatory that all Project Managers have received training in the Prince 2 Methodology before their appointment.

In addition, Project Managers appointed to large or complex projects should have gained then necessary experience.

6.1.5 Project Team
The project team is at the heart of the project. It needs to contain the balance of skills and resources required to deliver the project. The range of size and complexity of projects makes it impossible to define a typical project team. However the roles required within it can be defined and are set out in Section 2.1.1.

Particular care is required where projects are to be delivered by contractors or with the input of significant external resources. In this regard it is important to distinguish between external advice and expertise i.e. the use of legal, technical or commercial consultants and circumstances where external organisations are responsible for delivering some or all of the project. In the former case the external staff may be full members of the project team or may contribute advice to specific team members or groups. In either case it is important to agree roles and responsibilities and to ensure that communications mechanisms are in place and working well.

Where third parties are responsible for delivering all or part of the project, it is recommended that the contractors project management staff are integrated into the project team. In cases where, for whatever reason, this is not considered appropriate, great care is required in the design and management of the communications structures to ensure that Agency staff and the contractor are fully aware of what is happening.

In a hybrid team, i.e. one that includes contractor representatives, it is very important that roles and responsibilities are clearly defined, that communications are opened and maintained among all parties and that there is a clear understanding as to how conflict is to be managed and disputes resolved. This should include a clear escalation procedure, established at the outset.

Comprehensive guidance on the establishment and management of project teams is available in the publication 'Managing Successful Projects' published by CCTA and available in the Agency.

6.2 Project Financial Management
Project expenditure represents a significant proportion of the Agency's annual budget. It is important that this is managed efficiently and effectively and that we can be certain that the Agency receives value for money, both internally and externally. As a general principle, all budgetary authority rests ultimately with ministers in parliament. The Scottish Ministers have delegated responsibility in relation to the Agency to the Keeper & Chief Executive, who exercise this authority through the Management Board. The Management Board therefore must approve all budgets and changes to budgets.

In practice we prepare budgets as part of the annual business planning process and review them on a quarterly basis. The Board then approves budgets and their revision en-bloc. Project expenditure fits into this pattern. It is our intention however to focus more closely upon project expenditure and in future all major project expense will be reported individually to the Board.

6.2.1 Budgetary Approval
The process by which projects are awarded initial budgetary approval is set out in Sections 1 & 2. The important element remains the Business Case, which represents the value proposition for the project. It is important therefore that the Business Case addresses the issue of value for money as well as that of cost justification. As set out in section 1.5, provisional budget approval is set on the basis of the outline Business Case developed at the pre-project stage. Thereafter the full Business Case is developed and formal approval granted by the BCG on the basis of the full Business Case. If, on presentation of the full Business Case the assumptions in the outline Business Case do not hold good or the budget amount exceeds that agreed by the Management Board, then the full Business Case must be referred to the Management Board for a decision. Once approved, the budget cannot be altered without appropriate approval. Minor changes will be approved through the normal quarterly review process. Any major change (see section 6.2.2 Financial Tolerances) requires the explicit approval of the Management Board on the advice of the BCG.

6.2.2 Financial Tolerances
All projects require a tolerance range, both operational and financial. Again the tolerance range will vary, dependent upon the size and value of the project. The specific tolerances for each project will be set by the Management Board when budgets are agreed. However as a guide, for projects with values of between £100,000 and £250,000 tolerances might be +20%/-30% For projects of between £250,000 and £1.5 million tolerances might be +15% / -20%. For projects of over £1.5million, tolerances might be +10% / -15%.

6.2.3 Budget Change
Significant change to project budgets should be regarded as important events that merit careful management. 'Budget creep' is a bigger enemy than 'scope creep'. No change to the budget, which exceeds the tolerances, should be contemplated, far less approved, until a full revision of the Business Case has been conducted. The revised Business Case must support the change, both in cost effectiveness and value for money terms. All budget changes outwith tolerance levels must be endorsed by the BCG and approved by the Management Board.

6.2.4 Financial Reporting
Project financial performance will be reported to the Project Board at the intervals agreed, usually monthly. The project board will satisfy itself that these reports present a true and accurate picture of the project's financial status. Where the reports indicate specific issues or trends which might cause the project to exceed its tolerances, the project board will instruct the project team to take appropriate corrective action. Where it becomes clear to the project board that corrective action is ineffective it will ask the project team to prepare an exception report on the financial issues involved. This report should normally be available at the next meeting of the project board. At this meeting the project board must decide how it will manage the situation, either initiating actions to correct the financial position, or reporting the circumstances to the BCG, with recommendations.

7. Project Planning & Control

7.1 The Project Plan
The Project Plan is the document that governs the project. Again because of the diverse nature of projects it is impossible to be prescriptive as to what it should contain. Large projects will require sophisticated project plans. Smaller projects will require less. However all projects should contain the following elements:

7.1.1 Timetable & Key Milestones
Time is money. It is therefore vital that projects deliver their objectives within the agreed time frame. However it is equally important that projects are developed within a reasonable time frame and that time constraints are not allowed to damage the delivery of the project. In establishing initial timescales, Project Managers should take into account not only the nature and scale of the work proposed but also any procurement time required. It is worth remembering that if the project requires full-scale EU procedure, then at least 18 months should be allowed for this process alone.

It is wise to review the timetable for delivery of the project with the project team immediately prior to the start of the project. At this stage assumptions made during the planning cycle may no longer be valid. In addition where contractors are involved in the delivery, their operational staff as opposed to their sales staff should now be fully engaged. Clearly this process cannot be allowed to affect materially any contract awarded under open competition. However achieving agreement on realistic timings at the start can avoid time pressures later.

All projects, other than the very smallest, should be broken down into a series of intermediate stages, ideally related to intermediate deliverables. These stages represent the key milestones of the project and should be time-boxed. The time-line created by this process represents a key measurement of the project's progress. While it will be necessary to revise timings in the light of changing circumstances, serious slippage represents a risk and should be managed as such.

In addition to the cost tolerance set out in Section 6.2.2. which should cover resource, time tolerances require to be set for each project. As an Agency standard, these should initially be set at +15%/-15%. Based on these tolerance levels, the Project Board will thereafter agree with the Project Manager a tolerance for each stage once the Stage Plan has been produced.

7.1.2 Team Roles and Responsibilities
Section 2.1.3 sets out the key roles that must be present in every project team. Small teams may combine roles in one individual but all must be present. Additional roles may be required in large projects. In particular PRINCE 2 recommends that where projects are broken down into discrete chunks, each chunk is managed by a sub-set of the project team.

7.2 Change Control
Effective change control is necessary for two main reasons. Firstly it guards against 'scope creep'. All projects have a natural tendency to get bigger, become more inclusive and address issues not identified at the outset. While some change in scope is permissible and probably desirable, particularly where the outside world has moved on, it must be carefully controlled. If it is not, the project grows in an unmanaged fashion, costs inevitably escalate and unforeseen impacts create unmanaged risks. Secondly any material change to the project should be adequately justified, properly authorised and effectively managed. Change control allows this to happen in an agreed format. This is always important but vital wherever external contractors are involved. The change control regime should be set out in the PID and where appropriate the contract and strictly adhered to. Change control has both operational and administrative components. Administratively there must be a process for initiating, evaluating and signing off changes. Operationally there must be a process for agreeing and implementing change.

7.3 Project Tolerances
Project tolerances reflect the extent of the uncertainty related to any given project, together with the extent to which the Agency is willing to accept a performance range. That said all projects should have an established tolerance framework. The nature of even the smallest project means that it is impossible to predict precisely what the outcome will be. Outcomes should therefore be expressed in terms of a tolerance range. Tolerance can be expressed in the form [x+/-y ] (fixed tolerance) or [x+/-y%] ( ratio tolerance). In our case it may be more appropriate to express tolerance of outcomes in the form y=[no<98%x] and tolerance of financial deviation in the form [x+/- y%].

However tolerances are arrived at they must be monitored and where they are exceed or there is a risk that the final result will be outwith the tolerance, this should be reported and managed.

7.4 Project Reporting

7.4.1 Routine Reports - Progress/Control; Reports
Project and Programme Management are complex activities. Good communication is vital if everyone involved is to be able to discharge their individual responsibilities. A primary means of communication is the regular progress/control report prepared by the Project Manager and submitted to the Project Board. Such reports should review progress against the agreed time-line, highlight updates to the Risk Log, report performance against both resource and financial budget and make reference to any circumstance of which the board should be aware which do not warrant an exception report. Where the project is broken down into elements, the report should reflect this. Where the progress/control report identifies issues requiring a decision options should be presented, together with a recommendation. In many cases it is helpful if these can be presented together as a separate section of the report. Project managers should agree the format and frequency of report with the SRO at the outset.

7.4.2 Exception Reporting
Matters which are of serious concern or which do not lend themselves to inclusion in the regular progress/control report should be reported on an exception basis. Exception reports may be presented to the project board at its regular meetings, or in emergency submitted to the SRO at any time. Exception reports should, in the majority of cases, be completed when the project manager is forecasting that tolerances are going to be exceeded rather than when they have been exceeded. The SRO is responsible for deciding action appropriate to the scale and seriousness of the issues reported. It is expected, but not mandatory, that all exception reports will be brought to the attention of the chair of the BCG and the Programme Manager.

7.4.3 Technical Reports
Some projects may require the production of specific technical reports during their life. Such technical reports form an important part of the project documentation, particularly where they form the basis for decisions about the project. They should be retained on the project file and their consideration referred to in the minutes of the Project Board. Project Boards may commission technical reports in response to a range of situations including adverse technical performance of the project, the emergence of unforeseen risks or to examine a proposal for change control.

7.4.4 End Stage Report
Where projects have been broken down into discrete, time-boxed, packages a report is required at the end of each package, usually referred to as a 'stage'. The End Stage Report (ESR) should detail what was expected, what has been achieved and what should be done next. This is the case even where the overall project plan calls for further stages to take place. The ESR is an opportunity to review the project and confirm the Business Case. Where ESRs also coincide with the live introduction of changes, the process detailed in Section 8 should be followed.

7.4.5 Issue Escalation
Regrettably not all projects run smoothly. In particular where the Agency is involved with one or more contractors, circumstances may arise where the project team find themselves at odds with the contractor's staff. In these cases it is important that communication is maintained. If things progress to a stage where communication between the project team and the contractor has broken down, the SRO should be informed immediately. Despite maintaining communication it may still be difficult for the project team to function effectively. This will almost certainly be the case where Agency staff have ongoing concern about contractor performance. At this point the project manager should discus the situation with the SRO. At his or her discretion the SRO may make informal approaches to the contractor in an attempt to resolve outstanding differences. Alternatively or that failing the SRO is responsible for escalating the issues(s) to the next management level in the contractor organisation. This should be done formally and in writing. Thereafter the SRO should arrange to meet with the contractor to resolve the outstanding issues. If following reasonable negotiation the SRO fails to resolve the dispute, the chair of the BCG should be informed. At the discretion of the chair a detailed report should be prepared for submission to the BCG setting out the full history and current position in the dispute. The chair of the BCG will then escalate the issue to the most senior level of contractor management (usually the UK CEO) and request a meeting to try to resolve the dispute. Simultaneously the chair will report the circumstances to the Management Board. If after full escalation the issues remain unresolved, the chair of the BCG together with the SRO and Project Manager will meet with the Agency's legal advisers to review options. Ultimately the chair of the BCG can recommend to the Management Board that the contract be determined and compensation or other appropriate legal action considered.

7.4.6. End Project Report
At the end of each project an End Project Report will be completed. The End Project Report will comprise.

8. Project Completion

8.1 Implementation / Go Live Plan
Moving from a project to live implementation is a critical phase. Accordingly the overall arrangements for the transfer should be agreed at the outset, as part of the project plan. At this stage the membership of the project team is likely to change with some development members dropping out to be replaced by implementation staff from the area or areas affected. At this stage the relationship between the project team and the Business Change Manager/Team becomes of paramount importance. The diversity of projects and circumstances prevents the creation of a common template for the transfer of projects to the live environment. However all will involve the transfer of responsibility from the project board/project team to the Business Change Manager/Team. In practice members of the project team will join the BCT. The transfer should not take place until the project has been formally signed off and accepted. However the Business Change Manager should be involved in the preparation for go-live, which may be well before formal acceptance. In particular the BCM should be involved in planning the live testing regime that should precede any go-live. Exact details of the handover should be agreed between the SRO/Project Manager and the BCM. At this time they should also agree the composition of the BCT for the project.

8.2 Testing
Robust and realistic testing is essential in the go-live process. This is particularly true where the project involves the introduction of a new IT system or substantial modification to an existing system. However testing is also appropriate where only the process has changed rather than the technology.

Wherever possible testing should involve a three-stage process. First the technology or process should be tested under laboratory conditions to establish functionality, performance benchmarks and operational effectiveness. Second the tests should be transferred to a simulation environment which replicates the live field conditions as closely as possible. The scale of the project, the potential impact upon the live environment and the cost will determine the scale and realism of this simulation testing. Finally the testing will move to the live environment under controlled conditions. All live testing should involve the preparation of detailed impact assessments, communications strategy and status recovery plans.

The testing regime should form part of the project from the initiation stage.

8.3 Project sign off / final acceptance process

8.3.1 Single Stage Projects
Projects that comprise a single stage will have a single acceptance process. They may however have intermediate sign-off points, if for example the contract allows for stage payment to the contractor. Where stage payments are involved the contract should be clear regarding the conditions which warrant the payment and the project team should ensure that these have been met before recommending to the project board that the stage payment be approved.

When the project reaches the stage of final acceptance, the project team should be satisfied that all the conditions detailed in the contract/Project Plan have been met. If so they should recommend to the project board that the project be formally accepted and that any payments due on final acceptance be made. The contract may allow for retention, i.e. a small percentage of the price being retained against any snagging work. The Project Board/team need not be kept in being merely to manage retention. Management of retention should be delegated to the BCT.

8.3.2 Multi-stage Projects
Multi-stage projects will require formal sign-off at each stage. Where appropriate any contract for the delivery of a multi-stage project should be contingent upon each prior stage being successfully delivered. Thereafter the process mirrors that for a single stage project.

9. Post-implementation Review
All projects will be subject to post-implementation review (PIR). Again the scale and complexity of this activity will be related to the nature of the project. As a guide, smaller projects delivered internally, with clearly limited external involvement, will be reviewed by an internal team. The PIR team being made up of officers unconnected with the project. The PIR team will be appointed by and report to the BCG.

For larger projects and all those involving substantial external contractors, the PIR will be conducted by consultants, again appointed by and reporting to the BCG. The outcomes of all PIRs will be reported to the BCG and the Management Board.

10. Appendix

Bibliography
Managing Successful Projects with Prince 2 by CCTA (HMSO 2000)
Managing Successful Programmes CCTA (HMSO 2000)
Successful IT: Modernising Government in Action: The McCartney Report
The Rough Guide to Procurement