January 26, 2007 – Managing the Thing: Project Definition Part 2

Without defining the project, The Thing will likely fail to get accomplished. It will consume more time than anticipated and accomplish less than expected while costing more than it should have. When the wide variety of documents are boiled down to their simplest form that basics that need to be communicated are the Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach.

Project Background. The background is meant to describe who requested The Thing, what it is, why they requested it, and how the team arrived at the current point. A successful background is short and correctly spells the name of the person that requested it.

Scope. The scope section documents exactly what the team is responsible for (In Scope) and, just as importantly, what it is not (Out of Scope). Items should be identified clearly. As an example, “Support of User Acceptance Testing” does not clearly set expectations. You may be thinking, “make sure the system is up, answer a few questions, and fix anything that fails.” What the Sponsor may read between the lines is, “create the test scripts, train the testers, and supply coffee and donuts.” A better scope statement might read:
Support User Acceptance Testing by ensuring that the system is available, refreshing test data, recording defects and tracking corrections, and facilitating daily UAT meetings.

The Out of Scope portion further refines the expectations by addressing items that a newbie to the project might otherwise assume were the team’s responsibility. Examples would include:

• Training testers on the use of the system is the responsibility of the Training Department.
• The UAT Test Scripts will be developed by the Business as directed by the Business Project Manager.
• Bring your own stinking coffee and donuts.
  

Well, maybe the last one shouldn’t be in the final document.

Approach. The approach outlines the Technical Environment, Development Life Cycle and Deliverables.

Technical Environment. Is this web development or COBOL, JAVA or Infomatica? Clarifying this up front will set everyone’s expectations. This is not a Technical Specification so give a high-level overview and refrain from details of how the parts interact and perform.

Development Life Cycle. What phases or process will be followed as the project unfolds? Will you do prototyping, execute a pilot, or use JAD sessions to drive out requirements? Briefly define what the involved parties can expect.

Deliverables. This is the real substance of this section. In some cases it may make sense to have a separate section for it. Deliverables are the building blocks for the project and serve as checkpoints to verify progress. The sum of all of the deliverables should constitute the whole project so it will be helpful to develop a Work Breakdown Structure (WBS) to identify the all.

Each deliverable should be listed with its name, description, acceptance criteria, and approval authority. Below is a good example of a deliverable statement.

Name
Statement of Work

Description
This document defines the project by identifying the Scope, Deliverables, and Roles and Responsibilities. It is an agreement between the involved parties and forms the basis for project expectations.

Acceptance Criteria
The document contains the following sections:
1. Background identifying the request and brief history.
2. Scope of the project.
3. Approach with Technical Environment, Development Life Cycle, and all Deliverables identified.
….
Each section clearly articulates the expectations of each stakeholder.

Approval Authority
Project Sponsor
Business Project Manager
IT Project Manager
Manage of Sales

A good way to present this information is in a table. Notice how in the Acceptance Criteria lists the specific sections we have discussed. As we will see in the Acceptance Management section, those criteria are what the approver should be verifying when deciding whether or not the deliverable is done.

In the next entry we will cover the remaining sections of the PDD.