Why do we need a Project Definition Document? Isn’t the project already defined by the Project Charter…? Well, yes and no. The Charter initiates the project and defines it at Executive Summary level, for its executive readership. The PDD is finalised later, after the project is awarded, and draws heavily from the detailed output of the RFP process. Another important difference is that the Charter is a client-side, in-house document while the PDD is a contractual document. It is binding on, and signed off by, both in-house and contractors’ project teams.
The PDD starts with the high level description lifted from the Charter and proceeds to flesh it out. It is normal to divide a large project into quasi-independent workstreams. These could be based on physically affected areas or on the end users’ organisational structure. The advantage of the second approach is that it makes it easier to engage a users’ representative for each workstream. End user buy-in is always a good thing.
Having defined the workstreams, the next job of the PDD is to clarify the scope of the work to be undertaken. At this stage, scope statements are still at a high level, for example:
- Repurpose rooms G103 – G107 as news edit suites
- Migrate the contents of the legacy tape library to the digital asset management system
The PDD does not include the detail of each in-scope item. This belongs in the final Statement of Works that forms part of the signed-off design.
It is in the contractor’s interest to include in the PDD clear out-of-scope statements. This protects against ‘scope bloat’. The client cannot later reverse an out-of-scope statement without invoking an (expensive) formal change procedure.
It is normal for the PDD to include a list of assumptions and dependencies that are often closely intertwined. For example, a project’s success can depend on functionality or infrastructure provided by a parallel project. The dependency should be clearly stated along with the assumption that the parallel project will complete on time. When first populating the Risk & Issue log, it makes sense to import and recast the PDD assumptions as possible risks.
To prevent the PDD growing enormous (and to avoid repetition) best practice is to refer readers to a number of supporting project documents as required, each covering a single aspect of the work. These would include:
- Installation Standards Document (ISD)
- Clean Site Access Document (CSA)
- Site Safety Document (SSD)
- Test & Acceptance Procedures
- Asset Management Procedures
- Document Control Procedures
- Project Quality Control Plan
Financial aspects such as payment milestones are sometimes included in the PDD but as these tend to be sensitive they are normally treated separately. This is preferable as it allows for wider distribution of the PDD.