Professional Documents
Culture Documents
SOP Project ManagementV0 9
SOP Project ManagementV0 9
DISTRIBUTION EXCO
: Managers
IS Project Managers
PURPOSE
Project Management provides an integrated framework for project organisation, planning and
control which is designed to
This SOP defines the Standard Operating Procedure for managing IS projects
Page 2 of 77
SCOPE
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.
DEFINITIONS
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 77
PROCEDURE
Overview
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:
Page 4 of 77
a. Project Start-up
b. Project Scope
c. Project Organisation
d. Scheduling and Budgeting
e. Business Case
f. Project Control Procedures
g. 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.
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.
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:
5. The Project Manager will perform Stage-end Assessment at the end of each stage by
performing the following tasks:
6. The Project Manager will perform Project Control on all product related stages until all
the stages have been completed.
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:
4. The Project Manager will ensure that the following tasks are performed for Product and
Process Improvement:
Detail Procedures
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 Process Flow of the PIP Stage is depicted in Figure 1: Project Management Process
Overview
Page 9 of 77
To
in a way that
so that
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).
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
Page 11 of 77
3. IS Projects Office Manager selects and assign and brief a Project Manager to manage
the Project.
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.
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 77
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
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)
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
Page 13 of 77
representatives.
2. Business Analyst compiles graphical:
a. High level Process Models using AllFusion Process Modeller
b. High level Data Model using AllFusion Data Modeller
3. Business Analyst clearly indicate boundary of Project stating, where necessary, what
is included in and what is excluded from the Project.
4. Business Analyst clearly defines the end result of the Project.
5. 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.
6. Project Manager starts recording any assumption that must be verified. (See
Appendix 6: Project Plan)
7. Project Manager starts recording any constraints that must be taken into account. (See
Appendix 6: Project Plan)
8. Project Manager complete the Scope Section of the Project Plan (See Appendix 6:
Project Plan)
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)
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).
8. Project manager completes Walkthrough Report (See Appendix 8: Walkthrough
Report)
Page 15 of 77
To
Select and prepare the people whose involvement will be necessary for the project to
succeed
in a way that
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
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
Page 16 of 77
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
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
1. Project Manager identifies skills required per role for the project
Page 17 of 77
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
so that
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
2. Product Name
3. Product Description
4. Product Type
5. Product Path
6. 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)
Page 21 of 77
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.
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.
Page 24 of 77
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.
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.
Page 25 of 77
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 26 of 77
To
prepare a business case which compares the benefits and costs of the proposed project
in a way that
so that
the Project Steering Committee (PSC) has good quality quantitative information to
guide their decision as to whether to proceed with the project.
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 it’s 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
Page 27 of 77
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 life-cycle cost, is estimated in this task and is then used later as part of the
Business Case.
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 IHD’s 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
1. Determine any additional risk management activities associated with conducting the
project.
Page 28 of 77
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 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.
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 29 of 77
To
ensure that all procedures required to carry out and control the project work are
established
in a way that
so that
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.
Page 30 of 77
5. Create a <project> Quality Plan based on the IHD IS Quality Plan. See Appendix 19:
Project Quality Plan
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
c. 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.
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
Page 36 of 77
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.
Page 37 of 77
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)
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.
Page 38 of 77
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)
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 SOP’s 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.
6. Price Quotations from suppliers for resources
7. Change Request Impact Analysis
Page 42 of 77
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.
Page 43 of 77
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
Page 45 of 77
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.
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
Page 47 of 77
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
Page 48 of 77
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 49 of 77
To
document the results of the Project Initiation & Planning stage and to have the results
reviewed by management
in a way that
so that
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.
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.
Page 51 of 77
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.
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).
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 52 of 77
To
manage project work during a stage and prepare for the next stage
in a way that
so that
this stage can reach a successful conclusion and the project can progress to the next
stage.
Page 53 of 77
To
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
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
Page 54 of 77
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
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
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.
Page 55 of 77
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.
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
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
Page 56 of 77
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.)
Page 57 of 77
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
Page 60 of 77
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
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
Page 61 of 77
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.
6. Communicate and distribute to appropriate members of the
Project Organization.
Page 62 of 77
To
document the results of the current stage, prepare for the next stage, and have the
results reviewed by management
in a way that
so that
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
1. Refine the step- and task-level activities for the next stage
2. Include technical and management activities for controlling progress and change.
3. These include checkpoints, Project Board progress meetings, and stage assessments.
4. 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
5. 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).
6. Review the customised WBS with the Process Manager and discuss the rationale for steps
and tasks waived for the next stage.
7. 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.
8. 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.
9. Formally log all assumptions and issues identified.
10. Update Project Engineer, POC and Project Planner.
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
c. Roles and responsibilities are defined; required resources are realistic and
available
d. Updated project plans conform to expectations for the next stage
3. Document approvals by requesting the signature of Project Board members on the Stage
Report
4. Minute the Meeting
5. Distribute meeting minutes or other products (e.g., updated product baselines) to
attendees
6. Provide the IS Projects Office with updated project information
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.
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.
Page 66 of 77
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 67 of 77
To
in a way that
so that
To
complete all outstanding project work and determine the overall quality of the final
product
in a way that
so that
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 69 of 77
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.
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).
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 71 of 77
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
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
Page 72 of 77
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:
a. User management
b. User application operational staff
c. Information systems management
4. 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?
5. Analyse the data collected using trend analysis techniques and identify problem process
areas for process improvement analysis.
6. 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.
7. Update Project Closure Report with findings.
1. Analyse project actual values and update the metrics database with project metrics and
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
Page 73 of 77
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
Page 74 of 77
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.
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 75 of 77
HISTORY
Add Appendices
APPENDICES