BS 6079-1:2000 - Project management - Part 1: Guide to project management (BS6079)

British Standard A single copy of this British Standard is licensed to Giorgio Cavalieri on August 29, 2000 This is an uncontrolled copy. Ensure use of the most current version of this standard by searching British Standards Online at bsonline.techindex.co.uk

BRITISH STANDARD

Project management — Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Part 1: Guide to project management

ICS 03.100.50

BS 6079-1:2000 Incorporating Amendment Nos. 1 and 2 to BS 6079:1996 (amendment no. 2 renumbers the BS as BS 6079-1:2000)

BS 6079-1:2000

Committees responsible for this British Standard The preparation of this British Standard was entrusted to Technical Committee MS/2, Project management, upon which the following bodies were represented:

This British Standard, having been prepared under the direction of the Management Systems Sector Board, was published under the authority of the Standards Board and comes into effect on 15 April 1996

Summary of pages This document comprises a front cover, an inside front cover, pages i and ii, pages 1 to 52, an inside back cover and a back cover. The BSI copyright notice displayed in this document indicates when the document was last issued.

© BSI 01-2000

Amendments issued since publication The following BSI references relate to the work on this standard: Committee reference MS/2 Draft for comment 94/408410 DC, 94/408411 DC and 94/408412 DC ISBN 0 580 25594 8

Amd. No.

Date

Comments

10146

February 1999

Indicated by a sideline

10794

January 2000

Renumbers as BS 6079-1

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Association of Project Managers British Standards Society British Telecommunications plc Chartered Institute of Management Accountants Federation of Civil Engineering Contractors Federation of the Electronics Industry Fellowship for Operational Research Highways Agency Institute of Quality Assurance Institution of Incorporated Executive Engineers Institution of Mechanical Engineers Ministry of Defence Operational Research Society Power Generation Contractors’ Association (PGCA (BEAMA Ltd.)) Society of British Aerospace Companies Ltd. South Bank University User Standards Forum for Information Technology (Institute of Data Processing Management)

BS 6079-1:2000

Contents

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Committees responsible Section 1. General Introduction 1.1 Scope 1.2 References 1.3 Definitions

1 1 2 2

Section 2. The corporate aspects of project management 2.1 General 2.2 Nature of projects 2.3 The work to be done 2.4 The project life cycle 2.5 The benefits of project management

4 4 5 7 8

Section 3. Project and company organizational structures 3.1 General 3.2 The hierarchical functional organization 3.3 The matrix organization 3.4 The project organization 3.5 Criteria for reorganization

9 9 10 11 11

Section 4. The project management process 4.1 General 4.2 The project management process: introduction 4.3 The project management process: planning 4.4 The project management process: control 4.5 The project plan 4.6 Processes supporting the project management process 4.7 Project personnel development

13 13 13 24 27 29 40

Section 5. Project lifecycle 5.1 General 5.2 Types of project 5.3 Project phasing 5.4 Project phase sequence 5.5 Description of phase content

42 42 42 42 43

Annex A (informative) Project management methodology: cost/schedule control system criteria (C/SCSC)

50

Figure 1 — Arrangement of project phases, stages and milestones Figure 2 — Authority relationships in organization structures Figure 3 — Project management process flow Figure 4 — Model work breakdown structure Figure 5 — Model bar chart Figure 6 — Typical cumulative cost pattern Figure 7 — Format of cash flow forecast Figure 8 — Earned value chart Figure 9 — Project management life cycle Figure 10 — Periodic estimate of project cost and finishing date

6 10 15 16 21 35 36 39 43 47

Table 1 — Model project plan Table 2 — Example of discounted cash flow Table 3 — List of typical project phases

29 37 49

List of references © BSI 01-2000

Page Inside front cover

Inside back cover i

BS 6079-1:2000

Foreword This part of this Britsh Standard has been prepared by Technical Committee MS/2, Project management. It is published in three parts: Part 1: Guide to project management. Part 2: Vocabulary. Part 3: Guide to the management of business related project risks.

A British Standard does not purport to include all the necessary provisions of a contract. Users of British Standards are responsible for their correct application. Compliance with a British Standard does not of itself confer immunity from legal obligations.

Summary of pages This document comprises a front cover, an inside front cover, pages i and ii, pages 1 to 52, an inside back cover and a back cover. The BSI copyright notice displayed in this document indicates when the document was last issued. ii

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Change of identifier Wherever BS 6079:1996 appears in the text it should be read as BS 6079-1:2000.

BS 6079-1:2000

Section 1. General

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Introduction Project management could be said to be as old as humankind since, by definition, any management activity that introduces a new objective or causes change and has a definite start and finish time is a project. Formal project management as we know it today started from the development of network techniques in the late 1950s. The application of sophisticated project management techniques to projects in government and industry has become necessary to ensure the achievement of business, economic, environmental, strategic and political goals. The benefits of project management techniques are not restricted to large projects. Such techniques, like all good management practices, can usefully be applied to a project regardless of its size. It is often the case that major projects are broken down into smaller projects with a subcontractor, who thus becomes part of the project plan of the parent organization and needs to demonstrate competence in this area when tendering for the business. In any organization, whether private or public sector, service or manufacturing, software or hardware, it is necessary to plan, control and implement tasks to achieve a given objective. Although the concepts and basic principles of project management are universal, they have to be tailored and adapted to suit the particular circumstances of any project. This guide describes a full range of project management procedures, techniques and tools and the user is advised to select those elements that are appropriate to the project being considered. To ensure success, the management of a project needs to be entrusted to an individual with a knowledge of the particular requirements of a given project and with certain essential personal attributes. This guide defines the basic skills to look for when selecting a project manager and the project team. This standard provides guidance to the following people: — General managers: in organizations that operate projects: to raise awareness of the problems that are likely to exist within their own environment in the management of projects and to enable them to provide appropriate support for the project manager and team. — Project managers: responsible for achieving the defined project objectives: to improve their ability to cope with the many problems that occur (only some of which may be foreseen) and encourage better integration between the different disciplines taking part.

© BSI 01-2000

— Project support staff: co-ordinators, planners, designers, cost analysts, quality auditors, technicians etc; to help them to understand the problems that may occur in their project environment, and to provide possible solutions to those problems. — educators and trainers: those engaged in the teaching of network-based and other techniques for project management who need to understand the industrial context in which these techniques are used. This standard aims to draw attention to the management problems encountered in different project environments and to present possible solutions to these problems. Since there are no panaceas in project management, the solutions presented should be treated as guidance only; they may need to be adapted to suit the particular circumstances for which they are being considered. The only certainty in projects is that, without the full support of management for the project team and the appropriate choice and use of planning and control techniques for the project, it will usually fail to achieve its objectives. The guidance given and the principles of project management described are applicable to all sizes of project.

1.1 Scope This standard gives guidance on the planning and execution of projects and the application of project management techniques. It has a broad relevance to projects in many industries and the public sector, both at home and abroad. This standard aims primarily to provide guidance for relative newcomers to project management and to act as an aide mémoire for more experienced practitioners and those who interact with project management teams. The principles and procedures outlined are relevant to all sizes of organization, although they may not cover all aspects of every conceivable type and size of project. When consulting this standard it should be noted that, by definition, projects will have differing emphases and priorities.

1

Section 1

BS 6079-1:2000

1.2 References

1.3 Definitions For the purposes of this standard the definitions given in BS 3811, BS 4335, BS EN ISO 8402 and BS 7000-10, apply, together with the following. 1.3.1 configuration management the technical and administrative activities concerned with the creation, maintenance and controlled change of configuration data throughout the life of a product NOTE A fuller definition of configuration management and related terms is given in BS 7000-10.

1.3.2 deliverables the intermediate or end outputs of a project 1.3.3 earned value the value of the useful work done at any given point in a project 1.3.4 functional organization a line management structure where specific functions of a business are grouped into specialist departments that provide a dedicated service to the whole organization for example accounts department, production department, drawing office

a structure in which individuals, groups and managers continue to work within their specialist functional departments, but are assigned to work full-time or part-time under the direction of a project manager who is not their line manager such assignees are responsible to the project manager for their project work and to other functional managers for activities that are not related to the project 1.3.6 project a unique set of co-ordinated activities, with definite starting and finishing points, undertaken by an individual or organization to meet specific objectives within defined schedule, cost and performance parameters 1.3.7 project life cycle the sequential phases through which a project passes to reach its objectives 1.3.8 project management the planning, monitoring and control of all aspects of a project and the motivation of all those involved in it to achieve the project objectives on time and to the specified cost, quality and performance 1.3.9 project management activity (PMA) an operation, within a work package of a work breakdown structure, that is a specific action to be completed to aid the fulfilment of the project as a whole 1.3.10 project manager the individual or body with responsibility for managing a project to achieve specific objectives 1.3.11 programme manager the individual or body with responsibility for managing a group of projects 1.3.12 project organization the organizational structure that is created or evolves to serve the project and its participants 1.3.13 project programme a time and resource related schedule or diagram of project tasks that describes the project process

2

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

1.2.1 Normative references This standard incorporates, by dated or undated reference, provisions from other publications. These normative references are made at the appropriate places in the text and the cited publications are listed on the inside back cover. For dated references, only the edition cited applies; any subsequent amendments to, or revisions of the cited publication apply to this standard only when incorporated in the reference by amendment or revision. For undated references, the latest edition of the cited publication applies, together with any amendments. 1.2.2 Informative references This standard refers to other publications that provide information or guidance. Editions of these publications current at the time of issue of this standard are listed on the inside back cover, but reference should be made to the latest editions.

1.3.5 matrix organization

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 1

BS 6079-1:2000

1.3.14 project phase

1.3.20 statement of work (SOW)

that part of a project during which consistent activities are performed to attain a designated objective one of a series of distinct steps in carrying out a project that together constitute the project life cycle 1.3.15 project plan

a document stating the requirements for a given project task 1.3.21 task

a plan for carrying out a project, to meet specific objectives, that is prepared by or for the project manager 1.3.16 risk a combination of the probability, or frequency, of occurrence of a defined threat or opportunity and the magnitude of the consequences of the occurrence 1.3.17 risk management the process whereby decisions are made to accept a known or assessed risk and/or the implementation of actions to reduce the consequences or probability of occurrence 1.3.18 sponsor 1) the individual or body for whom the project is undertaken, the primary risk taker 2) the individual representing the sponsoring body and to whom the project manager reports 1.3.19 stakeholder

the smallest indivisible part of an activity when it is broken down to a level best understood and performed by a specific person 1.3.22 variations management the monitoring, recording and assessing of variations to the scope or timing of a project, irrespective of who generated the change the objective is to make all parties fully aware of the cost, time and quality implications of implementing such changes NOTE Variations management is a term used in the construction industry. It is closely related to the more widely used terms change management and configuration management.

1.3.23 work breakdown structure (WBS) the level at which a piece of work within a project is broken down for programming, cost planning, monitoring and control purposes, to be performed by a specific person, group or organization 1.3.24 work package a group of related tasks that are defined at the same level within a work breakdown structure

a person or group of people who have a vested interest in the success of an organization and the environment in which the organization operates

© BSI 01-2000

3

BS 6079-1:2000

Section 2. The corporate aspects of project management 2.2 Nature of projects

It is difficult to think of any corporate activity, private or public, for profit or not for profit, quoted or non-quoted, which is not facing change. The motive for change may stem from a perceived shortage of funds, changing patterns of demand, social pressures, technological advances, competitive and alternative suppliers of goods or services. There is little reason to suppose that the pressures will diminish, indeed some people would argue that the rate of change is likely to increase. Managements have to respond to those changes to survive, those who do it successfully will probably prosper, those who are slow or whose response is inadequate will decline and in due course fail. As managements take the series of decisions to move from where they are to where they want to be, or need to be, they will commit resources to the achievement of results they have not previously enjoyed. Each task will be unique in some aspect; opening a bank branch may not be novel to a major clearing bank but some single aspect, or combination of events involved in opening a particular branch will make it a one-off occurrence. Thus the pace of change is causing corporate managements to undertake more tasks with unfamiliar characteristics. The decisions, perhaps to run with a series of projects of differing significance and durations, will test management skills. As the projects become more numerous, they are likely to run across departmental boundaries and will tend to become more expensive. Such a bundle of activities creates significant managerial problems and the purpose of this standard is to provide a guide to project management, based on best practices. Research suggests that the overall track record of British organizations in managing projects, including take-overs, leaves much to be desired. The delivery of results on time, within predetermined cost and of the requisite standard within set safety and quality criteria is less frequent than it should be. This standard aims to help managements deal with these situations more efficiently and effectively. The principles expounded in the standard are as relevant to small companies and small projects as they are to major enterprises with multi-million pound projects spanning several years. Sections 3, 4 and 5 are aimed at operating management and this section is directed at senior managers.

Projects are the engines of change. They may be revenue generating projects with all the consequences chargeable to the profit and loss account or, as more commonly understood, capital projects with the initial impact mainly on the balance sheet. The book-keeping conventions have little bearing on the management process. A project is a means to an end. An enterprise may need, for example, to enhance income, and/or reduce costs, and/or improve productivity with reasonably clear ideas of the extent to which change has to be brought about. An understanding of the objective by the appropriate personnel should bring alternative ways of achieving or maybe even exceeding the objective. Following a review of the alternatives and their respective consequences senior management will decide on their preferred course of action and issue instructions to a responsible person for work to proceed. In due course, perhaps on time, or early, or late, the project will be declared complete and will usually become the responsibility of someone else. The ensuing results may or may not justify the expenditure that has taken place, which may or may not have been within agreed limits. In some cases the time delay in completion leads to such excessive costs that the project in its operational mode will never deliver an adequate return. Understanding the nature of projects may enhance the ability of managements to handle them. There are several attributes of projects, as follows: a) they are non-repetitive and tend to have significant unique features likely to be novel to the management; b) they carry risk and uncertainty; c) they should be approved in return for undertakings to deliver specified (minimum) quantified results within pre-determined quality and safety/health parameters; d) the authorization should leave no doubt that the results will need to be delivered with firm start and finishing dates, within clearly specified cost and resource constraints; e) they are usually in the hands of a temporary team and may be subject to change as the work progresses; f) in a long duration project, events inside and outside the enterprise may affect the outcome.

4

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

2.1 General

Section 2

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

2.3 The work to be done Effective project management may be broken down into five stages: — planning; — organising; — motivating; — implementing; — control by review and accountability. Senior management is responsible for establishing the objectives and constraints within which the project has to be delivered. They should set acceptable criteria and ensure that adequate planning has been done. This should establish the proposed expenditure and test the realism and acceptability of the expected benefits being put forward as justification. One of the major causes of sub-standard project management arises from failures at the planning stage causing a series of subsequent alterations/clarifications that pushes up expenditure and creates delays. Increasingly, projects cut across departmental boundaries and management has to ensure that the appropriate organisation is in place to run a project. This will often be a temporary arrangement, but it will generally call for a project manager supported by a team of staff with the appropriate skills for the needs of the project. The authority delegated to the project manager needs to be quite clear and because it will cover the team assembled from departments, that authority has to be notified throughout the enterprise. Without this authority the project manager may be thwarted by departmental intransigence. Working in a project team has been found to be an excellent capacity enhancing experience for departmental staff and may be seen as a valuable development method in career planning. On major projects it is not always possible for departmental staff to make the required contribution and maintain departmental responsibilities, as a result they may be seconded to a project on a full time basis.

© BSI 01-2000

BS 6079-1:2000

Management needs to consider the motivation of staff when they are taken out of their departmental roles. Tangible rewards related to the achievement of the project within the set constraints may involve money, but in an appropriate culture other rewards might include the kudos of being selected to work on a project, of promotion to wider responsibilities following success in a project team, etc. Where staff are deployed on a full time basis there should always be an understanding that as a minimum a return to previous duties is safe. Having agreed to run with a project and after an appropriate structure and pattern of motivation has been set up, management should issue instructions to proceed and the work of implementation can begin. People will be deployed, materials bought and services secured. Senior staff should, without becoming directly involved in the detail, ensure that proper operational procedures and controls are in place and being used. They should normally insist on reports at predetermined intervals, usually set as a condition of authorization, showing the current state of affairs and the latest expectation of completion in terms of at least cost and time. These reports will typically form the basis of reviews and the exercise of accountability with the project manager. These reviews will close one cycle and lead into the next cycle of replanning, to take account of changed circumstances, deal with problems and exploit opportunities. Figure 1 shows a typical arrangement of project phases, stages and milestones and Figure 3 illustrates the cycle of management activities that recurs throughout a project.

5

BS 6079-1:2000

Section 2

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Figure 1 — Arrangement of project phases, stages and milestones

6

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 2

BS 6079-1:2000

2.4 The project life cycle

2.4.3 Evaluating the project’s feasibility

2.4.1 General

In the first instance the feasibility study will be approximate as the prime purpose is to identify those ideas that look promising and separate them for closer attention than those which fail the tests. The schemes that offer promise should then be subjected to more demanding evaluation which will take up rather more of the time of the staff concerned. In many organizations those projects which survive a more rigorous examination will be brought to the notice of a senior manager who can, if so persuaded, champion the project and secure agreement for further progress. This will usually take the form of extended planning and a full evaluation. Organizations often find this is an appropriate time to select someone to run the initial project work, frequently someone who will become the project manager if the scheme proceeds. It would be that person’s responsibility to assemble a shadow team to provide the required inputs from marketing, sales, production, personnel, finance etc., that would be assembled and collated in financial terms and critically examined. The champion would seek authority to proceed only when satisfied with the plans that had been drawn up. These plans might be expected to incorporate Critical Path Analysis, an evaluation of Net Present Value using appropriate discount factors and a review of the sensitivity of the project to attendant risks. Larger organizations tend to have tiered authorities, each capable of authorizing projects up to a set value and recommending higher amounts to senior management. In agreeing authorization, management will usually set conditions and constraints not the least of which will be the timetable for reporting progress against key events or milestones. Funds will be earmarked and in large projects they may be released on a cumulative basis and triggered by the receipt of satisfactory progress reports from the project manager.

All projects tend to go through a similar life cycle. In large schemes the elements may be very clearly separated, in smaller works they may be linked and/or blurred. Different industries have their own terms but in general it is useful and possible to identify the following work that has to be carried out: 1) concept, basic ideas; 2) feasibility; tests for technical, commercial and financial viability; 3) evaluation and application for funds, stating risks; 4) authorization and any conditions; 5) implementation including design, procurement, fabrication, installation etc.; 6) control/accountability, periodic reviews and updates; 7) completion and hand-over to client; 8) operation, and inclusion in normal revenue planning/control procedures; 9) close down and cease operations; 10) termination including disposal of residual assets (liabilities). Some organizations are very successful in generating ideas for improvements, some are adept at converting those ideas into reality. The most successful do both, often by tapping into the knowledge and experience of their own workforce. Basic concepts will arise from solving current problems and also from identifying opportunities. Management needs to give encouragement both by tangible and psychological rewards. 2.4.2 Project concept Each concept should undergo a screening process to test the feasibility in at least three different ways. This should involve establishing first if the project is technically feasible, secondly if it would be commercially acceptable and finally if the costs and benefits show a balance that makes the risks of proceeding worthwhile.

© BSI 01-2000

2.4.4 Project implementation and handover As implementation proceeds management will be aware that the only certainty in projects is the consequence of the costs and liabilities being incurred; while the promised deliverables will come later in the implementation phase. Hence there is a need for competent project progress reports at sensible intervals with review meetings for the exercise of accountability.

7

Section 2

BS 6079-1:2000

2.4.5 Terminating the project In most cases, closing down the project may be simple and straightforward, but in a minority of instances final termination may be a major event, and probably become a project in its own right. Items such as North Sea oil platforms, nuclear installations in submarines and power stations have major termination consequences, which is why the financial appraisals need to be whole life assessments to allow for what may be massive termination costs.

8

2.5 The benefits of project management Good project management has proved to be an effective and efficient way of managing change in many types of organisation. It allows senior management to accomplish the following: a) direct scarce resources to what are judged to be the most desirable objectives; b) focus appropriate management skills on to specific tasks; c) secure commitments to deliver results from those wishing to proceed with the project; d) direct major elements of the business without being submerged in detail; e) keep control of a wide variety of projects running concurrently; f) ensure that issues such as quality and safety are engineered into projects at the design stage; g) extend the experience of staff working on projects and help equip them for wider responsibilities. Later sections of this standard pick up and expand the points made here, in a detailed manner that is more attuned to assisting the operators of project management activities.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

When the implementation is complete, management will usually require some degree of formality in handing over the project from the team that handled its completion to those responsible for its future operation. It is not uncommon for this next stage to last for a sustained number of years. Concurrent with the handover, a succinct and honest report on the history of the project to that stage can be helpful in identifying strengths and weaknesses to aid future project planning and control procedures. At handover the project team may be disbanded or switched to other projects. The subject of their efforts will be absorbed into the normal budgeting, revenue planning and control systems until the operation ceases, for example due to technical obsolescence, market changes, simple plant life expiry, etc.

BS 6079-1:2000

Section 3. Project and company organizational structures

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

3.1 General Any group that provides a service or produces a product should form itself into an organization with a structure. This structure, and the size of the organization, will inevitably affect the way the organization can respond to change and the introduction of projects. The structural form of the organization will normally be hierarchical, apart from organizations set up specifically to provide project services, with an emphasis on the functional operations. With this form, a small organization will always be able to respond more quickly to the need for change than a large one, since the owner or chief executive will have delegated less authority for specialist decision making to the functions. As the organization grows, this traditional form is characterized by comparatively routine and predictable working procedures, a relatively low rate of change, specialized functional staff and, because of this, a significant reduction in the need for cross-functional communication and co-operation. This has caused major problems in the current industrial environment as quick response to market demand for new or updated products or services or changes in the level of existing supply or product mix are required. The increasing rate of change, coupled with competitive demand to shorten development cycles, has led to the introduction and growth of project management as an organizational form within the traditional structure and the development of the matrix structure. Although project management structures are often incorporated within the traditional structure of hierarchical functional organizations, they have many of the same basic characteristics and share the same resources as the other functions. Such structures require a much higher degree of flexibility in working procedures because of the unique nature of projects. This flexibility is affected by the size and complexity of the project, its timescale, its geographical location and the contract terms and finance. Figure 2 illustrates the primary forms of organization and how the authority relationships change between them. BS 3375-1 gives further guidance on organization study.

© BSI 01-2000

3.2 The hierarchical functional organization In this type of organization, which is the traditional form for most manufacturing and process companies, there is usually no separate project function or organization. This form of organizational structure has existed for a long time and has significant advantages, with its simple reporting and centralized control, so long as the rate of change is slow and any projects are small enough to be contained within and serviced by one functional group. If the project enlarges and crosses functional boundaries, or the sheer number of projects overstretches the functional resources, then the disadvantages of this structural form become apparent. An ever-increasing burden may be imposed on the chief executive, in particular due to the lack of co-operation and co-ordination that occurs between the functional groups. In these circumstances the project manager may report directly to the chief executive and require the support of some specialist staff in undertaking the project. This of itself can cause problems for the executive as the functional heads will be reluctant to release suitable staff and the project manager will be reluctant to make do with inexperienced people. If or when the number or size of projects increases a permanent project function should be set up and even then there will still be the need to draw specialist assistance from the functional groups for various aspects of the project. For instance, in a hardware project, engineering design work will still be carried out in the appropriate functional groups and the co-ordination and timing of that work will be the responsibility of the project team in conjunction with the functional heads to whom the design staff report for their professional competence.

9

Section 3

BS 6079-1:2000

3.3 The matrix organization The problem of co-ordinating project activities does not become serious until functional boundaries are crossed or functional resources are overstretched. Until this happens it is not worth making changes to the organizational structure just to accommodate single projects with what is known to be a limited life. Once it becomes clear that projects will continue to be carried out within the organization and that there may be several running simultaneously, then a different situation arises and a change of organizational structure becomes essential. It also becomes necessary to set up a project management function with its own functional group of project specialists. Furthermore, if required by many of the projects, dedicated functional specialists will be appointed as part of the group either by withdrawing them from the existing functional groups or by external recruitment. If they are obtained internally, which if at all possible they should be, then it is essential that they be organizationally disengaged from their previous positions. Ideally the project group, like any other functional group, should be physically located in its own area, the functional specialists will then still be able to refer to the functional supervisors, but only for functional technical problems.

10

In multi-project situations this structure is essential and, while it may solve many problems, some will remain; also some new problems are created, in particular that of dual reporting. However firmly a functional specilist is disengaged from a previous supervisor, some loyalty will remain and the supervisor can influence the functional specialist’s career. This can often lead to a dual reporting situation: one official and one unofficial. If, for example, a functional specialist has an unresolved technical disagreement with the project manager, any appeal will need to be made through to the senior manager who has authority over both the project and the functional specialist’s supervisor. There should only be one reporting system for the project, that operated by the project team through the project manager. The changes in managerial behaviour required by the move to a matrix structure are far-reaching, stretching to the board itself. To ensure that different project teams and functional groups react in the same way to similar circumstances and that all have the same view or priorities, a strong corporate culture should be developed. This is neither an easy nor rapid goal to achieve, but without it there may be inconsistent behaviour between project and functional groups with possible serious consequences. The project manager’s challenge is to motivate the staff, both those seconded from the functions and others within the matrix, to achieve the required performance in the primary areas of quality, cost and timing of outputs. © BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Figure 2 — Authority relationships in organization structures

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 3

Equally, it is essential that these factors are also monitored by the functional manager. The management structure should allow differing views on objectives to be identified and resolved and should encourage peer group discussion on key issues. In a matrix structure several managers may have authority over project work; the functional manager for “how” and “by whom”, and the project manager for “what” and at “what cost”. The responsibility remains with the project manager and much tact and patience may be needed from senior management and project sponsors to make the matrix structure work properly. In particular, clear policies need to be established for the career paths of those seconded to the project teams, both on long and short term appointments.

3.4 The project organization The pure project form of organization is not common, however it can be employed with advantage where projects are the normal business of the organization. In this type of organization the project team usually remains as a multidisciplinary unit and is moved from one project to the next as each is completed. This has the disadvantage that there may be a failure to develop functional specialists and general managers within the organization which may result in some projects being starved of adequate specialists. This also means that the project manager and the project team may need to have a high degree of autonomy from the host organization and that the project manager has to be given almost total authority for the project within the constraints of the host organization’s general policies and strategies. This form of organization has the distinct advantage of being able to precisely define and control the project budget, with different policies for different projects. It also reveals the cost of management which is normally contained within the organization’s overheads.

3.5 Criteria for reorganization 3.5.1 General Organizational changes involve transition from the current state towards a future state. Experience has shown that the time scale for transition from, for example, a totally functional organization to a matrix organization can take from three to five years in a large organization.

© BSI 01-2000

BS 6079-1:2000

The effective management of change involves developing an understanding of the current state, developing an image of the desired future state and moving the organization through the transition period. As much care needs to be devoted to the transition state as to the future state, both are critical. The two basic issues to be addressed in reorganization are what the change should be and how the change should be implemented. 3.5.2 Politics of organizational change Political behaviour is a natural and expected feature of organizations. In the transition state these forces become even more intense as the old regime is dismantled and the new regime takes its place. Any significant change can upset or modify the balance of power among various formal and informal interest groups. The uncertainty caused by changes can lead to ambiguity and increased political activity as individuals try to protect their own interests. 3.5.3 Psychology of organizational change Change in organizations involves the movement from something known towards something that is unknown and this is usually unsettling for the individuals concerned. There is a need to recognize a psychological attachment to the former organization and time should be provided to disengage from the current state. Change can sometimes create a sense of loss and individuals need to work through their detachment from the current state. Those involved will be concerned that they will be needed in the new organization, that their skills are valued and that they will be able to cope with the new situation. This stress and anxiety can create performance problems and may lead individuals to resist changes that they might otherwise support. Wherever possible, staff should be given reassurance regarding their roles in the planned reorganization. A significant change in organization may disrupt the normal course of events within the organization. Such changes may also undermine existing systems of management control and make procedures seem irrelevant. Control is easy to lose during the transition from one state to another. As goals, structures and people shift, it becomes difficult to monitor performance and make correct assumptions that would otherwise be made during a stable period.

11

Section 3

BS 6079-1:2000

3.5.5 Managing the transition

The transition phase is characterized by great uncertainty and control problems as the current state is disassembled prior to full operation of the future state. Managers should co-ordinate the transition with the same degree of care, the same resources and the same skills as they manage any other project. The following summarizes the actions to be taken during the transition state: a) develop and communicate a clear image of the future state; b) construct a statement that identifies the impact of the change on different parts of the organization; c) maintain a stable vision and avoid unnecessary changes and conflicting views; d) communicate, including information on future decision making and operating procedures. These actions can be helped by the appointment of a transition (project) manager, allocation of specific resources for the transition, the use of a transition structured management system and a transition plan. The progress of the transition should be monitored and evaluated, with feedback of results via an established communication channel to the stakeholders.

Most formal organizational arrangements are designed either to manage the current or future states and not the transition state. Problems encountered in the transition state can relate to questions of power, anxiety and control. Transition implies changes in power with the inherent need to shape and manage political dynamics. To ensure success it is critical to: a) motivate individuals through communications; b) obtain the support of key groups; c) demonstrate leadership support of the change; d) communicate using symbols, language and graphics and build in stability, reduce anxiety; e) allow time to prepare for change, send consistent messages, build support and encourage participation. Managers and team leaders should serve as models, as through their behaviour they provide a vision of the future state and a source of identification for various groups within the organization. They should articulate the vision of the future state and provide support through political influence and needed resources. This can be achieved by creating dissatisfaction with the current state, so that it is recognized that the current state is not perfect and requires change to avoid unwanted economic and business consequences. It should also be achieved by motivating staff and recognizing that their participation, although time-consuming, yields benefits that can lead to improved decision making. There is a need to communicate constantly in this phase and to encourage feedback.

12

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

3.5.4 Planning the transition

BS 6079-1:2000

Section 4. The project management process

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

4.1 General The project management process described in this standard is different from the traditional line management process. Project management is a universal process that is as applicable to the design and construction of a hydro-electric power station as it is to the introduction of an information system for a bank or the design of a public transport system. Characteristically, the project management process is designed to minimize the risk of failure in terms of time, cost and product fitness for purpose. This standard describes a generic project management process that makes no assumptions about the content, size, phase or organization of the project. The guidance given can therefore be applied to most projects, regardless of industry sector, phase, size, complexity or content. Project plans are one of the critical outputs from the project management process and they are described in detail in 4.5.

4.2 The project management process: introduction Projects do not succeed just by assiduous adherence to a mechanical process. The successful project should be managed with enthusiasm, vision, single-mindedness and integrity. The project manager should be able to generate these qualities in the whole project team. It should be noted, however, that no amount of misdirected enthusiasm will avoid failure. The project management process described here mitigates this risk. Project tasks exist at all levels within the project. A work breakdown structure helps to describe project tasks in terms that are easily understood by all those involved. At the top of the work breakdown structure a single task can represent the complete project while tasks at the base of the work breakdown structure may represent detailed work undertaken by an individual (This concept is described later in this section). The project management process and project plan described here can be applied at all levels of the work breakdown structure. Thus, although the focus of this section is the process and plan used by the project team the guidelines for both process and plan can be used at any level within the project.

© BSI 01-2000

The project management process can be divided into two parts, project planning and project control. Project planning is the development of a workable project plan that describes project tasks in terms of “who does what”, “when”, “at what cost” and “to what specification”. This integrated plan of the project should be at a level of detail that the project manager considers necessary and sufficient to enable effective and efficient project control. The second part of the process is to use the plan to control and co-ordinate the progress of the project. There are further subordinate processes contained within both planning and control and, depending on the circumstances of the project in question, each process will make a greater or lesser contribution. The project management process and its subordinate processes are shown in Figure 3. The process of creating and using project plans is usually the responsibility of the project manager, assisted and advised as necessary by the sponsor and project team. Although the need to plan is usually most pressing at the beginning of a project, the plan should be regularly reviewed and updated as necessary during the project life cycle. It should be noted that the more planning done before contractual obligations are established, the less risk there is of failing to meet those obligations.

4.3 The project management process: planning 4.3.1 Obtain authorization to proceed from the project sponsor It is essential to apply for and obtain authorization from the sponsor or a board of management to implement the project. Authorization may be given by the project sponsor for the whole project, project phase or in stages for work up to specified milestones, at which point further authorization will usually be dependent upon satisfactory progress. Authorization starts the project management process.

13

Section 4

BS 6079-1:2000

4.3.2.2 Incentive mechanisms

Projects may evolve within organizations that already have the structure necessary to support project work. Such organizations may be oriented exclusively towards projects or, more commonly, may adopt a matrix structure with the enterprise giving an equal and balanced emphasis to both the project team and the specialist functional departments that undertake work for different projects. A well designed and managed matrix structure should have the advantage of generating creative tensions between the project and functional disciplines. Functions usually demand clear and unambiguous statements of requirement from the project team and project teams usually demand a positive commitment from the functions to timescales, costs and performance. Sub-contractors may be treated in the same way as an in-house function except that relationships between the sub-contractor and the project manager will usually be subject to formal contract. Alternatively, the project may have emerged as a separate entity without the support of an existing organizational structure. This is the case, for example, when a consultancy undertakes a project for a customer and where the work is done by third party agencies. The project manager needs to establish mutual accountability between the sponsor, suppliers, task owners and the project team and, if necessary, written terms of reference. The following organizational factors should be defined.

Payment for goods and services is a critical part of project management. Payment terms may often be defined by the contract and the project manager needs to be aware of the leverage that can be exerted by terms that focus suppliers on delivery to time, cost and performance parameters. Because projects are usually bound by strict timescales, the project team should be allowed adequate time to assess the quality of purchases before payment is authorized. It is essential, however, that suppliers are paid promptly and strictly within the timescales stated in the purchase order. Incentive, or premium payments, designed to accelerate critical activities that have a direct effect on overall project timescales, can offer both supplier and project manager mutual benefits. Penalties for late delivery, cost overrun or failure to meet specification should also be used where appropriate to focus supplier efforts on project goals. The project manager may also seek the right to retain payment until a period has elapsed during which time the goods and services being purchased can be assessed for fitness for purpose. The purchaser and supplier need to have a clear understanding of incentive mechanisms, which should be reflected in the contract. More guidance on procurement functions is given in 4.6.4.

4.3.2.1 Limits of authority The project manager needs to clearly understand the limits of authority for any action that is initiated, for example, financial limits may be imposed by the sponsor. Some organizations may prescribe lists of approved suppliers that limit the freedom of choice of subcontractor. The project manager may also be constrained in the action that may be taken against defaulting suppliers. In order to operate effectively, the project manager needs to understand clearly how the freedom to act is constrained. Such limits should be stated in writing and form part of the project plan.

14

4.3.2.3 Communication framework Success or failure of a project tends to depend on how well various members of the project team communicate with each other. It is essential for the project manager to implement an effective communication network designed to enable all relevant parties to report progress, express concerns and discuss how to achieve the project objectives. The project manager needs to identify a structure and schedule of meetings, each with their own terms of reference, list of attendees and agendas. All project management team members should recognize that effective communication is a two-way process and that suppliers need to be encouraged to raise concerns at the earliest opportunity, rather than waiting until a problem has matured into an intractable hazard. The project manager should promote an open forum for the discussion of issues. Suppliers and task owners should not feel so intimidated that they are prevented from discussing bad news or raising doubts about their ability to achieve specific objectives. More guidance on project organization is given in section 3.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

4.3.2 Establish the project organization

15

BS 6079-1:2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 4

© BSI 01-2000

Figure 3 — Project management process flow

Section 4

BS 6079-1:2000

4.3.3 Development of a Project Work Breakdown Structure (WBS)

4.3.3.1 Task decomposition The project deliverables need to be split into manageable units of work to generate an hierarchical structure of tasks where any one task is a child of a parent task that is higher in the structure and also the parent of one or more child tasks lower in the structure. An existing WBS can be helpful in identifying tasks for new projects, where similar work has been done in the past.

Figure 4 — Model work breakdown structure

16

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Once a project organization has been established, the project planning process should continue with the project manager providing suppliers with a summary statement of requirements so that each supplier can identify the tasks that need to be done. Figure 4 shows how a project can be broken down into individual tasks; although the example given is a specific product-based WBS (a contract to supply gas turbines), the principle is applicable equally to any type of project. The product-based WBS is the commonest and most useful form; however, there are several other ways in which a project can be broken down, such as by activities or by cost elements.

The techniques described in 4.3.3.1 to 4.3.3.6 should be used when developing a work breakdown structure.

Section 4

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

4.3.3.2 Task identification Task identification should begin by broadly defining tasks outlined in the statement of requirements and then expanding to a level of detail necessary and sufficient for inclusion in the project plan. At each iteration the estimated workload and costs need to be refined as necessary. It is essential that estimates, if not originated by the task owner, are sanctioned by the task owner. The project manager should not accept an estimate for a task from a third party who is not responsible for the task. The project manager should gauge the acceptability of each estimate by comparison with past performance and this may only be possible if previous work has been structured in a similar way. 4.3.3.3 Task levels The single, top level task of the project WBS will be the project as a whole. Lower levels within the project WBS should describe tasks that, when added together, comprise tasks appearing at higher levels. This hierarchy of tasks should enable task-related information to be summarized and audited to various levels of detail and should also permit exception thresholds and summary reporting requirements to be applied at whatever level the project manager decides is appropriate. An additional benefit of using a project WBS is that it provides a structured definition of tasks that can be reused for future projects. It can also be used to record trends in supplier and task owner estimates and actual performance for similar tasks in different projects. 4.3.3.4 Level of detail The project manager and project team need to be skilled in assessing the “depth” of the project WBS required. For example, if a project WBS is too shallow there will be a risk that tasks are not defined to an adequate level of detail. Conversely, if the project WBS delves too deeply into the task structure there is a risk that the project will be over-managed and the plan will become over-sensitive to change. 4.3.3.5 Validation of the task structure A useful rule that the project manager needs to apply to any task that is put forward for inclusion in the project WBS is to test whether it contributes to the deliverables of the parent task. If it does then the task is valid and should be included; if not, then the project manager should find out why the task is needed.

© BSI 01-2000

BS 6079-1:2000

The structured decomposition of tasks in the WBS should offer the project manager many opportunities to assess parent-children task relationships using principles of conservation. For example, is some element of the product defined in the parent task lost in the definition of child tasks? If so, then a child task corresponding to the missing element needs to be added to the WBS. New task material appearing in a child task also needs to be explained in terms of its parent task. 4.3.3.6 Relating tasks to the project organization There is considerable benefit in relating individual lowest level child tasks to specific organization elements, such that the child task is at the intersection of a product-based project WBS and an organizational breakdown structure. This relationship enables a responsibility assignment matrix to be developed that has lowest level child tasks along one axis and organizational breakdown structure elements along the other. The name of a task owner in a cell within the responsibility assignment matrix should show task accountability. The work breakdown structure can be product-based, cost-centre-based, task-based and/or function-based, but product-based is preferred. 4.3.4 Analyse the project tasks 4.3.4.1 Level of task decomposition A workable compromise between the extremes of insufficient or excessive levels to work breakdown structure needs to be achieved. The project manager should determine whether or not a task has been defined at an adequate level and ultimately this decision will be governed by experience, intuition and circumstances. 4.3.4.2 Single accountability Each of the lowest level tasks should have a single owner who is accountable to the project manager for the successful achievement of the task. If a task is shared by two owners then it should be split until unique accountability for the major part of the task can be clearly identified. One person may be the owner of several tasks. 4.3.4.3 Performance measurement capability Each task should contain within its definition the means to measure the performance of the task owner. Performance of tasks with extended durations and few discrete deliverables can be difficult to assess. Ideally tasks should be defined at a level where objective measures of performance can be applied. Thus short tasks, or long tasks with regular deliverables, should provide an adequate basis for measuring performance.

17

BS 6079-1:2000

4.3.4.4 Cost element The total costs of each task should be expressed in terms of their separate elements, for example in labour or purchases. It is often useful to decompose a task according to its cost elements. 4.3.4.5 Criticality

4.3.4.6 Earned value type The method of calculating earned value or performance should be the same for all work contained in the task. The earned value method is described in 4.6.6. If performance for part of the task is calculated on the basis of the discrete deliverables achieved and another part is calculated on the basis of percentage of planned costs then the task should be split to separate the two types of work. This should clarify the means of performance measurement. 4.3.4.7 Supplier performance reliability The level of detail to which the plan is defined will be influenced by the reliability of the supplier. Tasks assigned to proven suppliers may be defined in less detail than tasks assigned to unproven new suppliers. The project manager should ensure that the plan is set at a level that gives confidence and reassurance that the supplier will deliver in accordance with time, cost and performance parameters. Reliable suppliers and task owners should require less supervision, thus allowing the project manager to concentrate effort on eliminating risks elsewhere. 4.3.4.8 Task risk The ultimate criterion that the project manager needs to use to assess whether or not the project WBS is defined at an acceptable level of detail is the degree of risk associated with any task. If there is significant risk identified with the task the project manager may wish to decompose the task still further in order to isolate the risk and prepare mitigation plans.

18

4.3.5 Assign a single accountable task owner to project tasks The identification of a task owner for each child task is an important step in developing a project plan. If a single task owner cannot be identified then the project manager may not be able to manage the task. The task owner may be a member of the project team, an individual appointed by a supplier or subcontractor for liaising with the prime contractor or a manager who has resources that could be used to achieve the task objectives. The project manager should be aware that blind application of the “single accountable task owner” rule could lead to an unmanageable number of tasks, each allocated to the individual doing the task. Sensible application of this guideline recognises that reliable accountability normally exists some way above the individual task doer. The process of identifying the task owner is subtle but vital and depends on how the word “accountable” is interpreted. In this case the accountable task owner should have a duty to the project manager for the successful achievement of the task. This also implies that the project manager has a veto over the appointment of task owners and may, in certain circumstances, exercise the right to disqualify a task owner whose performance is unacceptable. In a matrix organization where project groups procure goods and services from various functions, a distinction between task owner and functional manager needs to be made. Often a relatively junior worker may be a task owner and have an accountability to the project manager for achieving the objectives of the project work, while at the same time reporting to a functional manager for the professional standards of the work. It is vital for the project manager to identify the task owner at the level within the functional organization where the task owner is best able to be accountable for project work. Seniority does not always make for an effective project task owner. Although ideally the task owner should be in direct control of all the resources needed to execute the task, this is rarely possible. A task owner who needs to subcontract to fulfil the task requirement may be acceptable to the project manager provided the subcontracted element of the task is a minor part of the whole task. In this case the project manager needs the ability to audit the trail of accountability through the task doer to the subcontractor.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

It should be possible to describe the task as either critical or non-critical. This means that task interdependence needs to be understood accurately. If a critical activity exists within a task then that activity may need to be broken out as a separate task.

Section 4

Section 4

4.3.6 Develop a statement of work (SOW) for project tasks

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

4.3.6.1 General Each task should be defined by its SOW, which for parent tasks need not be more than a summary of the work defined in the child tasks. The SOW may contain a qualitative assessment of risk associated with the task and should also define how and when to issue progress and exception reports and how performance is to be measured. The SOW may not emerge as a result of the task owner’s initial response to the project manager’s statement of requirement. Useful SOWs, that remain relatively stable throughout the project life cycle, usually result from several iterations between task owner and project manager. This iterative process should improve the quality of both the project manager’s understanding of the task owner’s needs and the task owner’s understanding of the project manager’s requirements. Bypassing this step in the planning process poses a high risk of cost overruns, late deliveries and contract changes. The primary elements of a SOW are as follows and are further described in 4.3.6.2 to 4.3.6.12: a) a task reference code; b) a summary description of the requirement; c) the name of the person accountable for completion of the task; d) a list of key deliverables; e) timescales for the deliverables; f) a schedule of task dependencies and subsidiary tasks; g) a schedule of costs by cost element; h) an assessment of risks associated with the task; i) performance measurement and task completion criteria; j) a description of the work content of the task; k) reporting requirements. 4.3.6.2 Task reference code Each task should be assigned a unique reference code; this is an essential and efficient way of summarising project information and can also be used within monitoring, reporting, accounting and configuration management systems. For large projects, WBS dictionaries of task definitions may be compiled where the task code provides a unique reference key. Task reference codes can provide a logical shorthand description of tasks that should instantly convey the relative position of the task in the overall project WBS. More information on configuration management is given in 4.6.2.

© BSI 01-2000

BS 6079-1:2000

The code for any task should correspond to the code assigned to that task in the project WBS defined in the WBS section of the project plan. A parent-child relationship between tasks is implied in the WBS code, for example task 1.1.1 is a subtask of task 1.1. 4.3.6.3 Summary description of task The SOW should contain a high level description of the work content for the task. The definitive detailed specification of the task requirements, for example, a colour scheme for the internal decoration of a building, should normally be given in reference documents that may be quoted in the contract. Such specifications need not be detailed in the project plan. A summary description should be sufficient to orient the reader and inform the project manager and task owner of the substance of the task and point to any supporting reference documents that give the full information. 4.3.6.4 Named accountable task owner The SOW should identify the task owner, who is ultimately accountable to the project manager for the successful achievement of the task, by name. Successful achievement needs to be measured in terms of cost, performance and timely delivery of all deliverables and the satisfactory performance of all reporting requirements. The task owner should estimate the time and cost of the task and register agreement by signing the “commitment acceptance” section of the project plan. 4.3.6.5 Key deliveries and milestones The SOW should contain a list of the key deliverables and the dates by which the task owner has committed to deliver them to the project manager through the life of the task. These deliverables and the task cost schedule should be used for performance measurement. Deliverables need to be defined in order to provide the sponsor and project manager with a means of measuring performance, and should, for example, include the start and finish of each subtask within the task and any relevant milestones. The SOW should also record the acceptance criteria to be applied to each deliverable. 4.3.6.6 Timescales for deliverables The start and finish dates and duration of the task should be recorded in the project plan. It may be beneficial to record earliest and latest start and finish dates for the task and to note whether or not the task is on or near to the critical path (see 4.5.6). This information needs to be consistent with dates in the schedule section of the project plan. Where the risk assessment indicates that there is a significant risk then a three point duration (best-worst-most likely assessment) should be included. 19

BS 6079-1:2000

4.3.6.7 Task dependencies

4.3.6.8 Schedule of costs by cost elements The planning activity should establish a schedule of costs for the task that differentiates between different cost elements. The effect of changing cost rates needs to be isolated and understood by the project manager. The SOW may contain a phased profile of expected costs for each task, with contributions from different cost elements identified separately. The integrity of this information is fundamental to the success of the project and time spent at the planning stage in identifying the key factors that influence costs is essential. An expenditure profile, showing the phased budget for the task over the relevant timescale, should be stated. In order to support earned value calculations, this profile should include increments of planned expenditure corresponding to each deliverable defined in the SOW. The expenditure profile should also show the current limits of authorized expenditure in terms of value and time, together with a risk assessment where necessary. 4.3.6.9 Assessment of risks The SOW should record the results of qualitative and quantitative risk assessment for the task where appropriate. Qualitative risk assessment should be based on identifying certain events with which risk is associated and then describing the risk. Quantification of each risk should be shown where appropriate and may be stated simply as the best, worst and most likely distribution in terms of cost, timescale and specification. The impact on delivery to specification is a technical statement of risk and needs to be translated into a cost and timescale effect before the project manager can process the information for project management purposes. The impact of a risk may be graded as follows: a) likelihood of occurrence (high/medium/low); b) impact on timescales (catastrophic/critical/marginal/negligible); 20

c) impact on costs (catastrophic/critical/marginal/negligible); d) impact on delivery (catastrophic/critical/marginal/negligible). More guidance on risk management is given in 4.6.3. 4.3.6.10 Performance measurement and task completion criteria The most important factor when selecting how to measure performance is to use the best objective measure possible. A list of a combination of cost, schedule and deliverables should provide a robust basis for measuring performance. Earned value or budgeted cost of work performed can be calculated using this combination (see 4.6.6). If the task deliverables list provides for an even distribution of deliverables throughout the project and the task expenditure profile has been compiled in line with the deliverables schedule, then these two data should form the basis for sound earned value calculation. Where no deliverables are scheduled during a relatively long period of task activity, then the project manager may impose a subjective method for estimating earned value. For example, earned value may be credited on the basis of 50 % of the planned cost at the start of the task and 50 % of the planned cost at completion. More guidance regarding performance measurement is given in 4.6.6. 4.3.6.11 Detailed description of task work content The SOW should contain unambiguous information that describes in adequate detail the work content of the task. Where possible, reference should be made to supporting documents and contracts in order to avoid duplication and possible corruption of information. Where work definitions are contained in reference documents, then these documents need to be subject to the same management disciplines as the project plan.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Tasks rarely exist in isolation. The project plan should record those tasks and people on which the current task depends (predecessors) and those tasks and people (successors) that depend, in turn, on the current task. The type of dependency should be recorded, for example, “finish-to-start”, where the successor task cannot begin until the predecessor task has finished. This should enable a network of inter-related tasks to be constructed that can be used to support analysis of the complete project plan. (Most project planning tools use task start dates, durations and dependencies to calculate how much additional time is available, also known as float, before the task becomes critical, i.e., zero additional time available.

Section 4

21

BS 6079-1:2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 4

© BSI 01-2000

Figure 5 — Model bar chart

Section 4

BS 6079-1:2000

4.3.6.12 Reporting requirements

22

The project manager needs to continuously balance timescales against cost and risk, without undermining the performance of the project. The SOW will be further developed and refined during the project planning process, usually revealing more information concerning task costs, timescales and risks. The project manager should analyze this information and understand the overall project cost profile, schedule and where the risks lie. This information can be integrated into a cumulative probability distribution for cost and time for the whole project, where the uncertainty has been calculated by random sampling from the individual probability distributions for those tasks where risk has been identified. This task may be mechanized and is usually based on the best current version of the project task network. The project manager should compare data contained in the SOW with previous data for similar work and, where differences are found, investigate the causes with the task owner. This should reduce the risk of inaccurate forecasting. New information is likely to perturb whatever fragile balance between time, cost, performance and risk the project manager has managed to construct. The critical path, at least during the preliminary project planning, may wander from task to task with disconcerting ease and unpredictability. The project manager can often buy time with money or save money by tightening timescales, but needs to be mindful of the objective to reduce the risk of failure and maximize the chance of success. The project manager should gauge where a task needs more time and seek to lengthen the time available by shortening other tasks. Alternatively some tasks may be allowed to take longer and any resulting cash savings then used to shorten tasks that lie on the critical path. This process is sometimes referred to as “crashing” which involves the project manager in experimenting with the available options. Significant results from such experiments need to be recorded systematically, not only to form part of the project manager’s historical records for use in future projects, but also to justify actions and enable informed decision-making during the project life cycle.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

The SOW should define what reports are needed and at what frequency to meet the requirements of the sponsor, contractual obligations and the level of information that the project manager decides is necessary to control the work. In general terms the task owner should be made responsible for informing the project manager of any changes to the information contained in the SOW, for example, changes to risk assessments. The following specific aspects of reporting should be addressed. a) Performance status: The task owner should report the actual or forecast date of achievement for the deliverables defined for the task. The method by which the task owner calculates and reports the earned value for the work completed to date may be defined by the project manager. b) Schedule status: The task owner may be required to report the estimated time of completion for each task. This information should be consistent with the status of deliverables progress. Forecast start or finish dates which are later than the most recent planned start or finish dates should be shown separately, as any slippage in these dates may affect the project completion date. c) Cost status: The task owner should report the actual expenditure and committed expenditure to date for each task. The task owner should also report the estimated cost at completion for each task. d) Status of quality progress: The task owner should report any change that might affect the form, fit or function of the task deliverables. e) Risk exposure system: The task owner should report any changes in the status of identified threats to the achievement of tasks, together with any newly identified threats or opportunities. f) Exception thresholds and variance reporting: The rules for triggering exception reports should be based on margins applied to the forecast time or cost at completion, or actual time and cost status and derived earned value statistics. An exception report may contain a statement of the actual or forecast exception, a description of the planned recovery action and an estimate of the threat to the project plan in terms of the time, cost and performance.

4.3.7 Balance time, cost, integrity of specification and risk

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 4

At this stage in the process the project manager may benefit from using a bar chart representation of project tasks (see Figure 5). The chart should present tasks as horizontal bars against a horizontal time axis. Its main use is as a graphical method of showing both the current state of the plan and, once the project has started, progress across all tasks simultaneously. The bar chart has great visual power. A large format project bar chart may be used to focus project review meetings on certain issues and, more generally, as the medium for recording issues and comments that occur during the day-to-day running of the project. 4.3.8 Obtain commitments to do project tasks 4.3.8.1 General Each task owner needs to formally agree to the appropriate tasks by signing the commitment section of the project plan. The task owner’s commitment should signal that the assigned work can be completed as defined in the plan. If the task owner has objections to the plan, changes should be negotiated with the project manager. If a compromise cannot be reached, it may be necessary to obtain the task owner’s commitment, subject to caveats in written form, agreed with the project manager. The process up to this point is likely to require several iterations between project manager and task owner. Commitment may be qualified by an expiry date beyond which the task owner reserves the right to withdraw a commitment that has not been formally accepted. On reaching the expiry date, the task owner may provide a revised offer of commitment with a new expiry date. Any work delegated by the task owner needs to be supported by commitment obtained from the organization, individual or subcontractor undertaking the work. The trail of commitment acceptance to the project from the ultimate task owner needs to be visible to, and auditable by the project manager. Final agreement between project manager and task owner should be based on the particular issue of the project plan that defines the contract work. This is necessary for obtaining a firm commitment to any changes to the plan that are identified during negotiation. The form of these negotiations will depend on the legal relationship between project manager and task owner and the agreement is often in the form of a legally binding contract. The project manager may need to select one or more bids from several competing suppliers at this point in the process and in the event of a contest should disclose the selection criteria. The project manager should be aware of the legal obligations relating to supplier selection and the need for the selection process to be non-discriminatory.

© BSI 01-2000

BS 6079-1:2000

4.3.8.2 Identify resources required The task owner needs to understand what resources are required to perform the task and at what levels of efficiency, before making a commitment. Resources may be in-house labour or goods and services procured from an external source. (Procurement is covered in 4.6.4.) Resource management is a related, but separate, discipline to project management and the project manager need not understand the nature of the resource required to undertake a task, only how the application of this resource translates into time, money, performance and risk. This separation of duties might appear unnecessary, but the task owner should be allowed the freedom to apply whatever resource is appropriate to the task, providing the timing, cost and performance of the project deliverables are not jeopardised. 4.3.8.3 Identify available resources It is the responsibility of the task owner to understand the availability of resource needed to complete the task as described in the SOW. Resource is often not dedicated to specific projects and, in these circumstances, the task owner has to know what competing demands there are for the resource, when they will be made and with what priority. 4.3.8.4 Balance load with capacity Understanding the resource demand profile based on all sources of demand is the responsibility of the task owner. Time and cost estimates should be given to the project manager when the task owner is satisfied that there are sufficient resources to satisfy the demands of the project. 4.3.8.5 Reserve and allocate resource In the latter stages of this iterative process the SOW becomes progressively firmer until the point is reached when the project manager accepts the offer from the task owner and asks for resources to be reserved pending a formal instruction to start work. When the instruction to start is given, the task owner has a duty to allocate the resource.

23

Section 4

BS 6079-1:2000

4.3.9 Finalize agreements

24

4.4.1 Control the project plan All projects are subject to change and their success depends on how well they are planned in the first instance and how well changes are managed. The project manager should ensure that changes to project objectives and consequent changes to task SOWs are communicated unambiguously and are reflected in the current version of the plan. All changes need to be agreed by the project manager and the task owners concerned and this agreement should be registered in the project plan. Essential changes should be implemented at the earliest opportunity to minimize the impact on time, cost and specification. The project manager is responsible for the integrity of the project plan and should ensure that all changes to the project plan are controlled. Such changes may be requested by the customer, sponsor or task owner. The planning process outlined in 4.3 should be followed as rigorously for a change to an existing plan as for a new plan. It is essential that the project manager ensures that the current version of the project plan reflects the current contractual requirements in terms of time, cost, performance and specification. The following guidelines should be used to manage changes to the plan effectively and efficiently. a) The project manager should be responsible for the control of the project plan and needs to authorize any changes. b) Issue of a revised, agreed project plan should automatically cancel all previous issues. c) Each issue of the project plan should be allocated a unique sequential revision code so that previous plans can be easily identified and replaced with the latest version. d) The reasons for changes to the project plan should be fully documented and a cross-reference made to the revision codes. A complete history of such changes should be retained by the project manager. e) Work should not be released from a draft project plan. f) No one item of work should be put in more than one project plan.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

The iterative process of project planning is itself a task that is constrained by time and money. The project manager should be given enough time to plan the project to the necessary level of detail, bearing in mind that project plans that are too detailed will be too sensitive to change and may require continuous formal change procedures during the project life cycle. When the project manager is satisfied that the plan represents the best chance of satisfying the sponsor’s requirement the agreements between project manager and task owners can be formalized. The degree of formality may vary depending on the nature of the agreement and the organization in which the work is being managed. Agreement signals that the project manager accepts offers from the task owners to do work as defined in the plan. Agreement should also signify a bilateral agreement between the project manager and each task owner. This may take the form of several, separate contracts. Thus the task owner commits the resources as planned and the project manager commits to release project funding, conditional upon successful completion of deliverables if necessary in agreed stages. A schedule of funding release dates, corresponding to phased increases in limits of liability, should be described in one of the statements of work under the “manage project” branch of the WBS. Work can then be released. The project manager should be authorized by the sponsor to agree to plans within the constraints specified. If the plan falls outside these constraints then the project manager needs either to change the plan in order to conform to the constraints or refer the issue to the sponsor. If the project manager is unable to accept any stated hazard or risk associated with any tasks in the plan, the appropriate task owner should re-plan such tasks so as to eliminate the hazard and to recommit to the revised work prior to agreement. If the risks remain unavoidable and unacceptable to the project manager then the project manager may seek an alternative task owner or refer the issue to the project sponsor. Ultimately, the sponsor may decide to abandon the initiative.

4.4 The project management process: control

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 4

g) Where a change to a project plan is minor and can be contained within the existing commitments of task owners, then the project plan can be amended without re-issue. Details of the amendment may then be given to all project plan holders by the project manager. Guidelines for deciding whether a change constitutes an amendment or a re-issue should be documented. h) The project manager, in consultation with a legal advisor if necessary, should be responsible for ensuring that the revised project plan does not jeopardize any contractual obligations. 4.4.2 Manage the project budget 4.4.2.1 Set annual budgets Organizations usually budget annually and, because projects may span several years, the project manager should ensure that budgets reflect the funding and cash flow requirements of project work in ensuing years. If this step is not followed, project funding may evaporate or adversely affect the budgets of other parts of the organization. More guidance on financial control techniques is given in 4.6.5. 4.4.2.2 Release project funds and retain management reserve Funds need to be released to the task owners so that project work may start and the project manager should also make allowance for unexpected problems or small changes in plan by retaining some of the project budget as a management reserve (MR). Determining the correct level of this reserve can be a key to the success of the project and the reputation of the project manager. An inadequate management reserve may put the whole project at risk when problems arise. Conversely, if the management reserve is too large the task owners whose budgets have been used to provide MR may use lack of adequate funding as an excuse for late delivery and poor quality of deliverables. Project funds may be applied according to the risks associated with the work. Where significant risks have been identified, maximum levels of expenditure for the task may be specified. Limits to the levels of both committed and actual expenditure should be identified for tasks that are to be released in stages. Budget logs, with cross references made to the tasks in the project plan, should be used to record all transfers of project funds. The project manager may keep logs for planned profit, total expenditure, management reserve and all task budgets.

© BSI 01-2000

BS 6079-1:2000

The task owner is responsible for ensuring that the costs incurred in performing work for the project are attributable to the correct task in the project WBS and should ensure that all costs attributed to the project can be audited. Task owners should be able to give the project manager a clear statement of those irrevocable costs for which the project would be liable if it was to be terminated. This needs to include, but not be limited to, the sum of all committed costs, If a legal relationship exists between the project manager and the task owner, for example, where there is a formal contract in place governing the sale of goods and services by the task owner to the project, it will be necessary to state contractually how the project and the task owner should allocate the costs if work is terminated prematurely. This requirement is usually only necessary when the services of third party suppliers are employed. Guidance on procurement functions is given in 4.6.4. 4.4.3 Instruct work to begin, continue or stop The structured nature of the tasks contained in the plan should permit the project manager to control the project by releasing or stopping work in terms of any permutation of task or part of a task. Critical project reviews may be required at specified milestones throughout long lead time projects, in order to give the sponsor and project manager the opportunity to review progress and decide whether to continue or curtail work. The means used by the project manager to start, continue or stop work need to be clear and unambiguous in terms of the amount of money released, the nature of the goods and services requested and the individual for whom the money is intended. This process is helped by having a realistic plan and clear SOW. Usually the project manager is responsible for formal termination of the project. This action should follow formal acceptance of the final project deliverables by the sponsor, achievement of all the project completion criteria and settlement of outstanding debts. 4.4.4 Monitor progress The monitoring and analysis of project data should enable the project manager to address problems at an early stage and take advantage of opportunities that might benefit the project. Time is a vital and non-recoverable asset, the aim should always be to pre-empt situations rather than to respond to problems after they have assumed unmanageable proportions.

25

Section 4

BS 6079-1:2000

26

c) Earned value: The task owner should report performance to plan regularly. Earned value measurement is one of the available methods of reporting performance and it can be used to calculate cost and schedule variances that may in turn be used to calculate performance indices and objective projections of cost, time or some other measurable value such as labour hours or materials usage, at completion. More information on the earned value method is given in 4.6.6. 4.4.5 Manage the project The project manager is responsible for co-ordinating reports submitted by task owners and for analyzing the information provided. The project manager should ensure that, when appropriate, visual aids such as a consolidated bar chart for the plan, are kept up to date. The relevant task owners should be kept informed of changes to the critical path for the contract and the estimated cost and time at completion for all permutations of tasks in the plan. Task owners may not always be aware of, or disclose, potential risks and in such circumstances the project manager may be forced to make a personal assessment of risks. The overall pattern of risk for the project needs to be analyzed continually to decide where to concentrate management effort to best effect. The project manager is responsible for reporting to task owners any hazards that are identified through analysis of the plan and for ensuring that the task owner has appropriate recovery plans in place. The project manager should also co-ordinate all project reports for the sponsor in accordance with the requirements of the plan. The project manager may record statistical data on task owner performance and overall project performance in terms of costs, timing and the quality of deliverables. This information may be used to validate future estimates from task owners for new project work. The project manager should be responsible for the security of the project plan. This will require control of the distribution of the plan. Each holder of the project plan should understand and comply with the rules of disclosure governing the plan. The rules may be dictated by either commercial sensitivity, national security or professional confidentiality requirements. Where appropriate the plan should be clearly marked to indicate its security level, for example “personal and confidential”, “restricted”, “private data” etc.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Good communications between project manager and task owner are essential. If communication links are weak then problems can escalate, no matter how much information is available. Effective monitoring and analysis should help the project manager and task owners to understand the status of the whole project, the effect of their performance on the project objectives and any risks that lie ahead. The task owner should fulfil the regular reporting requirements contained in the project plan and submit written exception reports to the project manager if the progress of work deviates significantly from plan. Exception reports should not only explain the reasons for exceeding or failing to achieve performance thresholds, but also describe how the situation can be recovered. The task owner is accountable to the project manager for the completion of committed tasks to time, cost and specification and should warn the project manager of any operational issues that affect the work of other task owners. The task owner should ensure that SOW data are kept up to date, inform the project manager of tasks in danger of becoming critical and provide a revised risk assessment for the task. Similarly, the project manager is responsible for keeping task owners briefed on the current state of the whole project. Specific project monitoring reports may be required and the vital basic elements of information that all projects require are as follows. a) Actual costs reported against planned cost and variances: These should be identified and compared to variance thresholds imposed by the project manager. If a threshold is breached then the task owner should provide reasons for the variance and submit a recovery plan stating the impact on cost, time and specification. The impact of current actual cost on project cash flow should be of specific concern to the project manager. This will either ease or increase the financial burden of the project. b) Time and cost at completion: The task owner should provide a regular estimate of the time and cost at completion for each task. Although it is possible for the project manager to extrapolate existing data to provide such an estimate, the task owner should also be given an opportunity to record a subjective view. Reconciling differences between the project manager’s estimate based on actual data and the task owner’s opinion should provide a useful insight into real and perceived progress.

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 4

BS 6079-1:2000

4.4.6 Assess risks

4.4.9 Negotiate

The risk of success or failure should be assessed continuously by means of cost and time estimates of the interdependent network of tasks that make up the project. The overall project risk factor can be analyzed by simulating project progress, in a series of tests, using random sampling from the best-worst-most likely time and cost distributions for each task and calculating where the critical path most often lies. This will produce cumulative cost and time distributions around the planned project cost and finish date. It can also produce a list of all project tasks ranked in order of the likelihood that each task will be on the critical path. Thus a task with a 95 % chance of being critical should warrant more attention than a task with only a 5 % chance of being critical. More guidance is given in 4.6.3.

A project manager succeeds or fails depending on an ability to negotiate effectively. It is essential to recognize two phases to negotiation: pre-contract and post-contract. The project manager needs to be aware that concessions or changes made during the pre-contract stage will be cheaper and easier to seek than when the project is in full operation. Once the project has started, the pressure on the project manager to complete to time and cost is continuous and task owners may be tempted to exploit their position by seeking additional money in order to keep the project on schedule. It is imperative that the project manager ensures that the scope of work in each task is properly defined at the outset, that risks are spread rather than concentrated and that there is little opportunity for task owners to hold the project manager to ransom. The task owner will naturally be seeking to exploit the position and profit from the project work. A project manager should be capable of convincing task owners that they too are stakeholders in the success of the project and that meeting the objectives of the project subsumes their personal objectives.

4.4.7 Manage risks As a result of monitoring and analyzing risks, the project manager should be able to identify those tasks where an alternative course of action is needed to mitigate the risk. Using the project plan the project manager can experiment with various alternative risk avoidance tactics and select those actions that best contain or avoid the risk. The project manager may need to obtain the support of the project sponsor to follow two parallel courses of action in order to manage an otherwise unavoidable risk. The project manager needs to gain the support of task owners when deciding a new course of action. The negotiation is likely to follow the steps in the planning process until agreement is reached, when a revised project plan may be issued. 4.4.8 Motivate task owners Projects should, by their nature, be directed towards achieving a definite end result. As a consequence, project managers should have very little trouble focusing task owners on project objectives. Prudent application of the management reserve should enable the project manager to retain some project funding for bonus payments and, providing these are part of the agreement between the project manager and the task owner, there is scope for good performance to be rewarded. This is a powerful motivating force. Good communication between the project manager and task owners is an equally powerful motivating force. A well-informed project team will usually perform better than one where information is rationed.

© BSI 01-2000

4.5 The project plan 4.5.1 General There may be variation in content, style and volume between one project plan and another, due to variety in the work and in the circumstances in which the project is to be executed. The key contents of a project plan are described in 4.5.2 to 4.5.7. 4.5.2 Project plan sections A basic project plan should contain the following sections: a) introduction and summary; b) commitment acceptance; c) project Work Breakdown Structure (WBS); d) schedule; e) Statement of Work (SOW). A sophisticated project plan, for example, for a major engineering development project may contain the elements shown in Table 1. 4.5.3 Introduction and summary This section of the project plan summarizes the essential elements of the project and makes reference to any information that may affect how tasks should be performed and managed. This preliminary part of the project plan should include the following information, not necessarily in the order given: a) project name, reference code, issue number and date of issue;

27

Section 4

BS 6079-1:2000

4.5.4 Commitment acceptance, agreements, budget releases and budget logs The project plan should contain a commitment and agreement section that records task owner commitments and the project manager’s acceptance of such commitments. The task owners need to formalize their commitments by signing against the appropriate project WBS reference. The project plans should contain details of any caveats that were added by task owners to qualify such commitments. Accountability for work in the project plan needs to be included in the statement of work. As the project progresses documents such as instructions for work to proceed and budget releases need to be recorded systematically in the appropriate budget log. Agreement by the project manager or the sponsor gives the project plan contractual status and responsibilities as described in the plan become binding.

28

4.5.5 Project work breakdown structure and WBS dictionary This is an hierarchical description of the tasks in the project plan. A project WBS should enable members of the project team to define their tasks at a meaningful level of detail. The use of a graphical project WBS should reduce the possibility of overlooking essential elements of project work and, if past project information is available and structured in a similar way, it allows direct comparison of past performance with current estimates. The most detailed level of project work defined in the WBS should be that which is considered by the project manager to be necessary and sufficient for the effective and efficient monitoring of deliverables and control of costs such that the requirements of the sponsor are met. A project WBS dictionary, with a short summary description of each task recorded against the task project WBS code, may also be included. A dictionary should provide a useful glossary of task definitions, as well as helping users to locate specific tasks swiftly. 4.5.6 Schedule of work The schedule of work required to satisfy the contract may be recorded as a consolidated bar chart that may be based on a critical path analyzed task network. A consolidated list of all deliverables ordered by time and by responsible owner should also provide a useful focus for the project team as a whole. 4.5.7 Statement of work (SOW) A statement of work should be included in the project plan as follows. Guidance on the contents of a typical SOW is given in 4.3.6. The project plan statement of work is not always the vehicle for the definitive technical specification of the project work content. These detailed data may exist in separate reference documents and contracts that may be referred to by the project plan where appropriate. Reference documents need to be subject to the same control disciplines as the project plan. For reasons of confidentiality, suppliers and task owners may only be given information that impacts their contribution to the project.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

b) project plan contents; c) name of sponsor; d) summary of the project objectives and the means planned to achieve them; e) summary of the project completion criteria and how the sponsor decides whether or not the project has succeeded in achieving its objectives; f) a list of amendments to the project plan with a project WBS reference to the amendment, a short summary of the amendment including the reasons why the amendment was necessary and the date of its incorporation; g) reference to mandates and injunctions governing the project, for example, policies, standards, specifications, health, safety and environmental issues; h) reference to guidelines governing how various elements of project work should be performed, for example, project management, procurement strategy, contract management, configuration and variation management, financial management, quality assurance, reliability management and the project organization, including the project team and task owners; i) a document circulation and contacts list; j) a list of associated contracts; k) reference to the business evaluation on which the original decision to authorize the project was based. The project manager needs to ensure that the project team are aware of any relevant assumptions in the business evaluation and that they each have a duty to report to the project manager when these assumptions are at risk. This section of the plan is likely to be confidential and its circulation limited to those who need to know.

Section 4

BS 6079-1:2000

Table 1 — Model project plan Typical clause numbers

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

1 2 3 3.1 3.2 3.3 3.4 4 5 6 7 8 9 9.1 9.2 9.3 9.4 10 11 12 13 14 15 15.1 15.2 16 17 18 19 20 21 21.1 21.2 22 23 24 25 25.1

Table 1 — Model project plan Typical clause numbers

Foreword Contents, distribution and amendment record Introduction General description Scope Project requirement Project security and privacy Project aims and objectives Project policy Project approvals required and authorization limits Project organization Project harmonization Project implementation strategy Project management philosophy Implementation plans System integration Completed project work Acceptance procedure Programme management Procurement strategy Contract management Communications management Configuration management Configuration control requirements Configuration management system Financial management Risk management Project resource management Technical management Test and evaluation Reliability management (see also BS 5760-1) Availability, reliability and maintainability (ARM) Quality management Health and safety management Environmental issues Integrated logistics support (ILS) management Project team organization Project staff directory

© BSI 01-2000

25.2 25.3

26 27 28

Organizational chart Terms of reference (TOR) a) for staff b) for the project manager c) for the committees and working groups Management reporting system Project diary Project history

NOTE The clause numbers given in Table 1 are for illustration only, they do not cross-refer to any clauses of this standard.

4.6 Processes supporting the project management process 4.6.1 Quality assurance 4.6.1.1 General The project management objective is to deliver on time, to cost and to specification; this can be made easier and more efficient if the organization implements a sound quality policy. 4.6.1.2 Quality system It is essential that the host organization has a quality management system that is directed towards the control of those elements of the project that affect the quality of the project deliverables. The project manager can usually gain confidence in the ability of the host organization when the quality management system is certified to a national or international standard. 4.6.1.3 Quality objectives There are many definitions of quality and one of the best known descriptive phrases is “fitness for purpose”. This should be interpreted for the purposes of project management as meeting the requirements of the customer with respect to time, cost and product specification (including health and safety, see 4.6.1.5). 4.6.1.4 Quality plans Quality plans, when required by the customer or the project manager, need to form an integral part of the overall project plan. The quality plan should provide a quantified means of demonstrating that specific quality requirements are being addressed. The quality plan should, for example, detail the steps needed to produce the project deliverables, with the appropriate quantitative acceptance criteria.

29

Section 4

BS 6079-1:2000

Quality plans should be considered in the feasibility phase (see section 5 for a discussion of project phases) and confirmed at the beginning of the implementation phase. Before it is included in a contract as a technical requirement, the quality plan needs to be agreed by both the quality manager and project manager. 4.6.1.5 Health and safety

4.6.2 Configuration management 4.6.2.1 General A configuration management system should be used to control the physical and functional characteristics of a product or service through documentation, records and data. Good CM practice should ensure that changes (variations) are implemented only after being authorized by the supporting documentation and not, as sometimes happens, with the documents being altered to reflect a configuration change that has already been implemented. The configuration management discipline needs to be applied throughout the life cycle of a project. During the early project phases this may require an increase in management costs. However, cost savings during the production and in-service phases should follow if CM is practised in concert with established project requirements. 4.6.2.2 Configuration management systems The task owner or contracting organization should establish and maintain a configuration management system, to the satisfaction of the project manager, to ensure that technical and administrative direction and surveillance is applied to the following activities: a) configuration item selection, identification and documentation; b) configuration control; c) configuration status accounting; and d) configuration audit.

30

The task owner or contracting organisation should prepare a configuration management plan that formally describes the scope, organization and procedures for CM and the points of contact responsible for CM. Where CM is a requirement at subcontract level the degree of control and the procedures to be employed should be detailed in the configuration management plan, agreed by the project manager and included in the overall project plan. 4.6.3 Risk management 4.6.3.1 General All projects, in common with all future work, are risky. A sponsor cannot be absolutely certain that the anticipated benefits from the project will be fully realized however successfully the project has been carried out. The sponsor is the primary risk taker but a project manager also faces risk in the form of the inevitable uncertainty surrounding the project process and unpredictable project environments. For the project manager, project risk is primarily the likelihood of negative occurrences adversely affecting the project so that its objectives become more difficult or even impossible to achieve. The project manager should therefore take positive steps to identify, assess and ultimately manage all risk inherent in the project, as an integral part of the project management process. By using a structured risk management process the project manager should ensure that as many risks as possible are identified, thus enabling the following action to be initiated: a) categorisation according to the nature of the risk; b) assessment of the probability of occurrence and potential impact on the project; c) the application of suitable risk response measures including contingency planning; d) the sharing, transfer or full acceptance of risks to the project; e) taking account of risks in management planning.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Project work often causes risks in terms of health, safety and the environment. In order to ensure such risks are understood and reduced to an acceptable level, every project should include an audit of these specific risks before work starts. This audit should be updated throughout the life of the project. Audit updates should be scheduled as part of the overall project plan.

4.6.2.3 Configuration management plan

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 4

Risk management, whether separately identified or not, should continue throughout the project life cycle. It should always be given special emphasis as a key element in project planning. Project planning cannot be realistic unless serious account is taken of what could go wrong and what can be done to increase the chances of success and lessen the prospects of partial or complete failure. Risk management techniques should be used to identify in advance the risk from problems and threats to the project. They then need to be continuously applied as a means of effectively reducing risk to a tolerable level. 4.6.3.2 The nature of project risk Unless risks are recognized they cannot be dealt with. If the risk identification process is to be effective, risk should be seen as arising from any significant threat or area of uncertainty that the sponsor and project manager may face during the life of a project. Potential risk within projects is not limited to accidents or the failure of technology or unsound commercial arrangements; differing perceptions of the project among the project team may pose a potential risk for the project manager. Failure to identify objectives and perceptions of all key stakeholders (those who participate in decision making or are affected by the project in some way) can result in a lack of shared understanding, or even conflict in a project, for which the project manager is unprepared. Those who participate in projects bring to the project their own perceptions of what they consider as possible risks. These perceptions determine their approach to the project and also their behaviour towards areas of uncertainty. Areas of uncertainty that they have not considered, or that lie outside their experience, will often be disregarded or not seen as risky and this can create a major area of risk itself that often goes unrecognized. 4.6.3.3 Risk identification The essential first step in effective risk management is the identification of as many as possible of the risks of significant problems arising during a project’s life and the highlighting of areas of uncertainty that themselves will constitute a risk. Only when this has been done can a project manager plan to reduce the threats and set up contingency plans to be used if problems actually materialize. Risk and the problems, threats or events that give rise to them should generally fall into one of the following categories: technological, political, managerial, sociological and financial. Risk analysis should answer the following three fundamental questions.

© BSI 01-2000

BS 6079-1:2000

a) What could go wrong? b) How likely is this to happen? c) What would be the consequences? Encouraging a project team to recognize the potential for failure can be helped by brainstorming, using generic and specific checklists of typical problems, analyzing both team members’ experience and lessons from similar previous projects, and modelling the project’s events through the use of the networks that support the project programme. The use of the project network to structure the analysis allows a team to concentrate not only on risks associated with particular activities, but also on risks arising from the interfaces between those activities where particularly high levels of risk may exist. 4.6.3.4 Risk quantification and reduction Once the important risks have been listed each should be assessed by estimating the nature and size of damage to the project that might occur should the worst happen. This primary risk is then quantified by assessing the likely frequency of the underlying problem occurring. Simply ranking the probability as high, medium or low will do much to indicate the size of risk and sophisticated methods are available when a more accurate forecast is required. Secondary risks arise because efforts to deal with the main problem or undesired event, if it occurs, often create further difficulties. Secondary risk, that sometimes can be of a greater magnitude than the primary risk, should not be overlooked in risk management planning. Once quantified, some risks may turn out to be completely intolerable to the project sponsor, thereby raising doubts over the entire project, or at the very least, the desirability of pursuing certain of the project objectives. The risk assessment may also cast doubt over the wisdom of employing particular methods to execute the project. In complex project situations analytical methods can be used to examine the likelihood of one problem impacting on another to produce an even greater risk.

31

Section 4

BS 6079-1:2000

4.6.4 Procurement processes

Plans for dealing with areas of risk and uncertainty in the project should be an integral part of the project plan. Risk analysis and risk management need to be central to the project manager’s understanding of the project and the difficulties to be faced in attaining the agreed objectives. One extreme response to risk may be to compromise on the project objectives; another may be to fund an alternative method of executing the project. Examples of less drastic means of dealing with risk are increasing management strengths in the project, reducing the dependency on one technology or one task on another or increasing the project plan’s flexibility and scope for management intervention so that potential obstacles to progress are avoided rather than left to be dealt with if they occur. Risk management strategies should feed in to every area of the project plan but are especially relevant to procurement and contract management policies. A project’s sponsor or project manager may wish to see some risks transferred to other parties who should be willing to take on and manage them and for transfer to be worthwhile there should be a balance between risk carried and the potential reward for so doing.

4.6.4.1 General

4.6.3.6 The risk management plan The entire risk management analysis and management plan should be documented and integrated with the project plan. Recognizing uncertainty in projects and the risks that can arise is an essential part of project planning. The problems that might occur and the measures for dealing with them should be documented in risk management plans. These should record who is to take responsibility for each risk reducing action and for any other actions such as contingency planning. Some risks may prove to be impossible to reduce and will require contingency plans. Expenditure on contingency plans is often provided for by insurance or through the creation of management reserves under the control of the project manager. Where more than one project is involved, a central contingency pool can be created and by this means a sponsoring organization can wholly or partly insure itself against the unexpected.

32

Procurement is a vital element in the success or failure of many projects, particularly those concerned with a hardware product. The commitments for materials, goods or services with a long lead time may have to be made before either the project team or the project manager are in place. These commitments can for good or ill set the course of the project. The procurement processes aim to acquire hardware, software, processed materials, services or combinations thereof that are necessary for the completion of the project. Thus procurement in projects is much wider than just purchasing or buying, particularly since in many projects the items to be procured are outside the normal experience of the parent organization and may involve special contract conditions. In addition, in many projects, procurement may require the procurement officer to organize activities such as: — the transport of material to a location distant from the parent organization, possibly overseas; — the organization of transport and documentation; — the arrangement of accommodation for staff away from home; — the hiring of specialists or consultants or other services; — the renting of equipment and plant not available in the parent organization. 4.6.4.2 Buying There are three main types of buying organization: a) Routine buying: where a central purchasing department buys all goods and services, based on the requirements of the project organization. b) Commodity buying: where a buyer or group of buyers specializes in a particular commodity. The buyer becomes very familiar with the product and its sources and should be able to obtain the best prices, discounts and deliveries. Care needs to be taken that excessively close relationships with suppliers do not develop. c) Project buying: where a buyer or group of buyers specializes in the purchasing needs of a particular project, dealing with the complete range of bought-in items. This should have the advantage that the buyer is fully committed to the project and is an integrated member of the project team. An experienced project buyer is often able to give valuable advice to the project manager regarding, for example, outstanding purchasing requirements and lead times.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

4.6.3.5 Response to risk

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 4

BS 6079-1:2000

4.6.4.3 Purchase orders

4.6.4.6 Inspection

The key document issued by a buyer is the purchase order. This needs to contain the following information: a) a unique purchase order reference number; b) terms and conditions of purchase; c) specification and reference or part numbers of the items to be purchased; d) acceptance criteria; e) value of order; f) delivery date; g) terms of payment; h) delivery address and instructions.

Failure to inspect may result in faulty or unfinished items being delivered. The subsequent repair or return to the supplier will usually result in costly delays that far outweigh the cost of inspection and rectification in the supplier’s works. Inspection of items within the supplier’s organization should be carried out in addition to any other in-house inspection stages specified in the quality plan. Any problem with meeting quality and acceptance criteria needs to be reported to the project manager, who should approve all concession requests or changes to specification, if necessary having first sought the sponsor’s agreement. Details of concessions and changes may also be subject to the configuration management system and details should be approved and recorded as necessary.

4.6.4.4 Vendor qualification Some advantages, in terms of delivery, cost and performance may be achieved by developing a preferred single source for each major purchased item, particularly for projects in the volume production area. In the first instance, vendors should be ranked and selected for further consideration according to their past quality and performance records. A good working relationship should then be established between the preferred vendor and the project team at all levels, so that the vendor is effectively absorbed into the culture of the project organization and fully understands its requirements. For the vendor this should be an opportunity for long-term business without significant competition. The advantage for the project team is quality and reliability of supply. 4.6.4.5 Expediting Unless orders are regularly expedited, delivery dates and promises should not be relied upon. Suppliers need to be visited or reminded at set intervals to ensure compliance with delivery dates. The project manager should set up an efficient contractual expediting programme and needs to be advised of every actual or potential slippage, so that remedial action can be taken immediately. This could take the form of high level contacts, premium payments, reprogramming where possible or even cancellation of the order. The imposition of liquidated damages for failure or partial delivery or lateness of requested documentation can be of great help to the expediter, who needs to be fully aware of the downstream implications of a late delivery.

© BSI 01-2000

4.6.4.7 Shipping The shipping of items (especially to overseas destinations) requires careful planning and control. It may also be necessary to carry out route surveys when heavy or large loads have to be transported. The shipping function should include custom clearance, obtaining transport permits, chartering vessels or aircraft, co-ordinating the economical filling of containers and obtaining the necessary documents to comply with export and import regulations. Even when the responsibility for shipping rests with the supplier, the project manager needs to be satisfied that all the shipping arrangements have been correctly implemented. 4.6.4.8 Subcontract administration in construction projects The conditions laid down in subcontracts for construction projects can be either general or special as follows: a) general conditions, as laid down by professional institutions, trade associations, government departments or local authorities, b) specialist conditions, as issued by the buying authority in accordance with an internal standard or specific project requirement embodied in the contract.

33

BS 6079-1:2000

4.6.5 Financial control processes 4.6.5.1 Financial evaluation Authorization for projects to proceed should be based on formal evaluation of a proposal. A project that has not been subjected to such scrutiny is at much greater risk of failure. The only financial certainty is that the rate of expenditure will escalate as the project progresses to implementation; the project manager should therefore keep a firm control on project finances at all times. The cost of delivering the project will only be justified if the claimed benefits, either in profit or services to society, are subsequently realized. Costs are largely set by specifications and procedures built-in during the design phase. After the decision to proceed is taken, these tend to progressively become legal commitments as binding orders. Contracts are placed and actual expenses, as they are fulfilled, are invoiced and paid for. Figure 6 shows how costs tend to build-up before any benefits are delivered. Any review to consider possible abandonment of a project needs to be concerned with the total committed cost rather than merely the amount actually expended.

34

It is important that as soon as sufficient work has been completed, the disparate threads of a project are brought together in the common measure of money. This is to determine the full cost of development and implementation and the difference anticipated between the operating costs and income over a reasonable period of time. The evaluation should concentrate on cash flow, rather than bookkeeping conventions used for financial accounting. The project manager needs to produce a realistic assessment of the cash needed; capital and associated revenue. These data should be given in time periods, for example three or six monthly intervals, that are appropriate to the duration of the project. The assessment may also show the expected cash receipts throughout the project, from initial grants to any close down income at the termination of the project. The project manager will need to ensure that the financial forecasts are realistic and achievable and that a management reserve is included to cope with unexpected issues. For some projects a substantial part of the full life cash flow may be needed for decommissioning and safely disposing of assets at close-down. The accuracy of data will tend to diminish as the forecasting horizon is extended into the distant future and will become grouped, rounded-off and generally less detailed. Data for the relatively near term should, however, be reasonably accurate and detailed, see Figure 7.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

The difference between a subcontract and a purchase order in the construction industry is that the former has a site erection content. Consequently all construction enquiry and contract documents need to contain details of the various site agreements with other contractors and trade unions, regulations, restrictions and methods of progress control. Since stage payments are usually based on site measurement, a subcontract demands considerably more administrative effort than a purchase order. Whether this work is done in the office or on site, the project manager should be responsible for ensuring that it is done efficiently and regularly by an experienced and trusted person.

Section 4

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 4

BS 6079-1:2000

Figure 6 — Typical cumulative cost pattern The project manager needs to make the most sensible use of the available data, while recognizing that financial evaluation is only one of the elements that will be considered when deciding to approve or reject a project. In certain situations the quantifiable benefits will be augmented by real but less tangible benefits and wholly subjective benefits. It is essential that these benefits are identified and wherever possible measured and further quantified as the work progresses. In larger projects the initial evaluation will be followed by periodic updated evaluations at predetermined milestones, as part of the monitoring procedures and authorization requirements.

© BSI 01-2000

Projects are concerned with the future and always bear a degree of uncertainty and risk. The evaluation needs to include a full assessment of the principal risks, showing the assumptions made and referring to the consequences of various scenarios. Where possible the sensitivity of the project to these risks should be analyzed. In appropriate circumstances risk management will require a full separate statement and contingency plan. It should always be remembered that investment money is usually the scarce resource and the results shown in the financial evaluation may be crucial in obtaining the necessary funding. The consequent application of funds should also be seen as a commitment to the project by the signatories.

35

Section 4

BS 6079-1:2000

4.6.5.2 Time related value of money The purpose of most projects is to enhance profit by some combination of improved income and reduced costs; this can be achieved, for example, by increasing the capacity or utilization of an asset. The real value of money is constantly changing; one pound of income today is likely to have significantly different buying power from a pound received in ten years’ time. To compare the worth of alternative projects competing for scarce funds, the net cash flow figures should be adjusted to a common time base. Using compound interest to reflect the cost of money, it is usual to discount a stream of future cash flows to a Net Present Value (NPV). An NPV calculation puts most weight on near term income and increasingly less weight on receipts stretching out into the more uncertain future. The resultant Discounted Cash Flow (DCF) needs then to be compared to the original investment to establish a NPV that is directly comparable from one proposal to another.

36

A similar use of the concept of time adjusted cash flow values seeks to find the Internal Rate of Return (IRR) that will discount the cash flow back to the original investment. If that rate is higher than the cost of borrowing, the proposal should pass the hurdle and may then have to be compared to other draft projects. Under most circumstances, managers need to select the project offering the best fit to the criteria being used. Examples of these criteria are speed of pay back, first year return, overall percentage return on investment and annual average rate of return on the original investment. It is being increasingly recognized that financial techniques need to deal with whole life projections. DCF techniques should be applied consistently to ensure familiarity with the techniques being used and to ensure comparability between projects competing for scarce resources, with minimum hurdles of returns set for all investments in one-off projects. Table 2 gives the discounted cash flow and net present value of two small commercial projects competing in an environment where the cost of investment monies is judged to be 10 % and both projects need an initial investment of £50,000. © BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Figure 7 — Format of cash flow forecast

Section 4

BS 6079-1:2000

Table 2 — Example of discounted cash flow

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Project A

Residual value at project end Years of life Cash profits after interest but before depreciation Year 1 Year 2 Year 3 Year 4 Year 5 Total Average p.a. Discounted cash profits Year 1 Year 2 Year 3 Year 4 Year 5 Total Less original investment Net Present Value (NPV) % NPV on investment

Project B

nil 4

nil 5

32,500 27,500 22,500 19,500

20,000 25,000 25,000 30,000 15,000 115,000 23,000

102,000 25,500 29,545 22,726 16,904 13,318 82,493 50,000 32,493 64.8

Discount rate in 10 % regime

.9091 .8264 .7513 .6830 .6209

18,182 20,660 18,782 20,490 9,313 87,427 50,000 37,427 74.8

NOTE The authorizing body would consider these financial projections with other criteria in determining which project, if any, to proceed with.

When this step has been completed, the manager evaluating the project needs to decide on the source of the funds which are to finance the project and should ensure that interest costs are built into the evaluation and the balance sheet assessments. Full account should also be taken of the consequences of changes in debtors, creditors, stock and working overdraft facilities etc. 4.6.6 Earned value performance measurement 4.6.6.1 General A key principle of good project management practice is the use of performance measurement techniques such as earned value analysis at the task level. Earned value measurement should enable a clearer measure of the project work accomplished and better forecasts of the likely task and project completion dates and associated costs, compared with the traditional method of simply comparing the actual and planned cost to date.

© BSI 01-2000

4.6.6.2 Earned value principles Earned value is based on assigning a value to the achievement of project work. Ideally, achievement is in terms of milestones and deliverables. The value is usually monetary but can be expressed in any appropriate units such as man hours. The value to be earned when a specific milestone is achieved is based on the planned cost of achieving the milestone. Thus, for example, if the plan showed that £50,000 was required to achieve milestone X, £50,000 worth of earned value would be credited to the task owner when achievement of milestone X was demonstrated. Earned value is also known as the Budgeted Cost of Work Performed or BCWP. Earned value based performance measurement replaces the traditional practice which only compares planned and actual costs. This practice tended to confuse actual costs with actual progress, a confusion which is eliminated by using earned value (see Figure 8).

37

Section 4

BS 6079-1:2000

4.6.6.3 Project milestones and deliveries

4.6.6.4 Performance analysis Performance analysis should begin at the task owner level, where the actual cost of work performed (ACWP) on a given task needs to be compared with the earned value credited so far to the task owner. The difference between earned value and actual cost is called the cost variance: Cost variance = BCWP – ACWP where ACWP is the acutal cost of work performed; and BCWP is the earned value Similarly the cost impact of schedule slippage, the schedule variance, may be determined. At the end of a task the earned value should always be equal to the planned cost (because earned value is based on planned cost). Thus use of the cost based schedule variance is not recommended for work that is nearing completion. Schedule variance (cost) = BCWP – BCWS where BCWS is the budgeted cost of work scheduled (or planned cost). Alternatively, as shown in Figure 8, a time based schedule variance may be determined by calculating the difference between the planned and actual time taken to complete the work to date. Schedule variance (time) = OD – ATE where OD is the Original Duration planned for the work to date; and ATE is the Actual Time Expended for the work to date. Negative cost or schedule variances are unfavourable and positive variances favourable. The same data may be expressed as ratios that give an indication of value for money. If work is proceeding to, or better than, plan, these ratios will be equal to or greater than unity. Conversely unfavourable variances will be less than unity.

38

Cost performance index (CPI)

= BCWP -----------------ACWP

However, a Schedule Performance Index (SPI) may be calculated in two alternative ways to give a cost or time based forecast. The cost based SPI is part of earned value analysis and the time based SPI is for use when forecasting the possible achievement of intermediate time points, the remaining time to complete the project or the total project time. Further guidance on time based forecasting is given in 4.6.6.5. The alternative methods of calculating SPI are as follows: Cost based SPI

= BCWP -----------------BCWS

Time based SPI

= OD -----------ATE

When calculating any of these ratios or indices, only data from the current phase of the project should be used. This is because the preceding phases may have been performed under different conditions. For example, activities in the conception or feasibility phases are likely to be significantly different in nature to those in the implementation phase. Equally, these data should be directly related to the work breakdown structure, so that by consolidation, the performance of the whole project, or any part of the project, may be determined at any point in time. Provided an analysis of every task is available at a given milestone, a complete picture of the project performance, together with reasons for variations, should be identifiable. This should focus management attention on the opportunities and problem areas and their effect on the project as a whole. A singularly useful way of using earned value data is to plot CPI as a function of SPI (cost based) through time. The line drawn through the points should reveal very accurately the direction of the task and, if drawn at the level of the whole project, the complete project. This method of presenting data, often referred to as a “bull’s eye diagram”, may also be used to demonstrate the effect of recovery action. An example of the chart is given in Figure 10.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

The project plan should specify when milestones and deliverables are to be achieved. Project milestones and deliverables should have the following characteristics: a) represent a well defined event, for example delivery of a specific product or completion of a project phase; b) a clear relationship to a task within the project plan; c) quantifiable criteria for assessing achievement; d) be defined at a specific point in time.

These ratios, known as performance indices, may be determined as follows:

Section 4

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

BS 6079-1:2000

Figure 8 — Earned value chart 4.6.6.5 Forecasting based on earned value statistics Forecast project completion cost and time can be based on simple formulae using earned value statistics as follows:

where EAC

is the estimated cost at completion

BAC

is the budget at completion (total planned cost of work).

( BAC – BCWP ) EAC = ACWP + -----------------------------------------CPI

© BSI 01-2000

39

Section 4

BS 6079-1:2000

In time forecasts

4.7.4 Evaluation and decision making

Planned Total Project Time

= PTPT

Schedule Variance (time)

= OD – ATE

Planned Time to Complete (PTC)

= PTPT – OD

Estimated Actual Time to complete = PTC/SPI (time) = ATE + PTC/SPI (time)

Depending on the type and quality of the progress data, alternative methods may be used for producing forecasts. Wherever possible, it is perferable to use cost or labour hours data, but in the absence of such data, other methods based on network techniques may be used (to establish OD and ATE) if only activity durations are available.

4.7 Project personnel development 4.7.1 General The variety of demands placed upon a project manager and the members of the project team is substantial. The list of attributes and skills described in 4.7.2 to 4.7.14 should be developed to ensure the effectiveness of individuals and the project team as a whole. NOTE Many of these attributes are not exclusive to project management.

4.7.2 Leadership Individuals should be able to stimulate action, progress and change and to get things moving by means of the following attributes: a) demonstrating initiative and achieving results; b) displaying strong persuasive skills when dealing with team members; c) delegating effectively; monitoring the effectiveness of the team as a whole and the contribution of its individual members; d) being competent at running effective meetings and having the ability to manage and control change. 4.7.3 Technological understanding Individuals need to have an adequate, but not a specialist, understanding of the technical requirements of the project so that business needs are addressed and satisfied.

40

4.7.5 Management of people Individuals should be able to motivate and enthuse colleagues by means of the following attributes: a) being able to work co-operatively and communicate effectively with people at all levels in the organization; b) being concerned for and having an understanding of people’s needs; c) showing enthusiasm for the project and a constant personal drive toward achieving its goals; d) developing the skills of and encouraging the individual project team members. 4.7.6 Systems design and maintenance skills Systems design and maintenance skills include: a) being computer literate and demonstrating competence in the use of the relevant computer systems and applications; b) having a working knowledge of the internal administration and systems of organizations within the project environment. c) having a working knowledge of the systems and environment that the project deliverables will encounter in the operational phase. 4.7.7 Planning and control skills Planning and control skills include: a) the ability to identify problems and opportunities; b) making the best use of available resources to achieve the project objectives; c) encouraging the project team members to set personal objectives with respect to planning, organizing and time management methods; d) being familiar with modern planning and monitoring techniques;

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Estimated Total Project Time

Individuals should be able to evaluate alternatives and make authoritative decisions by means of the following attributes: a) being able to sift through and understand volumes of project data, identify important material and seek out any missing information, to make an informed decision on the facts presented; b) getting to the root of project issues, identifying key relationships, political implications and applying a pragmatic cause and effect approach to the decision process; c) understanding the project objectives, establishing the correct priorities and choosing the most appropriate course of action.

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 4

BS 6079-1:2000

4.7.8 Financial awareness

4.7.13 Legal awareness

Financial awareness involves: a) being familiar with financial and risk management techniques; b) having a broad based financial knowledge including the ability to understand company accounts; c) being familiar with cash flow and variance analyses, understanding profit and loss statements and able to develop financial models; d) being cost conscious and able to control costs to plan.

The individual should have an understanding of contract law and any statutory requirements that could affect the project.

4.7.9 Buying and general procurement Individuals should have the capability to participate in the development of the procurement strategy. 4.7.10 Communications skills Communications skills should consist of the following: a) being able to express themselves in a clear, understandable and unambiguous manner; b) demonstrating skills in verbal and written presentation; c) using the most appropriate presentation media and methods and tailoring the level of detail to a given audience; d) thinking on one’s feet and giving meaningful responses to questions; e) dealing effectively with sub-contractors, customers and people outside the project environment; f) giving clear, unambiguous instructions. 4.7.11 Negotiating skills To be effective in negotiation individuals should be: a) skilful in pre-determining a customer’s stated, implied and latent needs; b) skilful in countering hidden agendas and political objections to the project; proficient in preparing appropriate responses to issues and planning a negotiation strategy in advance; c) able to convince people, appeal to their interests and counter their technical objections; d) persuasive in obtaining additional project resources when required.

4.7.14 Character Besides these skills, that can all be learnt, there is still one factor that is overriding: the personality of the project manager. Without the personal qualities that are a part of character the other aspects will generate only an average project manager, not a good one. Incorporated in the character should be a mixture of enthusiasm, dedication, drive, determination, vision and humour. 4.7.15 Project team blend As a project progresses, the project team should gain a variety of functional skills and experience in such fields as marketing, engineering, social services, finance and personnel. These skills may be brought to the project by the people seconded to the team perhaps for the life of the project or for particular phases where the need for a particular talent is dominant. Besides the functional skills that are important for carrying out the tasks of the project, it has been found desirable to try to ensure a mix of personal characteristics. It may be considered that the project manager needs the ability to link and lead people who between them can: a) create innovative approaches to the issues; b) sell the work of the team to the influential third parties; c) pragmatically test ideas within the team before adoption; d) secure co-operation from within the organization and know where to go for specific backing and back-up; e) get things done; f) insist on progress at acceptable standards; g) take a semi-detached view of events and see things as they are. h) maintain composure under pressure and keep calm when things go wrong.

4.7.12 Contractual skills Contractual skills include: a) capability in developing a contractual strategy; b) effective communication of contract terms and conditions to appropriate sub-contractors; c) ability to manage sub-contractors;

© BSI 01-2000

41

BS 6079:2000

Section 5. Project lifecycle 5.1 General

5.2 Types of project Projects may be categorized in various ways to identify appropriate methods of efficient project management. Some examples of these project categories are as follows: a) by duration, for example three months or ten years; b) by total cost, for example £20,000 or £6 billion; c) by complexity, for example straight sequence of simple activities or highly interrelated, multi-organizational, multi-disciplined; d) by method of operating, for example in-house projects, contracted-out or a combination of both; e) by technical, organizational and administrative features as follows: 1) strategic long term; 2) research and development (R & D); 3) administrative and procedural; 4) capital plant manufacture; 5) major engineering works on local and/or dispersed sites; 6) planning and controlling changeovers; 7) one-off or repetitive building construction; 8) new product introduction;

42

5.3 Project phasing 5.3.1 General Any project, irrespective of size and complexity, will naturally move through a series of distinct phases between its conception and termination. In large projects the phases should be formally identified and separated to enable effective management of the project. Where commitment of substantial resources is required, authorization may be limited and need to be reconfirmed at specific milestones. For small projects the phases are usually less formal, but may still need to be identified, for example, at management reviews. Figure 9 shows a project phase structure that covers the project whole life cycle.

5.4 Project phase sequence Projects of any significant size, duration or cost should benefit from phasing into sequential blocks of related activities. There are a minimum of five fundamental project phases, namely conception, feasibility, implementation, operation and termination, that can be identified in all projects. The points between phases are often referred to as milestones and they provide a natural opportunity to review, record and report project progress before going forward to the next phase. Checks should be made at each milestone to ensure that the previous phase has been satisfactorily completed and that the project objectives are being fully achieved. Depending on the results, a decision on whether to proceed, modify or stop the project should be taken; in this respect it may be necessary to obtain authorization from the sponsor. All projects should normally have some preparatory work before they are formally started and it is advisable to appoint a manager possibly in a part-time capacity, at the earliest opportunity, to co-ordinate such work. This manager may then naturally progress into the role of project manager when the project is formally authorized.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Projects differ from other enterprises in several ways, in particular by their transient and unique nature. The principal features that characterize projects include the following: a) their duration is usually predetermined (finite) with definite start and termination dates specified; b) what happens during the execution of a project invariably affects the subsequent deliverables; c) the project organization is often temporary and may change from one phase to the next during the execution of the project; d) all projects will contain some risk and uncertainty; e) most projects are non-repetitive; they might also include some essentially unique feature or the use of technologies beyond the current state of the art; f) and finally, although projects are a contained set of tasks they are seldom carried out in isolation, but interact with other projects and organizations; their structures and systems are interactive organizationally, technically, economically and socially.

9) major overhauls and planned maintenance; 10) production planning; 11) emergency planning; 12) plant commissioning and/or operation; 13) information technology software; 14) office or factory relocation.

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 5

BS 6079-1:2000

Figure 9 — Project management life cycle Organizations and sectors of industry tend to develop project life cycles that are phased to enable the use of an agreed methodology between interested parties. In most cases these phases share many features of, and are therefore comparable to, the generic life cycle described in Figure 9. Table 3 gives some examples of project phases that are used in a wide range of industries and the public sector.

© BSI 01-2000

5.5 Description of phase content 5.5.1 General The five basic phases described in 5.4 may be further subdivided into stages depending on the size, complexity and nature of planned activities, the size and nature of the project. This is particularly true of the implementation phase that could, for example, include product definition, design, development, production and installation stages. Significant milestones, such as project authorization and handover may also be indicated. The content of a typical industrial project is described in 5.5.2 to 5.5.9.

43

Section 5

BS 6079-1:2000

5.5.2 Conception phase

44

5.5.3 Concept-feasibility phase transfer milestone At this milestone the project sponsor should apply to the appropriate level of management for authorization to enter the feasibility phase. Development of the concept into a feasible project will almost certainly require the commitment and use of funds and resources. 5.5.4 Feasibility phase The objective of this phase is to establish technical and financial feasibility and, where appropriate, commercial feasibility. The studies, experiments and results of test programmes, the initial estimates and appraisals of cost, timescales and risk, the demand on resources and the impact upon incremental revenues, should then be used to forecast the commercial or social benefits to be expected from the project. Failure to identify inherent deficiencies in a project at this stage can have extensive adverse effects in later phases. It is, therefore, important to invest adequate effort in clearly defining the work to be carried out in the feasibility study. Work done in the feasibility phase may be confined to paper assessments and evaluation, but technical and experimental work, including modelling, should be carried out where validation of a basic concept or identification of a technical problem is required. The following work should be completed before a positive recommendation to proceed with the project can be contemplated: a) a technical study to see if the concepts are practical and can be developed into a useful working product or service; b) a commercial and/or cost-benefit analysis; c) market research to determine probable demand and pricing sensitivity of the proposed product or service; d) preliminary estimates of the financial implications of the project, including an assessment of the probable income generated and the operational costs such as production, distribution and marketing.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Managers in enterprises should be constantly looking for opportunities to improve the performance of their organizations. Initial ideas are by their nature generally vague and uncertain, but may have sufficient interest to merit further investigation. Concepts that are considered worthy of serious consideration are then taken to the next phase that will test the feasibility of the ideas before a full scale project implementation programme is launched. Concept formulation is usually the first phase of a project life cycle and should cover the period from the emergence of an idea for a project to an initial formal statement of a user’s or sponsor’s needs. Ideas for new projects might be expanded by exchanges of views between the customer, sponsor and if necessary specialist advisors; they are derived from factors such as: a) a change in policy requiring a new capability; b) the identification of a new actual or latent requirement; c) outputs from research programme offering new means of meeting a requirement or providing a new capability; d) replacement of an obsolescent system or an advance in technology; e) correction of a deficiency in an existing product or service identified in operation, training or research; f) response to a new opportunity opened up by a competitor; g) an agreed perception of a need emerging from discussions with customers or other areas of the organization; h) work being done on an existing project that stimulates the idea for its successor, or some new utilization. During the conception phase the first basic ideas on how to create or satisfy a need or solve a particular problem should be generated and investigated. The conception phase should be a period when free thinking and the involvement of potential stakeholders is encouraged to generate and then build upon many new ideas and solutions.

A functional department or small team of specialists and researchers may manage the tasks until it is deemed that commissioning a full scale project is justified. Although it is not essential to formally appoint the project manager until the project reaches a more advanced stage, a firm candidate for the post needs to be identified at the earliest opportunity. This person should be consulted during the planning and decision process, pending formal appointment, perhaps on a part-time basis.

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 5

These data have to be accurate enough to gauge the acceptability of the project to either commerce or society. If this hurdle is passed, further work should be undertaken to complete a full technical and financial evaluation. The output of the feasibility phase should be a written report typically containing the following information: e) a technical appraisal of alternative solutions investigated including the results of any research or experiments; f) an evaluation of the preferred solution(s) showing in broad terms how the project objectives could be met and an outline description of the characteristics, benefits and features of the preferred proposal; g) a statement of any identified areas of scientific, technical or social difficulty and any special steps needed to overcome these, with an assessment of the risks involved; h) detailed plans, including specifications, for the implementation phase and plans for subsequent phases; i) estimates, as thorough and realistic as necessary, of the likely time and costs for development and delivery of a product or establishment of a service together with estimates of support costs. Costs of options should be included as necessary; j) an assessment of other resources required; k) operational considerations and potential for future enhancements; l) end-of-life disposal methods and costs. The sponsor should decide from an evaluation whether to seek further information or to recommend management to authorize the project moving into the implementation phase. 5.5.5 Project authorization milestone 5.5.5.1 General Formal authorization is needed to ensure that funds and resources can be made available and committed to the project. The authorization process usually has three stages: evaluation and application followed by formal authorization. The authorizing body should be informed of any potential risks and disadvantages so that a balanced decision can be made about the project’s future. No substantial work, commitment of resources or expenditure should be permitted without prior authorization. Small projects may be approved by a senior manager, but major projects need to be submitted to the top management level for authorization. Applications should be presented in writing, in a standard form, for signature by the authorizing body.

© BSI 01-2000

BS 6079-1:2000

Authorization may be conditional upon time and expenditure limits, satisfactory progress reports and further applications for authorization at specified stages of implementation. 5.5.5.2 Evaluation The evaluation should include a forecast of the financial impact of the project in terms of its probable costs and benefits. Because, with few exceptions, the organization will incur significant costs long before the benefits of the project are realized, tight cost controls should be exercised throughout. Where a project has a life of several years or more, the estimated cash flow should be discounted, to offset interest cost factors and derive an estimate of net cash surplus at net present value (NPV) that may be directly compared with the original investment. The evaluation should assess whole life cycle costs taking account of, for example, major cost implications, such as those in a manufacturing environment where the build-up and financing of tooling, raw materials, manufacturing stock and marketing efforts will consume cash well before any income is received. With certain types of project, such as those in the power industry, the appraisal should allow for decommissioning, and/or disposal costs that will arise after operations cease. In other words the financial case should encompass all aspects of the project life cycle. It is not enough just to know the respective totals of income and expenditure. The financial and cash flow information should generally reflect the timing of the various operations and may be presented as a plan or network; information regarding the timing of the expected cash outflows and inflows is essential. The intervals used in the financial plans and assessment will reflect the size and complexity of the project, ranging from perhaps monthly on small schemes, to yearly for the very long term projects. In undertaking an evaluation it is essential that the sensitivity of the project to the various risks is properly considered so that the authorizing body has a clear idea of the range of results that could be expected. For complex projects a risk management plan is essential and should be maintained throughout the duration of the project. There is, for example, a particular requirement for risk analysis in those projects where there is a high research element and a significant chance of failure, such as the development of pharmaceuticals.

45

Section 5

BS 6079-1:2000

5.5.5.3 Application The project sponsor should make a formal application for approval of a project before commencement of any substantial work, commitment of resources or expenditure. Applications for major projects need to be comprehensive and realistic, they should be presented in writing, in a standard form, for signature by the authorizing body. The quality and content of the application can have a significant bearing on whether or not the project is authorized. An application should contain the following types of information: a) a brief written description of the project and its benefits, using illustrations and models where appropriate; b) financial data concerning the cost of delivering the project, if necessary broken down by phase; c) the expected revenues, operating costs, projected return on capital employed and cost-benefit analysis where applicable; d) the human and physical resources needed; e) a realistic assessment of the technical and financial risks involved; f) a forecast of the effect of the project upon the operation and strategic plans of the sponsoring organization; g) a recommended plan of action; h) the signatures of the principal stakeholders as a commitment to deliver the project in accordance with the projected time, cost and performance criteria. 5.5.5.4 Formal authorization Given an evaluation that is satisfactory and within the existing policy constraints of the organization, an authorization to start the project implementation phase should follow. It may be the project sponsor or senior managers who will need to be satisfied that all the financial, technical and other relevant evaluation data have been taken into consideration to provide an audit trail and a clear and unambiguous way ahead. This information should have been properly defined and adequately documented in the application.

46

It is usually the sponsor or project manager who should present the case for the project to the authorising authority. In most organizations there will be several levels of authorization, each management level having authority to approve capital expenditure to a preset financial limit. Authorization for larger expenditures generally moves higher up the management hierarchy with ultimately all major projects requiring authorization by the main board of directors, or in the case of the public sector, such authorization would be by an approving committee, HM Treasury and the Minister of State. The splitting of a large project into smaller projects, so that authorization can be given by a lower level of management, should not be condoned; this practice is ultimately counter-productive. After due consideration, the authorizing body needs to decide whether the project should proceed or not, given the funding facilities and competing demands for finance, human and physical resources. The authorization may be conditional upon time and expenditure limits and receipt of satisfactory progress reports. Further applications for authorization may be required at specified stages of implementation, e.g. during the definition stage when a more comprehensive evaluation should be completed. 5.5.6 Implementation phase Having secured a formal authorization to proceed with the venture, the project manager should initiate the practical work needed to bring the project to fruition. The implementation phase may need to be fragmented into several stages, depending upon the nature, size and complexity of the implementation tasks. These stages may encompass, for example, the following major tasks: a) further definition; b) design; c) development; d) procurement; e) manufacture, construction or assembly; f) physical completion, commissioning and acceptance testing. During the implementation phase, a comparison of the physical and financial progress against plan should be made at predetermined intervals. Assessments of the probability of completing the project to time, cost and performance parameters should be made at predetermined intervals and corrective action initiated or progressed as necessary (see Figure 10).

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

It is necessary to make the most sensible use of all the data available while recognizing that the financial evaluation, although a major element, is only one aspect that should be considered when deciding to approve or reject a project application. In certain situations the readily quantifiable cost benefits will be augmented by real but intangible benefits and as the impact of projects spreads across more functions the more elusive benefits will need to be identified even if measurement is difficult.

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Section 5

BS 6079-1:2000

Planning for implementation is a key part of the project definition and development stages. This is essential not only to ensure a smooth transition from the feasibility study to implementation, but also to ensure that the final product conforms to the end user’s requirements. For example products should be designed for ease of production, use and maintenance and be dependable in service. Before commencement of implementation, development should have reached the point where there is sufficient confidence that a standard acceptable to the user can be achieved.

It is seldom possible to achieve a clear cut transition from the development stage into production. Usually, for example, it is necessary to order some materials and tooling for production or recruit and train staff in parallel with the last stages of development to ensure the smooth transition and the emergence of a product or service. This involves technical, financial and other risks that need to be quantified and the implications assessed. The project management team should identify those risks and advise on alternative courses. Early implementation commitments should normally be entered only on a stage by stage release basis so that the risk is minimized; the use of configuration management becomes important here.

Figure 10 — Periodic estimate of the project cost and finishing date

© BSI 01-2000

47

Section 5

BS 6079-1:2000

5.5.7 Handover milestone

5.5.8 Operation phase Operation is normally a set of recurrent activities characterized by a relatively low rate of change and is usually the responsibility of a functional manager. The main activities in the operational phase, besides the actual use of the project deliverables, are as follows: a) the marketing and sale of products and services; b) performance monitoring

48

5.5.9 Termination phase Termination usually refers to the end of a project; this point, for a project team, could occur when the responsibility is handed over to an operational organization, a customer or when the project is discontinued at the end of its useful life. It may occur at an earlier stage in the life of the project if there is a failure to meet the necessary cost, time, performance or quality criteria. The final phase of the project cycle may involve the disposal of equipment, the withdrawal of a service or the achievement of the project objective. It is the responsibility of the sponsor or owner of the project deliverables to decide the timing of the disposal of obsolescent or surplus hardware, software and resources, and inform users that a product, service or process has been withdrawn. Adequate effort should be expended to ensure that optimum solutions for disposal are found. The final task should be the preparation of an analysis of the whole project and the documentation of its complete life cycle history. The history of the project should give valuable guidance to others who are embarking on new projects; provide lessons and examples for newcomers and reference documentation for the owners of any remains of the project. The importance of this exercise cannot be over-emphasized for reducing risks in the planning and execution of future project work and handling any issues that might arise, for example, following the disposal of scrap. NOTE The project life cycle may extend over many years and the final report may be written by staff who were not members of the original project team. In this case relevant information from the project handover and acceptance reports should be referred to as necessary.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

At the conclusion of the project implementation phase the product or service should be handed over to the customer; this may involve a commissioning activity plus formal acceptance procedures. Handover may be a phase in its own right for a large project, or otherwise a key milestone. The handover may be instantaneous or a gradual process taking a considerable period to complete depending on the nature of the deliverables. The project manager should be required to demonstrate that the deliverables meet the specification and previously agreed quality. The handover needs to be carefully monitored to ensure that rapid corrective action is taken with respect to potential and actual problems. As the transfer of authority from the project team to the user takes place, unexpected changes in the project may be introduced that cause it to fail to meet the specification in some way, thus exposing the project sponsor to financial penalties or legal action. As a consequence of handover the project manager and team may be redeployed to functional departments or alternative projects. The handover needs to be documented by the project manager and the recipient of the deliverables as follows. a) Before relinquishing responsibilities, the project manager should prepare a report detailing the history of the project and its accomplishments, compared with what was promised at the time of authorization. This handover report should also give reasons for any significant deviations from the project plan and specifications. As well as providing a justification for handover, the report should also be of benefit to future projects, in helping avoid common problems and the tendency to re-invent the wheel. b) Before accepting the project, the customer should prepare a report that explains the circumstances and conditions under which the project is being accepted. This acceptance report should also give details of performance shortfalls, areas of dispute, payment retentions and action needed to rectify specific problems, if appropriate.

c) further development, as necessary, where there are initial performance limitations; d) the setting up and implementation of post-design services; e) in-use support consisting of the provision of training aids, spares, repair, maintenance, modification/enhancement programmes and upkeep facilities. For certain projects the cost of plant shutdown and decommissioning will be a major expense that should be assessed at the beginning and throughout the project life cycle. Provision for plant shutdown and decommissioning should be made when deciding pricing strategies for products made by plant during its operational phase.

Section 5

BS 6079-1:2000

Table 3 — List of typical project phases Phase/Stage

Conception

Description

Usually the start of project work, by translation of ideas and/or identifying needs.

Pilot study Research

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Initiation Feasibility

Establishing the commercial, technical, social and environmental feasibility of project. Estimating project cost and timescale, also identifying risks and health and safety issues; determining the support and capability of prospective contractors.

Evaluation

Evaluation of the whole or part of the project between phases; prospective contractor preparing tender.

Application

Making a formal proposal for authorization of a project.

Authorization

Getting agreement to proceed with project in whole or in part; by obtaining acceptance of a tender by the customer or board.

Definition

Verifying the approach; developing the specification.

Development

Designing a product that conforms to the specification.

Implementation

This phase can include several individual stages: design, procurement, construction, commissioning etc.

Realization Production Manufacture Fabrication Construction Works Installation

Installing the plant/product and making it work.

Commissioning Launch

Open up sales to a pilot area, then whole market.

Introduction Branch-Out Shipping Handover

Transferring responsibility for the project to a customer or functional department.

Acceptance In-use

Maintaining the product.

In-service Operational Termination

Decommissioning the product; disposal of the project.

Disposal Final report

© BSI 01-2000

The last act of project manager, to document the history of the project.

49

BS 6079-1:2000

Annex A (informative) Project management methodology: cost/schedule control systems criteria (C/SCSC)1)

1)

The text of this annex is based upon Part 11, Section B, Attachment 1 of the Department of Defense Instruction Number 5000.2, dated February 1993 and titled “Defense Acquisition Management Policies and Procedures”.

50

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

A.1 General In the 1960s the United States Department of Defense introduced 35 principles of good project management practice to be adopted by government project managers for large scale government contracts. These cost/schedule control systems criteria, known as C/SCSC or C-Spec embody a methodology aimed at integrating cost, schedule and performance measurement data with delivery of a product. The criteria describe the attributes of a project management system but do not prescribe the system itself. A number of national governments have adopted these criteria as are an increasing number of contractors, particularly within the military industrial sector. C/SCSC are also being adopted by companies outside the military sector. The criteria are quoted as “The contractor’s management control systems shall include policies, procedures and methods that are designed to ensure that they will accomplish the considerations reflected herein.” A.2 Organisation a) Define all authorized work and related resources to meet the requirements of the contract, using the contract work breakdown structure (WBS). b) Identify the internal organizational elements and the major subcontractors responsible for accomplishing the authorized work. c) Provide for the integration of the contractor’s planning, scheduling, budgeting, work authorization and cost accumulation systems with each other, the contract work breakdown structure, and the organizational structure. d) Identify managerial positions responsible for controlling overhead (indirect costs). e) Provide for the integration of the contract work breakdown structure with the contractor’s functional organizational structure in a manner that permits cost and schedule performance measurement for contract work breakdown structure and organizational elements.

A.3 Planning and budgeting a) Schedule the authorised work in a manner which describes the sequence of work and identifies the significant task interdependencies required to meet the development, production and delivery requirements of the contract. b) Identify physical products, milestones, technical performance goals, or other indicators that will be used to measure output. c) Establish and maintain a time-phased budget baseline at the cost account level against which contract performance can be measured. Initial budgets established for this purpose will be based on the negotiated target cost. Any other amount used for performance measurement purposes should be formally recognized by both the contractor and the Government. d) Establish budgets for all authorised work with separate identification of cost elements (labour, material, etc.). e) As far as possible identify the authorized work in discrete, short span work packages. Establish budgets for this work in terms of money, hours, or other measurable units. Where the entire cost account can not be subdivided into detailed work packages, identify long term effort in larger planning packages for budget and scheduling purposes. f) Ensure that the sum of all work package budgets, plus planning package budgets within a cost account, equals the cost account budget. g) Identify relationships of budgets or standards in work authorization systems to budgets for work packages. h) Identify and control level-of-effort activity by time phased budgets established for this purpose. Only that effort which cannot be identified as discrete, short span work packages or as apportioned effort may be classed as level-of-effort. i) Establish overhead budgets for the total costs of each significant organizational component, these expenses will become indirect costs. Reflect in the contract budgets at the appropriate level the amounts in overhead pools that are planned to be allocated to the contract as indirect costs. j) Identify management reserves and undistributed budget. k) Provide that the contract target cost plus the estimated cost of authorized but unpriced work is reconciled with the sum of all internal contract budgets and management reserves.

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

Annex A

A.4 Accounting a) Record direct costs, on an applied or other acceptable basis, in a manner consistent with the budgets in a formal system that is controlled by the general books of account. b) Summarize direct costs from cost accounts into the work breakdown structure without allocation of a single cost account to two or more work breakdown structure elements. c) Summarize direct costs from the cost accounts into the contractor’s functional organizational elements without allocation of a single cost account to two or more organisational elements. d) Record all indirect costs which will be allocated to the contract. e) Identify the basis for allocating the cost of apportioned effort. f) Identify unit costs, equivalent unit costs, or lot costs as applicable. g) The contractor’s material accounting system will provide for: 1) accurate cost accumulation and assignment of costs to cost accounts in a manner consistent with the budgets using recognized, acceptable costing techniques; 2) determination of price variances by comparing planned versus actual commitments; 3) cost performance measurement at the point in time most suitable for the category of material involved, but no earlier than the time of actual receipt of material; 4) determination of cost variances attributable to the excess usage of material; 5) determination of unit or lot costs when applicable. 6) full accountability for all material purchased for the contract including the residual inventory.

© BSI 01-2000

BS 6079-1:2000

A.5 Analysis a) At the cost account level on a monthly basis using data from, or reconcilable with, the accounting system: 1) compare budgeted cost for work scheduled and budgeted cost of work performed; 2) compare budgeted cost for work performed and actual (applied where appropriate) direct costs for the same work; and 3) identify variances resulting from the comparisons between the budgeted cost for work scheduled and the budgeted cost for work performed and between the budgeted cost for work performed and actual or applied direct costs, classified in terms of labour, material, or other appropriate elements together with the reasons for significant variances. b) Identify on a monthly basis, in the detail needed by management for effective control, budgeted indirect costs, actual indirect costs, and cost variances with the reasons for significant variances. c) Summarize the data elements and associated variances listed in A.4 g)1) and 2), through the contractor organization and work breakdown structure to the reporting level specified in the contract. d) Identify significant differences on a monthly basis between planned and actual schedule accomplishment and the reasons. e) Identify managerial actions taken as a result of criteria items in A.4 a) to A.4 d). f) Based on performance to date, on commitment values for material, and on estimates of future conditions, develop revised estimates of cost at completion for work breakdown structure elements identified in the contract. Compare these with the contract budget base and the latest estimate of funds requirement reported to the Government.

51

BS 6079-1:2000

52

d) Prevent revisions to the contract budget base except for Government directed changes to contractual effort. e) Document internally the changes to the performance measurement baseline and notify expeditiously the procuring activity through prescribed procedures. f) Provide the contracting officer and the contracting officer’s authorized representatives with access to the information and supporting documentation necessary to demonstrate compliance with the cost/schedule control systems criteria.

© BSI 01-2000

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

A.6 Revisions and access to data a) Incorporate contract changes expeditiously, recording the effects of such changes on budgets and schedules. In the directed effort prior to negotiation of a change, base such revisions on the amount estimated and budgeted to the functional organizations. b) Reconcile original budgets for those elements of the work breakdown structure identified as priced line items in the contract, and for those elements at the lowest level in the programme work breakdown structure, with current performance measurement budgets in terms of changes to the authorized work and internal re-planning in the detail needed by management for effective control. c) Prohibit retroactive changes to records pertaining to work performed that would change previously reported amounts for direct costs, indirect costs, or budgets, except for correction of errors and routine accounting adjustments.

Annex A

BS 6079-1:2000

List of references Normative references BSI publications

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

BRITISH STANDARDS INSTITUTION, London

BS 3811:1993, Glossary of terms used in terotechnology. BS 4335:1987, Glossary of terms used in project network techniques. BS 7000, Design management systems. BS 7000-10:1995, Glossary of terms used in design management. BS EN ISO 8402:1995, Quality management and quality assurance – Vocabulary.

Informative references BS 5760, Reliability of systems, equipment and components. BS 5760-1:1985, Guide to reliability and maintainability programme management.

© BSI 01-2000

BS 6079-1:2000

BSI — British Standards Institution

BSI 389 Chiswick High Road London W4 4AL

Licensed Copy: Giorgio Cavalieri, ALSTOM, 29-Aug-00, Uncontrolled Copy. © BSI

BSI is the independent national body responsible for preparing British Standards. It presents the UK view on standards in Europe and at the international level. It is incorporated by Royal Charter. Revisions British Standards are updated by amendment or revision. Users of British Standards should make sure that they possess the latest amendments or editions. It is the constant aim of BSI to improve the quality of our products and services. We would be grateful if anyone finding an inaccuracy or ambiguity while using this British Standard would inform the Secretary of the technical committee responsible, the identity of which can be found on the inside front cover. Tel: 0181 996 9000. Fax: 0181 996 7400. BSI offers members an individual updating service called PLUS which ensures that subscribers automatically receive the latest editions of standards. Buying standards Orders for all BSI, international and foreign standards publications should be addressed to Customer Services. Tel: 0181 996 7000. Fax: 0181 996 7001. In response to orders for international standards, it is BSI policy to supply the BSI implementation of those that have been published as British Standards, unless otherwise requested. Information on standards BSI provides a wide range of information on national, European and international standards through its Library and its Technical Help to Exporters Service. Various BSI electronic information services are also available which give details on all its products and services. Contact the Information Centre. Tel: 0181 996 7111. Fax: 0181 996 7048. Subscribing members of BSI are kept up to date with standards developments and receive substantial discounts on the purchase price of standards. For details of these and other benefits contact Membership Administration. Tel: 0181 996 7002. Fax: 0181 996 7001. Copyright Copyright subsists in all BSI publications. BSI also holds the copyright, in the UK, of the publications of the international standardization bodies. Except as permitted under the Copyright, Designs and Patents Act 1988 no extract may be reproduced, stored in a retrieval system or transmitted in any form or by any means – electronic, photocopying, recording or otherwise – without prior written permission from BSI. This does not preclude the free use, in the course of implementing the standard, of necessary details such as symbols, and size, type or grade designations. If these details are to be used for any other purpose than implementation then the prior written permission of BSI must be obtained. If permission is granted, the terms may include royalty payments or a licensing agreement. Details and advice can be obtained from the Copyright Manager. Tel: 0181 996 7070.