Author Topic: Project scope document: Why I have found it useful  (Read 2495 times)


  • EA User
  • **
  • Posts: 164
  • Karma: +0/-0
    • View Profile
Project scope document: Why I have found it useful
« on: December 15, 2002, 10:16:48 pm »
I want to share a technique that I learned from datawarehousing experiences, and have been using successfully for the last two years: the project scope document.

In a nutshell, the idea is to produce, at the very early stages of the project and within a relatively short period of time, a document that will be agreed upon by the sponsor and all other key project participants, and that clearly delineates the scope of the project.

The main value of this document is to mitigate scope-creep.

The project scope document has essentially the same structure as the technical-description section of a project proposal; and, indeed, the technical section of a proposal can be considered as a scoping document. But I would like to stress that "technical section of a proposal" is a limited concept in comparison to the sort of document I'm talking about here.

Components of the project scope document

The scope document I will describe here is based on real proposals and/or scoping documents intended for two to six-month projects; so keep in mind that I'm using "light-weight" examples, which are ideal to explain the main ideas, but that do not cover the needs of either very short or very large projects.  Almost needless to say, not all sections of the example described here are necessary for each and every project.

Executive summary
For "light-weight" projects, I suggest to keep it less than one-page long.

"On October 9, 2002, XCo, SA invited TYSG, SA to prepare a proposal for the development of a Sales Analysis Decision-Support System. The document that follows has been prepared in response to the aforementioned invitation. In this proposal, we outline a roadmap intended to fulfill XCo's request."

"1. The scope of this project is constrained to implementing a Sales Analysis Data Mart (referred to henceforward as «the data mart»).


Links to the overall organization strategy
"The system is needed critically for driving revenue and forecasting plan management". It is usually a very short section, but it is one of the most challenging parts of the document.

Project Goals
"Based on the scope outlined, the goals of this project can be stated as follows:

"1. Ensure that existing source data will be usable in a data mart. This will be achieved by conducting a data quality survey of XCo sales information, as it exists in its source systems.

"2. Implement a technical solution for the extraction, transformation and loading (ETL) of..."

"1. Project personnel will avoid unnecessary distractions to users and executives by initially examining all relevant, existing material...

"1. Senior management will remain committed to the goals and objectives for the duration of this effort..."

Critical success factors
"1. Strong, visible management support for the project...

"1. The project will be developed within estimated cost and time..."

Security Issues and Concerns
"TYSG strongly recommends that worldwide sales data should be encrypted before it is transmission from one subsidiary to another..."

Acceptance Criteria
"The system must prove its capacity to accurately store and retrieve one month of the information needed to answer the business question..."

If time allows it, present a business process overview. You can use this model to further explain and illustrate the project's scope. For general guidelines on this type of diagrams see Sparx Systems' "The Business Process Model". For an in-depth discussion, see Chapter 3 in Erikssonn-Penker: "Business Modeling with UML".

Business question
This section applies only to datawarehousing projects: "What are the organization's sales, in terms of quantity (in kilograms) and extended price (in local currency, Euros and US Dollars), grouped or broken down according to the following criteria: Customer, Product..."

Domain model
If time allows it, include a small diagram of real-world objects (customer, salesperson, product...) in your target area, and their relationships. The simplest form of a domain model is a non-attributed class diagram.

"Real-world" objects can be discovered by carrying out a quick use-case/scenario modeling session (and I will present a future contribution on this).

Technical architecture (and/or technical architecture alternatives)
Existing and/or alternative technological architecture at the subject area is depicted in a deployment diagram.

Project Roadmap
"The detailed project roadmap can be found in the attached Gantt charts and in the ROUTE01.XLS file provided in ...

Project Roles and Development Team
Actors and/or «workers» (user, manager, subject-matter expert...) are placed in the project org-chart (which can also be used as a project directory).

If there are open issues, include a section with short descriptions of these.

For elegance, and if time allows it, create a section on Glossary and Acronyms

Finally, if needed, create a section on Bibliography and References: "The classical book on data marts is Ralph Kimball's The Datawarehouse Toolkit (Wiley & Sons, New York)."

A good project scope document is never produced during a first iteration; so do plan for a total re-do of your first draft.

If you have not written formal statements of work, or technical proposals, your first try at a project scope document will take about a week (including interviews and/or Joint Application Development sessions) for a "light-weight" project. This time will be substantially reduced in subsequent scoping efforts, once you can use a good previous scope document as a template; but keep in mind that you still have to do the interviews and/or JAD sessions.  

Most components of the scope document map very nicely to tasks and deliverables in the next project stages; for instance, the domain model derives directly into one or several class diagrams.

Also, the scope document is very useful when you find yourself in a situation in which the project is directly assigned, without contract or formal documentation. If this is the case, the first task in the project should be to draft the project scope and have it approved by the project's sponsors.

You're in a real hurry and don't want to loose time drafting a formal document? Then just conduct a session with the project sponsor and get agreement on the main points mentioned above; but I would suggest for someone to tactfully take good notes of the session's agreements.

Jaime Gonzalez
« Last Edit: December 15, 2002, 10:19:53 pm by jaimeglz »


  • EA User
  • **
  • Posts: 183
  • Karma: +0/-0
    • View Profile
Re: Project scope document: Why I have found it us
« Reply #1 on: December 16, 2002, 08:45:54 am »

Interesting stuff.  It actually is alot of a mix between what RUP tries to focus on AS WELL AS Six Sigma and the rigid rules that go into the Tollgate (L1 through l5) methodology.  

Steve Straley