Posts Tagged ‘Execution’

Project Specification

Posted: February 27, 2012 in Projects
Tags: , , ,


The first step in budgeting is to identify the specifications. A specification is the definition of the project or a statement of the problem, not the solution. Normally, the specification contains errors, ambiguities, misunderstandings, and enough rope to hang the project manager and the entire team. 

Importance of Project Specification

A project specification is an essential part of the design, and states how the work should be executed to ensure that it meets the designer’s assumptions

A specification document describes how something is supposed to be done

From a purely defensive point of view, the agreed on specification also affords you protection against the numbties that have second thoughts, or new ideas, half way through the project. Once the project is underway, changes cost time and money. The existence of a demonstrably agreed on specification lets you resist or charge for (possibly in terms of extra time) such changes. 

Benefits of Specification for Project and project Manager

It is only logical that the specification be written down and agreed on by all parties involved in the project. Having an agreement in writing has several benefits:

  • The clarity will reveal misunderstandings.
  • The completeness will remove contradictory assumptions.
  • The rigor of the analysis will expose technical and practical details that numbties normally gloss over through ignorance or fear.
  • The agreement forces all concerned to actually read and think about the details.

Errors In Making A Specification

It’s very easy to err when making a specification. The major points of error are usually:


The global context: Numbties often focus too narrowly on the work of one team and fail to consider how it fits into the larger picture. Some of the work given may actually be undone or duplicated by others. Some of the proposed work may be incompatible with that of others.

Inferences: Between your team and its customers and suppliers there are interfaces. At these points something gets transferred. Exactly what, how, and when should be discussed and agreed upon from the very beginning. Never assume a common understanding, because you will be wrong. All it takes for your habitual understandings to evaporate is the arrival of one new member, in either of the teams. Define and agree to interfaces and maintain a friendly contact throughout the project.

Time-scales: Numbties always underestimate the time involved for work. If there are no time-scales in the specification, you can assume that one will be imposed upon you (which will be impossible). You must add realistic dates. The detail should include a precise understanding of the extent of any intermediate stages of the task, particularly those that have to be delivered.

External dependencies: The project may depend upon the work of others. Highlight the effect that problems with these would have upon your project so that everyone is quite clear about their importance.

Resources: The numbty tends to ignore resources. The specification should identify the materials, equipment, and manpower that are needed for the project. The agreement should include a commitment by managers to allocate or fund them. Make double sure that the actual numbers are practical and/or correct.