Defining the scope project

Defining the project scope


The first thing to realize is that the client often does not know what he/she wants. Never start a project without first agreeing on clear requirements. This is what worked for me. I would start with a simple Project Overview and discuss it verbally with the client. Then I would go back and write up a detailed Functional Spec containing a Requirements Matrix. (I describe each of these documents below.)

The more effort you spend here upfront, the less crises you will face in later stages of the project when things are harder or impossible to change.

A Project Overview looks like this:

Problem description

1. Goal - 1 or 2 measurable broad goals, achievable in the timeframe
2. Objectives - a small list of specific sub-goals
3. Success criteria - how will we know when we're done?
4. Assumptions - ensure that there are no surprises later
5. Risks and alternative plan - if something goes wrong, can we change direction?


Each of these sections should be described in plain English, with as few technical details as possible. One or two paragraphs per section usually suffice. The aim is to arrive at an agreement on the broad objectives of the project. Discuss the Project Overview verbally, in a face-to-face meeting with the client's managers, if possible. This is the first test of your communication skills - both written and oral.