Project Scope Document: A "How To" (Part 1)
Some years ago I ran across an article about a professor whose students and colleagues would approach him asking him for employment references. Often he did not want to provide a reference because, frankly, it would not be glowing. If he told the truth about the colleague or student, he might lose a friend or get sued. If he wrote a nice reference letter, he would feel wrong because, after all, he had misled someone who was counting on his judgment.
What could he do? After thinking about it for a while, he decided that he could tell the truth and make the person who asked for the referral happy, too. So, he invented what he termed a Lexicon of Inconspicuously Ambiguous Referrals, LIAR for short. Here are some examples:
Each of the above phrases can lead to two diametrically opposed interpretations. I use this story as an icebreaker when we want to take the time to properly understand the system requirements, but the users want to brush me off with the classic line, "It's really very simple. Just go do it." After they have a good belly laugh at the statements, I ask them whether they really want us to interpret their business without their active participation and review. The point is always thoroughly understood.
The act of preparing for this document provides the necessary focus and agreement to have a successful project. This is your chance to build a team that will work together to achieve a common purpose.
The completed scope document acts as a "to-do" list and a reference to jog memories and help prevent scope creep. It also acts as an important legal document if things go poorly.
No matter what you do, requirements cannot be completely fixed before the system is built Ė if the goal is to build a system that will meet the needs of the business at the time it is delivered. Heisenberg's Uncertainty Principle applies to software system development as well as the quantum physics of electrons. The very act of building a system changes the system that needs to be built.
That said, there is no excuse for doing a sloppy job of gathering requirements! Your work in this deliverable (as initially produced) should prove to be mostly correct at the time that the system is delivered. If you update copies of it as the requirements change (a good idea, by the way), the latest copy of it will be completely correct.
of the layout of this document is based upon sample documents
provided in a very thought-provoking class conducted by Ron Ross and
Gladys Lam at www.BRSolutions.com.
It ties back to the Zachman Framework in that each of its
components are intended to answer one of the six basic questions: Who,
What, When, Where, How, and Why.
We really liked it for its concise clarity of expression -
it's just what an exective summary should be!
have extended and modified this format a bit.
Most importantly, we added the "Problem Statement,"
as we always found ourselves having to give a bit of explanation
before others read the document.
This enabled us to quickly explain, within the document, why
they should take the time to read it.
If they "feel our feeling of their pain," we have
found that they are much more likely to read the rest of the
document with a positive attitude.
Who says a Political Science degree isn't useful in this
field? We have
streamlined the presentation of the "goal and objective
measurement criteria" when the goal/objective is basically
measurable in its own right.
explanation for how we fill in the blanks is largely a reflection of
our practice prior to using this format, as are our quality checks
on the information contained in the document.
|Project Sponsor||Major Business Objects||Major Functional Transformations||Business Locations||Major Business Actors||Major Business Events||Business Mission, Goals and Objectives|
|Business Line Expert||Fact Model||Tasks||Business Communications Map||Workflow Models||Entity / Object Life Histories||Policy Charter: Risks, Tactics, Policies|
|Business Analyst||Data / Object Model||Behavior Allocation / Object Model||Platform & Communications Map||Use Cases with Rules||Resource Allocation||Rule Book|
|System Analyst||Database Design||Program Specifications||Technical Platform & Communications Design||Procedure & Interface Specifications||Work Queue & Scheduling Designs||Rule Specifications|
|Programmer||Database Schema||Program Source Code||Network||Procedures & Interfaces||Work Queues & Schedules||Rules|
|System User||Operational Database||Operational Code||Operational Network||Operational Procedures & Interfaces||Operational Work Queues & Schedules||Operational Rules, Policies, Risks|
Table 1 -- "You Are Here." Zachman Framework for the Project Scope Document 
1.1.1 Entry Criteria
Entry criteria are relatively lax for this deliverable.
|"a Need"||Someone must want something. We donít have to know what it is yet, just that the need exists.|
|Knowledge of how to find out who has (or knows) the need.||Without this, things canít go downhill because they are already at the bottom!|
Table 2 -- Project Scope Document Entry Criteria
1.1.2 Sample Project Scope Document
As this will be the first sample document we show you, we will have to explain our method of presentation as well as explain how the project scope document is organized. That makes both of our jobs (ours to explain and yours to learn) a bit harder, but not too hard as long as we keep in mind that there are two different lessons being learned at the same time.
We will start by explaining our presentation method.
Each page of the sample document will be printed just as it would appear in a real document, except for page headers and footers.
There are two exceptions to this:
- First, the sample document pages are lightly shaded and have a border around them to make them visually different from the rest of the article.
- Second, we have added footnotes to explain a specific point in the document to you.
Not every section is needed in every instance of every document. This is a methodology, not a religious catechism!
Here are five examples documents. (Note: Each example will open in a new window, letting you keep this main document open, as you look through the examples.)
- Example Project Scope document -- cover page
- Example (page 1) -- Statements of Problem, Mission, Objectives, & Goals
- Example (page 2) -- Major Scope Aspects (Business Objects, Functional Transformations, Business Events, Business Locations, Business Actors)
- Example (page 3) -- Measurement Criteria & Scope Sign-off
- Example (page 4) -- Definition of Terms
Now that you understand what is included in a Project Scope document, it is equally important that you realize what is not included in the document!
First of all (and least importantly), we did not list each and every business function. If we have a given business object called, for example, "Thing", we can expect there will be, at a minimum, a "Maintain Thing" function and a "List Thing" function. So, we don't waste our project sponsor's valuable time listing the blatantly obvious.
We do, however, make sure that our project sponsor knows that basic fact of the universe, because not all of them do!
More importantly, we did not address the issue of "how" we will achieve these goals and objectives. Our purpose in documenting the project scope is precisely so we will have a proper conceptual road map for deciding just that!
Why don't we put "how" we will achieve the goals and objectives into the document? Because we have nothing to gain and everything to lose. There may be different ways to get the job done and we may not have thought of the best one yet. If we have already locked ourselves in to how we will proceed, we may not be able to change direction and use the better way we discover as we delve deeper into the problem domain.
If pressed to detail the "how" component, explain that they will get much better results if they tell you what they require the system to accomplish, then have you tell them how. Otherwise, they are asking you for a travel itinerary before they choose their destination!
It is always best to use everyday analogies to explain why you won't do what they have just asked you to. They may not have figured it out about software construction, but they do know that the travel agent can't quote them a price until they say where they want to go.
Then, back it that comment with a project plan for delivering the next Zachman row of deliverables in detail and the remaining rows with (inherently) less accurate estimates (or the promise to deliver such a plan by a specified date in the very near future).
In the next installment, we will examine in detail each of the major components of the project scope document, making a point to place each component within the Zachman Framework.
...coming May 1
might want to check out the website www.BRSolutions.com. Ron Ross is a major
contributor to business rules theory, and his company's web site always has
interesting business rules material on it. We've modified the Zachman
Framework that is presented by his company. You might also want to check out
the courses that they offer on business rules definition as well as their
books. Both are excellent. [return]
 The same situation is true when interviewing for a job. Never answer the question: "How much did you make in your last job" or "How much do you expect to make here?" You have nothing to gain and everything to lose. They already know what salary range they can offer. If you quote a number that is too low, their offer will be lower than you could have gotten from them. If you quote a number that is too high (but would happily accept a lower offer), they won't hire you because they think you will be unhappy with their offer and jump ship at the first opportunity. The proper answer, no matter how hard they press, is "I want a fair wage for the valuable services I will provide to your company. Make me an offer based upon what I am worth to your company. If the only reason I will not accept the offer is based upon the salary amount, I will tell you that and we can negotiate further if you wish to."
The above example is not a digression; it is another example of a good negotiating technique. Anyone who is involved in determining or maintaining the project scope knows that, given no constraints on time or resources, the system should "do everything auto-magically." This is because constraints require prioritization of scarce resources. In the example above, the recruiter must prioritize minimizing salary expense with filling the position quickly. Your answer lets them know that you understand their dilemma and will work with them to avoid a catastrophic mistake on their part (which would be losing out on hiring a highly-qualified candidate like yourself over a few thousand dollars). They know they can't make an offer that is too low or it would insult you (particularly since you handled them so professionally), so they are unlikely to name the lowest figure in the salary range to start with. [back]
© 2000, Stonebridge Technologies, Inc.