Definition Phase

Version 1.1                 May 10, 2000

Project Statement Standard

This page contains the published standards for the Definition Phase of the System Development Life Cycle used within the Ministry and by its contracted consultants.

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 STATEMENT CONTENTS

2.1.    Background
2.2.    Project Overview
2.3.    Project Objectives
2.4.    Project Scope
2.5.    Project Approach
2.6.    Project Communications
2.7.    Project Team
2.8.    Deliverables and Milestones
2.9.    Project Schedule
2.10.  Critical Success Factors
2.11.  Risks, Assumptions & Constraints
2.12.  Issues
2.13.  Project Management Processes
2.14.  Sign-off
2.15.  Appendices (as applicable)

3.         MULTIPLE PROJECT STATEMENTS PER PROJECT

4.         CONCLUSION

APPENDICES

Appendix A         Sample Project Statement - Table of Contents

EXAMPLES

Example 1 : Project Objectives
Example 2 : Project Approach
Example 3 : Project Communications
Example 4 : Project Team Org Chart
Example 5 : Deliverables Schedule
Example 6 : Project Schedule
Example 7 : Critical Success Factors

[TOC]

VERSION CONTROL

This section of the document records the various versions or releases of this document.

[TOC]

1.       INTRODUCTION

This section outlines the Audience and Purpose of this document. It also lists acknowledgments and the document's relationship to other standards documents.

1.1      Audience

This standard is provided for Project Managers and Application Managers responsible for a project as well as users and other stakeholders of the project.

Prior to a project being started, regardless of which phase(s) of the System Development Life Cycle the project involves, the contractor or Project Manager should be instructed to produce a Project Statement. The Project Statement is to follow and conform to the standard outline in this document. This fact must be specified in the contract.

1.2      Purpose

The purpose of this document is to outline the contents of the deliverable (Project Statement) expected to be delivered as part of every Project.

This document can also be used as a template for contractors so that the Ministry's standard appearance of all deliverables can be ensured.

Projects should adhere to the format provided by this document and provide information relevant to the project that is required for stakeholder approval.

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 the second in the series of seven (7) Ministry phases addressing the System Development Life-Cycle (SDLC).

Refer to the other documents in the SDLC series.

1.5      Outstanding Issues

None

[TOC]

2.      PROJECT STATEMENT CONTENTS

The purpose of the Project Statement document is to provide a "road-map" for the successful execution of a project. It is to be created as the first step in the project, after the completion of the Feasibility Phase (Project Charter) and after the project has been given the approval and funding to proceed. The Project Statement provides an effective way of communicating, to project stakeholders, the project scope, resources and schedule as well as any risks or constraints inherent in the implementation of the project. Agreement, by all stakeholders to the Project Statement ensures that everyone involved in the project is clear on its objectives, goals and outcomes.

A project is a "temporary endeavor undertaken to create a unique product or service" (temporary, because every project has a definite beginning and a definite end). The Project Statement is vital in ensuring all stakeholders are clear on the project scope and direction and is a way of confirming, in writing, that the intent of the project is understood.

The sections to be included in the Project Statement are detailed below. In addition to these sections, which describe the project, a number of sections should be included at the beginning of the document to introduce the Project Statement itself. For a complete suggested format/content refer to the sample in Appendix A.

2.1      Background

"How did the project arrive at this point?"

This section brings the reader up to speed on the project. It describes any relevant history on the project as well as introducing the project in relation to this history. As well, it puts the project in context for the reader (e.g. the Water Management program with the Resources Inventory Branch).

This section should provide a new stakeholder with enough information to understand, at a high level, how the project progressed to this point and the reasons for continuing on with the "next step" of the project.

2.2      Project Overview

"What is this project going to do?"

The Project Overview summarizes what this project intends to do. It provides a high level summary of the project as well as a description of the work/tasks/activities which will be performed.

2.3      Project Objectives

This section lists the objectives of the project; what it is that will be accomplished by the end of the project.

Example 1 : Project Objectives

2.4      Project Scope

This section clarifies the scope of the project. It summarizes the tasks and activities that are "in scope" and also identifies any aspects that are deemed to be "out of scope".  There may be several sub-sections to this Project Scope section, with a description of scope related to each sub-section.

For example:

depending on the project, there may be scope related to the:

• functionality that will be addressed;
• data that will be modeled;
• historical information to be reviewed (i.e. legacy systems);
• stakeholders who will be involved in the design; and
• geographic regions that will be considered.

Where such sub-areas of scope exist, they should be separated into appropriately titled sub-sections.

2.5      Project Approach

This section describes the tasks or activities of the project. Some examples of project tasks are:

• Project Initiation;
• Review of existing documentation;
• JAD Design Workshop;
• Review of existing legacy systems; and
• Evaluation of current business practices.

Quite often, some/all of these phases will map to the deliverables for the project.

For each task the "objectives" of that task must be provided as well as any information relating to the successful completion of the task. An example follows.

Example 2 : Project Approach

2.6      Project Communications

This section lists any/all types of communication strategies which will be used during the project. Some examples of communication strategies are conference calls, status reports, team meetings and a project web site. For each communication strategy a list of objectives is to be provided as well as a description of the communication strategy. An example follows:

Example 3 : Project Communications

2.7      Project Team

This section will provide a pictorial representation of the Project Team, including all staff from the vendor team as well as staff from the Ministry. Names and the titles (as they relate to this project) of the individuals are to be included. The key contacts for the vendor and ministry must be identified and their relationship to other members of the project team.

This section will also provide a list of the Roles & Responsibilities of the various team members and/or groups.

Example 4 : Project Team Org Chart

2.8      Deliverables and Milestones

This section lists all Deliverables per the project contract. Also to be included here is any Milestone which is not related to a deliverable. (eg. the delivery of the Final Requirements is a milestone associated with a deliverable, whereas the start of QA testing is not associated with a deliverable but is a milestone none-the-less). Both Deliverables and Milestones must include a target delivery/completion date. An example of a delivery schedule follows:

Example 5 : Deliverables Schedule

This list of deliverables should form the starting point for reporting deliverable status in the regular status report. The "Target" date will not change and the status report will include a completion date for each deliverable. Refer to the Project Status Reporting Standard.

2.9      Project Schedule

The Project schedule must be provided in the Ministry compatible standard tool (currently MS-Project). All Milestones listed in Section 2.8 must be included on the schedule.

The Project Schedule should provide, at a minimum, the following information and should be in a Gantt Chart format:

• Task Name;
• Resources allocated;
• Start Date;
• Finish Date;
• Effort;
• Duration.

An example of a project schedule follows:

Example 6 : Project Schedule

2.10    Critical Success Factors

This section lists any Critical Success Factors (CSF's) which will need to be met or adhered to for the success of the project, whether these relate to Ministry or Vendor responsibilities. It will be the responsibility of the Project Manager to monitor activities against these CSF's throughout the project to ensure they are met and thus ensuring the success of the project. In order for these CSF's to be effective they must be measurable.

Example 7 : Critical Success Factors

2.11    Risks, Assumptions & Constraints

This section will list any project risks, assumptions and constraints, where:

Each of these (risks, assumptions, constraints) must be described separately in their own sub-section.

Note: The difference between a CSF and a risk, assumption and constraint is that a CSF will impact the success of the project if not met, whereas a risk, assumption and constraint will not definitely occur and pose only a potential impact to the success of the project or some aspect of it.

2.12    Issues

This section lists any known issues relating to the project. It is assumed that these issues will be resolved during the project for successful completion of the project. If there are no unresolved issues at the time of preparing the Project Statement, this section must be included and the absence of issues identified.

Issues raised during the project will be documented on the Project Status Report by the vendor's Project Manager and will be reviewed and resolved through Project Status meetings or through a separate meeting as required.

2.13    Project Management Processes

This section describes the Project Management process which will be used to manage the project. The following areas should, at a minimum, be described:

Where appropriate, this section should reference forms or documents to be used with these project management processes and samples of these should be included in an Appendix of the Project Statement.

2.14    Sign-off

Commencing on a new page, the last section of this document must be a sign-off page where appropriate members of the Ministry and (as appropriate) contract team can accept and approve the Project Statement deliverable.  Typically the Project Statement document will be signed by one or more individuals from each of the following lists in the following way:

John Smith
Project Sponsor

Signed _________________ Date ______________

from the Ministry:

• Project Sponsor;
• Business Champion;
• Project Manager/Coordinator;
• IMB Business Analyst;

from the Contractor:

• Director/Partner Responsible; and
• Project Manager.

2.15    Appendices (as applicable)

All relevant forms, documents, and reports and supporting information are to be included in this document in appropriately numbered appendices. At a minimum, the following should be provided:

• Sample Project Management Forms (i.e. Change Request form);
• Sample Status Report; and
• Detailed Schedule.

[TOC]

3.      MULTIPLE PROJECT STATEMENTS PER PROJECT

A large project that is broken into a number of Phases over a period of time will require a new/updated Project Statement for each Phase, describing the objectives, scope etc. for that particular Phase. Some of the information within Project Statements which relate to the same project, will be duplicated while other information will be unique to that particular phase of the project. For example, key objectives for building an application will be true throughout the various phases of the SDLC; however schedules, team members, project approach etc. will probably differ from one Phase of the project to the next.

[TOC]

4.       CONCLUSION

This document provides the guidelines and template that will facilitate the production of a standard Project Statement deliverable with a consistent appearance.

It is intended to provide a framework for documenting, at a high level, the various parameters of a project. Its goal is to ensure there is an agreed-to "road map" for the project.

This document is intended to clearly communicate the Ministry's deliverable expectations for the System Definition Phase (Phase 2) of the System Delivery Life-Cycle (SDLC).

[TOC]

Bibliography

This document contains material that has been taken from the Project Statement for Phase I of the CRISP (Comprehensive Records Information & System for Pesticides) project.

[TOC]

APPENDIX A

Sample Project Statement

Table of Contents

Title Page

Table of Contents

1.       INTRODUCTION
          1.1    Audience
          1.2    Acknowledgements
          1.3    Related Documents

2.       BACKGROUND

3.       PROJECT OVERVIEW

4.       PROJECT OBJECTIVES

5.       PROJECT SCOPE

6.       PROJECT APPROACH

7.       PROJECT COMMUNICATIONS

8.       PROJECT TEAM

9.       DELIVERABLES & MILESTONES

10.     PROJECT SCHEDULE

11.     CRITICAL SUCCESS FACTORS

12.     RISKS, ASSUMPTIONS & CONSTRAINTS

13.     ISSUES

14.     PROJECT MANAGEMENT PROCESSES

15.     CONCLUSION

16.     SIGNOFF

APPENDICES

[TOC]