Features

Articles

Project Scope Document: A "How To" (Part 1)

Summary: Project Scope Document: A "How To" (Part 1)

David Wendelken Consultants, Stonebridge Technologies, Inc. Read Author Bio || Read All Articles by David Wendelken

Betty Hilbrant Baker Consultant, Stonebridge Technologies, Inc. Read Author Bio || Read All Articles by Betty Hilbrant Baker

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:

You would be lucky to get this person to work for you.
I am glad to say that this is a former colleague of mine.
I can assure you that no one would be better for this position.
I cannot say enough good things about this person.
I most heartily recommend this person with no qualifications whatsoever.

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.^[1]

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.

Much 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!

We 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.

Our 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.

Table 1 provides a "you are here" roadmap for the Project Scope Document.

	What	How	Where	Who	When	Why
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 ^[2]

1.1.1 Entry Criteria

Entry criteria are relatively lax for this deliverable.

Entry Requirement	Comment
"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.)

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.^[3]

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).

Next Time

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

References:
[1] Wendelken, David and Carrie Anderson. The Oracle Designer/2000 Handbook, Addison-Wesley, 1996, pg 14. [back]
[2] Yellow boxes are detailed in the deliverable. [back]

You 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]

[3] 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.

Standard citation for this article:

David Wendelken and Betty Hilbrant Baker, "Project Scope Document: A "How To" (Part 1)" Business Rules Journal, Vol. 1, No. 4, (Apr. 2000)
URL: http://www.brcommunity.com/a2000/b002a.html

About our Contributor(s):

David Wendelken Consultants, Stonebridge Technologies, Inc.

David Wendelken is a consultant for Stonebridge Technologies, Inc. This is a condensed extract from their forthcoming book, tentatively entitled "Building Business Rule-Based Systems for Internet Deployment." They can be reached at 1 (404) 248-1226 or at dwendelk@concentric.net.

Read All Articles by David Wendelken

Betty Hilbrant Baker Consultant, Stonebridge Technologies, Inc.

Betty Hilbrant Baker is a consultant for Stonebridge Technologies, Inc. This is a condensed extract from their forthcoming book, tentatively entitled "Building Business Rule-Based Systems for Internet Deployment." They can be reached at 1 (404) 248-1226 or at dwendelk@concentric.net.

Read All Articles by Betty Hilbrant Baker