SDLC STANDARDS

Project Management

Project Management Approach

This page contains the published standards for the Ministry's approach to effective project management.

Version 1.1
September 20, 2000

Table of Contents

VERSION CONTROL

1.      INTRODUCTION

1.1    Audience
1.2    Purpose
1.3    Assumptions
1.4    Other Standards
1.5    Outstanding Issues

2.      PROJECT MANAGEMENT APPROACH

2.1    Issues
2.2    Change Requests
2.3    Requests For Decision
2.4    Approach to Project Status Reporting

3.      CONCLUSION

APPENDICES

Appendix A:            ISSUE RESOLUTION FORM , download (WORD 60K)
Appendix B:            ISSUE RESOLUTION SUMMARY FORM
Appendix C:            CHANGE REQUEST FORM , download (WORD 60K)
Appendix D:            CHANGE REQUEST SUMMARY FORM
Appendix E:             REQUEST FOR DECISION FORM , download (WORD 60K)
Appendix F:             REQUEST FOR DECISION SUMMARY FORM

  [TOC]

VERSION CONTROL

This section of the document is to be used to control the various versions or releases of the document.

  [TOC]

1.       Introduction

This section contains a brief introduction of the document for the reader.

1.1      Audience

This document is intended for the use of Project Managers, for carrying out Systems Development projects in the Ministry.  All projects for the British Columbia Ministry of Sustainable Resource Management must follow this approach to project management.

All contractors engaged to perform Project Management are instructed to conform to the project management approach outlined in this document.   
This fact must be specified in the RFP and contract.

1.2      Purpose

This document outlines some of the mechanisms for use in Project Management, ensuring that there is consistency across all the Ministry's projects.

All recommendations or suggestions for the improvement of this standard should be sent for review to: wwwIsbStds@ssbpost.env.gov.bc.ca

1.3     Assumptions

It is assumed that in order to make effective use of this standard, that the audience is familiar with the Ministry's System Development Life Cycle (SDLC) Overview, of which this standard is a part.

1.4     Other Standards

This standard is one of the standards associated with Project Management.

Other documents in the SDLC series.

1.5     Outstanding Issues

There are no identified outstanding issues at this time.

[TOC]

2.        PROJECT MANAGEMENT APPROACH

This section describes some of the control mechanisms to be used by Project Managers in order to provide effective project management.  There are three main aspects of a project that need to be managed carefully and efficiently in order for a project to be successful and effective. They are:

• Issues;
• Change Requests; and
• Requests for Decision.

These mechanisms are to be used in conjunction with the Approach to Project Status Reporting section of this document.

2.1     Issues

Under normal circumstances all project related issues will be resolved by the Project Manager providing that the issue falls within the mandate of the Project Manager and the scope of the project. 

Issues can and are encouraged to be raised by anyone involved in a project.  All Issues raised in the course of conducting a project are to be recorded on an appropriate Issue Resolution (IR) Form.  Project Managers should make IR forms easily available to all project participants.  Each IR form is to be numbered for the project so that they can be easily tracked and monitored on an IR Summary Form (spreadsheet).

The intent of a formal Issue Form is to enable the Project Manager to raise, track and monitor project related issues to their successful resolution.  Any issue relating to a project whether it refers to scope, business procedure, business content, technology used or proposed, etc., should be outlined on the appropriate form, numbered and recorded, processed for resolution, resolved and marked as such in an IR Summary.  In this way each issue can be ensured that it receives the appropriate attention and its resolution passed to the appropriate project team member for action.  All IR's are to be recorded on an IR Summary Form (spreadsheet) so that status and resolution of each IR can be easily tracked and monitored.

The content and format of the Issue Resolution (IR) Form is described below and should be read in conjunction with the sample IR Form included at Appendix A of this standard.

2.1.1  IR Number

The form's unique number.  It should be numbered in a style that uniquely identifies the IR both within the project and from one project to another.  Some components that should be considered in generating a project IR number are:

• project ID;
• project phase; and
• sequential number.

Example:  Project - Water Quality Data Management System
                Phase - not applicable
                Sequence - starting 001

                IR Form Number - WQDMS001

2.1.2  Initiator

The name of the person that is initiating the project issue.

2.1.3  Title

The initiator's job or project title.

2.1.4  Contact

The IR form initiator's contact phone number and/or email address.

2.1.5   Branch/Organization

The IR form initiator's branch within the Ministry or the organization that the initiator belongs to.

2.1.6   Date

The date that the issue was recorded or raised.

2.1.7   Description

Provide a detailed description of the issue, relating to the project, that needs to be resolved.  The description should also indicate the effect or impact that the issue will have on the project or business area.  As well, outline possible alternatives that may be considered in the resolution of the issue.

2.1.8   Recommendation

Suggest one or more recommended solutions for the issue as well as the resource(s), cost and effort required.

2.1.9   Assigned

Identify who the issue has been assigned to for resolution.

2.1.10 Date Assigned

The date that the issue was assigned for resolution.

2.1.11 Resolution

Provide a detailed description of the solution and resolution to the issue. Cross reference any other applicable documents in the resolution.

2.1.12 Sign-Off

On completion/resolution of the Issue (IR) it should be signed-off and dated by the appropriate members of the project team.  The persons signing-off the IR will vary depending on the issue and the areas effected.  Typically each IR will be signed-off as completed by:

• Business Champion; and/or
• Project Manager; and/or
• Business Analyst; and/or
• Development Project Manager.

Process

The process to be followed when using an Issue Resolution Form is as follows:

• Issue initiator fills out the IR form (paragraphs 2.1.2 to 2.1.8);
• IR to be handed to the Project Manager;
• IR Form received by the Project Manager who numbers the form (2.1.1) and enters onto the IR Summary.  As appropriate, provide a numbered copy to the initiator;
• Project Manager assigns the IR for resolution in the appropriate time frame and records the assignment and date on the IR Summary; and
• When the IR is resolved to the satisfaction of appropriate project team members, record the resolution on the IR form and sign-off the IR as complete.  Project Manager records the resolution and date on the IR Summary.

[TOC]

2.2     Change Requests

Change Requests (CR) are to be used to monitor and control all substantiated and approved modifications to the scope of a project.  CR's are usually used with fixed price contracts to document a change in project scope that will effect (usually increase) the cost of a project.

A CR will provide the following information:

• outline of the details of the change(s) requested;
• definition of the impact of the change(s) on the project and/or business area;
• provide a justification for the change(s) and expected benefit(s);
• outline the available alternative(s);
• identify the recommendation(s) and associated effort and costs for the disposition of the change and the implementation alternative(s) selected; and
• allow appropriate authorization and or rejection of the CR.

The intent of a formal Change Request Form is to enable the Project Manager to track and monitor, all project related requests and requirements deemed to be outside the scope of the project on an appropriate Change Request (CR) Form, to their approval and subsequent inclusion in the project scope or rejection.  Any change in the scope of a project should be outlined on the appropriate form, numbered and recorded, presented to the appropriate authority(ies) for review and subsequent approval or rejection and marked as such in a CR Summary.  In this way each change request can be ensured that it receives the appropriate attention and the related decision communicated to the project team.  All CR's are to be recorded on an CR Summary Form (spreadsheet) so that status and resolution of each CR can be easily tracked and monitored.

The content and format of the Change Request(CR) Form is described below and should be read in conjunction with the sample CR Form included at Appendix C of this standard.

2.2.1  CR Number

The form's unique number.  It should be numbered in a style that uniquely identifies the CR both within the project and from one project to another.  Some components that should be considered in generating a project CR number are:

• project ID;
• project phase; and
• sequential number.

Example:  Project - Water Quality Data Management System
                Phase - Phase I
                Sequence - starting 001

                CR Form Number - WQDMS-I001

2.2.2  Initiator

The name of the person that is initiating the change request (usually the Project Manager).

2.2.3  Title

The initiator's job or project title.

2.2.4  Contact

The CR form initiator's contact phone number and/or email address.

2.2.5   Branch/Organization

The CR form initiator's branch within the Ministry or the organization that the initiator belongs to.

2.2.6  Date Initiated

The date that the Change Request was recorded or raised.

2.2.7  Business Function(s) Affected

Describe the business function(s) that will be affected by the change request.

2.2.8  Description

Provide a detailed description of the scope of the change(s) requested.  The description should also indicate the effect or impact that the change(s) will have on the project or business area if not approved.  As well, outline possible alternatives that may be considered.

2.2.9  Justification

Provide a detailed justification for the change(s) to the project's scope and the expected benefit(s) that will be derived by the business area and/or project if included in the project scope.

2.2.10 Estimate

Provide a detailed estimate of costs for the project team resource(s) to carry out the change request. 

The estimate should also identify any impact to the current project schedule as a result of this CR.

2.2.11 Authorization

In order for the CR to be included in the project scope it must be authorized by the appropriate members of the Ministry's project team.

The person(s) authorizing the CR will vary depending on the change and the areas effected.  Typically each CR will be signed (approved or rejected) by:

• Project Sponsor; and/or
• Business Champion; and/or
• Business Analyst; and
• Project Manager; and
• Development Project Manager.

Process

The process to be followed when recording a change in project scope on a Change Request Form is as follows:

• Project Manager fills out the CR form (paragraphs 2.2.2 to 2.2.9);
• Project Manager numbers the form (2.2.1) and enters onto the CR Summary;
• Project Manager presents the CR to the appropriate member of the Ministry's project team for review and approval/rejection;
• Ministry approves/rejects the Change Request and provides the appropriate authorization;
• Project Manager records the approval/rejection of the CR and date on the CR Summary; and
• Approved CR's forwarded to the Development Team for action.

[TOC]

2.3     Requests for Decision

A Request for Decision (RFD) form is to be used to document business and policy issues that cannot be resolved within the combined Ministry and contractor project team.   Typically these will be documented issues that have not been resolved and that need to be escalated to a higher authority for a decision.  RFD's are prepared by a member of the project team or the Project Manager for presentation to the project Steering Committee or Executive Director for a decision.

Depending on the impact of the decision, the contract scope may be effected.  Any changes in the contract scope must be identified on an appropriate Change Request form that may be submitted for authorization at the same time as the RFD.

The intent of a formal RFD Form is to enable the Project Manager to raise, track and monitor project related issues that are unable to be resolved by the normal project processes and authorities.  Any issue that cannot be resolved within the project team should be outlined on the appropriate form, numbered and recorded, submitted to the appropriate authority for review and decision and marked as such in an RFD Summary.  In this way each RFD can be ensured that it is not overlooked, receives the appropriate attention and its decision passed to the appropriate project team member for action.  All RFD's are to be recorded on an RFD Summary Form (spreadsheet) so that status and resolution of each RFD can be easily tracked and monitored.

The content and format of the Request For Decision (RFD) Form is described below and should be read in conjunction with the sample RFD Form included at Appendix E of this standard.

2.3.1  RFD Number

The form's unique number.  It should be numbered in a style that uniquely identifies the RFD both within the project and from one project to another.  Some components that should be considered in generating a project RFD number are:

• project ID;
• project phase; and
• sequential number.

Example:  Project - Water Quality Data Management System
                Phase - not applicable
                Sequence - starting 001

                RFD Form Number - WQDMS001

2.3.2  Initiator

The name of the person that is initiating the Request For Decision (RFD) usually the Project Manager.

2.3.3  Title

The RFD initiator's job or project title.

2.3.4  Contact

The RFD form initiator's contact phone number and/or email address.

2.3.5  Branch/Organization

The RFD form initiator's branch within the Ministry or the organization that the initiator belongs to.

2.3.6  Date Initiated

The date that the RFD was prepared or raised.

2.3.7  Decision Required

Provide a detailed background to the decision being requested.  The request should also indicate the effect or impact that the issue will have on the project or business area. 

2.3.8  Alternatives/Recommendation

Outline possible alternatives that may be considered in the resolution of the request.   Suggest one or more recommended solutions for the request as well as the resource(s), cost and effort required.

2.3.9  Planned Action

Identify the planned action that the project team will be taking while awaiting the decision AND (if different) the default action that will be taken if a decision is not reached.

2.3.10 Resolution

Provide a detailed description of the solution and resolution to the request. Cross reference any other applicable documents in the resolution.

2.3.11 Sign-Off

On completion/resolution of the Request For Decision (RFD) it should be signed-off and dated by the appropriate members of the project Steering Committee.  The persons signing-off the RFD will vary depending on the request and the areas effected.  Typically each RFD will be signed-off as completed by:

• Steering Committee Representative or Chair; and
• Project Sponsor; and/or
• Business Champion; and/or
• Business Analyst; and
• Project Manager.

Process

The process to be followed when preparing and processing a Request for Decision is as follows:

• Project Manager fills out the RFD form (paragraphs 2.3.2 to 2.3.9);
• Project Manager numbers the form (2.3.1) and enters onto the RFD Summary;
• Project Manager presents the RFD to the project steering committee or  Director for review and decision;
• Steering Committee or Director approves/rejects the Request For Decision and provides the appropriate authorization and decision;
• Project Manager records the approval/rejection of the RFD and date on the RFD Summary; and
• Approved RFD's distributed to the Development Team for action.

[TOC]

2.4     Approach to Project Status Reporting

Project Status Reporting is a mechanism to enable Project Managers to ensure that a project is meeting its objectives and adhering to its defined budget and schedule (on time and on cost).

For any given project, depending on its size, complexity and structure, there can be a number of different status reports produced:

• status of contract development team;
• status of a sub-project (ie: Data Conversion; Data Warehouse; Data Capture; Operational Database; etc); and
• status of the overall project.

Each of these is described in more detail below.  For a detailed description of the Project Status Report format and content refer to the Project Status Report standard.  In addition, each Project Status Meeting should have meeting minutes or action items recorded by the Vendor Project Manager.  In this way there will be a permanent record of discussions and agreements from the project status meetings.

2.4.1  Overall Project

A project status report for the overall project (combining activities from all sub-projects and the Development Team) will be produced by the Project Manager for presentation to the Project Steering Committee or Director by the Business Champion (or his designate - which could be the Project Manager).  It is recommended that the Project Manager attend the presentation of the Project Status Report to the Project Steering Committee or Director in support of the Business Champion.

It is recommended that the Ministry Project Manager and the Business Champion meet prior to the Steering Committee meeting to discuss and review the project's progress and plans for future activities and deliverables as outlined in the Project Status Report.   This status report format and content should conform to the Project Status Report standard and minutes or action items from each project status meeting should be recorded and published.

2.4.2  Development Team

The status report produced for the contract Development Team will usually be produced by the Development Project Manager/Leader to report the status of contracted deliverables and (for time and materials contracts) costs. The scope of this status report will concentrate only on those tasks and activities relating to the Development Team.

It is recommended that the Ministry Project Manager and the Development Team meet bi-weekly (or as appropriate depending on project activity) to discuss and review Development Team progress and plan for future activities and deliverables.  A status report should be produced and circulated prior to each regular Development Team status meeting.  This status report format and content should conform to the Project Status Report standard and minutes or action items from each project status meeting should be recorded and published.

2.4.3  Sub-Project Component

Those projects that are of sufficient size and complexity, that have separate teams addressing individual sub-projects of the operational system such as data conversion and/or data warehouse, will likely require separate status meetings and status reports.

It is recommended that the Ministry Project Manager and the Team Leader for each separate sub-project meet bi-weekly (or as appropriate depending on project activity) to discuss and review Development Team progress and plan for future activities and deliverables.  A status report should be produced and circulated prior to each regular sub-project status meeting.  This status report format and content should conform to the Project Status Report standard and minutes or action items from each project status meeting should be recorded and published.

The diagram below is intended to summarize the possible various project status reports and their frequency.

[TOC]

3.      Conclusion

This document outlines the some of the control mechanisms to be used by Project Managers in order to provide effective project management.  This will enable projects within the Ministry to be managed with a consistent approach.

[TOC]

Appendix A

____________________________________________
Use additional pages as required

[TOC]

Appendix B

Ministry of Sustainable Resource Management

Incident Report (IR) Summary

[TOC]

Appendix C

_________________________________
Use additional pages as required

[TOC]

Appendix D

Ministry of Sustainable Resource Management

Change Request (CR) Summary

[TOC]

Appendix E

_________________________________________
Use additional pages as required

[TOC]

Appendix F

Ministry of Sustainable Resource Management

Request For Decision (RFD) Summary

[TOC]