|
|||
| Joint Astronomy Centre |
|
|
|
| Show document only |
|
||||||||||||||||||||||
|
____________________
|
||||||||||||||||||||||
|
|
|
FM 302 MANAGEMENT AND CONTROL OF MAJOR PROJECTS
FM 302 THE MANAGEMENT AND CONTROL OF MAJOR PROJECTS 1. This FM is intended to identify the key issues which need to be addressed by management when considering new major projects (broadly those over £100k, although many of the principles apply equally to all projects) and should be read in conjunction with FM 301 (Economic Appraisal of Projects in PPARC). Project management in PPARC is, where appropriate, to be conducted in line with the PRINCE (Projects in a Controlled Environment) methodology, which is summarised at Annex B to this FM. PRINCE sets out a good practice guide to project management, which is widely used in the public and private sectors and is endorsed by PPARC. Following PRINCE concepts does not guarantee a successful project in itself, but puts in place the necessary stages which will limit failure. 2. This FM covers Major Projects relating to PPARC assets and those relating to scientific programme projects. As the nature of these projects differ this FM has been split into two sections; with the first covering major projects associated with the purchase or maintenance of major PPARC assets, (eg a new building, computer system, remedial works to existing assets etc), and the latter scientific programme projects. Delegation limits are detailed in FM 101. 3. Although local variations can apply to this FM, controls and good practice should be maintained at all times. The summary of PRINCE methodology at Annex B should be regarded as a guide to the principles concerned. Full training is needed to obtain a detailed understanding and appreciation of the way this methodology should be applied within PPARC. MAJOR PROJECTS (NON-SCIENCE PROGRAMME) 4. Three key points are to be addressed before embarking on a project: · ensure that there are in place suitable reporting/communication/control
systems and methods; 5. The need for clear and suitable reporting/communications/control systems is identified in paragraphs 30 to 33 of FM 301 (Economic Appraisal of Projects in PPARC). In particular, the need for clearly defined delegated authority is emphasised. This must be fully documented in letters to those receiving the delegated authority and must be understood by all parties. 6. The way in which such delegated authority will be exercised is also important. The granting of such authority should be accompanied by agreement on the resources necessary to manage the project. It is essential that such resources are adequate. Where necessary independent advice should be sought. 7. It is also essential that the project management team contains the correct mix of professional/technical/administration skills and clerical/secretarial support. It is, however, a matter of judgement as to whether the project manager (team leader) should be an appropriate professional (eg architect, engineer, scientist) or an administrator. Either can be successful. The important consideration is that the person selected should have recent experience of successfully managing a comparable project, or recent experience of successfully managing smaller projects and recent project management training. Where in-house staff are to be appointed as project managers up-to-date training should be provided. The alternative of contracting or seconding in an experienced project manager should always be considered and such consideration recorded on the project files. Pre-contract consideration: deciding what to build 8. The following key points should be addressed before embarking on the detailed design and procurement of a project: · define the need for the project; 9. It is an important principle that the objectives of the project are clearly stated and that these should be incorporated into the Statement of Requirement (SoR). The SoR is not a detailed design, but it is the end-users' specification of objectives which the design should achieve. Where appropriate, it should include criteria for: · reliability, including a statement of the environmental conditions and
mission against which such reliability is to be achieved; 10. FM 301 (Economic Appraisal of Projects in PPARC) provides guidance on the selection and evaluation of options, and the guidance contained therein should be followed at this stage. 11. The consideration of reliability and maintainability should lead to an assessment of whole life costs. At this stage as accurate an estimate as possible should be made of the future annual costs of operating and maintaining the facility, including the costs of any major mid-life refurbishment or upgrade. Professional advice should be obtained if necessary. This is an essential part of the economic appraisal and is also necessary to avoid the over-commitment of "baseline" allocations. 12. Risk and uncertainty must be considered. In the type of projects normally managed by PPARC it may or may not be appropriate to conduct statistical analyses of risk, but it is important to consider and document risk and uncertainty in a methodical way. For example, what are the risks and uncertainties which might lead to the project failing to met its objectives, in full or in part, and failing to be delivered within budget and on time? How will such risk be allowed for and what contingencies, time and money, might be needed in the project planning and management? 13. The need for pre-contract feasibility studies should always be considered, even though this would often require the commitment of funds in advance of money being allocated for, and might delay the start of, the main project. Feasibility studies, possibly carried out by expert consultants, can lead to the early identification of potential difficulties, can clarify the precise requirements of the project, and so can lead to a better contract. Adequate time should be allowed for such studies and for recommendations to be included in the planning process. Even if the project does not eventually proceed, reasonable expenditure on feasibility work is unlikely to attract criticism. 14. There are a number of reasons for underestimating during the original concept to pre-contract stages: i) lack of experience and knowledge; 15. Reasons i) to iv) are within the control of those responsible for directing the project, who should require estimates to be properly constructed from a zero base, documented as fully as possible, and kept up to date. As experience shows that original concept/'best guess' estimates are usually substantial underestimates, a significant contingency should be added at that stage. As the SoR develops, along with the feasibility and preliminary design work, the estimate can be refined and the contingency progressively reduced as uncertainty diminishes. It is important that the project manager establishes a procedure for identifying changes to estimates and timing, records these and the reasons and draws them to the attention of management. 16. Reasons v) to viii) are less easy to control or anticipate. Further, independent advice might be obtainable, for example from another body with experience of a similar project or by the use of project audit consultancies (see paragraph 21). Redress for poor professional advice should, as far as possible, be included in consultancy contracts. 17. Estimates of major project costs are published in the PPARC Operating Plans, and when these relate to capital expenditure they are detailed in the DTI Spending Plans and incorporated in the overall capital figures in the annual Supply Estimates. These planned data are compared to actual performance annually and significant variations require robust explanations. Major overspends or project failures could result in the PPARC Accounting Officer (ie the Chief Executive) being called to appear before a Public Accounts Committee. 18. Necessary professional advice and assistance should be sought and commissioned. Where consultants are used, the PPARC should: · decide their role and their relationship with the project manager, other
members of the project management team, other consultants, and the main
contractor and subcontractors; 19. The role of consultants may vary from project to project, ranging from advice and design, through technical supervision, to full project management. Consultants may complement the in-house team or replace them completely. The objectives should be to achieve the optimum balance of in-house and bought-in expertise and resources, and to follow current good practice. PPARC Finance Division can provide access to guidance on good practice as promulgated by the Office of Government Commerce (OGC). In any event, the role of consultants should be clearly defined, in writing, at an early stage, and that role communicated to all concerned with the project. Likewise, any change in their role during the course of a project must be put in writing and communicated to all concerned. 20. The selection of consultants should normally be by competitive tender. Criteria for evaluating tenders should be established in advance of the receipt of tenders, recorded and used by the tender board. Standard PPARC procedures for competitive tendering should be followed. 21. All consultancy contracts for major projects should be drawn up and let by Contracts staff in accordance with current best practice (OGC and other). Evidence of the consultants' professional indemnity insurance must be obtained. 22. The use of audit consultants should be considered. Such consultants are used to evaluate the completeness and validity of the work of the design consultants, and possibly to comment on other aspects of the project, for example the management arrangements. Their use is not appropriate to all projects, but such independent advice can be important where a project is complex, unusual, or contains a higher than normal degree of risk or uncertainty. 23.A public sector organisation embarking on a project should: - select a procurement strategy and decide how it should be administered, taking account of the amount of input required by the organisation: the greater the risk, the greater the input required; - select the contractors best capable of delivering the service and accepting the defined level of risk; - aim to make no client changes once a particular design feature has been decided, such changes are one of the major causes of cost overruns: the elimination of change should be a prime objective; - consider, with the advice of consultants and/or others, how the design and construction phases are to be inter-related and who is to carry them out. Where there would be a clear advantage in giving the design and construction to the same contractor, this should be done; - Ensure that, before a project is submitted for full approval, estimates of cost and timescales are valid and up-to-date. 24. In selecting the strategy it is important to decide how much direct control of the design and construction is necessary. Direct control consumes considerable in-house resources, whereas contracting out consumes much less and can achieve the same objective, provided the contract is tightly drawn with the minimum of provisional sums and tough, but fair, liquidated damages payable by the contractor for late delivery, failure to meet specifications etc. OGC guidance on good practice should be observed. 25. There should be a strong presumption in favour of selecting contractors for design and construction by a process of competitive tendering. The selection process must, at the minimum, confirm with EU public procurement directives, but in some cases it may be desirable to seek expressions of interest from a wider field, for example by advertising in the appropriate trade press. In short-listing contractors to be formally invited to tender for unusual projects, it is important not to apply criteria which narrow the field too rapidly. For example, where a special type of experience or expertise is required, potential tenderers should be asked to explain how they would acquire and mobilise such experience or expertise. They should then be judged against their responses rather than being eliminated solely for the lack of a track record of similar projects. Guidance on competitive tendering is contained in FM 401 and procurement staff will administer the tendering process within delegated limits. 26. There are two different design and construction philosophies, either of which can be valid in appropriate circumstances. The first, traditionally used by PPARC on most projects, is to employ separate contractors for design and construction. The advantages are that the design leads to a very tight specification against which a fixed price construction contract can be achieved. The disadvantages are that re-design work may be required during construction, and errors in design may lead to additional cost claims from the construction contractor. 27. The second is to let a single design and construct contract, using the SoR as the contract specification. The advantage of this strategy is that it leads naturally to much closer liaison between designer and builder and hence a better chance of optimum solutions being developed. The disadvantage is that the client cannot see exactly what is to be built prior to letting the main contract. This may lead to increased pressure for client changes as the project proceeds. 28. As a rule of thumb, separate design and construction contracts may offer the best strategy for unusual, one-off projects, whilst combined design and construction contracts may be more suitable for projects requiring a high proportion of industry standard components or which follow closely on other designs. However, in all projects both strategies must be considered and the relative merits and drawbacks weighed up and documented before a decision is made. 29. The greater the separation of project management, design and construction functions, the more important it is to achieve absolute clarity as to where the contractual responsibilities lie and the greater the task of ensuring good communications are maintained between all concerned. 30. When managing the construction phase of a project the following should be followed: · draw up contract documents for the construction phase, including general
specifications and documentation of the scope of the work; 31. In general, PPARC seeks to use well established forms of contract for major projects. Even so, weaknesses can arise. When drafting contracts for major projects, particular attention needs to be paid to: · whether stage payments should be linked to measured work by the contractor
or to milestone events in the performance of the contract; 32. In cases where it is not possible to achieve the ideal contractual position for PPARC, for example because of the relative negotiating strength of the potential contractor, the consideration of these and other factors should be properly recorded on registered files. 33. On satisfactory completion of a project the work should be formally accepted by the project manager. For example, the client might issue a certificate of practical completion to the contractor. The procedure may vary from project to project, but it is important that the project is formally 'closed off' by the project management team, and that client and customer clearly understand the extent of any continuing commitments, for example during a guarantee period. 34. The project management committee should carry out an evaluation at the end of the project. The evaluation should measure the success of the project and define and record the lessons learnt, in order to improve performance on subsequent projects. 35. Post-project evaluation and feedback is a standard procedure in PPARC (see FM 301 -Economic Appraisal of Projects in PPARC). This is an important means of ensuring that lessons are learnt and are retained in the corporate memory. 36. The evaluation should be carried out soon after project completion whilst events are still fresh in people's minds. If a maintenance or guarantee period is involved an interim evaluation should be carried out on practical completion with a final evaluation at the end of such a period. 37. It is important that these strategies are considered afresh at the start of each new project and that best advantage is taken of current available guidance and best practice. Particular attention needs to be paid to the following aspects: · resources allocated to project management must be appropriate to the scale
and complexity of the project; 38. The methodical application of the points identified in the checklist (Annex A to this FM) to this paper should ensure that future projects are managed to the best modern standards. MAJOR PROJECTS - SCIENTIFIC PROGRAMME Setting up the project 39. Two key points are to be addressed before embarking on a project: · ensure that there are in place suitable reporting/communication/control
systems and methods; 40. The need for clear and suitable reporting/communications/control systems is identified in paragraphs 30 to 33 of FM 301 (Economic Appraisal of Projects in PPARC). In particular, the need for clearly defined delegated authority is emphasised. This should be fully documented in letters to those receiving the delegated authority and understood by all parties. 41. It is essential that the project management team contains the correct mix of professional/technical/administration skills. And that that the people selected should have recent experience of successfully managing a comparable project, or recent experience of successfully managing smaller projects. See the overview of PRINCE project management at Annex B. 42. The following key points should be addressed: · the proposed concept; 43. It is an important principle that the objectives of the project are clearly stated and that these should be incorporated into the Statement of Requirement (SoR). The SoR is not a detailed design, but it is the end-users' specification of objectives which the design should achieve. Where appropriate, it should include criteria for: · reliability, including a statement of the environmental conditions and
mission against which such reliability is to be achieved; 44. FM 301 (Economic Appraisal of Projects in PPARC) provides guidance on the selection and evaluation of options, and this should be followed at this stage. 45. Proposals for new facility instruments must be submitted to the relevant Facility Board or Committee for prioritisation, and if agreed it will be submitted, via the Facility Director, to the Ground Based Facility Committee for inclusion in the relevant Operating Plan. It is the responsibility of the Facility Director to agree the design and technical specification in consultation with the relevant board or committee. Subsequent design studies must be reported to the Facility Board/Committee. Details of the PPARC project approval processes are contained in FM 101. 46. The consideration of reliability and maintainability should lead to an assessment of whole life costs. At this stage as accurate an estimate as possible should be made of the future annual costs of operating and maintaining the facility, including the costs of any major mid-life refurbishment or upgrade. Professional advice should be obtained if necessary. This is an essential part of the economic appraisal and is also necessary to avoid the over-commitment of "baseline" allocations. 47. Risk and uncertainty must be considered. In the type of projects normally managed by PPARC it may or may not be appropriate to conduct statistical analyses of risk, but it is important to consider and document risk and uncertainty in a methodical way. For example, what are the risks and uncertainties which might lead to the project failing to met its objectives, in full or in part, and failing to be delivered within budget and on time? How will such risk be allowed for and what contingencies, time and money, might be needed in the project planning and management? Many scientific projects in PPARC will be high risk by nature through charting new territory or operating in high risk environments, however, this is not an excuse to avoid properly considering these factors. 48. The need for feasibility studies should always be considered, even though this would often require the commitment of funds in advance of money being allocated for, and might delay the start of, the main project. Feasibility studies, possibly carried out by 'experts', can lead to the early identification of potential difficulties, can clarify the precise requirements of the project, and so can lead to a better contract. Adequate time should be allowed for such studies and for recommendations to be included in the planning process. Even if the project does not eventually proceed, reasonable expenditure on feasibility work is unlikely to attract criticism. 49. Consideration should be given to the possibility of external participation in any instrumentation project, including international collaboration. Estimating cost and time 50. There are a number of reasons for underestimating during the original concept to pre-contract stages: i) lack of experience and knowledge; 51. Reasons i) to iv) are within the control of those responsible for directing the project, who should require estimates to be properly constructed from a zero base, documented as fully as possible, and kept up to date. As experience shows that original concept "best guess" estimates are usually substantial underestimates, a significant contingency should be added at that stage. As the SoR develops, along with the feasibility and preliminary design work, the estimate can be refined and the contingency progressively reduced as uncertainty diminishes. It is important that the project manager establishes a procedure for identifying changes to estimates and timing, records these and the reasons and draws them to the attention of management. 52. Reasons v) to viii) are less easy to control or anticipate. Further, independent advice might be obtainable, for example from another body with experience of a similar. 53. In line with FM 101 submission for approval must: · State the objective; 54. The outcome of the design study must be reported to the Facility Board/Committee. The report should include a draft budget, with more accurate costings, together with a formal project plan including science requirements, milestones and a cash limited cost profile. 55. Estimates of major project costs are published in the PPARC Operating Plans, and when these relate to capital expenditure they are detailed in the DTI Spending Plans and incorporated in the overall capital figures in the annual Supply Estimates. These planned data are compared to actual performance annually and significant variations require robust explanations. Major overspends or project failures could result in the PPARC Accounting Officer (ie the Chief Executive) being called to appear before a Public Accounts Committee. 56. - select a project strategy and decide how it should be administered, taking account of the amount of input required by the organisation: the greater the risk, the greater the input required; - select the organisation best capable of delivering the goods/service and accepting the defined level of risk; - aim to make no client changes once a particular design feature has been decided, such changes are one of the major causes of cost overruns: the elimination of change should be a prime objective; - consider, with expert advice, how the design and build phases are to be inter-related and who is to carry them out; - Ensure that, before a project is submitted for full approval, estimates of cost and timescales are valid and up-to-date. 57. In selecting the strategy it is important to decide, where applicable, how much direct control of the design and construction is necessary. 58. There are two different design and construction philosophies, either of which can be valid in appropriate circumstances. The first is to adopt separate design and construction. The advantages are that the design leads to a very tight specification against which a fixed price construction contract can be achieved. The disadvantages are that re-design work may be required during construction, and errors in design will lead to claims from the construction contractor. 59. The second is a single design and build contract/agreement, using the Statement of Requirements as the contract specification. The advantage of this strategy is that it leads naturally to much closer liaison between designer and builder and hence a better chance of optimum solutions being developed. The disadvantage is that the client cannot see exactly what is to be built prior to letting the main contract. This may lead to increased pressure for client changes as the project proceeds. 60. As a rule of thumb, separate design and construction contracts/agreements may offer the best strategy for unusual, one-off projects, whilst combined design and construction contracts may be more suitable for projects requiring a high proportion of industry standard components or which follow closely on other designs. However, in all projects both strategies must be considered and the relative merits and drawbacks weighed up and documented before a decision is made. 61. The greater the separation of project management, design and construction functions, the more important it is to achieve absolute clarity as to where the contractual responsibilities lie and the greater the task of ensuring good communications are maintained between all concerned. Project Build 62. In general, PPARC seeks to use well established organisations for major projects. Even so, weaknesses can arise. Particular attention needs to be paid to: · whether agreements should require stage payments linked to measured work
or to milestone events in the performance of the agreement; 63. Any factors relating to the project which could potentially affect the outcome should be properly recorded on registered files. 64. If, during the course of the project, the contingency sum which was built into the original project costing needs to be utilised then a case for release must be made to the Director Science. This needs to address the alternatives and consequences should contingency funds not be released, which may include descoping the project (see FM 101). 65. On satisfactory completion of a project the work should be formally accepted by the project manager. The procedure may vary from project to project, but it is important that the project is formally 'closed off' by the project management team, and that client and customer clearly understand the extent of any continuing commitments. Evaluation 66. The project management committee should carry out an evaluation at the end of the project. The evaluation should measure the success of the project and define and record the lessons learnt, in order to improve performance on subsequent projects. 67. Post-project evaluation and feedback is a standard procedure in PPARC (see FM 301 -Economic Appraisal of Projects in PPARC). This is an important means of ensuring that lessons are learnt and are retained in the corporate memory. 68. The evaluation should be carried out soon after project completion whilst events are still fresh in people's minds. If a maintenance or guarantee period is involved an interim evaluation should be carried out on practical completion with a final evaluation at the end of such a period. Conclusions 69. It is important that these strategies are considered afresh at the start of each new project and that best advantage is taken of current available guidance and best practice. Particular attention needs to be paid to the following aspects: · resources allocated to project management must be appropriate to the scale
and complexity of the project; 70. Annex A lists the points which need to be addressed as part of managing projects. Some points will clearly relate to non science programme projects only. 71. Any queries concerning the content or interpretation of this FM should be referred to Paul Blackford, Head of Planning & Budgeting, PPARC Finance Division, Swindon Office, tel: 01793 442062, e-mail: paul.blackford@pparc.ac.uk. David Bennett CHECKLIST OF ACTIONS Setting up the Project - have all the guidance and rules in FM 301 (Economic Appraisal of Projects in PPARC) been correctly applied; - are the planned project management resources adequate? - is the proposed project manager suitably experienced and trained? - has a proper comparison been done of the relative merits of an in-house project manager and one contracted/seconded in? Pre-contract consideration: deciding what to build - has a full Statement of Requirements (SoR) been drawn up? - does the SoR contain appropriate criteria for reliability, maintainability, availability and quality assurance? - have all reasonable options, including that of not proceeding, been evaluated? - have whole life costs been identified and evaluated? - have risks and uncertainty been properly analysed? - has adequate feasibility work been carried out? Estimates of Cost and Time - does the original estimate have a justifiable basis, supported by independent advice where appropriate? - does the estimate take reasonable account, by inclusion of contingencies, of risk and uncertainty? - has the estimate been regularly updated, with professional advice, as the SoR and specification/design developed? - has the project been subject to independent audit? Employment of Consultants - has the role of consultants been fully defined and communicated to all concerned? - does that role follow current guidance on good practice for the type of project? - have the consultants been selected by competitive tender? If not, why not? - have consultancy contracts been properly drawn up and let? - does the consultant hold adequate professional indemnity insurance? - has the use of audit consultants been considered/have audit consultants been employed? With what results? Procurement Strategy - is the procurement strategy manageable and appropriate to the objectives of the project? Does it conform with recommended good practice? - does the selection of contractors result from competition? - is the "no client changes" rule being rigorously applied? - have the options for the separation or combination of design and construction contracts been properly considered? Project Build - does the contract comply with current guidance (OGC etc) on best practice? - has any divergence from best practice been considered by the Head of Procurement and agreed by the PPARC Head of Finance and the reasons properly recorded? Evaluation - has a post-project evaluation been carried out? - have the results been promulgated? PRINCE - PROJECT MANAGEMENT Contents 1. Introduction 1.1 What is a Project? 2.1 PRINCE Background 3. Process Overview 3.1 The Process Model PRINCE Project Management - An Overview 1. Introduction 1.1 What is a Project? PRINCE defines a project as: A management environment that is created for the purpose of delivering one or more business products according to a specified business case. A PRINCE project would have the following characteristics: - a finite and defined lifetime Any project will fall within a specific business context; it may be stand-alone, one of a sequence of related projects, or part of a programme or corporate strategy. Since a project is, by definition, a temporary structure created to achieve a particular business benefit or objective, it is disbanded once the work is completed. A project has a life cycle, namely the path and sequence of activities needed to produce the final business product. The product will also have its own life cycle, which will normally extend beyond the end of the project that produces it. The two life cycles should not be confused; they are shown in Figure 1. PRINCE (PRojects IN a Controlled Environment) covers the project life cycle plus some of the pre-project preparation. Figure 1 Product and project life cycles 1.2 Types of Project All projects are different, but they can generally be classified into one of four categories, as shown in Table 1. Project Yes Do we know how to go about it? No Table 1 Categories of Project The characteristics of the projects are summarised as follows. 1) Closed projects occur when an organisation is undertaking a task that is well defined and is familiar with the approach to it. It will quite often have been undertaken previously and procedures describing the approach and past experiences may well exist. Typical examples could be: a construction company putting up another building; a computer service organisation installing a new computer system; a pharmaceutical company undertaking drug trials of a new product. Since closed projects are well defined, they are often large and complex with a great many dependencies. The challenge is normally to complete the job quicker, more effectively or with fewer resources. 2) Semi-closed projects involve a very well defined goal but little knowledge of how to achieve it. An example could be the implementation of a management information system, giving senior staff all the information they need at the touch of a button. One way to tackle semi-closed projects can be to have a number of parallel "solution seekers" who then pool experiences. 3) Semi-open projects are characterised by a good understanding of the way in which the job should be done, but only a hazy idea of the ultimate goal. Examples would include developing completely new products or finding uses for a new technology. Scientific research will often fall into this category. Since the approach is well known it can be tempting to put too much effort into defining and planning, rather than searching for the goal. In the IT environment, modern prototyping methods (such as Rapid Application Development) are particularly useful for this type of project. 4) Open projects occur when an organisation is unsure both of what should be done and how it is to be carried out. They often come about when a business is attempting to do something it has never done before and can arise from a change to the external business, political or legislative environment, or from implementing a new part of its own strategy. Organisational change can fall into this category, such as implementing a Quality Improvement programme. Another example would be developing a new product for a market an organisation has not sold into before. The way to succeed in open projects is to proceed very slowly, evaluating and reviewing after each step. PRINCE can handle all types of project, though the way in which the method is applied will vary. 1.3 Project Failures It is a fact that projects often fail. While they may start out from some perceived business need, the need and objective can become blurred and confused as time goes on. A project may end up not delivering what was expected and the investment made may produce few benefits. Projects often fail, not through ineffectiveness of people, but because of the complexity of managing a project. A survey found that 80% of the reasons for project failure were management, rather than technical. Some problems typically encountered include: - impossible constraints on time and/or budget; An organisation can minimise the problems causing project failure by adopting a methodology for managing projects. A methodology will seek to provide answers to the questions "what is to be produced?", "by whom?", "how and when will it be done?" and "why are we doing it?". Furthermore, it will seek to provide these answers in a clear, unambiguous form that can be documented, understood, agreed by all concerned, and followed. The PRINCE methodology has been developed with this in mind. Note that it is possible for a project to 'fail' in terms of its final outcome, but be classed a success in terms of project management. This type of situation can arise, for example, when during the lifetime of the project the reason for undertaking it ceases to be valid; organisational and political changes, or technological advances are common causes for this to occur. In such situations the right approach will be to abort a project, so that resources of staff time and money are not wasted. 2. The PRINCE Methodology 2.1 PRINCE Background PRINCE has been evolving and developing in both private and public sectors since the late nineteen-seventies, and is therefore a well proven method. PRINCE was launched officially in 1989 and is owned by the CCTA (Central Computer & Telecommunications Agency). It is publicly available; any organisation may therefore use it without license or payment. Experience with the initial published version of PRINCE proved its strengths, but also showed a number of areas that needed improvement. These included an orientation towards IT, a prescriptive manner for particular management techniques and an overly bureaucratic approach (although the latter is more a question of implementation than actuality). A new version (PRINCE II) has been developed which builds on the strengths of PRINCE I while overcoming its deficiencies. The new version was developed by a group of consultant organisations, with HMSO and IBM responsible for its publication (for the paper and on-line versions respectively). 2.2 Scope of PRINCE PRINCE is not intended to cover all subjects relevant to project management, since some aspects lie more properly in other areas, such as Programme Management. In addition, there are a number of existing and proven methods which cover certain aspects of project management, such as: a) people management techniques (motivation, delegation and leadership), The techniques and tools needed will vary according to the business environment and the type of project. PRINCE draws a real distinction between management of a project and the technical work done to produce the required product or outcome. PRINCE covers the management of the project and its resources, but does not address the specialist techniques involved in creating products; this is covered by other methods, to which PRINCE must interface. Another area of concern often lies with procurements. While the contracting process does not form one of the elements of PRINCE, since contracting and procurement can be thought of as technical activities, they can be managed under the PRINCE umbrella. Where a procurement forms part of a PRINCE project, it will be important to ensure that project documentation is in line with contractual requirements. 2.3 PRINCE in Context PRINCE has been designed for use on any project and in any environment. It contains all the necessary concepts and management processes that are required for a properly run and managed project. However, it is important to realise that the way in which PRINCE is applied will vary considerably and the method should therefore be tailored to suit both the organisation and a particular project. Appropriate tailoring is critical to the effectiveness of the method. PRINCE projects focus on the production and delivery of specified products to satisfy a specified business case. There will be higher level issues, such as managing programmes, which will need to be handled by other methods. Similarly there are lower level techniques for managing particular tasks. PRINCE occupies the ground in between these two extremes. A project can rarely be undertaken in isolation and will be subject to dependencies. There will be outputs from one project required for another. There may be shared resources required by a number of projects. PRINCE emphasises the products that a project is required to deliver, thereby forming a sound basis for the identification and management of dependencies and the definition of project boundaries. 2.4 PRINCE Elements 2.4.1 Interests Within any project there are number of groups with an interest in its outcome. These include: 1) Customers who have commissioned the work and will benefit from the end result. This is sometimes known as the Business interest. 2) Users who will use or operate the final product. These are often drawn from the same group as Customers. 3) Suppliers who provide the special skills and/or resources to the project, or provide goods or services. These can be drawn from a Technical department within the Customer's organisation. In addition there may be sub-contractors who provide products or services to the suppliers. PRINCE recognises the different interests and requires that they are all considered and protected at each stage of a project. Figure 2 shows the partnership of these interests. Figure 2 Principal Project Interests
The Customer/Supplier environment assumes that there will be a Customer who specifies the required outcome, uses the final products and, normally, funds the work, while a Supplier provides the skills and resources to achieve that outcome. PRINCE has been developed from the point of view that these two parties are drawn from separately managed enterprises and sometimes from commercially separate organisations. Where both are drawn from a single organisation, the composition of the Project Board will be influenced. Regardless of the composition of the team undertaking the work, the Customer should always be involved throughout the project, particularly in the creation and the verification of products. 2.4.2 Business Case A requirement of PRINCE is that the business benefits to be obtained are defined in advance and considered throughout the project. The benefits are stated in the Business Case, which forms part of the project Initiation Document. If for some reason the benefits cease to be achievable, it will often be more cost-effective to cancel the project than continue with it. Benefits can take many different forms: a) financial, in the form of additional revenue or to avoid costs (or
possibly even to ensure survival!); Throughout a PRINCE project, the Business Case is reviewed and progress measured against the defined benefits. During the lifetime of a project opportunity may arise to generate additional benefits that may enhance the final product, or provide improvements to other projects. However, any deviations from the initial Business Case must be strictly controlled by the Project Board. 2.4.3 Project Organisation An overall objective of PRINCE is to have the right people involved in a project at the right time. The organisational structure therefore needs to be defined and responsibilities allocated at a level commensurate with authority. Figure 3 shows the general organisational structure of a PRINCE project. Figure 3 PRINCE Organisational Structure The Project Board are owners of the project; they are responsible for the project's success or failure. It will report normally to the corporate or programme management. Below the Board is the Project Manager, possibly supported by a series of specialist team managers (or stage Managers). The Project Manager is responsible to the Project Board for all aspects of the project on an on-going day to day basis. Overall their function is to plan the project and to ensure that project products are delivered to the Board on time, within budget, to the required quality levels and satisfying the Business Case. The Specialist Teams are made up of a mixture of users and technical experts, creating the technical end products. Since projects will sometimes involve external contractors it may be that these teams are drawn from the supplier. The Project Assurance Team (PAT) does not have executive power. They are there to provide confidence to the Project Board. Board members are very unlikely to have time to devote to detailed assurance (eg of quality) and this function is usefully delegated. Project Support is there to provide a centre of excellence in project management to assist the Project Manager. Its function can vary and could include supporting project management tools, providing configuration management, processing requests for change, assisting in drawing up plans, helping with estimation and acting as a repository for historical project information. Ideally it would be concentrated in a Project Support Office. For the duration of the project these reporting lines exist within a matrix management framework. Each member retains their normal line management boss for the purposes of personnel administration and allocation of non-project work, but is responsible to the project boss for project work. 2.4.4 Product-Based Approach PRINCE employs the Product-Based Planning technique, which focuses on what has to be produced rather than what needs to be done. It involves three elements: i) the Product Breakdown Structure, in which the end business product is
broken down, in a hierarchical form, into its component products; The product based planning technique allows the project to define in clear terms the quality criteria to which each product must conform. Means of testing quality need to be built into the management process of a project. PRINCE describes one technique, Quality Review, that may be used, but other techniques may be appropriate to use either in addition or as alternatives. Whatever methods are chosen the Quality plans must state what they are, when and how they will be applied and by whom. 2.4.5 Tolerance No project ever goes completely to plan. Some things will go a little slower than planned, or cost a little more. Other things will go quicker, cost a little less. These little variations will occur all the way through a plan. Although the Project Board will agreed a plan with the Project Manager, it does not want the Project Manager to be constantly seeking its authority to spend an additional pound, or report that the plan is one day behind schedule. On the other hand, the Project Board does not want progress to deviate wildly from the plan without being told and being able to react. The dividing line between differences which are permissible and those which require Project Board intervention is called Tolerance. The two standard elements to tolerance are time and cost, although scope and quality are other possible options. Tolerance is the permissible deviation from a Stage or Project Plan without bringing the deviation to the attention of the Project Board (or higher authority if the deviation is at project level). Separate tolerance figures should be given for time and cost. 2.4.6 Project Phases PRINCE allows a project to be divided into a number of stages, each of which forms a separate entity for management purposes. Each stage has a defined set of products (or outcomes), a lifespan, resources and an organisation structure. The completion of each stage is determined by the satisfactory delivery of the appropriate products. Stage boundaries are chosen to suit the project and can depend on: a) the order of delivery of products; Whatever the size of the project, PRINCE defines a Project Initiation Stage, during which the project is accurately defined and planned. The Initiation Stage concludes with a management review during which the viability of the project is assessed and, if appropriate, authorisation given to proceed with the project. This avoids making unnecessary commitment of resources. The principal documentation to come out of this stage is the Project Initiation Document, or PID, which contains complete details of the project, including business case, plans, quality strategy, the organisation etc. In certain situations, a Feasibility study may be required as a precursor to a project. This would investigate the situation and determine options for the way forward. Under PRINCE such a study would normally be handled as a distinct project; the main project would then follow on after a conscious (and informed) management decision. A project has a limited lifetime and so PRINCE defines a final phase, Project Closure, which closes down a project, captures any useful historical data, documents any lessons that can be learned for the future and accepts the final business product. Between project initiation and closure there will be one or more management stages during which work will be carried out to produce the required products. During stages the progress will be monitored continuously to ensure that the project is proceeding according to the agreed plan and that changes affecting project outputs are controlled. If more than one stage is involved some management effort will be expended in managing the boundaries. 2.5 Processes and Components 2.5.1 PRINCE Processes PRINCE is a process-based approach to project management, where the processes define the activities to be carried out during the project. In addition, PRINCE defines a number of components that need to be considered within each of the activities. The relationships in the PRINCE Process Model are shown in Table 2. Level 1 2 3 4 Table 2 PRINCE Process Model Apart from one or two exceptions, PRINCE is not prescriptive with regard to the Techniques and their supporting Product Outlines. Users of the method are free to select the tools that are most appropriate for their organisations and the project in hand. With the emphasis of PRINCE on tailoring, an organisation can therefore make use of any techniques with which it is familiar, provided that such techniques are compatible with PRINCE. The major exception is Product Based Planning; this technique is one of the cornerstones of PRINCE. Figure 4 shows the eight PRINCE processes, which range from getting the project started correctly, through controlling the progress of the project to its completion. The common Planning process is used by many of the other processes. Throughout the process model there are management inputs and outputs of each process. PRINCE is a product based method, so each product is identified, defined and its delivery controlled. Naturally, responsibilities for each process and product must be defined. Figure 4 PRINCE Processes 2.5.2 PRINCE Components PRINCE recognises sight components, namely: - organisation Each component needs to be considered to a greater or lesser extent within each of the individual processes. Many of these components have already been described in Chapter 2. A project, by its nature, needs to be set up to handle change since the future is always less predictable than with routine work. Also, since projects can be large and complex, or deal with new or unusual factors, risk must be considered as part of the project management. During a project the specification of products will invariably need to change. Such changes need to be controlled as they can destroy the project's overall chance of success. Controlling changes is linked to version control, which PRINCE handles as Configuration Management. Configuration Management focuses on controlling the products being delivered, knowing at what stage and version they are at any time, who is working on them and why. 3. Process Overview 3.1 The Process Model PRINCE identifies eight processes which need to be undertaken when managing a project namely: - Starting up a Project Planning is a process used throughout a project. These processes have inputs
and outputs, and interact with each other. Figure 6 shows the processes
diagrammatically, together with typical input and output Figure 6 PRINCE Processes and their interactions These processes link to a range of project management techniques, some of which are specific PRINCE techniques, and some of which are generic and generally used techniques. Project management is seldom straightforward enough to be a simple, linear process. In a PRINCE context, there are essentially five parallel process levels to take into account, as shown in Figure 6. The first four of these are management process levels, while the fifth is of a 'technical' nature. Programme Management Customer only Directing a Project Developing Products Customer or Supplier/Technical a) At the highest level is programme management. While it is not part of project management as such, programme management is important, as it will often set the context for one or more projects. It is also worth noting that the type of programme management in use within a particular business or organisation may consist of more than one process level. It may also be applied with variable degrees of formality. Figure 6 suggests that this is a ?Customer only? domain. However, there may be certain circumstances where the Supplier takes some programme management responsibility. b) Within the project itself the highest level is Directing a Project (the Project Board work). At this level a minimum of management effort is expended. c) At the level of Managing a Project the majority of management effort is expended. d) At the lowest management level, Managing Product Delivery would be handled by Team Leaders. e) Below this, Developing Products (which is not part of project management) carries out the tasks which produce the project's interim and final products. There are two major ways in which these levels interact. These are: i) The higher level processes exercise control over the lower levels. ii) The output of the lower level processes provides the input which allows the higher level processes to function effectively. 3.2 Summary of the Processes 3.2.1 Directing a Project Directing a Project runs from the start-up of the project until its closure and is aimed at the Project Board. The Project Board manages by exception, monitors via reports and controls through a number of decision points. The key processes for the Project Board break into four main areas: - Initiation (starting the project off on the right foot); - Ad hoc direction (monitoring progress, providing advice and guidance,
reacting to exception situations); This process does not cover the day-to-day activities of the Project Manager. 3.2.2 Starting up a Project This is the first process in PRINCE. It is a pre-project process, designed to ensure that the prerequisites for initiating the project are in place. The process expects the existence of a Project Mandate which defines in high level terms the reason for the project and what outcome is sought. This process should be very short but should often include some form of feasibility study. The work of the process is built around the production of three elements: - ensuring that the information required for the Project Brief is available; 3.2.3 Initiating a Project The objectives of Initiating a Project are to: - agree whether or not there is sufficient justification to proceed with the
project; 3.2.4 Managing Stage Boundaries This process provides the Project Board with key decision points on whether to continue with the project or not. The objectives of the process are to: - assure the Project Board that all deliverables planned in the current Stage
Plan have been completed as defined; 3.2.5 Controlling a Stage This process describes the monitoring and control activities of the Project Manager involved in ensuring that a stage stays on course and reacts to unexpected events. The process forms the core of the Project Manager's effort on the project, being the process which handles day-to-day management of the project. Throughout a stage there will be a cycle consisting of: - authorising work to be done; This process covers these activities, together with the on-going work of risk management and change control. 3.2.6 Managing Product Delivery The objective of this process is to ensure that planned products are created and delivered by: - making certain that work on products allocated to the team is effectively
authorised and agreed; 3.2.7 Closing a Project The purpose of this process is to execute a controlled close to the project. The process covers the Project Manager's work to wrap up the project either at its end or at premature close. Most of the work is to prepare input to the Project Board to obtain its confirmation that the project may close. The objectives of Closing a Project are, therefore, to: - check the extent to which the objectives or aims set out in the Project
Initiation Document have been met; 3.2.8 Planning Planning is a repeatable process, and plays an important role in other processes, the main ones being: - Planning an Initiation Stage; PRINCE provides a product-based start to the planning activity. It also provides a planning framework which can be applied to any type of project. This involves: - establishing what products are needed;` |
