SOP Project ManagementV0.9

Page 1 of
STANDARD OPERATING PROCEDURE IS IS PROJECTS OFFICE
SECTION: IS Projects Office
SOP NO: 502
TITLE: IS Project Management
ISSUE NO: 1.0 Draft
PREPARED BY: Pieter Erasmus
EFFECTIVE DATE:
EXPIRES:
EXPECTED REVIEW:
CHECKED BY:
APPROVED BY:
APPROVED BY:
NAME: Robin Botha
NAME: ___________________
NAME: __________________
SIGNATURE: __________
SIGNATURE: _____________
SIGNATURE: _____________
DATE: _______________
DATE:
DATE:
DISTRIBUTION:
_____________
_____________
EXCO
Managers
IS Project Managers
PURPOSE
Project Management provides an integrated framework for project organisation, planning and
control which is designed to
Ensure the timely and cost-effective production of all the end-products

Maintain acceptable standards of quality
Achieve for ihd the benefit for which the investment in the project has been made
Project Management specifically addresses Information Systems projects. It can be

adapted to any size or type of Information Systems project and also includes activities
required to establish infrastructure teams/plans/procedures.
This SOP defines the Standard Operating Procedure for managing IS projects
SCOPE
The Project Management process consists of three stages:
Page 2 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Project Initiation & Planning: defines the activities necessary to set a project up for
success.
Project Control: defines the activities necessary for the ongoing management of a
project.
Project Closure: defines the activities necessary to bring a project to a successful
conclusion.
This SOP does NOT include:

Project Identification, Project Selection or Project Prioritisation
Product related processes i.e. Project Execution (e.g. Software Development or
Software Maintenance). The selected product process is dependant on the type of
project and is created or selected & customised in the Project Initiation & Planning
Stage of a Project.
DEFINITIONS
Detail information regarding the Project Management Methodology can be accessed at
http://lp-db2-01/advisor3/PLWEB/ca/template/T_PM/f_1.htm
RESPONSIBILITY
The Project Manager, who is assigned by the IS Projects Office Manager to manage a
Project, is responsible to apply this SOP to each approved IS Project and to ensure that the
Project Board i.e. Project Sponsor, Customer Representative(s) and Technical
Representative(s) and all Project Team Members are aware of the Processes.
A project produces a product that serves the business requirements of the customer and
organisation. All groups that have a stake in a project should be business partners who
ensure that the functionality, capability, timing, costs, and people interfaces are all addressed.
To be successful, senior management commitment and involvement is crucial, but the
business partnership at all levels of the organisation must also be developed and maintained.
Page 3 of
SOP NO: 502
ISSUE NO: 1.0 Draft
PROCEDURE
Overview
Approved
Project
Proposal
PROJECT
INITIATION &
PLANNING
PM1
Project
Plan
PROJECT
CONTROL
Project
Records
PM2
Schedule, Approved Change Requests,

Project Board Progress Reports,
Resolved Issues
PROJECT
CLOSURE
PM3
Product &
Process
Improvement
PROJECT
EXECUTION
D1
Team Progress Reports,

Actuals, Issues, Problems, Change Requests,
Exceptions
Figure 1: Project Management Process Overview.

Overview: Project Initiation & Planning (Activity PM1 in Figure 1 above)
1. All IS Projects will be initiated by a Project Proposal that was approved and assigned a
priority by the Project Steering Committee (PSC). (Refer to Project Identification &
Selection SOP No 501)
2. The IS Projects Office Manager will assign a new project to one of the Project Managers
to manage based on Project Manager skills and workload.
3. The Project Manager will perform the Project Initiation and Planning Stage to compile a
Project Plan and make the project information available on ADvisor on the Intranet
using the AllFusion Process Management Suite of Software Tools. The following
steps in the Project Initiation & Planning Stage must be performed:
a.
b.
c.
d.
e.
f.
g.
Project Start-up
Project Scope
Project Organisation
Scheduling and Budgeting
Business Case
Project Control Procedures
Project Initiation and Planning Stage Assessment
4. The Project Plan will be reviewed and approved by the IS Projects Office Manager and
the Project Steering Committee before proceeding with project execution.
Project
Product(s)
Page 4 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Overview: Project Control and Execution (Activity PM2 and D1 in Figure 1 above)
1. Any project will contain product related stages (e.g. Analysis, Logical Design, Physical
Design, Construction & Testing and Installation) that will be executed by the project team.
The product related work must be controlled by the Project Manager to ensure that the
approved project plan is executed.
2. Project control consists of the following:
a. Stage Management
b. Stage-end Assessment
3. The Project Manager will perform Stage Management for each product related stage in
the WBS (Work Breakdown Structure).
4. The Project Manager will perform Stage Management by ensuring the following tasks are
performed:
a.
b.
c.
d.
e.
f.
Kick Off the Stage

Monitor Project Progress and Cost
Identify and Resolve Issues
Communicate and Market Project
Execute Change Control Procedures
Manage Exception Situations
5. The Project Manager will perform Stage-end Assessment at the end of each stage by
performing the following tasks:
a.
b.
c.
d.
e.
f.
g.
h.
Ensure Requirements Traceability

Review Project Deliverables
Develop Schedule for Next Stage
Revise and Review Project Plan
Prepare Stage End Assessment
Conduct Stage End Assessment
Baseline Project Deliverables
Complete Configuration Management Audit
6. The Project Manager will perform Project Control on all product related stages until all the
stages have been completed.
Overview: Project Closure (Activity PM3 in Figure 1 above)
Page 5 of
SOP NO: 502
ISSUE NO: 1.0 Draft
1. The Project Manager will formally close the project after the main product or deliverable of
the project has been installed and is in use by the customer that requested the product.
2. The Project Manager will perform the following steps to close a project
a. Project Completion
b. Product and Process Improvement
3. The Project Manager will ensure that the following tasks are performed during Project
Completion:
a.
b.
c.
d.
e.
f.
Prepare & Conduct Project Evaluation

Initiate the Maintenance Process
Close Outstanding Project Work
Prepare for Project Closure Meeting
Conduct Project Closure Meeting
Review and Baseline Project/Deliverables
4. The Project Manager will ensure that the following tasks are performed for Product and
Process Improvement:
a.
b.
c.
d.
Collect Project Feedback and Metrics

Collate and Analyse Metrics
Analyse Product Quality
Complete Process Review
Page 6 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Detail Procedures
Work Breakdown Structure Summary List
Stage PM.PIP: Project Initiation and Planning
Step PM.PIP.01: Project Startup
Task PM.PIP.01.010: Establish Project Charter
Task PM.PIP.01.020: Confirm Project Sponsor and Project Manager
Task PM.PIP.01.030: Prepare Project Initiation & Planning Stage Schedule
Step PM.PIP.02: Project Scope
Task PM.PIP.02.010: Identify Business Drivers, Objectives, & Success
Criteria
Task PM.PIP.02.020: Determine Project Scope
Task PM.PIP.02.030: Identify High Level Solution
Task PM.PIP.02.040: Review and Compile Products
Step PM.PIP.03: Project Organisation
Task PM.PIP.03.010: Define Project Organisation
Task PM.PIP.03.020: Determine Training Requirements for Project Team
Task PM.PIP.03.030: Review Project Organisation
Step PM.PIP.04: Scheduling and Budgeting
Task PM.PIP.04.010: Define Project Approach and Schedule
Task PM.PIP.04.020: Define Initial Project Budget
Task PM.PIP.04.030: Perform Risk Analysis
Task PM.PIP.04.040: Define Next Stage Activities and Schedule
Step PM.PIP.05: Business Case
Task PM.PIP.05.010: Determine the Project Costs
Task PM.PIP.05.020: Quantify Benefits
Task PM.PIP.05.030: Review Risk Analysis
Task PM.PIP.05.040: Perform Cost Benefit Analysis
Step PM.PIP.06: Project Control Procedures
Task PM.PIP.06.010: Customise Quality Assurance Plan
Task PM.PIP.06.020: Customise Configuration Management Plan
Task PM.PIP.06.030: Customise Communications Plan
Task PM.PIP.06.040: Customise Progress Reporting Procedures
Task PM.PIP.06.050: Customise Problem Reporting Procedures
Task PM.PIP.06.060: Customise Issues Management Procedures
Task PM.PIP.06.070: Customise Cost Control Procedures
Task PM.PIP.06.080: Define Exception Management Procedures
Task PM.PIP.06.090: Define Other Project Controls
Step PM.PIP.07: Project Initiation and Planning Stage Assessment
Task PM.PIP.07.010: Complete Project Plan
Task PM.PIP.07.020: Review Project Plan
Task PM.PIP.07.030: Prepare Stage End Assessment
Page 7 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Task PM.PIP.07.040: Conduct Stage End Assessment

Task PM.PIP.07.050: Complete Process Review
Task PM.PIP.07.060: Baseline Project Plan
Stage PM.PCTL: Project Control
Step PM.PCTL.01: Stage Management
Task PM.PCTL.01.010: Kick Off the Stage
Task PM.PCTL.01.020: Monitor Project Progress and Cost
Task PM.PCTL.01.030: Identify and Resolve Issues
Task PM.PCTL.01.040: Communicate and Market Project
Task PM.PCTL.01.050: Execute Change Control Procedures
Task PM.PCTL.01.060: Manage Exception Situations
Step PM.PCTL.02: Stage End Assessment
Task PM.PCTL.02.010: Ensure Requirements Traceability
Task PM.PCTL.02.020: Review Project Deliverables
Task PM.PCTL.02.030: Develop Schedule for Next Stage
Task PM.PCTL.02.040: Revise and Review Project Plan
Task PM.PCTL.02.050: Prepare Stage End Assessment
Task PM.PCTL.02.060: Conduct Stage End Assessment
Task PM.PCTL.02.070: Baseline Project Deliverables
Task PM.PCTL.02.080: Complete Configuration Management Audit
Stage PM.PCL: Project Closure
Step PM.PCL.01: Project Completion
Task PM.PCL.01.010: Prepare & Conduct Project Evaluation
Task PM.PCL.01.020: Initiate Maintenance Process
Task PM.PCL.01.030: Close Outstanding Project Work
Task PM.PCL.01.040: Prepare for Project Closure Meeting
Task PM.PCL.01.050: Conduct Project Closure Meeting
Task PM.PCL.01.060: Review and Baseline Project/Deliverables
Step PM.PCL.02: Product and Process Improvement
Task PM.PCL.02.010: Collect Project Feedback and Metrics
Task PM.PCL.02.020: Collate and Analyse Metrics
Task PM.PCL.02.030: Analyse Product Quality
Task PM.PCL.02.040: Complete Process Review
Page 8 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Stage PM.PIP: Project Initiation and Planning

To
take the ideas and intentions of a group of people who see the need for a project in
their organisation and convert them into a formal, planned, resourced and funded
project
in a way that
clearly and explicitly defines the objectives and scope of the project
develops an overall schedule of activities and resources required to carry out the
whole project
develops a detailed schedule of activities and resources required to carry out the next
stage of the project
defines a project organisation structure which can be used to effectively manage and
carry out the necessary work
establishes a convincing business case for the project
gains commitment and approval to the project from the appropriate level of senior
management
so that
the project is firmly set up for success

the probability of producing a high quality product on budget and on schedule is
maximized
The Process Flow of the PIP Stage is depicted in Figure 1: Project Management Process
Overview
Page 9 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Figure 2: Project Initiation & Planning Process Flow
Page 10 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PIP.01: Project Startup

To
establish a charter for the project
in a way that
the mission of the project is fully explained

project scope and boundaries are clearly identified showing what's inside the scope
and what's outside
major deliverable(s) are documented describing what the project is to produce
assumptions are laid out in an understandable manner
project organizational requirements are defined
quality assurance program that will be applied
rough order of magnitude of project costs
so that
a guide is established for the operation of the project

management has an understanding of the project costs and achievements to be
made
mappings can be made against the corporate strategic plan
Task PM.PIP.01.010: Establish Project Charter

1. If an approved Project Proposal does not exist, the IS Projects Office Manager must
first apply the Project Identification & Selection SOP to ensure that the requested
project is approved first and an approved Project Proposal is supplied to the Project
Manager
2. The Project Manager will compile a Project Charter from the PSC approved Project
Proposal. (See APPENDICES).
Task PM.PIP.01.020: Confirm Project Sponsor and Project Manager

1. IS Projects Office Manager confirms that a Project Sponsor has been appointed for
the Project.
2. IS Projects Office Manager distributes Project Charter to Project Sponsor for Review
3. IS Projects Office Manager selects and assign and brief a Project Manager to
manage the Project.
Page 11 of
SOP NO: 502
ISSUE NO: 1.0 Draft
4. Project Manager updates the Project Charter with Project Sponsor views.
5. Identify Key Resources that may be of assistance in the Project Initiation & Planning
Phase.
6. Project Manager drafts the preliminary Project Organisation Chart (See Appendix 2:
Project Organisation). Apply the Project Organisation Technique in the Process
Library.
Task PM.PIP.01.030: Prepare Project Initiation & Planning Stage Schedule
The Project Manager:
1. Plans the activities (work breakdown structure), effort, resources, and time scales for
the Project Initiation & Planning Stage by reviewing any previous studies addressing
the area of interest.
2. Creates a blank project in Project Engineer.
3. Create a project level task and rename it to the Project Name
4. Import the PIP kernel and demotes to a Stage level
5. Identifies other projects that are closely associated with the proposed project and
review them with the appropriate Project Managers.
6. Reviews the activities in Project Initiation & Planning Kernel and customises the PIP
WBS.
7. Identify resources to perform Project Initiation & Planning Stage.
8. Requests Project Office Console Administrator to create new resources in POC
(Project Office Console)
9. Imports required resources into from POC into Project Engineer
10. Assigns resources to tasks in Project Engineer
11. Estimates the effort for each task per resource.
12. Updates the schedule based on available resources
13. Check Project file into POC and schedule project using Project Planner
14. Determines any constraints that must be observed during Project Initiation & Planning
15. Documents any assumptions that have been made in producing the schedule
16. Creates a Project Initiation & Planning Stage schedule and make available in Advisor
by changing the status from Plan to Schedule.
Page 12 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PIP.02 Project Scope

To
establish the project scope and clearly define the project boundaries
in a way that
takes into account the project background, including previous and related initiatives
uses pictures instead of words whenever possible
identifies the Business Objective that is the underlying reason for the project
clearly defines the objectives of the project in relation to the Business Objective
identifies the major business requirements that the project must meet
identifies the constraints the project must work within
clearly and explicitly defines what the project will and will not cover
so that
a clear and commonly understood target and benchmark is available to project
members and other interested parties by which they can steer the direction of the
project and assess the quality of the final product.
Task PM.PIP.02.010: Identify Business Drivers, Objectives, & Success Criteria
1. Project Manager, with the help of a Business Analyst, conducts a series of Interactive
Development and/or interview sessions with the business and management
representatives to identify major objectives and critical requirements for the new
project.
2. Business Analyst complete the following Documents:
a. Business Needs/Drivers (See Appendix 3: Business Needs/Drivers)
b. Business Solution Document (See Appendix 4: Business Solution)
c. Problem/Requirement List (See Appendix 5: Problem/Requirement List)
3. Project Manager completes the Objective Section of the Project Plan (See Appendix
6: Project Plan)
Task PM.PIP.02.020: Determine Project Scope
1. Project Manager, with the assistance of a Business Analyst, defines the scope of the
project in Interactive Development Sessions with the business and management
representatives.
2. Business Analyst compiles graphical:
Page 13 of
SOP NO: 502
ISSUE NO: 1.0 Draft
3.
4.
5.
6.
7.
8.
a. High level Process Models using AllFusion Process Modeller

b. High level Data Model using AllFusion Data Modeller
Business Analyst clearly indicate boundary of Project stating, where necessary, what
is included in and what is excluded from the Project.
Business Analyst clearly defines the end result of the Project.
Project Manager compiles a Product Breakdown Structure (PBS) to identify the major
deliverables and interim products that is necessary to produce the Project end
deliverable.
Project Manager starts recording any assumption that must be verified. (See
Appendix 6: Project Plan)
Project Manager starts recording any constraints that must be taken into account.
(See Appendix 6: Project Plan)
Project Manager complete the Scope Section of the Project Plan (See Appendix 6:
Project Plan)
Task PM.PIP.02.030: Identify High Level Solution

1. Project Manager and Business Analyst define, create diagrams and describe the high
level solution.
2. Highlight the constraints or any special technical requirements.
3. Identify dependencies and interfaces between this project and other initiatives.
4. Define projected improvements in critical areas and associated benefits
5. Describe the technical requirements and associated feasibility
6. Define the organisational impact of the likely solution
7. Business Analyst completes the High Level Solution paragraph in the Project Plan
(See Appendix 6: Project Plan)
8. Project manager records problems and requirements in the Problem/ Requirements
List (See Appendix 5: Problem/Requirement List)
1.
2.
3.
4.
5.
Project Manager schedules Walkthrough Review Sessions.

Project Manager, Business Analyst finalise Interim documents.
Project Manager update Project Plan (See Appendix 6: Project Plan)
Project Manager baselines products using Harvest Change Manager.
Project Manager distributes frozen products to Walkthrough Review Attendees for
preparation.
6. Project Manager, Business Analyst and contributors review the Business Drivers,
Objectives, Problem/Requirements List, Success Criteria, Project Scope, and High
Level Solution applying the Walkthrough Review Technique.
7. Informal Problem Report/Change Request (PR/CR) is raised for all changes (See
Appendix 7: Problem Report/Change Request Form).
Page 14 of
SOP NO: 502
ISSUE NO: 1.0 Draft
8. Project manager completes Walkthrough Report (See Appendix 8: Walkthrough

Report)
Page 15 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PIP.03: Project Organisation

To
select and prepare the people whose involvement will be necessary for the project to
succeed
in a way that
clearly identifies roles and responsibilities

ensures that the best individuals to fulfill roles and responsibilities are selected
identifies training required to enable individuals to fulfill their roles and responsibilities
on the project
gains the appropriate allocation of resource time to the project
ensures that all major interest groups are appropriately represented
updates the project and stage schedules in line with available resources
so that
the project benefits from having a group of people who can operate in an integrated
fashion and who understand exactly the roles they must play in contributing to the
success of the project
Task PM.PIP.03.010: Define Project Organisation
1. Project Manager defines the Project Organisation using the Project Organisation
Technique.
2. Establish Initial Project Organisation
a. IS Projects Office Manager confirms or recruits and appoints Project Manager
for Project & Initiation Stage.
b. PSC, IS Projects Office Manager or Project Manager recruits and appoints
Project Sponsor
3. Identify Key Business Areas
a. Project Manager identifies and names all impacted Business Areas including
IS and external suppliers.
b. Project Manager completes the first column of the Project Organisation
Worksheet with Key Business Areas. (See Appendix 2: Project Organisation)
c. Project Manager revises Project Scope Paragraph in the Project Plan if
required.
4. Identify involved personnel for each business area
a. Project Manager identifies and records resource names per Business Area.
b. Project Manager identifies and records resource names per Business Area
that will represent external suppliers and/or customers
Page 16 of
SOP NO: 502
ISSUE NO: 1.0 Draft
c.
Project Manager requests, negotiates and procures resources not available

with resource Managers/functional managers.
d. Project Manager records all resource names in the Project Organisation
Worksheet. (See Appendix 2: Project Organisation)
5. Assign roles to Personnel
a. Project Manager defines roles required in the Project.
b. Project Manager assigns roles to each resource. One resource can have
more than one role.
c. The following roles are mandatory and MUST be assigned to resources:
i. Project Board (Project Sponsor, Technical Representative and
Customer Representative)
ii. Project Manager
iii. Project Coordinators (Planning Coordinator, Business Coordinator
and Technical Coordinator)
iv. Project Team
d. The following roles are optional:
i. Key Stakeholders
ii. Key Resources
iii. Intervening managers
e. Project Manager determines estimated time commitment per resource per
role.
6. Document Project Organisation
a. Project customizes Role Descriptions.
b. Project Manager completes Project Organisation Worksheet and Project
Organisational Structure in Project Organisation Document
7. Finalise the Project Organisation
a. Project Manager confirms that unassigned resources (without a role) is
required in the project.
b. Project Manager reviews the proposed project organisation to ensure that it
includes all participants needed to achieve the project objective.
c. Project Manager briefs and conducts interviews with all Project Team
Members to discuss assigned roles.
d. Project Manager updates Project Organisation Worksheet and Project
Organisational Structure in Project Organisation Document
Task PM.PIP.03.020: Determine Training Requirements for Project Team
1. Project Manager identifies skills required per role for the project
2. Project Manager assesses skills of assigned resource
3. Project Manager and Trainer develop a Project Training Plan to train Project Members in:
a. Methodologies
b. Technologies
c. Business Areas
4. Project Manager updates Project WBS in Project Engineer to include Project Training
activities.
Page 17 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Task PM.PIP.03.030: Review Project Organisation

1. Project Manager prepares Project Pitch (a PowerPoint Presentation) covering:
a. Description
b. Objectives
c. Scope
d. High Level Solution
e. Project Organisation (Roles, Structure, Resource names)
f. Project Training Requirements
2. Enlist Project Champions to deliver briefings to various target groups.
3. Project Manager reviews the Project Organisation applying the Walkthrough Review
Technique in the briefing Sessions.
4. Project Manager records all feedback
5. Project Manager updates documentation
Page 18 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PIP.04: Scheduling and Budgeting

To
develop an overall time schedule for the project and a detailed time schedule for the
next stage of the project
in a way that
defines the overall development approach for the project

produces a customised work breakdown structure (task list) specific to the project
creates an estimate for the total cost of the project, and the associated target
completion dates
identifies the major Project Board control points
identifies at a high level the human resources required to carry out the project
identifies at a high level other resources required to carry out the project
defines details and specifics for the Next Stage, including tasks, actual resource
requirements, task and resource dependencies, cost estimates, and the associated
target completion dates
identifies and plans for risks to the project
so that
a schedule is available to guide the project and to use as a benchmark by which

progress on the project can be monitored and controlled.
risks are identified and mitigated.
Task PM.PIP.04.010: Define Project Approach and Schedule

1. Establish the overall Work Breakdown Structure (WBS)
2. Stages, Steps and Task Structure
Project Management Processes
Project Initiation and Planning Stage
Project Control Stage(s)
Project Closure Stage
Product Processes
Analysis Stage
Logical Design Stage
Physical Design Stage
Construction and Testing
Installation
3. Decide on the project approach
Page 19 of
SOP NO: 502
ISSUE NO: 1.0 Draft
a. Determine type of project

b. Select a template
c. Create WBS in a workshop?
4. Create a Project in Project Engineer either
a. Create a blank project
i. Create Activity Types
ii. Create a WBS and complete the following:
1. Activity Name
2. Activity Description
3. Activity Mandatory
4. Activity Type
5. Activity Keyword
6. Activity Link to a HTML file
7. Activity Replication Rule if applicable
b. Create a project from a 3rd Party Scheduler
c. Create a project from a Process Library Template
5. Customise the project
a. Customise the WBS
i. Remove unnecessary Stages, Steps or Tasks
ii. Include additional Stages, Steps and Tasks to reduce risks
iii. Include the following Project Management Activities:
1. Project Initiation and Planning Stage as the first Stage
2. Project Control:
a. Stage Management Step for each Product stage at the
beginning of each product Stage
b. Stage-end Assessment Step as the last Step in the
Product Stage.
3. Project Closure as the last Stage
iv. Record all Assumptions and Issues
v. Replicate Tasks where iteration is required
b. Define the following project objects if not already defined:
i. Keyword Sets
1. Keyword Set Name
ii. Keywords
1. Keyword Name
2. Keyword Set Name
iii. Product Types (One of Project Management, Quality Assurance,
Analysis, Design, Construction, Installation)
iv. Product Tools
1. Tool Name
2. Tool Description
3. Tool Path
4. Tool Keyword
v. Products that will be created, used and updated. Ensure that there is at
least one Major Product Deliverable per Project Stage.
1. Product Reference
Page 20 of
SOP NO: 502
ISSUE NO: 1.0 Draft
2.
3.
4.
5.
6.
Product Name
Product Description
Product Type
Product Path
Product Default Tool that will be used to create and update
product
7. Product Example
8. Product Keyword
vi. Resources.
1. Do NOT create resources in Project Engineer. All Resources are
created in central resource pool in POC
2. Create Resource Types in PE
3. Import Resources from the POC
a. Open Database/Resource Pool dialog in PE
b. Connect to MPC Server and supply following
Information:
i. Service name: http://lp-db2-01/poc
ii. Your User ID
iii. Your Password
c. Select IHD Resource Pool
d. Select Group by: All Resources
e. Select Resources to import to PE
4. Create Resources if resource does not exist in IHD Resource
Pool in POC.
a. POC Administrator to create required Resources in POC
with information supplied by Project Manager or
Resource manager per resource:
i. Resource Name (21 Characters Maximum)
ii. Title
iii. Phone
iv. E-Mail
v. Description
vi. Login ID. Firstname and initial letters of
surname (e.g. ClaireV for Claire Vermeulen or
AlisonLR for Alison le Roux)
vii. Password. Initial password of pass
viii. The name of the resources functional manager.
ix. Resource Type (Labour, Material or Equipment)
x. Resource Pool = IHD Resource Pool
xi. The Department the Resource functionally
belongs in.
xii. Workweek = IHD Standard Work Week
xiii. Availability Level = 100%
xiv. Overtime Percent Type
xv. Availability Date
xvi. Termination Date
Page 21 of
SOP NO: 502
ISSUE NO: 1.0 Draft
xvii. Indicate if resource must be included in

headcount (Yes for permanent IHD employees,
No for contractual resources)
xviii. Indicate if this resource is a manager
xix. Indicate if resource must complete a timesheet
xx. Supply Bill rate per hour with the start date and
end date this bill rate is valid.
xxi. Supply Calendar details the resource is not
available for project work.
b. Perform Import Resources from the POC to make newly
created resources available n PE
5. Complete resource details in PE
a. Select a Resource Type
b. Define a Resource Keyword
vii. Roles
1. Role Reference
2. Role Name
3. Role Description
4. Role Keyword
viii. Techniques
1. Technique Reference
2. Technique Name
3. Techniques Description
4. Technique Path
5. Technique Keyword
c. Assign the following objects for each lowest level activity except where indicated
else:
i. Inputs (Products) required to perform an activity
ii. Outputs (Products) that will be updated or created by an activity (for
every activity)
iii. Keywords to identify activity
iv. Predecessor activity(s). This includes dependencies on activities in other
Projects external to this project.
v. Roles that is required to execute activity
vi. Techniques that might be followed
6. Discuss and agree the Project with affected Resource Managers and resources.
7. Perform an Initial Top-Down Estimate
a. Estimate the overall effort and record in Project Engineer
b. Apportion down to Stage and optionally Step Level
c. Review Top-Down Estimate
d. Record all Planning Assumptions in Project Engineer using the Effort PMAsm
column in the estimating worksheet.
8. Define the initial Resource requirements
a. Define Labour Resources
b. Define other Resources
c. Do NOT Assign any Resource to any tasks now.
Page 22 of
SOP NO: 502
ISSUE NO: 1.0 Draft
9. Check Project into Project Office Console from Project Engineer

a. Create a <project>.pci file by selecting in Project Engineer Database/Check In
Project and follow the screen dialogue.
b. Launch Project Office Console (POC) and log in.
c. Check in your project. Select Projects/Check in and follow the screen dialogue
selecting the <project>.pci file just created. The project is now stored in the
Master Process Continuum (MPC) Database.
10. Schedule Project with Project Planner
a. Launch Project Planner
b. File/Open/Load Project/Files of Type = ODBC Repository. Select the <project>
file and it will be loaded into Project Planner
c. Project Planner will now schedule the <project> assigned start end end dates to
the activities in the WBS.
d. Save a Baseline for the <project>. Edit/Transfer to Baseline/OK
e. Save <Project>. This will update the <project> in the MPC
11. Check out Project from POC into Project Engineer
a. If not active, launch POC.
b. Login
c. Check out <project>. Select Projects//Check Out and follow the screen dialogue.
A <project>.pco file will be created.
d. Check out <project. into Project Engineer. Select Database/Check out Project
and follow screen dialogue.
e. The <project> is now available in PE
12. Create Reports and charts using PE or Project Planner.
13. Repeat above until Project Schedule is acceptable
Task PM.PIP.04.020: Define Initial Project Budget
1. Determine the project budget including at least the following Cost Items:
a. Capital Expenditure
i. Equipment/Hardware
ii. Software Packages
iii. External, Outsourced Staff (Labour) from Project Engineer
b. Expenses
i. Internal Staff (Labour) From Project Engineer
ii. Training
iii. Facilities
iv. Materials/ Supplies
v. Travel
vi. Rentals
c. Contingency
2. Complete the Budget Paragraph in the Project Plan. See Appendix 6: Project Plan
3. Review the Project Budget with the Project Sponsor and IS Projects Office Manager and
get approval.
Page 23 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Task PM.PIP.04.030: Perform Risk Analysis

1. Evaluate overall project to identify and quantify areas of high risk for the planned
solutions(s):
a. Create External Dependencies Risk Analysis Checklist. Appendix 9: Risk
Analysis Checklist for External Dependency Risks
b. Create Risk Analysis Checklist for Business Case Risks. Appendix 10: Risk
Analysis Checklist for Business Case Risks
c. Create Organisational Risk Analysis Checklist. Appendix 11: Risk Analysis
Checklist for Organisational Risks
d. Create Planning Risk Analysis Checklist. Appendix 12: Risk Analysis
Checklist for Planning Risks
e. Create Technical Risk Analysis Checklist. Appendix 13: Risk Analysis
Checklist for Technical Risks
f. Summarise the Risk for the project complete the Risk Evaluation
Summary Form. Appendix 14: Risk Evaluation Summary Form
2. Create Risk Management Action Plan to avoid, mitigate or accept the identified risks.
Appendix 15: Risk Management Action Plan
3. Revise Project Schedule based on Risk Management Action Plan adding the additional
activities in Project Engineer and reschedule using Project Planner.
Task PM.PIP.04.040: Define Next Stage Activities and Schedule
1. Identify Step and Task Level activities for the next Stage.
2. Tune the next Stage WBS to:
a. Remove unnecessary steps/tasks
b. Include additional steps/tasks to reduce risks
c. Instantiate activities to include multiple iterations and/or timebox cycles as
appropriate
3. Using estimating guidelines and metrics produce initial estimates for each step and task
within the next stage.
4. Tune these base estimates to reflect the actual circumstances impacting the project.
5. Aggregate the estimates to the top using a new column in the estimating worksheet in
Project Engineer.
6. Compare the aggregation of this bottom up estimates to the top down estimates for the
entire project.
7. Record all assumptions and issues identified.
8. Using the estimates for the next stage, assign specific resources from the IHD Resource
Pool. This will now be at the individual level for human resources. The allocation may be
simply to activities, or to roles within activities, or to responsibilities within roles within
activities.
9. Make adjustments for Expertise Level.
Page 24 of
SOP NO: 502
ISSUE NO: 1.0 Draft
10. Notify the IS Projects Office or POC Administrator of any additional resources that will be
required. The IS Projects Office will have the responsibility of providing resources to the
Project Manager.
11. Update Project Engineer
12. Check in <project. to POC
13. Schedule with Project Planner, save another baseline and save to POC.
14. Check out <project> to PE.
1. Review the following products using the Walkthrough Review Approach with contributing
parties:
a. Project WBS
b. Effort Estimate
c. Schedule
d. Project Budget
e. Risk Management Action Plan.
2. Use the Change Control Procedure to manage changes to Baselined products.
3. Compile all the Informal Products (Work Papers produced on the Task Level), Key
products (Interim Deliverables produced in the Step Level) into the Project Plan (Major
Deliverable).
4. Check Products into Harvest Change Manager for Configuration Control
5. Inform the IS Projects Office Manager that the Project Plan is complete.
Page 25 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PIP.05: Business Case

To
prepare a business case which compares the benefits and costs of the proposed
project
in a way that
looks creatively for all possible areas of benefit

thoroughly researches all areas of cost
quantifies benefits in financial terms wherever possible
quantifies cost in financial terms
provides an assessment of the risks of the project and
ideas on how they can be reduced
draws conclusions about the merits of the case
offers alternatives where appropriate
revises other sections of the project plan
so that
the Project Steering Committee (PSC) has good quality quantitative information to
guide their decision as to whether to proceed with the project.
Task PM.PIP.05.010: Determine the Project Costs
1. Review the project budget and determine that all costs have been identified.
2. Review and calculate Risk Contingency costs and update the Project Budget in the
Project Plan.
3. Identify and describe different options.
4. Estimate the cost of operating and maintaining the final product over its intended
lifecycle. The following areas need to be considered for Product life-cycle operating costs
for the completed system/solution:
a. Hardware and software procurement (licenses & maintenance renewal)
b. Backup/recovery media, disaster recovery, off-site storage
c. Environmental resources
d. Consumables (paper, etc.)
e. Staff requirements (operations, support, training)
5. Complete the Costs paragraph in the Cost/Benefit Analysis Worksheet for each option.
See Appendix 16: Cost/Benefit Analysis Worksheet. It is important to note that the initial
Project Budget did not include the total product life-cycle costs (operations and support)
that may add significantly to the overall cost of the product solution. This cost, the product
Page 26 of
SOP NO: 502
ISSUE NO: 1.0 Draft
life-cycle cost, is estimated in this task and is then used later as part of the Business
Case.
Task PM.PIP.05.020: Quantify Benefits
1. Identify and quantify all benefits associated with the final product of the project.
2. Categorize the benefits as tangible, intangible or strategic.
a. Tangible benefits may include:
i. additional income
ii. return on improved cash flow
iii. reduction in headcount
iv. discontinuing operation of existing computer system
v. elimination of license fees
vi. avoidance of recruiting additional staff
vii. avoidance of additional office space
b. Intangible benefits may include:
i. improved staff morale
ii. improved company image
iii. reduced staff turnover
iv. reduction in number of accidents
v. better information on which to base decisions
c. Strategic benefits may include:
i. improving IHDs position in the marketplace
ii. providing information that was not previously available
iii. preparing a base for future projects
3. Assign a financial value (in Rand) to each tangible benefit.
4. Document any calculations used to determine tangible benefits.
5. If possible, calculate the strategic value of the solution to the company as well as
intangible benefits.
6. Complete the Benefits paragraph in the Cost/Benefit Analysis Worksheet. See Appendix
16: Cost/Benefit Analysis Worksheet.
7. Determine the Return on Investment (ROI) by completing the ROI Spreadsheet. See
Appendix 17: ROI Spreadsheet
Task PM.PIP.05.030: Review Risk Analysis
1. Determine any additional risk management activities associated with conducting the
project.
2. Update the Risk Analysis Checklists (See Appendix 9: Risk Analysis Checklist for External
Dependency Risks, Appendix 10: Risk Analysis Checklist for Business Case Risks,
Appendix 11: Risk Analysis Checklist for Organisational Risks, Appendix 12: Risk Analysis
Checklist for Planning Risks, Appendix 13: Risk Analysis Checklist for Technical Risks
Page 27 of
SOP NO: 502
ISSUE NO: 1.0 Draft
and Appendix 14: Risk Evaluation Summary Form) and Risk Management Action Plan
(Appendix 15: Risk Management Action Plan) with any additional information.
3. Revise the Project Schedule as necessary using Project Engineer and Project Planner.
Task PM.PIP.05.040: Perform Cost Benefit Analysis
1. Compile the costs, benefits, risk analysis, and return-on-investment products into the
Business Case. See Appendix 18: Business Case
2. According to the organisational standards, analyse the benefits against costs in light of
the risk, in order to determine the project's financial viability. This analysis should
consider:
a. Cost vs. value of the benefits
b. Project budget vs. the IHD budget
c. Return on Investment (ROI)
d. Payback
e. Discounted cash flow
i. Net Present Value (NPV)
ii. Internal Rate of Return (IRR)
3. If a poor Cost/Benefit Ratio occur, adjust the Project Plan Scope, WBS, Estimates or
assigned Resources.
4. Update Project Engineer and reschedule using Project Planner.
5. Include the following in the Business Case:
a. Cost summary
b. Benefit summary
c. Tangible benefits
d. Replaced costs
e. Cost containment
f. Increased revenue
g. Intangible benefits
h. Calculation of net benefit
6. Include the Business Case in the Project Plan (See Appendix 6: Project Plan)
Page 28 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PIP.06: Project Control Procedures

To
ensure that all procedures required to carry out and control the project work are
established
in a way that
identifies all necessary procedures for project and product control

defines appropriate standards for the project
defines necessary performance levels and tolerances
ensures that a communication mechanism is established to coordinate activities
among the members of the project organisation
ensures issues are identified and escalated as appropriate
ensures product baselines are established and controlled
assists in managing and controlling changes to the project
facilitates impact analysis related to changes
minimises unforeseen impacts of changes
promotes improved developer productivity
so that
all project work is carried out in a quality manner, as effectively as possible.
Task PM.PIP.06.010: Customise Quality Assurance Plan

1. Review the IHD IS Quality Plan and customise it for the project.
2. Determine which techniques to use throughout the project to ensure quality is built into
products as they are developed.
3. Identify Major Deliverables and Key Products that should be (either formally or informally)
managed. Based on product reviews established in the quality control plan, ensure that
the appropriate Review Techniques (Walkthrough Review and/or Inspection Review) are
placed at the appropriate points in the WBS.
4. Define the Process Quality mechanism that is used to ensure that standard processes
and procedures are followed. Use Process Quality Inspection Checklists to verify
compliance with standard processes and products.
5. Create a <project> Quality Plan based on the IHD IS Quality Plan. See Appendix 19:
Project Quality Plan
Task PM.PIP.06.020: Customise Configuration Management Plan
Page 29 of
SOP NO: 502
ISSUE NO: 1.0 Draft
1. Customise the IHD IS Configuration Management Plan to create the Project Configuration
Management Plan (See Appendix 20: Project Configuration Management Plan ) that will
define:
a. where the products of the project will be stored
b. how updates to the products (both change requests and problems) will be
controlled
2. Product Baselining.
a. Define the Storage Location.
b. Define Folder Structure
c. Define Product Baselining Procedures. When and how a product will be
controlled.
d. Create Project on Harvest Change Manager Administrator.
e. Activate Project so that it is available to Project members in Harvest Change
Manager Workbench.
f. Document the standard points in the development process where product
baselines will be established.
g. Define the type of baselines (rolling or frozen).
h. Define Configuration Items (CIs or Products) that compose each Baseline.
i. Define the dependencies and relationships between Configuration Items
(CIs). Complete the Configuration Item Relationship Document (See
Appendix 21: Configuration Item Relationships). This provides a basis for
impact analysis of Change Requests and grouping of items for Change
Packages.
j. Complete the Baselining Procedures Appendix in the Project Plan. See
Appendix 6: Project Plan
3. Change Control Procedures
a. Define the Change Control mechanisms that will be used in the project for
creating a product Baseline from CIs.
b. Establish a change control log on HEAT for the project.
4. Complete the Project Plan with the following products:
a. Baselining Procedures
b. Configuration Item Relationships
c. Project Configuration Management Plan
Task PM.PIP.06.030: Customise Communications Plan
1. Define mechanism for:
a. intra-group communication procedures to coordinate day-to-day activities
among team members.
b. inter-group coordination procedures outlining how activities will be
coordinated across teams (e.g., requirements, development, testing,
configuration management, process quality assurance, infrastructure,
architecture, data base administration, etc.)
c. standards for meeting agendas and minutes
Page 30 of
SOP NO: 502
ISSUE NO: 1.0 Draft
d. the identification of specific tasks to be added to the schedule to support the

execution of your plan (e.g., additional review tasks, communications tasks)
2. Review the roles defined for the project to determine the groups that will be required for
communicating project information
3. Establish the Project Communications Plan. See Appendix 22: Project Communication
Plan)
Task PM.PIP.06.040: Customise Progress Reporting Procedures
1. Determine the mechanisms to be used to monitor progress on the project. Progress
Reporting procedures should be defined for:
a. Time reporting, activity tracking and product completion reporting.
b. Individual team member progress reporting to stage manager
c. Progress reporting to the Project Board and IS Projects Office
d. Progress reporting to Project Steering Committee
2. Time Reporting, activity tracking and product completion reporting
a. Use iTime in POC.
i. Normal Time
ii. Overtime
iii. Add Tasks
iv. Non-Project Tasks
v. Effort To Complete (ETC)
vi. Save Time
vii. Submit Time
b. Complete daily
c. All project team members except Executive Management must complete
timesheets. The effort in hours from all team members are required for
metrics purposes. That includes:
i. IHD IS Department staff
ii. IHD staff from other departments
iii. Outsourced, external staff; with and without a Bill Rate.
3. Individual team member progress reporting to stage manager on a weekly basis.
a. Prepare for Team Checkpoint Meeting
i. Team Member completes iTime Sheet before Team Checkpoint
Meeting.
ii. Team Member completes Team Progress Report ( See Appendix 23:
Team Progress Report) and submit to Project Manager before
Checkpoint Meeting with the following contents:
1. Team Member Name
2. Project Name
3. Stage Name
4. Reporting date
5. Reporting Period Start Date
6. Reporting Period End Date
Page 31 of
SOP NO: 502
ISSUE NO: 1.0 Draft
7. Accomplishments for the period: these should be major

accomplishments (for example, reaching key milestones,
delivering key components)
8. Plan vs. Actual: Summary of actual progress against plan
9. Issues and Actions: Any issues about the person's schedule
or the project in general that present heightened risk for the
project. When possible, suggested actions should be
submitted to provide the manager with alternatives for
solutions related to the issue.
10. Planned Activities for the Next Reporting Period.
iii. POC Administrator post Time
iv. Project Manager:
1. Review the effort expended by the team against scheduled
activities.
2. Review the latest estimates for completing current activities
and determine if the project is still on schedule.
3. Determine if the stage is out of the tolerance levels for
progress agreed with the Project Board.
4. Decide if corrective action is needed, even if the stage is still
within the agreed tolerance levels. Determine the corrective
action and adjust the project schedule accordingly. If it is
clear that the action needed will impact stage tolerance, the
stage should be considered as out of tolerance.
5. Add activities to the Project Schedule from the stage
schedule and assign team members to carry out the new
activities.
6. Prepare a summary of accomplishments, new issues, status
of open issues, and activity for the next four weeks. Note that
activity for the next period may include new activities and/or
changed resource assignments.
7. As a result of reviewing the stage status and analyzing
problems, corrective action may be required.
b. Conduct Team Checkpoint Meeting Weekly:
i. The Checkpoint should be conducted as a brief, structured meeting.
ii. Communicate information to the team that can't be communicated in
a less time-consuming way. Face-to-face communication of critical
information allows the team to ask questions and discuss issues so
that there is less chance for misunderstanding.
iii. Communicate priorities related to changes to the Project Schedule
iv. Discuss issues pertinent to the team and make decisions about how
to proceed.
v. Review status of open issues and determine any further action
required on these issues.
vi. Review the status of any outstanding quality reviews.
vii. Review any new Change Requests, and add activities to the project
schedule to analyse or action changes.
Page 32 of
SOP NO: 502
ISSUE NO: 1.0 Draft
viii. Review accomplishments that bring credit to the team and

individuals. Also, communicate positive feedback from sources
outside the team (for example, the project board or business).
c. Follow up Team Checkpoint:
i. Produce an updated version of the Project Schedule in Project
Engineer, Schedule with Project Planner. Updates to the Project
Schedule can be:
1. activities marked as complete
2. change to expected completion date for an activity
3. change in team member assignments to an activity
4. additional activity added from an analysis of the current state
of the project
5. additional activity added to address an open issue
6. additional activity added to complete a quality review
7. additional activity added to analyze or action a Change
Request.
8. activity taken from the stage schedule, because the activity is
now in the Project Schedule scheduling window.
ii. Re-assess cost and completion estimates for the stage.
iii. Prepare a checkpoint report and/or a management highlight report,
as required by the progress control procedures and distribute as
appropriate.
iv. POC Administrator Creates time for the next Reporting Period and
informs all Resources when Time Reporting can commence in
ADVisor.
4. Progress reporting to the Project Board and IS Projects Office
a. Occurs monthly with the Project Board (Project Sponsor, Customer
Representatives, Technical Representatives, Project Manager and invited
guests.
b. Prepare for Project Board Checkpoint:
i. Review the project progress since the last Project Board checkpoint
review (or Stage End Assessment).
ii. Determine the highlights that need to be reported to the Project
Board.
iii. Prepare an agenda for the Project Board Checkpoint Review.
iv. Arrange and schedule a meeting of the Project Board.
v. Prepare any presentation or other material required for the Project
Board Checkpoint Review.
vi. Compile the Project Board Progress Report (See Appendix 24:
Project Board Progress Report):
1. Project Manager Name
2. Project Name
3. Stage Name
4. Current date
Page 33 of
SOP NO: 502
ISSUE NO: 1.0 Draft
c.
5. Reporting Period Start Date (Day after last Reporting Period

End Date)
6. Reporting Period End Date
7. Project Metrics. A summary of specific measures key to the
board:
a. Planned Completion Date
b. Planned Effort
c. Actual Effort
d. Planned Budge
e. Expended Budget.
f. Accomplishments for the reporting period: these
should be major accomplishments (for example,
reaching key milestones, delivering key components)
g. Plan vs. Actual: Summary of actual progress against
plan
h. Issues and Actions: Any project issues that require
decisions by the board. When possible, suggested
actions should be submitted to provide the board
with alternatives for solutions related to the issue.
i. Planned Activities for the Next Period.
j. Outlook for the next period: A projection of
accomplishments for the next period.
vii. Decide if any information should be distributed with the Project Board
Progress Report.
viii. Distribute The Project Board Progress Report ahead of the meeting.
ix. Prior to conducting the Project Board checkpoint review, prepare the
following:
1. Updated project plan.
2. Proposed changes to project/stage teams
3. Summary of project/stage status
Conduct Project Board Checkpoint:
i. Conduct the Project Board Checkpoint Review following the prepared
agenda.
ii. Communicate information to the board that can't be communicated in
a less time-consuming way. Face-to-face communication of critical
information allows the board to ask questions and discuss issues so
that there is less chance for misunderstanding.
iii. Discuss issues pertinent to the board and make decisions about how
to proceed.
Page 34 of
SOP NO: 502
ISSUE NO: 1.0 Draft
iv. Review status of open issues and determine any further action
required on these issues.
v. Review any new Change Requests, and add activities to the Project
Schedule to analyse or action changes.
vi. Review accomplishments that show the project is progressing as
planned.
d. Follow-up Project Board Checkpoint:
i. Record the decisions made by the Project Board and take any
appropriate action.
ii. In some cases, there will be a series of additional project activities
that are required to address the Project Board's requirements.
iii. Review the overall project and stage plans and identify any changes
that are required.
iv. If the section of the plan that requires change is subject to change
management, follow the change management procedure.
v. If the sections are not subject to change management, update them
and distribute to appropriate members of the Project Organisation.
vi. Update Project in Project Engineer and schedule with Project
Planner.
5. Progress reporting to the Project Steering Committee (PSC)
a. Prepare for PSC
i. Complete Presentation Slides per Project
ii. Distribute to IS Projects Office Manager
iii. Review with IS Projects Office Manager
b. Conduct PSC Meeting
i. IS Projects Office Manager conducts PSC Meeting
ii. Project manager attends and clarify any issues
iii. PSC Decisions are minutes
c. Follow-up PSC Meeting
i. Update Project Plans with Decisions
ii. Inform Project Team Members
6. Complete the Progress Control Procedure Appendix in the Project Plan. See Appendix 6:
Project Plan, with the above procedures.
Task PM.PIP.06.050: Customise Problem Reporting Procedures
1.
2.
3.
4.
Review IHD Problem Reporting System on HEAT

Review the Change Control Procedure
Customise as appropriate for the project level problem reporting requirements.
Determine the appropriate project milestones to complete root cause analysis for a set of
Problem Reports. This provides the opportunity to detect and correct process problems
during a project.
5. If a corporate problem reporting mechanism has not been established, add the Problem
Reporting Mechanism kernel of activities to the Project Template so that the appropriate
tasks may be added to the Stage Schedule to build one.
Page 35 of
SOP NO: 502
ISSUE NO: 1.0 Draft
6. The end result of a problem report is a change request, therefore, one form is often used
to document both problems and changes (See Appendix 7: Problem Report/Change
Request Form). However, additional information is collected about reported problems. It is
important to capture root cause of the problem. Through structured analysis of the
process used to develop the defective product, information is gathered to correct the
defective process, thus preventing the same problems/defect from reoccurring. Therefore,
it is important to collect root cause analysis information for each problem identified.
Task PM.PIP.06.060: Customise Issues Management Procedures
1. Identify the types of issues that may arise on the project (e.g., project scope, technical,
resource, planning, or scheduling).
2. Define a mechanism to resolve them. Issue Management must include the following:
a. Definition of the issue form (See Appendix 27: Issue Form.) It must contain
the following information:
i. Issue Name. A unique, descriptive name that will readily identify the
issue.
ii. Issue Description. A full description of the issue. It may be phrased
as a question, thus inviting an answer.
iii. Originated by. Name(s) of the people who identified the issue.
iv. Potential Impact. Description of the potential impact that the Issue
could have on the project. This may include rough estimates of time
and effort impacts that the Issue may have.
v. Priority. An indication of the urgency of the issue. Possible priorities
are:
1. Stage stopper - the issue must be resolved for work to
continue on the current stage
2. Project stopper - the issue must be resolved by the end of
the current stage for work to continue on the project
3. Low - the issue has little impact on the project at the
moment, but could become more important if it is not
resolved
4. Interesting - it would be interesting to know more about this
issue, but we do not want to expend too much effort on it
5. Not an issue - the project team is already aware of the issue,
and has addressed it in the project and stage plans
6. Irrelevant - the issue does not affect the project in any way. It
is a non-issue
vi. Date Originated. Date the issue was identified.
vii. Status. The current status of the issue. Possible values are:
1. Unassigned
2. In Progress
3. Escalated to Project Board
4. Resolved
5. Closed (did not need to be resolved)
Page 36 of
SOP NO: 502
ISSUE NO: 1.0 Draft
viii. Resolution Owner. The individual responsible for the resolution of

the issue.
ix. Proposed Resolution. A narrative description of the proposed
resolution of the issue.
x. Target Date for Resolution. The date by which a resolution is
required.
xi. Resolution. A narrative description of the current status of the issue,
how the issue was resolved, and any subsequent actions.
xii. Resolved by. The individual(s) who actually resolved the issue.
xiii. Date Resolved. The date the issue was last worked on, and the
date it was resolved.
b. Definition of the Issue Log. (See Appendix 28: Issue Log) The Issue Log is a
summary of the Issue Form and shall contain the following information:
i. Issue Name. A unique, descriptive name which will readily identify
the issue.
ii. Originated by. Name(s) of the people who identified the issue.
iii. Priority. An indication of the urgency of the issue. Possible priorities
are:
1. Stage stopper - the issue must be resolved for work to
continue on the current stage
2. Project stopper - the issue must be resolved by the end of
the current stage for work to continue on the project
3. Low - the issue has little impact on the project at the
moment, but could become more important if it is not
resolved
4. Interesting - it would be interesting to know more about this
issue, but we do not want to expend too much effort on it
5. Not an issue - the project team is already aware of the issue,
and has addressed it in the project and stage plans
6. Irrelevant - the issue does not affect the project in any way. It
is a non-issue
iv. Date Originated. Date the issue was identified.
v. Status. The current status of the issue. Possible values are:
1. Unassigned
2. In Progress
3. Escalated to Project Board
4. Resolved
5. Closed (did not need to be resolved)
vi. Resolution Owner. The individual responsible for the resolution of
the issue.
vii. Target Date for Resolution. The date by which a resolution is
required.
viii. Date Resolved. The date the issue was last worked on, and the
date it was resolved.
ix.
c. Logging of issues:
Page 37 of
SOP NO: 502
ISSUE NO: 1.0 Draft
i. Identify Project Issue

1. Identify, log and describe an issue that is thought to affect the
project.
2. Any person in the Project Organisation should be allowed to
raise an issue.
3. If you are using a Groupware tool, such as HEAT, it should
be possible to view the Issues Log automatically. If you are
using a manual, or semi automated system, one person
should be responsible for collating the forms and maintaining
the Issues Log. This is usually a responsibility of the
Planning Coordinator or Project Manager
4. The following items should be completed on the Issues Form
when an Issue is raised:
a. Issue Name
b. Issue Description
c. Originated by
d. Potential Impact
e. Date Originated
f. Status
g. Proposed Resolution
d. Assess impact of Issue.
i. Assess the impact of the issue on the project and assign a priority
ii. Consider the following potential impacts on the project in assessing
the issue:
1. Scope of the project
2. Project risks
3. Quality of final product of the project
4. Quality of intermediate products
5. Affect on stage schedule
6. Affect on project schedule
7. Affect on project resources
8. Affect on project budget
9. Affect on project benefits
iii. Determine if the issue is within the scope of the project, and if it is
not, decide if the scope should be extended.
iv. Estimate any additional work required to address the issue. If the
Issue does not affect the Project, the Issue can be marked as closed.
It is useful to keep these Issues on the list, so that it is clear that the
Issue was identified and assessed.
v. If the issue requires effort, determine an approach to resolve the
issue.
vi. Allocate any resources required to resolve the issue, and schedule
the resources to do the work.
Page 38 of
SOP NO: 502
ISSUE NO: 1.0 Draft
vii. The Project Manager will usually prioritise Issues and decide what
actions to take. Team members should be encouraged to define
ideas on how to resolve issues.
viii. Update the issue log with the following information:
1. Potential Impact. A description of the potential impact that
the Issue could have on the project. This may include rough
estimates of time and effort impacts that the Issue may have.
2. Priority. The priority assigned to the Issue.
3. Status. The status should be updated to In Progress or
Closed.
4. Owner. The individual responsible for the resolution of the
issue.
5. Proposed Resolution. A narrative description of the
proposed resolution of the issue.
6. Target Date for Resolution. The date by which a resolution
is required
e. Monitor progress in resolving the issue.
i. The resources assigned to the Issue should resolve the issue.
ii. The Issues Log should be reviewed at the team's regular checkpoint
meetings. The people responsible for resolving issues should
describe their progress. If the Issue has been resolved, the resolution
details should be recorded on the Issues Form and the status
updated to Resolved.
iii. In some cases, the Project Manager may not have suitable authority
to resolve an Issue. In this situation, the Issue should be escalated to
the Project Board. It may be necessary to hold a special Project
Board meeting to review the Issue.
iv. Each Issue should be monitored until it is resolved. Resolution
means that the Issue is no longer a threat to the project.
v. The Issue Form should be updated as follows:
1. Potential Impact. May be updated during resolution,
depending on further information that may be obtained.
2. Priority. May be updated during resolution, depending on
the progress in resolving the issue.
3. Status. The status should be kept up to date until the Issue
is resolved.
4. Owner. The individual responsible for the resolution may
change, especially if the Issue is escalated to the Project
Board.
5. Proposed Resolution. This may be revised while the Issue
is being resolved.
6. Target Date for Resolution. This may be revised while the
Issue is being resolved. If possible, a record of target dates
should be retained.
7. Resolution. This should be completed when the Issue is
resolved.
Page 39 of
SOP NO: 502
ISSUE NO: 1.0 Draft
8. Resolved by. This should be completed when the Issue is

resolved.
9. Date Resolved. This should be completed when the Issue is
resolved.
f. Communication and escalation of issues
i. Make the Issue log and Issue forms available to all Project Members
either by using HEAT an/or in Harvest Change Manager.
ii. Issues that will have an impact on the Project Cost, Time,
Requirements and scope that can not be authorised by the Project
Manager must be escalated to the Project Sponsor for resolution
3. Update the Issue Resolution Procedure in the Project Plan. (See Appendix 6: Project
Plan)
Task PM.PIP.06.070: Customise Cost Control Procedures
1. Determine the mechanisms to be used to monitor project costs. Project cost management
includes the processes required to ensure that the project is completed within the
approved project budget.
2. The Cost Control Procedures describes how cost variances will be managed (e.g.
different responses to major problems than to minor ones). The Cost Control Procedures
may be formal or informal, highly detailed or broadly framed, based upon the needs of the
project stakeholders.
3. Ensure that the relevant IHD Finance Department SOPs are adhered to, specifically:
a. Policies and Procedures for Capital Expenditure
b. Accounting Policies, Controls and Procedures
c. PF04 - Policy Regarding General and Year End Accounting
d. F24 - Accounting Procedures for Fixed and Leased Assets
e. F03 - Signature Approval / Authority Limits to Committing Company Funds
f. F01 - Trading with and Paying of Suppliers/Creditors.
4. Project Costs consist of the following:
a. All costs in a project is capitalised even if it is OPEX.
b. Variable costs. These include labour measured in hours (IHD internal staff
and outsourced staff) and material costs measured in units assigned:
c. Fixed costs
d. The project costs will then be depreciated when the project is completed and
the project sponsor start getting benefit from the main project deliverable.
5. Cost control process:
a. Monitor Cost Performance
i. Detect Changes from various performance reports:
1. Team Progress Reports
2. Actual values on Timesheets using iTime
3. Schedule against last approved baseline
4. Accounting Variance Reports supplied by Finance or from
Delta I.
5. Project Planner Reports.
Page 40 of
SOP NO: 502
ISSUE NO: 1.0 Draft
6. Price Quotations from suppliers for resources

7. Change Request Impact Analysis
ii. Compare against Project Cost Baseline the last approved Project
Budget (See Appendix 6: Project Plan).
iii. Understand variances (negative and positive)
iv. Document Variance Reasons
b. Prevent incorrect, inappropriate, or unauthorised changes from being
included in the cost baseline:
i. Before procurement:
1. Obtain quote
2. Choose best quote
3. Requisition an Order:
a. Complete an Order Requisition Form (See Appendix
29: IHD Order Requisition Form)
b. Attach the relevant Project Budget page from the
Project Plan to the Order Requisition and indicate on
the Project Budget where the Project Cost will be
incurred.
c. Project Manager requests by signing after
requested by.
d. IS Projects Office Manager signs.
e. Cost Centre Manager signs if different from the IS
Projects Office Manager.
4. If item to be procured is a CAPEX item:
a. Complete the IHD Asset Procurement Authorisation
Form Forms FA 6 (See Appendix 30: IHD Asset
Procurement Authorisation - Form FA 6):
b. Attach to Order Requisition Form
c. Project Manager requests by signing after
requested by.
d. IS Projects Office Manager signs.
e. Cost Centre Manager signs if different from the IS
Projects Office Manager.
f. Relevant Executive signs
g. Chief Executive Officer signs
5. Submit Order Requisition (with Asset Procurement
Authorisation if necessary) to Finance:
a. Procurement assign an Purchase Order Number
b. Finance place order
6. Record Purchase Order Number against Project Budget Cost
Item.
ii. After delivery of procured item. That includes equipment, material or
a deliverable after a Review as been performed.
1. For equipment (it includes project defined deliverables) and
material:
a. Review deliverables
Page 41 of
SOP NO: 502
ISSUE NO: 1.0 Draft
b. Project Manager check that the correct items has

been received
2. For Labour:
a. Project Manager review printed timesheets from
iTime for external, outsourced labour resources.
b. Project Manager sign timesheets
c. IS Projects Office Manager signs timesheets.
d. Cost Centre Manager signs timesheets
3. Project Manager signs Supplier Invoice
4. IS Projects Office Manager signs Invoice
5. Cost Centre Manager signs Invoice
6. Record Supplier Invoice Details against Purchase Order
Number
iii. After a cost variance. Obtain approval for cost variances if tolerance
is exceeded from Project Board or Project Steering Committee.
Authorise all Costs for the Project:
iv. Project Accounting Coordination:
1. Finance performs accounting function
2. Project manager must schedule regular meeting to
coordinate Accounting entries with the Project Budget actual
Costs.
c. Record approved cost changes accurately against baseline:
i. Update Resource in POC with new cost. That includes equipment,
material and labour.
1. Labour. Add new Bill Rate with start and end dates in POC
2. Material: Add new Bill Rate with start and end date in POC
3. Equipment: Change Bill Rate to new cost
ii. Update Finance about approved cost changes
d. Inform appropriate stakeholders of authorised cost changes.
i. Follow the Exception Management procedure if there is a cost
exception out of the agreed cost tolerance.
ii. Communicate Change Request Impact if there is a cost implication.
iii. Update costs in Project Planner, POC and Project Engineer to make
it visible in ADvisor.
iv. Report the following in Project Board Progress Reports, Stage
Reports and Project Steering Committee progress:
1. Cost Baseline.
2. Actual and committed costs
3. Variance
4. Forecast - Estimate at Completion (EAC). Can be one or a
combination of:
a. Current estimates are fundamentally wrong. EAC =
Actual Cost to date + New estimate for all remaining
work.
Page 42 of
SOP NO: 502
ISSUE NO: 1.0 Draft
b. Current estimates are not typical and will not reoccur. EAC = Actual Cost to date + remaining
budget.
c. Current variances are typical of future variances.
Actual Cost to date + remaining budget modified by
a performance factor.
e. Take corrective action to bring project back within acceptable cost tolerances:
i. Reduce scope of project
ii. Increase productivity of labour resources
iii. Renegotiate costs with suppliers.
iv. Procure alternate resources form alternative suppliers.
v. Sacrifice Quality of Product
vi. Reduce number of resources (Labour and Material)
vii. Reduce effort to perform an activity
viii. Crash project. Decrease the total duration of a project.
f. Before IHD Financial Year end (December):
i. When a Project Schedule spans across a financial year-end, accrue
for Project Costs not spent in a financial year to be spent in the next
financial year.
ii. Involve Finance
g. After Project Sign-off:
i. Transfer depreciation of CAPEX Items to the relevant Line Function
Cost Centres.
ii. The date depreciation starts equals the go-live date of the projects
main deliverable.
iii. Involve Finance.
6. Update the Project Plan (See Appendix 6: Project Plan) with the Cost Control Procedure
for this project.
Task PM.PIP.06.080: Define Exception Management Procedures
1. Identify the tolerances on the project plan that will be accepted before the Project Board is
automatically alerted. Tolerance is the level of deviation from the project plan the Project
Sponsor will accept before being notified. Establish Tolerances for:
a. Actual cost vs. Estimated cost
b. Actual effort vs. Estimated effort
c. Actual time vs. Elapsed time (duration)
d. Actual resource availability vs. Planned availability
e. Actual product quality vs. Standard quality
2. The inner and outer limits of tolerance are usually expressed as a plus/minus percentage
on the planned completion date. Tolerance constitutes the authority level, or amount of
discretion that is given to the Project Manager
3. Define the procedures for dealing with exceptions. Exceptions are any major variation
(exceeding the established tolerance levels) from the project plan that requires action
from the Project Board.
Page 43 of
SOP NO: 502
ISSUE NO: 1.0 Draft
4. The exception management procedure is as follows when an exception should occur (i.e.
one of the tolerances are exceeded):
a. Analyse Cause of Exception Situation. Analyse the causes for the project
being out of tolerance and identify options for getting the project back on
plan. There are a number of reasons the project can be out of tolerance:
i. Resource availability
1. Excessive non-effective time
2. Unscheduled activities
ii. Performance
1. Motivation/Commitment
2. Higher learning curve than expected
3. Skill levels
4. Ineffective process/tool
5. Quality of work
iii. Activities
1. Unrealistic estimates
2. Dependencies (either within the project or external)
iv. Quality of products
v. Lack of business partner involvement
b. Create Exception Plan
i. Review the options for getting the project back on plan
ii. Decide if there is a clear course of action that should be taken
iii. If there is a single course of action, prepare a plan based on this
option for recommendation to the Project Board
iv. If it is not clear what option should be taken, prepare an analysis of
the options for the Project Board together with an outline exception
plan for each option.
v. An exception plan should contain:
1. Short term schedule of activities required to get the project
back on track
2. Analysis of the impact of the exception situation on the
project in terms of:
a. Cost
b. Resource Requirements
c. Time Line
d. Revised Business Case
3. Recommended changes to
a. Project Scope
b. Overall Project Schedule
c. Project Organisation
Page 44 of
SOP NO: 502
ISSUE NO: 1.0 Draft
d. Project Budget
Prepare for Exception Assessment
i. Arrange a project assessment meeting of the Project Board to decide
what course of action to take on the project
ii. Prepare an agenda and any presentation material that will be
required to present the cause of the exception situation and the
resulting exception plan(s) to the Project Board in order for them to
make a decision
iii. If possible, decide on a recommendation for the Project Board
d. Conduct Exception Assessment
i. Conduct the Project Assessment meeting
ii. The Project Board should make a decision on how to proceed with
the project that the Project Manager and Project Team can follow
e. Follow-up Exception Assessment
i. Record the decision made by the Project Board.
ii. Take the appropriate action.
1. In most cases, this will be a series of additional project
activities that are required to address the causes of the out of
tolerance situation.
2. Review the overall project and stage plans and identify any
changes that are required
3. If the section of the plan that requires change is subject to
change management, follow the change management
procedure
4. If the sections are not subject to change management,
update them.
5. Update Project Engineer, POC and Project Planner.
6. Communicate and distribute to appropriate members of the
Project Organization.
5. Complete the Exception Management Appendix in the Project Plan (See Appendix 6:
Project Plan) and add the Tolerance levels.
6. Set the tolerance levels in ADVisor.
a. Login to ADVisor.
b. Click on Project Website/Preferences/Organization
c. Set Tolerance level for:
i. Budget
ii. Effort
iii. Schedule
c.
Task PM.PIP.06.090: Define Other Project Controls

1. Identify additional procedures as required to control the project
2. Revise any corporate procedures for the project as necessary
3. Identify the means for managing requirements on the project. Requirements
Management defines how the agreed requirements of a project will be managed.
Page 45 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Requirements provide the basis for defining the project and validating the completed
solution through testing and other quality activities. The process templates support
requirements management by defining activities that include
i. Users' heavy participation in project activities through the use of the
Interactive Development technique
ii. Baselining of requirements
iii. Completion of a Requirements Traceability matrix as a part of Stage
End Assessment for each project to provide product validation
iv. Customer approval/signoff at each Stage End Assessment
4. Define the Procurement Management Plan. This may be a collection of procedures from
IHD Purchasing department.
5. Customize the IHD Subcontractor Management Plan.
a. Once a contractor is found, a documented agreement covering the technical
and non-technical (e.g., delivery dates) requirements is established and used
as the basis for managing the subcontract.
b. Part of the documentation should be a plan for the work and quality
standards and procedures.
c. If a corporate subcontractor management plan does not exist, insert the
kernel concerning Subcontractor Management.
6. Complete the relevant Appendices in the Project Plan (See Appendix 6: Project Plan)
1. Review each product using the Inspection Review Technique and Change Control
Procedures:
a. Exception Management Procedures
b. Tolerance Parameters
c. Quality Plan
d. Configuration Management Plan
e. Baselining Procedures
f. Configuration Item Relationships
g. Problem Reporting/Change Request Procedures
h. Issue Resolution Procedures
i. Communication Plan
j. Progress Control Procedures
k. Cost Control Procedures
l. Any other procedures defined.
2. Compile the above component products into the Parent Product - Project Control
Procedures.
Page 46 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Page 47 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PIP.07: Project Initiation and Planning Stage Assessment

To
document the results of the Project Initiation & Planning stage and to have the results
reviewed by management
in a way that
provides a comprehensive package of information from which a decision can be

made
gains agreement on the Business Case for the project
gains agreement on the scope of project
gains agreement on the overall approach and schedule for the project
gains agreement on the Project Organization
gains commitment to making the necessary resources available for the project
gains agreement to the approach and schedule for the next stage of the project
gains agreement to the control procedures defined for the project
provides a record of the project and stage plans for use in managing and controlling
the project if it gets authorization to proceed
confirms that the Project Initiation & Planning stage is complete
so that
a decision can be made as to whether to commit to and authorize the project
Task PM.PIP.07.010: Complete Project Plan
1. Produce the Project Plan, using all the products created in previous steps.
2. Prepare a Project Recommendation:
a. Analyse the business case for the project and prepare recommendations on
whether/how to proceed for review by the Project Board
b. This information is summarized into the Project Recommendations section of the
Project Plan. Based on the Business Case and the Risk Analysis
3. Revise the project schedule to include any activities identified during the previous tasks
using Project Engineer, POC and Project Planner.
4. Check Project Plan package into Harvest Change Manager and promote to Draft State.
Task PM.PIP.07.020: Review Project Plan
1. Freeze the Project Plan for any further changes.
2. Conduct an Inspection Review of the Project Plan, the major deliverable of the Project
Planning & Initiation Stage following the Inspection Review Technique.
Page 48 of
SOP NO: 502
ISSUE NO: 1.0 Draft
3. Apply any changes following the Change Control Procedure.

Task PM.PIP.07.030: Prepare Stage End Assessment
1.
2.
3.
4.
5.
Determine the recommendations to be made to the Project Board.

Gather the information the Project Board needs to make decisions.
Prepare any necessary briefing material.
Prepare a PowerPoint Presentation.
Prepare a brief Stage Report covering the work carried out during the Project Initiation &
Planning Stage. (See Appendix 25: Stage Report)
6. Arrange and schedule the meeting. The Agenda must contain the following items:
a. Review Project Plan
b. Review Project Scope
c. Review the Project Schedule
d. Review the next stage plans
e. Review Project Control Procedures
f. Review the Project Organization
g. Review the Business Case
h. Review and resolve issues
i. Make appropriate decisions to go ahead with project.
7. Distribute in advance materials, including agenda and Stage Report
Task PM.PIP.07.040: Conduct Stage End Assessment
1. Present the results of the Project Initiation & Planning Stage to the Project Board by
following the prepared agenda.
2. Request approval to proceed with the Project. It may one of the following decisions:
a. Refer to the Project Steering Committee for disposition.
b. Approve and go ahead
c. Approve on conditionally.
d. Implement changes and present again
e. Put Project on hold
f. Cancel Project
3. Update the Project Plan and next stage schedule based on the decisions made by the
Project Board.
4. Document approvals by requesting the signature of Project Board members.
5. Decide, with the Project Board, whether or not to provide a presentation of the project to a
wider audience (e.g., in the form of a "Kick-Off" meeting). The audience would include
additional business or IT groups that will be directly or peripherally involved in the project.
6. Distribute meeting minutes or other products (e.g., updated product baselines) to
attendees.
Page 49 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Task PM.PIP.07.050: Complete Process Review

1. Complete a Process Quality Assurance Review of the Project Initiation & Planning Stage
to ensure required procedures were completed as required and approval to proceed with
the project was obtained and documented.
2. Complete the Process Quality Inspection Checklist - Project Initiation & Planning Stage
Assessment (See Appendix 26: Process Quality Inspection Checklist PIP Stage
Assessment)
3. Based on the results of the review, determine if a Problem Report/Change Request
(PR/CR) form should be initiated on the process being audited. If appropriate, complete a
PR/CR form to initiate process improvement activities. (See Appendix 7: Problem
Report/Change Request Form)
4. Distribute the results of the review (Process Quality Assurance Checklist and any PR/CR
forms) to the appropriate team members, the project manager, and the IS Projects Office
Manager (in the role of Process Manager).
Task PM.PIP.07.060: Baseline Project Plan
1. Ensure that change requests (PRs/CRs) that were generated as a result of the inspection
have been closed.
2. Ensure that the Project Plan (Major deliverable) has been approved.
3. Freeze the project baseline.
a. Check in all the updated, final, components of the Project Plan package into
Harvest Change Manager.
b. Promote the Project Plan Package to Final Status.
4. Distribute the baseline to appropriate individuals/teams and to the Projects Office
5. Create a new version of the baseline to use as a rolling baseline (objects can be checked
in/out without changing the baseline version) to support continued development of
products.
Page 50 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Stage PM.PCTL: Project Control

To
manage project work during a stage and prepare for the next stage
in a way that
controls project progress

resolves any issues identified during the stage
provides reports to management as defined in the stage schedule
so that
this stage can reach a successful conclusion and the project can progress to the next
stage.
Page 51 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PCTL.01: Stage Management

To
start the project work on the stage
in a way that
gains agreement and commitment to the stage plan from the project team
initiates the on going day by day planning of stage activities
initiates the stage control procedures
informs stakeholders what the project is about and how it is progressing
so that
the project team members can begin to work as a team for the success of the stage
and project
Task PM.PCTL.01.010: Kick Off the Stage
1. Acquire new resources for the Project Team. These can be both human and non-human
resources.
2. Ensure project Team Members are trained according to Project Training Plan
3. Organise physical resources for the Project Team members:
a. Office space
b. Equipment:
i. Computer with access
ii. Printer with access
c. Telephone service
d. Supplies
e. Services:
i. Login to IHD LAN
ii. Outlook
iii. MS Office
iv. ADVisor
v. Access Cards
4. Define Commitment Calendars by creating time in POC for project members to be able to
capture actual effort in iTime.
5. Brief Project Team using the Project Pitch, a PowerPoint Presentation. Cover the
following items:
a. Define the overall Project
b. Current Status
c. Detailed plans for current stage
d. Introduce participants who may come from different parts of IHD or are from
external suppliers
Page 52 of
SOP NO: 502
ISSUE NO: 1.0 Draft
e. Establish expectations related to control procedures (quality, progress, issues,

change)
f. Gain commitment from the project team members
g. Establish visibility for the project and team
h. Build morale
i. Documentation required to perform activities
Task PM.PCTL.01.020: Monitor Project Progress and Cost
1. Because no project goes exactly as planned, it is important to monitor the degree to
which the plan is being followed, and to take appropriate action if the project is deviating
significantly from the plan.
2. Apply the Progress Control Procedures that were defined during the Project Initiation &
Planning stage. These procedures cover day-to-day progress tracking of the team, up to
Project Board, IS Projects Office and Project Steering Committee reporting:
a. Time Reporting. Ensure Project members complete and save Timesheets daily
using iTime.
b. Team Checkpoint Meetings - Weekly:
i. Collect Team Progress Reports
ii. Review Project Progress
iii. Schedule weekly Team Checkpoint Meetings
iv. Conduct weekly Team Checkpoint Meetings
v. Follow up Team Checkpoint Meeting and update Project Engineer, POC
and Project Planner
vi. Produce & distribute weekly Project Checkpoint Report
c. Project Board Checkpoint Meetings Monthly:
i. Prepare for Project Board Checkpoint write Project Board Progress
Report (See Appendix 24: Project Board Progress Report)
ii. Conduct Project Board Checkpoint
iii. Follow-up Project Board Checkpoint
d. Project Steering Committee Meetings
i. Prepare for PSC
ii. Conduct PSC Meeting
iii. Follow-up PSC Meeting
3. Monitor project costs by following the Cost Control Procedures detailed during the
Project Initiation & Planning stage to ensure that the project is completed within the
approved budget.
4. When any of the stage tolerances are exceeded, the stage manager should carry out the
activities in the Manage Exception Situations task and the associated technique to
regain control of the project.
Task PM.PCTL.01.030: Identify and Resolve Issues
Page 53 of
SOP NO: 502
ISSUE NO: 1.0 Draft
1. Issues can arise at any time and can come from any source. An issue is a matter of
concern which creates a barrier to the progress of the project. The resolution of an issue
can impact any aspect of the project, including scope, costs, benefits, risks, project
organization, estimates and schedule. The goal is to prevent issues from having an
adverse affect on a project.
2. Often, issues are identified during checkpoint reviews. Some may have a bearing on the
project, and some will be of little consequence. Any issues that arise should be evaluated
and dealt with as efficiently and effectively as possible. An issue can often linger on, even
after it has supposedly been resolved, so it is important to track issues to complete
resolution.
3. Carry out the procedure described in the Issues Management technique:
a. Identify Project Issue
b. Log Issue
i. Complete Issue Form (See Appendix 27: Issue Form)
ii. Complete Issue Log (See Appendix 28: Issue Log)
c. Assess impact of Issue.
d. Monitor progress in resolving the issue
e. Communicate issues
f. Escalate issues
Task PM.PCTL.01.040: Communicate and Market Project
1. Communicate and market the project to the organisation applying the Project
Communications Plan (See Appendix 22: Project Communication Plan). This may take
several forms, and being prepared is the best attack.
2. Update the Project Pitch (PowerPoint Presentation). For times when a quick
presentation about the project is needed, present the Project Pitch. This is a short
presentation, usually two to five power point slides that generally explains the high points
of the project. The best source of information is the Executive Summary in the Project
Plan.
3. Prepare an "Elevator Speech" for the project in PowerPoint. This speech is a very quick
look at the project. Prepared ahead of time, this speech is wonderful for when senior
management asks what you're working on. In this speech, cover the following:
a. what the product does
b. who it's for
c. what the benefits are
d. why it's unique
4. Market the Project regularly by using:
a. Email
b. Project Newsletter
c. IHD Newsletter
5. Make the Project available in ADVisor for Project Stakeholders to access and see:
a. Create Stakeholder in POC as a resource.
b. Provide URL to Stakeholders: http://lp-db2-01/advisor3/AdvService
c. Let Project Stakeholders view the Project Details on ADVisor.
Page 54 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Task PM.PCTL.01.050: Execute Change Control Procedures

1. Change is inevitable in any project. Change Requests may be submitted for a variety of
reasons:
a. New business requirement
b. New legislation
c. Changes in the business
d. Resolution of an issue
e. A problem that must be solved
f. Different thinking about the product
2. Apply the Change Control Procedures in the Project Configuration Management Plan
(See Appendix 20: Project Configuration Management Plan)
a. Informal change control is applied during a product's early development. This
informal change control is referenced/used by the Walkthrough Review
technique and serves to ensure that the development of the product can quickly
evolve without unnecessary delays
b. Formal change control should be applied to a product that has evolved to a more
stable point in its development and is reviewed using the Inspection Review
technique. The Inspection Review technique includes a formal quality review;
and after approved changes are implemented, establishes an approved product
baseline
c. Log all problems following the Problem Reporting Procedure
3. Formal Change Control:
a. Document Request for Change
i. Document both problems and enhancements on the standard Change
Request/Problem Report form. (See Appendix 7: Problem
Report/Change Request Form).
ii. Update the Change Request Log with a reference to the new Change
Request/Problem Report. (If using an automated change request system,
this is done automatically by the system.)
iii. Change Request/Problem Report forms are only used to document
requests to base lined products
b. Analyze Impact
i. Assign the Change Request/Problem Report to a team member for
analysis to promote better understanding of the request. This analysis
may determine that due to a misunderstanding or user error, the request
should be recommended for disapproval
ii. If so, stop here and submit a recommendation to the Change Control
Board for disapproval of the request
iii. If the request is valid, complete a detailed analysis of the real and
potential impacts of implementing the request.
1. Assess the impact of the potential change, taking into account
business, customer and technical impact.
2. Identify changes required to any baseline products and estimate
the effort required to make the changes.
Page 55 of
SOP NO: 502
ISSUE NO: 1.0 Draft
3. Identify changes required to current work, and estimate the

additional effort required to incorporate the changes
4. Identify changes required to scheduled work and estimate the
change in effort resulting from the change.
5. Identify any changes to other parts of the Stage and Project
Plans that may be needed if the change is actioned.
iv. Review or assign a Severity level to the request (the originator of the
request may have assigned a severity level, but this may need to be
modified based on the analysis of the request). A suggested set of
severity levels are:
1. Critical
2. High
3. Medium
4. Low
c. Submit For Change Control Board (CCB) Disposition and Implementation
i. All Change Requests and Problem Reports must be reviewed and
approved by the Change Control Board (CCB). The CCB will determine
whether the request is
1. approved
2. approved with modifications
3. disapproved
ii. Ensure that the right individuals (e.g., the originator of the request, the
product developer, appropriate management, quality assurance) attend
the CCB meeting where the request will be reviewed and dispositioned.
iii. Confirm and update if necessary, the Severity rating for each PR/CR. The
Severity rating is used to assist in prioritization and grouping of PR/CRs
with the appropriate development iteration/release where it should be
implemented
iv. Log the disposition of the request in the Change Control Log
v. Submit approved requests through the normal technical channels for
implementation
d. Log Implementation Status
i. Modify the Status field of the Change Request/Problem Report as it is
completed:
1. In progress
2. Fixed
ii. Log the specific Configuration Items (CIs) that were added, changed or
deleted
iii. Log the product release/version number the in which the change will be
implemented
e. Close Change Request
i. Modify the Status field of the Change Request/Problem Report as it is
closed out:
1. QA approved
2. Originator Approved
Page 56 of
SOP NO: 502
ISSUE NO: 1.0 Draft
ii. Log Closure Date as the date change was QA approved. (This date will
be the date testing/QA approves the product baseline which implements
the change.)
iii. Contact the originator to ensure they are happy with the implemented
change.
4. Informal Change Control:
a. Document Individual Comments/Requests
i. Requests may be documented during an Interactive Review Meeting
where the product is reviewed/ exercised during the meeting. In the case
of an electronic prototype, some exercising of the prototype may take
place by reviewers after the meeting, on an individual basis, for a limited
time period (1 week). The following documentation guidelines can be
used to document comments/requests collected via either type of review
ii. Document problems and enhancements in a list format via e-mail or via
documents created in a word processor. Provide ample identification and
description of the problems and enhancements in the product being
reviewed
iii. Send comments/requests to the Review Facilitator
b. Summarise Comments/Requests
i. Post individual review comments/requests where they can be accessed
by all reviewers (e.g., common server directory).
ii. Roll all comments into a Walkthrough Report (See Appendix 8:
Walkthrough Report).
iii. Collect Rough Order of Magnitude (ROM) estimates for each request
iv. Identify type of request (e.g., defect, enhancement).
v. List actions required to implement each request
vi. Distribute summary (Walkthrough) report to all reviewers and other
appropriate team members and management
vii. Schedule analysis and dispositioning of comments/requests
c. Analyse and Disposition Review Comments/Requests
i. Complete analysis of the comments/requests, noting impacts to other
evolving products and/or approved base lined products. Because an
informal review is considered a part of the development process,
comments/requests are less likely to "critically impact" the project and
more likely to simply be used as additional information required to
develop the product. However, care should always be taken to ensure
that other products/objects that may be affected by the comment/request
are identified and fully understood.
ii. Document the details/actions that need to take place to resolve each
comment/request in the Walkthrough Report (See Appendix 8:
Walkthrough Report)
iii. In a meeting format, or via electronic posting, work with the review team
and quality assurance to agree on the disposition of each comment/
request. Using the same team, prioritise the comments/requests.
iv. Update the Walkthrough Report to reflect the disposition of each
comment/request.
Page 57 of
SOP NO: 502
ISSUE NO: 1.0 Draft
d. Submit Summary Report for Implementation

i. Submit the Walkthrough Report through the normal technical channels for
implementation.
ii. Update the appropriate products and product specifications to reflect the
decisions made.
e. Close Walkthrough Report
i. Ensure all comments/requests have been resolved by validating that the
product's design or latest version reflects the comments/requests
documented in the summary report
ii. Change the disposition of each comment/request to "resolved
iii. Close the Walkthrough Report by documenting who approved the report
as officially closed and noting the closure date.
Task PM.PCTL.01.060: Manage Exception Situations
1. One aspect of the project control procedure is to monitor the progress on the project with
respect to agreed tolerances. These tolerances are usually set in the areas of:
a. Cost
b. Time
c. Quality
2. When an out-of-tolerance situation is identified as defined in the Project Plan, follow the
Exception Management Procedure as specified in the Project Plan:
a. Analyze Cause of Exception Situation. Analyze the causes for the project being
out of tolerance and identify options for getting the project back on plan. There
are a number of reasons the project can be out of tolerance:
i. Resource availability
1. Excessive non-effective time
2. Unscheduled activities
ii. Performance
1. Motivation/Commitment
2. Higher learning curve than expected
3. Skill levels
4. Ineffective process/tool
5. Quality of work
iii. Activities
1. Unrealistic estimates
2. Dependencies (either within the project or external)
iv. Quality of products
v. Lack of business partner involvement
b. Create Exception Plan
i. Review the options for getting the project back on plan
ii. Decide if there is a clear course of action that should be taken
Page 58 of
SOP NO: 502
ISSUE NO: 1.0 Draft
iii. If there is a single course of action, prepare a plan based on this option
for recommendation to the Project Board
iv. If it is not clear what option should be taken, prepare an analysis of the
options for the Project Board together with an outline exception plan for
each option.
v. An exception plan should contain (See Appendix 31: Exception Plan):
1. Short term schedule of activities required to get the project back
on track
2. Analysis of the impact of the exception situation on the project in
terms of:
a. Cost
b. Resource Requirements
c. Time Line
d. Revised Business Case
3. Recommended changes to
a. Project Scope
b. Overall Project Schedule
c. Project Organisation
d. Project Budget
c. Prepare for Exception Assessment
i. Arrange a project assessment meeting of the Project Board to decide
what course of action to take on the project
ii. Prepare an agenda and any presentation material that will be required to
present the cause of the exception situation and the resulting exception
plan(s) to the Project Board in order for them to make a decision
iii. If possible, decide on a recommendation for the Project Board
d. Conduct Exception Assessment
i. Conduct the Project Assessment meeting
ii. The Project Board should make a decision on how to proceed with the
project that the Project Manager and Project Team can follow
e. Follow-up Exception Assessment
i. Record the decision made by the Project Board.
ii. Take the appropriate action.
1. In most cases, this will be a series of additional project activities
that are required to address the causes of the out of tolerance
situation.
2. Review the overall project and stage plans and identify any
changes that are required
3. If the section of the plan that requires change is subject to
change management, follow the change management procedure
4. If the sections are not subject to change management, update
them.
5. Update Project Engineer, POC and Project Planner.
Page 59 of
SOP NO: 502
ISSUE NO: 1.0 Draft
6. Communicate and distribute to appropriate members of the

Project Organization.
Page 60 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PCTL.02: Stage End Assessment

To
document the results of the current stage, prepare for the next stage, and have the
results reviewed by management
in a way that
ensures requirements can be traced from stage to stage

provides a summary of the work carried out in the stage
identifies the tasks necessary to carry out the next stage of the project
develops a detailed schedule and approach for the next stage of the project
gains agreement on any revisions to the overall scope of project, approach, business
case, human/nonhuman resources, control procedures and schedule
provides a record of the project and stage plans (for project management and control)
if authorization is given to proceed
confirms that the stage is complete
so that
a decision can be made as to whether to commit to and authorise the project to
proceed
Task PM.PCTL.02.010: Ensure Requirements Traceability

1. A requirements traceability matrix is needed to ensure that each requirement is fully met.
2. Create a matrix that maps components from the previous stage to components in the
current stage to show how requirements can be traced from stage to stage, component to
component, to the finished product.
3. Suggested mappings for a standard project:
a. project scope to problem/requirements list
b. problem/requirements list to solution-definition components
c. problem/requirements list to test cases
d. solution-definition components (prototype) to build (production) components
e. build components to application/system
Task PM.PCTL.02.020: Review Project Deliverables
1. Major Deliverables (products) require an Inspection Review, completed as a part of this
task. The purpose of the Inspection Review is to verify the accuracy of the product by
identifying any problems or defects
Page 61 of
SOP NO: 502
ISSUE NO: 1.0 Draft
2. Freeze the Stages Major Deliverables by checking into Harvest Change Manager and
promote the package to Draft Status. The Major Deliverables will differ depending on the
Project approach chosen. Refer to the Project MRI for list of Major Deliverables.
3. Perform Inspection Reviews on each Major Deliverable and apply the Change Control
Procedure.
4. Problem reports or change requests (PRs/CRs) may be generated as a result of the
inspection. Some of the PRs/CRs may be resolved immediately. If there are no requested
changes as a result of the inspection, the product is held ready for the upcoming
baselining activity.
5. All PRs/CRs must be resolved before approval.
Task PM.PCTL.02.030: Develop Schedule for Next Stage
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Refine the step- and task-level activities for the next stage
Include technical and management activities for controlling progress and change.
These include checkpoints, Project Board progress meetings, and stage assessments.
Tune the work breakdown structure for the next stage based upon the scope, objectives,
and constraints of the project:
a. remove unnecessary steps/tasks
b. include additional steps/tasks to reduce risks
Determine the sequence of activities in the steps and tasks within the next stage to reflect
activity dependencies. Define dependencies, and dependency type, between activities of
the same level (e.g., step to step, task to task).
Review the customised WBS with the Process Manager and discuss the rationale for
steps and tasks waived for the next stage.
Using estimating guidelines and metrics produce initial estimates for each step and task
within the next stage. Tune these base estimates to reflect the actual circumstances
impacting the project (level of expertise, skill type). Compare the aggregation of this
bottom up estimates, to the previous estimates for this stage.
Using the estimates for the next stage, allocate specific resources (human). The
allocation may be to activities and/or to roles and responsibilities within activities. Notify
the IS Projects Office of any additional resources that will be required. This office has
responsibility for providing resources to the project manager via Project Office Console.
Formally log all assumptions and issues identified.
Update Project Engineer, POC and Project Planner.
Task PM.PCTL.02.040: Revise and Review Project Plan

1. Review the Project Plan applying the Walkthrough Review Technique.
2. Review the overall Project Budget, and make changes based on the latest Project
Schedule.
3. Review Risk Analysis and revise Risk Management Plan as necessary.
4. Update the Business Case to reflect any changes in costs, benefits and risks for the
project.
Page 62 of
SOP NO: 502
ISSUE NO: 1.0 Draft
5. Review the resource requirements and update the Project Organisation accordingly.
6. Review the latest statement of the project scope and ensure it still accurately reflects the
current status and plans for the project.
7. Obtain input and commitment from all groups (e.g., testing, quality assurance,
development, etc.) that must support or implement the plan.
8. Provide input to the IS Projects Office to ensure the Projects Portfolio database is current.
9. Update the Project Plan where necessary.
Task PM.PCTL.02.050: Prepare Stage End Assessment
1.
2.
3.
4.
Determine the recommendations to be made to the Project Board

Gather the information the Project Board needs to make decisions
Prepare any necessary briefing material
Create a Stage Report (See Appendix 25: Stage Report) covering
a. the activities performed in the stage
b. the products created or updated in the stage
c. the schedule for the next stage
d. the overall plan for the project
5. The report should be a compilation of the various products developed in the stage with
covering narratives
6. Arrange and schedule the meeting
7. Distribute advance materials, including agenda and Stage Report. The Agenda should
contain:
a. Progress report
b. Actual vs. Estimates: resource, exceptions
c. Quality report (error rate, changes in control procedures)
d. Change report (change requests, actions, rework)
e. Issues (resolved, outstanding)
f. Review of project scope, business case, project plans, project control procedures,
project organisation
g. Future outlook; preview of the next stage plans
h. Recommendations to the project board
Task PM.PCTL.02.060: Conduct Stage End Assessment
1. Present the results of the current Stage to the Project Board. Follow the prepared
agenda.
2. Request Project Board approval to proceed. In making their decision, the Project Board
must be satisfied that:
a. All appropriate activities, products and controls have been included; tolerances
reflect the necessary level of control for the next stage
b. The nature and sensitivity of assumptions, prerequisites, and risks have been
identified
Page 63 of
SOP NO: 502
ISSUE NO: 1.0 Draft
c.
3.
4.
5.
6.
Roles and responsibilities are defined; required resources are realistic and
available
d. Updated project plans conform to expectations for the next stage
Document approvals by requesting the signature of Project Board members on the Stage
Report
Minute the Meeting
Distribute meeting minutes or other products (e.g., updated product baselines) to
attendees
Provide the IS Projects Office with updated project information
Task PM.PCTL.02.070: Baseline Project Deliverables

1. Ensure that change requests (PR/CR) that were generated as a result of the Inspection
Review of each Major Deliverable have been closed.
2. Ensure that each major deliverable has been approved.
3. Freeze the project baseline.
4. Distribute the baseline to appropriate individuals/teams and to the IS Projects Office
5. Create a new version of the baseline to use as a rolling baseline (objects can be checked
in/out without changing the baseline version) to support continued development of
products.
6. Transfer the baseline for the Project Schedule in Project Planner.
Task PM.PCTL.02.080: Complete Configuration Management Audit
1. Verify that all components of the project baseline are present and that there are no
additional components/objects associated with the baseline that should not be there
2. Verify that product baselining and change control standards/procedures were followed
3. Based on the results of the review activities, determine if a Problem Report/Change
Request (PR/CR) form should be initiated on the process being audited
4. If appropriate, complete a PR/CR form to initiate process improvement activities.
5. Distribute the results of the process review to the appropriate team members, project
manager, and the IS Projects Office Manager (in the role of the Process Manager).
These are:
a. Process Quality Inspection Checklist (See Appendix 32: Process Quality
Inspection Checklist - Configuration Management Audit)
b. PR/CR forms (See Appendix 7: Problem Report/Change Request Form)
Page 64 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Stage PM.PCL: Project Closure

To
formally close the project
in a way that
establishes mechanisms for the continued development or improvement of the final

product of the project
improves the standard process for this type of project
updates the estimating model for this type of project
so that
the project resources can be re-deployed
Page 65 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PCL.01: Project Completion

To
complete all outstanding project work and determine the overall quality of the final
product
in a way that
evaluates the product against the original objectives

reviews outstanding project items
resolves outstanding project items
so that
the overall project objectives can be met

the project can be formally closed
Task PM.PCL.01.010: Prepare & Conduct Project Evaluation

1. Determine what form the final evaluation of the product should take. It could be:
a. a meeting
b. a quality review
c. a questionnaire
2. Prepare material
3. Distribute material
4. Carry out the evaluation in the chosen way
5. Determine if the project has been successful in relation to the original acceptance criteria
6. Determine if the product does meet all requirements
7. If the product does not meet requirements, identify the shortcomings and record them
8. Determine if any of the shortcomings with the final product need to be addressed
9. If there are any items that need action, decide on the best way of addressing the items.
Options include:
a. do not close the project
b. define a follow-on project
c. initiate a maintenance process
10. Compile the Product Improvement Report (See Appendix 33: Product Improvement
Report)
11. Distribute the Product Improvement Report.
Page 66 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Task PM.PCL.01.020: Initiate Maintenance Process

1. If there is a need for on-going maintenance of the final product, a maintenance process
should be initiated.
2. Establish a Maintenance Process if none exists.
3. Compile a Maintenance Guide (See Appendix 35: Maintenance Guide) and distribute.
4. Transfer current maintenance work to the Maintenance Organisation that must follow the
Maintenance Process.
Task PM.PCL.01.030: Close Outstanding Project Work
1. Review the Change Control log and close any outstanding items.
2. Review the Issue Log and close any outstanding items.
3. Review the Quality control log and close any outstanding items from completed quality
reviews.
4. The project logs may be closed by transferring the items to a follow on project or to the
maintenance process.
5. Produce personal assessments for all project team members.
6. Close and store project files. This may require forwarding some documents to other parts
of IHD (e.g., contracts correspondence).
7. Prepare the Risk Management Action plan on the final actions taken, for approval in the
project closure meeting. (See Appendix 15: Risk Management Action Plan).
Task PM.PCL.01.040: Prepare for Project Closure Meeting
1.
2.
3.
4.
5.
Determine what needs to be accomplished in the project closure meeting.

Decide who should attend.
Arrange and schedule the project closure meeting
Produce and circulate pre-meeting material (meeting notification, any required reading)
Produce outline Project Closure Report (See Appendix 36: Project Closure Report) for
review at the closure meeting.
Task PM.PCL.01.050: Conduct Project Closure Meeting

1.
2.
3.
4.
5.
6.
7.
Carry out the project closure meeting in the agreed way.

Review the Risk Management Plan.
Document how the project did in mitigating risks.
Gain approval on closure actions.
Revise the closure actions if they were not approved in the project closure meeting.
Celebrate project success!
Update Project Closure Report.
Page 67 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Task PM.PCL.01.060: Review and Baseline Project/Deliverables

1. Freeze the Project Baseline. This creates a final "snapshot" of all products (project
deliverables and product deliverables) that are a part of the project baseline.
2. If a major deliverable has been created and requires an Inspection Review, the review is
completed as a part of this task.
a. The purpose of the Inspection Review is to verify the accuracy of the product by
identifying any problems/defects. The end result of the review will be Problem
Reports/Change Requests (See Appendix 7: Problem Report/Change Request
Form) which may be resolved immediately. In this case, a new baseline is created
after these changes have been implemented.
b. Complete the Inspection Report (See Appendix 37: Inspection Summary Report)
c. Complete the Process Quality Inspection Checklist (See Appendix 38: Process
Quality Inspection Checklist)
3. This final baseline is used to facilitate analysis of the project and processes used to
support the project
4. Distribute the base lined products to appropriate individuals/teams and to the IS Projects
Office.
5. Create a new version of the Project Baseline to use as a rolling baseline (objects can be
checked in/out without changing the baseline version) to support maintenance of project
deliverables.
6. Transfer all Files in Harvest Change Manager to Round Table.
Page 68 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Step PM.PCL.02: Product and Process Improvement.

To
examine the performance of the project and quality of the final product against the
planned objectives
in a way that
identifies and captures metrics and factors that will improve the development process.
captures product improvements to feed into the maintenance environment
so that
subsequent projects may learn from the successes and mistakes of this project effort
Task PM.PCL.02.010: Collect Project Feedback and Metrics

1. Capture feedback on the performance of the new application/solution and the process
approach used. Take the following factors into account:
a. Content of Process Template used
b. Identification of applicable/inapplicable tasks
c. Project management effectiveness (e.g., project control, organization,
communication)
d. Effectiveness of development and testing tools
e. Problems encountered and solutions effected
f. Factors causing deviation from plan
g. Achievement of intangible benefits
h. Planned vs. Implemented project scope
i. Application quality (implemented application vs. Requirements)
j. Technical performance
k. Project team
l. Operations staff
m. Response and run times
n. Organizational impact
o. User satisfaction with the delivered application
2. Use the following mechanisms may be used to gather feedback:
a. Workshops
b. Interviews
c. Questionnaire
3. Everyone involved in the project should be considered a source and an appropriate
mechanism used to solicit feedback. Include the following project Stakeholders:
Page 69 of
SOP NO: 502
ISSUE NO: 1.0 Draft
4.
5.
6.
7.
a. User management
b. User application operational staff
c. Information systems management
Another source for feedback on the process approach/template used is data collected
during the root cause analysis of product errors. For example, for each product error, the
following questions should be answered:
a. During what task was the problem detected?
b. What type of error is it?
c. During whose process did the error initiate (prime/sub contractor)?
d. During what Stage in the process did the problem initiate?
e. During what Step in the process did the problem initiate?
f. What control (quality) process (es) missed catching the problem/error?
Analyse the data collected using trend analysis techniques and identify problem process
areas for process improvement analysis.
Root cause analysis of product errors should be completed throughout the development
process, at appropriate milestones. Root cause analysis should be conducted as early as
possible after a defect is found; however, to be most efficient, a modest backlog is
required for each analysis session.
Update Project Closure Report with findings.
Task PM.PCL.02.020: Collate and Analyse Metrics
1. Analyse project actual values and update the metrics database with project metrics and
2.
3.
measures. Metrics and measures which may be collated and analysed include:
a. Additional/revised weighting factors in estimating guidelines
b. Additional/revised factors for risk analysis
c. Defect rates
d. Productivity rates
e. Application size (e.g., function points or lines of code)
f. Actual effort versus estimated effort
g. Resource usage
h. Planned and actual budget utilization
i. Planned and actual resource utilization
j. Planned and actual schedule
k. Steps/tasks where a large number of errors initiated
l. Control processes that missed catching a large number of errors
m. Types of errors (with percentages) found
n. Tasks where a large number of errors were found
Identify any improvements required to:
a. Estimating models.
b. Risk analysis model.
Identify and analyse specific process activities that need improving to prevent defects on
future projects. Use trend analysis techniques on root cause analysis metrics.
Page 70 of
SOP NO: 502
ISSUE NO: 1.0 Draft
4. Perform an analysis of the process approach using the feedback and metrics collected.
5.
6.
Based on analysis of metrics, determine:

a. Appropriateness of Process Template
b. Identification of applicable/inapplicable tasks
c. Project management effectiveness (e.g., project control, organization,
communication mechanisms)
d. Accuracy of estimating guidelines
e. Planned vs. Actual budget utilization
f. Planned vs. Actual resource utilization
g. Planned vs. Actual schedule
h. Factors causing deviation
i. Problems encountered and solutions effected
j. Effectiveness of development and testing tools
Complete Problem/Change Request (See Appendix 7: Problem Report/Change Request
Form) or Problem/Requirement List (See Appendix 5: Problem/Requirement List) where
action is required.
Produce a Process Improvement Report that includes recommendations to the Process
Manager on improving the process.
Task PM.PCL.02.030: Analyse Product Quality

1. Perform an analysis of the quality of the new application/solution using the feedback and
metrics collected. Factors to be analysed include:
a. Achievement of tangible benefits
b. Achievement of intangible benefits
c. Planned vs. Implemented project scope
d. Actual cost/benefits profile
e. Application quality (implemented application vs. Requirements)
f. Technical performance
g. Response and run times
h. Machine loading and resource utilisation
i. Hardware configuration
j. Software configuration
k. Problems encountered and solutions effected
l. Organisational impact
2. Analyse not only the entire product, but also components of the product. It is possible that
certain components of the product are of high quality, and should be submitted for use in
the Reuse Library.
3. Produce a Product Improvement Report (See Appendix 33: Product Improvement Report)
that will be fed into the maintenance process.
Task PM.PCL.02.040: Complete Process Review
Page 71 of
SOP NO: 502
ISSUE NO: 1.0 Draft
1. Review the results of Product and Process Improvement to ensure that all processes
have been completed according to IHD standards.
2. Capture required information to enable improvement.
3. Capture process in Project Engineer for use in Process Engineer
4. Based on the results of the review, determine if a Problem Report/Change Request form
(See Appendix 7: Problem Report/Change Request Form) should be initiated on the
process being audited. If appropriate, complete a PR/CR form to initiate process
improvement activities.
5. Distribute the results of the review, Process Quality Inspection Checklist (See Appendix
39: Process Quality Inspection Checklist - Product & Process) and any Problem
Report/Change Request Forms to the appropriate team members, the project manager,
and the Process Manager.
4. Produce a Process Improvement Report (See Appendix)) that will be fed into the Process
Improvement (SEPG) process.
Page 72 of
SOP NO: 502
ISSUE NO: 1.0 Draft
HISTORY
Issue
Changes
Date Issued
Author
0.2
Working Document up to Task

PM.PIP.06.060: Customise Issues
Management Procedures
25 June 2002
Pieter Erasmus
0.3
Working Document completed (Without

Appendices) for:
2 July 2002
Pieter Erasmus
4 July 2002
Pieter Erasmus
10 July 2002
Pieter Erasmus
0.4
Project Initiation & Planning Stage
Project Control Stage
Completed Working Document except Cost

Control Procedure
Add Appendices
0.5
Completed SOP
1.0
Draft of SOP 502
Page 73 of
SOP NO: 502
ISSUE NO: 1.0 Draft
APPENDICES
Appendix 1: Project Charter
Appendix 2: Project Organisation
Appendix 3: Business Needs/Drivers
Appendix 4: Business Solution Document
Appendix 5: Problem/Requirement List
Appendix 6: Project Plan
Appendix 7: Problem Report/Change Request Form
Appendix 8: Walkthrough Report
Appendix 9: Risk Analysis Checklist for External Dependency Risks
Appendix 10: Risk Analysis Checklist for Business Case Risks
Appendix 11: Risk Analysis Checklist for Organisational Risks
Appendix 12: Risk Analysis Checklist for Planning Risks
Appendix 13: Risk Analysis Checklist for Technical Risks
Appendix 14: Risk Evaluation Summary Form
Appendix 15: Risk Management Action Plan
Appendix 16: Cost/Benefit Analysis Worksheet
Appendix 17: ROI Spreadsheet
Appendix 18: Business Case
Appendix 19: Project Quality Plan
Appendix 20: Project Configuration Management Plan
Appendix 21: Configuration Item Relationships
Appendix 22: Project Communication Plan
Page 74 of
SOP NO: 502
ISSUE NO: 1.0 Draft
Appendix 23: Team Progress Report

Appendix 24: Project Board Progress Report
Appendix 25: Stage Report
Appendix 26: Process Quality Inspection Checklist PIP Stage Assessment
Appendix 27: Issue Form
Appendix 28: Issue Log
Appendix 29: IHD Order Requisition Form
Appendix 30: IHD Asset Procurement Authorisation - Form FA 6
Appendix 31: Exception Plan
Appendix 32: Process Quality Inspection Checklist - Configuration Management Audit
Appendix 33: Product Improvement Report
Appendix 34: Process Improvement Report
Appendix 35: Maintenance Guide
Appendix 36: Project Closure Report
Appendix 37: Inspection Summary Report
Appendix 38: Process Quality Inspection Checklist
Appendix 39: Process Quality Inspection Checklist - Product & Process

SOP Project ManagementV0.9

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SOP Project ManagementV0.9

Uploaded by

Copyright:

Available Formats

Page 1 of

STANDARD OPERATING PROCEDURE IS IS PROJECTS OFFICE

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

PREPARED BY: Pieter Erasmus

NAME: Robin Botha

Ensure the timely and cost-effective production of all the end-products

Project Management specifically addresses Information Systems projects. It can be

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

This SOP does NOT include:

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

Schedule, Approved Change Requests,

Team Progress Reports,

Figure 1: Project Management Process Overview.

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

Kick Off the Stage

Ensure Requirements Traceability

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

Prepare & Conduct Project Evaluation

Collect Project Feedback and Metrics

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

Task PM.PIP.07.040: Conduct Stage End Assessment

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

Stage PM.PIP: Project Initiation and Planning

the project is firmly set up for success

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

Figure 2: Project Initiation & Planning Process Flow

SECTION: IS Projects Office

SOP NO: 502

TITLE: IS Project Management

ISSUE NO: 1.0 Draft

Step PM.PIP.01: Project Startup

the mission of the project is fully explained

a guide is established for the operation of the project

Task PM.PIP.01.010: Establish Project Charter

Task PM.PIP.01.020: Confirm Project Sponsor and Project Manager