1 Ringbourne Management Ltd - PowerPoint PPT Presentation

Title: 1 Ringbourne Management Ltd


1

• An Overview

2
Prince 2 Overview - Agenda

• Why use a method
• What is Prince
• Components
• Processes

3
Why use a project management method?

• Project failures are all too common some make
  the headlines, the vast majority are quickly
  forgotten. The reasons for failure are wide and
  varied. Some common causes are
• lack of co-ordination of resources and activities
• lack of communication with interested parties,
  leading to products being delivered which are not
  what the Customer wanted
• poor estimation of duration and costs, leading to
  projects taking more time and costing more money
  than expected
• insufficient measurables
• inadequate planning of resources, activities, and
  scheduling
• lack of control over progress so that projects do
  not reveal their exact status until too late
• lack of quality control, resulting in the
  delivery of products that are unacceptable or
  unusable.

4
Why use a project management method?

• Without a project management method,
• those who commission a project, those who manage
  it and those who work on it will have different
  ideas about how things should be organised and
  when the different aspects of the project will be
  completed
• those involved will not be clear about how much
  responsibility, authority and accountability they
  have, and as a result, there will often be
  confusion surrounding the project
• projects are rarely completed on time and within
  acceptable cost this is especially true of large
  projects.

5
Why use a project management method?

• A good project management method will guide the
  project through a controlled, well-managed,
  visible set of activities to achieve the desired
  results. PRINCE adopts the principles of good
  project management to avoid the problems
  identified above and so helps to achieve
  successful projects. These principles are
• a project is a finite process with a definite
  start and end
• projects always need to be managed in order to be
  successful
• for genuine commitment to the project, all
  parties must be clear about why the project is
  needed, what it is intended to achieve, how the
  outcome is to be achieved, and what their
  responsibilities are in that achievement.

6
What is PRINCE?

• PRINCE (PRojects IN Controlled Environments) is a
  structured method for effective project
  management
• The key features of PRINCE are
• its focus on business justification
• a defined organisation structure for the project
  management team
• its product-based planning approach
• its emphasis on dividing the project into
  manageable and controllable stages
• its flexibility to be applied at a level
  appropriate to the project.

7
What does PRINCE provide?

• PRINCE provides projects with
• a controlled and organised start, middle and end
• regular reviews of progress against plan and
  against the Business Case
• flexible decision points
• automatic management control of any deviations
  from the plan
• the involvement of management and stakeholders at
  the right time and place during the project
• good communication channels between the project,
  project management, and the rest of the
  organisation.

8
What does PRINCE provide?

• Project Managers using PRINCE are able to
• establish terms of reference as a pre-requisite
  to the start of a project
• use a defined structure for delegation, authority
  and communication
• divide the project into manageable stages for
  more accurate planning
• ensure resource commitment from management is
  part of any approval to proceed
• provide regular but brief management reports
• keep meetings with management and stakeholders to
  a minimum but at the vital points in the project

9
What does PRINCE provide?

• Those who will be directly involved with using
  the results of a project are able to
• participate in all the decision-making on a
  project
• if desired, be fully involved in day-to-day
  progress
• participate in quality checks throughout the
  project
• ensure their requirements are being adequately
  satisfied

10
(No Transcript)
11
8 Components

• Organisation
• Structure and Role Descriptions
• Plans
• Products, Activities and Resources
• Controls
• Management, Team and Quality
• Stages
• Management and Technical
• Management of Risk
• Risk Assessment and Management
• Quality in a Project Environment
• Quality requirements and Response
• Configuration Management
• Tracking Products and Documentation
• Change Control
• Capture and Assessment

12
8 Processes
13
8 Processes

• There are eight processes, each made up of a
  collection of processes. The processes are
• Starting up a Project (SU)
• Gathering basic information
• Initiating a Project (IP)
• Getting agreement that we know what we are doing
• Controlling a Stage (CS) and Managing Product
  Delivery (MP)
• Controlling development
• Managing Stage Boundaries (SB)
• Taking stock and getting ready for the next part
  of the project.
• Planning (PL).
• Common planning steps
• Directing a Project (DP)
• Senior management taking decisions at key points
  of the project
• Closing a Project (CP)
• Making sure the project has done the job

14
Summary of the Processes
15
Component 1 - Organisation
16
Roles and ResponsibilitiesProject Board

• The Project Board is appointed by corporate or
  programme management to provide overall direction
  and management of the project. The Project Board
  is accountable for the success of the project,
  and has responsibility and authority for the
  project within the remit (the Project Mandate)
  set by corporate or programme management.
• The Project Board is the projects voice to the
  outside world and is responsible for any
  publicity or other dissemination of information
  about the project.
• Specific responsibilities
• The Project Board approves all major plans and
  authorises any major deviation from agreed stage
  plans. It is the authority which signs off the
  completion of each stage as well as authorises
  the start of the next stage. It ensures that
  required resources are committed and arbitrates
  on any conflicts within the project or negotiates
  a solution to any problems between the project
  and external bodies. In addition, it approves the
  appointment and responsibilities of the Project
  Manager and any delegation of its project
  assurance responsibilities.

17
Roles and ResponsibilitiesExecutive / Sponsor

• The Executive is ultimately responsible for the
  project, supported by the Senior User and Senior
  Supplier. The Executive has to ensure that the
  project is value for money, ensuring a
  cost-conscious approach to the project, balancing
  the demands of business, User and Supplier.
• Throughout the project the Executive owns the
  Business Case.
• The Executive is responsible for overall business
  assurance of the project, that is that it remains
  on target to deliver products which will achieve
  the expected business benefits, and the project
  will complete within its agreed tolerances for
  budget and schedule.
• If the project warrants it, the Executive may
  delegate some responsibility for the above
  business assurance functions.

18
Roles and ResponsibilitiesSenior User

• The Senior User is responsible for the
  specification of the needs of all those who will
  use the final product(s), User liaison with the
  project team and for monitoring that the solution
  will meet those needs within the constraints of
  the Business Case in terms of quality,
  functionality and ease of use.
• The role represents the interests of all those
  who will use the final product(s) of the project,
  those for whom the product will achieve an
  objective, or those who will use the product to
  deliver benefits. The Senior User role commits
  User resources and monitors products against
  requirements. This role may require more than one
  person to cover all the User interests. For the
  sake of effectiveness the role should not be
  split between too many people.
• Where the projects size, complexity or
  importance warrants it, the Senior User may
  delegate the responsibility and authority for
  some of the assurance responsibilities to a User
  assurance role.

19
Roles and ResponsibilitiesSenior Supplier

• Represents the interests of those designing,
  developing, facilitating, procuring,
  implementing, (and possibly operating and
  maintaining) the project products. The Senior
  Supplier role must have the authority to commit
  or acquire Supplier resources required
• It should be noted that in some environments the
  Customer may share design authority or have a
  major say in it.
• If necessary more than one person may be required
  to represent the Suppliers
• If warranted, some of their assurance
  responsibility may be delegated to separate
  supplier assurance personnel. Depending on the
  particular Customer/Supplier environment of a
  project, the Customer may also wish to appoint
  people to specialist assurance roles.

20
Roles and ResponsibilitiesProject Manager (1)
21
Roles and ResponsibilitiesProject Manager (2)

• The Project Manager is given the authority to run
  the project on a day-to-day basis on behalf of
  the Project Board within the constraints laid
  down by the board.
• In a Customer/Supplier environment the Project
  Manager will normally come from the Customer
  organisation, but there will be projects where
  the Project Manager comes from the Supplier. A
  typical example would be an in-house project,
  where the Customer and Supplier belong to the
  same organisation. In the latter case the
  Customer may appoint a Project Director or
  Controller to be its day-to-day liaison with
  the Project Manager.
• The Project Managers prime responsibility is to
  ensure that the project produces the required
  products, to the required standard of quality and
  within the specified constraints of time and
  cost. The Project Manager is also responsible for
  the project producing a result which is capable
  of achieving the benefits defined in the Project
  Initiation Document.

22
Roles and ResponsibilitiesHints and Tips for the
Project Manager (3)

• It may be beneficial to employ high quality
  people part-time rather than lesser quality
  people full-time.
• It is important to remember that Prince assumes
  the Project Manager will be from the Customer. It
  is possible that the Project Manager may be from
  the Supplier.
• Where the Project Manager does not have direct
  authority over personnel required to work on the
  project, it is strongly recommended that the
  agreement of the appropriate managers is obtained
  (and maintained throughout the project) for the
  commitment of their personnel.
• Remember that the Project Managers role is to
  manage the work, not do it.
• The Project Manager must avoid becoming involved
  in low-level detail to the extent that sight is
  lost of the big picture, that is what is going
  on in every part of the project.
• Different Project Manager attributes are needed
  for different types of project.
• In tailoring the Project Manager and Team Manager
  roles in a Customer/Supplier environment,
  consideration must be given to whether it is
  acceptable for Customer resources to be managed
  by a Supplier, or Supplier resources to be
  managed by the Customer representative. If such a
  situation is permitted, the division of
  management responsibilities for human resource
  management should be made clear, for example
  appraisals, promotion and training.

23
Roles and ResponsibilitiesTeam Manager

• The use of this role is optional. The Project
  Manager may find that it is beneficial to
  delegate the authority and responsibility for
  planning the creation of certain products and
  managing a team of specialists to produce those
  products. There are many reasons why it may be
  decided to employ this role. Some of these are
  the size of the project, the particular
  specialist skills or knowledge needed for certain
  products, geographical location of some team
  members, and the preferences of the Project
  Board.
• The Team Managers prime responsibility is to
  ensure production of those products defined by
  the Project Manager to an appropriate quality, in
  a timescale and at a cost acceptable to the
  Project Board. The Team Manager reports to and
  takes direction from the Project Manager.
• The use of this role should be discussed by the
  Project Manager with the Project Board and, if
  the role is required, planned at Project
  Initiation time.

24
Roles and ResponsibilitiesProject Assurance (1)

• The Project Board members do not work full-time
  on the project, therefore they place a great deal
  of reliance on the Project Manager. Although they
  receive regular reports from the Project Manager,
  there may always be the questions at the back of
  their minds, Are things really going as well as
  we are being told?, Are any problems being
  hidden from us?, Is the solution going to be
  what we want?, Are we suddenly going to find
  that the project is over-budget or late? There
  are other questions. The Supplier may have a
  quality assurance function charged with the
  responsibility to check that all projects are
  adhering to the Quality System.
• To cater for a small project, PRINCE starts by
  identifying these project assurance functions as
  part of the role of each Project Board member.
  According to the needs and desires of the Project
  Board, any of these assurance responsibilities
  can be delegated, as long as the recipients are
  independent of the Project Manager and the rest
  of the Project Management Team.

25
Roles and ResponsibilitiesProject Assurance (2)

• Each of the assurance roles which is delegated
  may be assigned to one individual or shared. The
  Project Board decides when an assurance role
  needs to be delegated. Any use of assurance roles
  needs to be planned at Initiation Stage,
  otherwise resource usage and costs for assurance
  could easily get out of control.
• There is no stipulation on how many assurance
  roles there must be. Each project should
  determine what support, if any, each Project
  Board role needs to achieve assurance.
• Assurance covers all interests of a project,
  including all business, User and Supplier.

26
Roles and ResponsibilitiesProject Support

• The provision of any project support on a formal
  basis is optional. It is driven by the needs of
  the individual project and Project Manager.
  Project support could be in the form of advice on
  project management tools, guidance and
  administrative services such as filing, and the
  collection of actuals, to one or more related
  projects. Where set up as an official body,
  project support can act as a repository for
  lessons learned, and a central source of
  expertise in specialist support tools.
• One support function which must be considered is
  that of Configuration Management. Depending on
  the project size and environment, there may be a
  need to formalise this, and it quickly becomes a
  task with which the Project Manager cannot cope
  without support.

27
Component 2 - Planning

• Plans are prepared for the Project as a whole,
  for each stage within the project and, optionally
  for the teams work within each Management Stage.
• There is also an Exception planning process to
  handle divergences from the original plan
• Prince 2 method includes techniques for Product
  planning, Activity planning, Resource planning
  and Quality planning.

28
Component 2 - Planning (2)
Plan Text
The Plan Text provides a high-level, overall view
of the plan, summarising its key features
Product Breakdown Structure
Identifying the Products that will be produced by
the Project. The Products will be categorised
under the headings of Specialist, Management
and Quality Products
Product Descriptions
Describing the Products that will be produced by
the Project. There is a prescribed format for
Product Descriptions
Product Flow Diagrams
Describing the relationships that exist between
each Product, and external entities
PERT or Activity Network
Showing the relationships that exist between the
Activities that will be undertaken to create the
Products identified in the Product Breakdown
Structure
Gantt or Timescale Plan
Derived from the PERT Network, this shows when
Activities are planned to start and end. Major
review points (End Stage Assessments) are also
shown on this plan.
29
Component 2 - Planning (3)Product Based
Concerned with planning, monitoring and
reporting - Plans - Reports - Control Docs
Determined by the scope and objectives of the
project
Relating to documents that control the quality of
the outcome - Quality Plan - Issues - Logs
30
Component 2 - Planning (4)Management Products
31
Component 2 - Planning (5)Quality Products
32
Component 2 - Planning (6)Example

• A landscape gardener is asked to design and
  construct the rear garden for a local
  businessman. The area is an acre in size,
  currently waste land filled with post-building
  rubbish, brambles etc.. The businessman says he
  has some ideas about what he wants
• a large patio
• a brick-built barbecue on the patio
• lots of lawn
• flower beds with lots of colourful shrubs and
  flowers
• He will get a gardener in to look after the
  garden when it is finished, so he wants a garden
  shed to be put in a discrete corner of the
  garden, filled with the tools which the gardener
  will need
• All that is known about the businessman is that
  he has a lot of money, but getting money out of
  him can be difficult. The landscape gardener
  decides that he will pin the customer down by
  getting a written specification, then get
  agreement to a design. Because of the tightwad
  reputation, the landscape gardener will ask for
  part payments in advance of those products
  requiring heavy expenditure

33
Component 2 - Planning (7)Specialist Products
Landscaped
garden
Preparation
Construction
Marked
Agreed
Site
Cleared
Mainten-
Design
out
Building
Garden
spec
desc
site
ance
layout
Patio
Lawns
Shed
BBQ
Flower beds
Tools
34
Component 2 - Planning (8)Product Descriptions

• Product Title
• Purpose of the Product
• Compositions
• Derivation
• Format and Presentation
• Allocated to
• Quality Criteria
• Type of Quality Check Required
• People or Skills Required for
• Reviewing the Product
• Testing the Product
• Approving the Product

35
Component 2 - Planning (9)Product Flow Diagram
Contract 1
Site Description
Agreed Specification
Acceptance Criteria
Contract 2
Cleared Site
Approved Design
Marked Out Layout
Patio
Stocked Beds
Tool Shed
Purchased Tools
Lawn
Barbecue
Landscaped Garden
36
Component 2 - Planning (10)Identifying Activities
Contract 1
Agree specification
Document current state
Site Description
Agreed Specification
Define acceptance criteria
Acceptance Criteria
Negotiate contract
Contract 2
Design layout
Clear site
Cleared Site
Approved Design
Mark out layout
Buy paving Dig foundations Build patio
Buy shed Lay shed base Assemble shed
Marked Out Layout
Construct beds Stock beds
Patio
Stocked Beds
Tool Shed
Purchase tools
Prepare lawn
Build barbecue
Purchased Tools
Lawn
Barbecue
Sign off acceptance criteria
Landscaped Garden
37
Component 2 - Planning (11)Product Flow Diagram
Hints and Tips

• At project level the dependencies can be rather
  crude, for example not all elements of major
  product 1 need to be done before any elements of
  major product 2 can start.
• The easiest way to create a flow diagram is to
  put all the specialist products in their required
  sequence and then add the management and quality
  products to the correct point in the flow.
• Post-its on a whiteboard can be an effective way
  of developing a PFD
• A useful way to get started with the flow of
  specialist products is to top and tail the
  diagram, that is put the final product at the
  bottom of a sheet of paper and any products which
  are pre-requisite to starting the work at the top
  (in ellipses)
• If Project Board approvals are listed as
  management products, their later placement in the
  sequence will show where the Stage ends should
  come, if this is not already known.
• The Derivation section of a Product Description
  gives useful information about dependencies.
• It is useful to show the source of any products
  from third parties in the Product Flow Diagram.
• The Project Board may find that the Product Flow
  Diagram and Product Checklist are easy to use to
  check on plan progress.

38
Component 2 - Planning (12)Gantt Chart
39
Component 3 - Controls

• The major controls for the Project Board are
• Project Initiation (Should the project be
  undertaken?)
• End Stage Assessment (Has the stage been
  successful? Is the project still on course? Is
  the Business Case still viable? Are the risks
  still under control? Should the next stage be
  undertaken?)
• Highlight Reports (Regular progress reports
  during a stage)
• Exception Reports (Early warning of any forecast
  deviation beyond tolerance levels)
• Mid Stage Assessment (The Project Board jointly
  consider what action to take in response to a
  forecast deviation)
• Project Closure (Has the project delivered
  everything expected? Are any follow-on actions
  necessary? What lessons have been learned?)
• Work Package Authorisation is a control which the
  Project Manager uses to allocate work to
  individuals or teams. It includes controls on
  quality, time and cost and identifies reporting
  and hand-over requirements. The individuals or
  teams monitor progress through the Work Package
  and report back to the Project Manager via
  Checkpoints

40
Component 4 - Stages

• Stages are partitions of the project with
  decision points. A stage is a collection of
  activities and products whose delivery is managed
  as a unit. As such it is a sub-set of the
  project, and in PRINCE terms it is the element of
  work which the Project Manager is managing on
  behalf of the Project Board at any one time. The
  use of stages in a PRINCE project is mandatory,
  the number of stages is flexible and depends on
  the needs of the project.

Design has been broken into three activities.
Part B falls within Stage 1. Part C of Design and
part D of Training form the second management
stage, and part E of Design is planned to be done
in Stage 3.
41
Component 5 - Management of Risk
42
Component 5 - Management of RiskRisk Analysis

• Risk analysis is essential for effective
  management of risk. It comprises three
  activities
• risk identification, which determines the
  potential risks that could be faced by the
  project
• risk estimation, which determines how important
  each risk is, based on an assessment of its
  likelihood and consequences to the project and
  business
• risk evaluation, which decides whether the level
  of each risk is acceptable or not and, if not,
  what actions can be taken to make it more
  acceptable.
• The actions break into broadly five types
• prevention, where countermeasures are put in
  place which either stop the threat or problem
  from occurring, or which prevent it having any
  impact on the project or business
• reduction, where the actions either reduce the
  likelihood of the risk developing, or limit the
  impact on the project to acceptable levels
• transference, which is a specialist form of risk
  reduction where the impact of the risk is passed
  to a third party via, for instance, an insurance
  policy or penalty clause
• contingency, where actions are planned and
  organised to come into force as and when the risk
  occurs
• acceptance, where the Project Board decides to go
  ahead and accept the possibility that the risk
  might occur (believing that either the risk will
  not occur or the countermeasures are too
  expensive).

43
Component 5 - Management of RiskRisk Management

• Risk management consists of four major
  activities
• planning, which, for the countermeasure actions
  itemised during the risk evaluation activities,
  consists of
• identifying the quantity and type of resources
  required to carry out the actions
• developing a detailed plan of action to be
  included in a Stage Plan
• confirming the desirability of carrying out the
  actions identified during risk evaluation in the
  light of any additional information gained
• obtaining management approval along with all the
  other aspects of the plans being produced
• resourcing, which will identify and assign the
  resources to be used for the work to carry out
  the risk avoidance or amelioration, prevention,
  reduction, transference and contingent actions.
• monitoring, which consists of
• checking that execution of the planned actions is
  having the desired effect on the risks identified
• watching for the early warning signs that a risk
  is developing
• modelling trends, predicting potential risks
• checking that the overall management of risk is
  being applied effectively
• reporting on Risk status, especially on risks
  with extra-project impact
• controlling, which is taking action to ensure
  that the events of the plan really happen.

44
Component 6 - QualityWhat is Quality ?

• Quality is defined in ISO 8402 as the
• totality of characteristics of an entity which
  bear on its ability to satisfy stated and implied
  needs
• Within projects, quality is a question of
  identifying what it is about the projects
  products or services that makes them fit for
  their purpose of satisfying stated needs.
  Projects should not rely on implied needs. These
  lead to uncertainty and, as such, are of little
  use.

45
Component 6 - QualityQuality Expectations

• functional requirements
• performance
• practicability
• security
• compatibility
• reliability
• maintainability
• expandability
• flexibility
• clarity
• comparison to another product
• cost
• implementation date

46
Component 6 - QualityQuality Review

• The objectives of a Quality Review are
• to produce a product which meet business, user
  and specialist requirements
• to assess the conformity of a product against set
  criteria
• to provide a platform for product improvement
• to involve all those who have a vested interest
  in the product
• to spread ownership of the product
• to obtain commitment from all vested interests in
  the product
• to provide a mechanism for management control.

47
Component 6 - QualityThree Steps of a Quality
Review (1)

• Preparation, consisting of
• confirmation of the availability of the nominated
  reviewers and agreement on dates for the return
  of comments and the review itself
• distribution of a copy of the product and its
  Product Description to reviewers where this is
  possible, for instance, if it is a printed
  document. Alternatively, making the product
  available for inspection by the reviewers
• assessment of the product against the quality
  criteria
• entry of the major errors on an Error List
• annotation of minor errors on the product, where
  applicable
• return of the annotated product and Error List to
  the Producer
• a plan of the review meeting, and agreement on
  the agenda

48
Component 6 - QualityThree Steps of a Quality
Review (2)

• Review Meeting, consisting of
• discussion and clarification of each of the major
  errors raised by the reviewers
• agreement of the follow-up appropriate to each
  error
• documentation of the follow-up actions and
  responsibilities
• summary of the actions at the end of the meeting
• agreement on the Quality Review outcome, and
  sign-off of the product, if appropriate.

49
Component 6 - QualityThree Steps of a Quality
Review (3)

• Follow-up, consisting of
• notification to the Team Manager of Quality
  Review results
• a plan of any remedial work required
• sign-off of the product following successful
  remedial work.

50
Component 7 - Configuration MgmtDefinition

• Configuration Management may be thought of as
  product control.
• The construction of a car is a good example of
  the need for Configuration Management.
• What components have to be brought together in
  order to assemble this version of the car?
• What about that recent change to the fascia and
  the redesigned windscreen wipers?
• How can the assemblers be sure that they have the
  correct components?
• The answer is from the records held by
  Configuration Management.
• If a replacement window winder for a five-year
  old model is needed, the cars serial number in
  conjunction with the records kept by
  Configuration Management will ensure that the
  right one is supplied.

51
Component 7 - Configuration MgmtFunctions

• Configuration Management consists of five basic
  functions
• planning - deciding what level of Configuration
  Management will be required by the project and
  planning how this level is to be achieved
• identification - specifying and identifying all
  components of the final product
• control - the ability to agree and freeze
  products and then to make changes only with the
  agreement of appropriate named authorities. Once
  a product has been approved, the motto is
  Nothing moves, nothing changes without
  authorisation
• status accounting - the recording and reporting
  of all current and historical data concerned with
  each product
• verification - a series of reviews and
  configuration audits to ensure that there is
  conformity between all products and the
  authorised state of products as registered in the
  Configuration Management records.

52
Component 7 - Configuration MgmtMethod (1)

• Configuration Management covers the following
  functions
• identifying the individual sub-products of the
  final product
• identifying those products that will be required
  in order to produce other products
• establishing a coding system which will uniquely
  identify each product
• identifying the owner of a product version
• identifying the producer to whom creation or
  amendment of that version of a product has been
  delegated
• recording, monitoring and reporting on the
  current status of each product as it progresses
  through its own specific life-cycle

53
Component 7 - Configuration MgmtMethod (2)

• Configuration Management covers the following
  functions (continued)
• filing all documentation produced during the
  development life of the product
• retention of master copies of relevant completed
  products within the configuration library
• provision of procedures to ensure the safety and
  security aspects of the products and control
  access to them
• distribution of copies of all products and
  recording of holders of product copies
• maintenance of the record of relationships
  between products so that no product is changed
  without being able to check for possible impact
  on related products
• administering change to all products, from
  receipt of Project Issues, through assessment of
  the impact of proposed changes, release of copies
  of products to the eventual receipt of the
  amended versions
• establishment of baselines (is described later)
• performance of configuration audits.

54
Component 8 - Change ControlPurpose

• Changes to specification or scope can potentially
  ruin any project unless they are carefully
  controlled.
• Change is, however, highly likely. The control of
  change means the assessment of the impact of
  potential changes, their importance, their cost
  and a judgmental decision by management on
  whether to include them or not.
• Any approved changes must be reflected in any
  necessary corresponding change to schedule and
  budget.
• In PRINCE all potential changes are dealt with as
  Project Issues.

55
Component 8 - Change ControlProcess (1)

• All changes are treated as types of Project Issue
  and are handled through the same change control
  approach. A Project Issue can be
• a request to change the specification of
  requirements (Request For Change)
• a suggestion to improve one or more of the
  projects products (Request For Change)
• a record of some current or forecast failure to
  meet a requirement (Off-Specification)
• a question on any project topic
• a statement of concern

56
Component 8 - Change ControlProcess (2)

• An impact analysis is carried out to identify
• what would have to change
• what effort would the change need
• what the impact on the Business Case would be
• what the impact on the risks would be
• Hints and Tips
• Evaluating the impact of potential changes can be
  erroneously taken to mean only the impact on the
  Customer. Impact analysis must cover the three
  areas of Business, User and Supplier. Before a
  change goes to the Senior User for consideration,
  the impact on the Supplier must be known, e.g.
  the cost and effort required, and what products
  would have to be changed.

57
Component 8 - Change ControlProcess (3)

• The Project Manager decides which Requests For
  Change, if any, should be implemented within the
  current Stage Plan constraints. Even for those
  which the Project Manager is prepared to
  implement without extra funds or time, there
  should be discussion with the Senior User and
  Senior Supplier. Without the approval of the
  Project Board, the Project Manager should not
  authorise any work which would change a product
  which has already been approved by the Project
  Board.
• Where the Project Manager does not wish to
  personally take the decision on whether or not to
  implement the changes, the relevant Project
  Issues are passed to the Senior User(s). The
  Senior User can decide to reject Project Issues,
  put them in pending status, or ask for their
  implementation. Where implementation is sought,
  the Senior User canvasses the Executive and
  Senior Supplier for their agreement to any extra
  cost and effort required. This may lead to more
  being rejected or put into pending status.