In the first installment of this article, we set the stage for "Project Scope" -- in the context of the Zachman Framework -- and examined a sample project scope document. In this installment, we will examine in detail each of the major components of the project scope document.

1.1.3 Defining the Scope Document Components

Here are the major components of the project scope document. We'll make a point of placing each component within the Zachman Framework. Table 3 presents a brief definition of each of the components. The subsections following this will provide more detail, examples, and guidelines for them. All of these components are important, but some of them are harder to do or get than others.

Table 3 -- Project Scope Document Components

Component	Zachman Question	Zachman Audience	Prefix	Definition
Problem Statement	Why	Sponsor		A brief allusion to the pain that the organization is feeling that motivates it to undertake a project.
Mission Statement	Why	Sponsor	M- DM-	What the business does for its customers. Contrary to popular belief, this should not take a six-month project just to discover. If we are discussing a subdivision of an organization, we might record two mission statements. One will be for the organization as a whole, and the other will be for the organizational unit.
Business Objectives	Why	Sponsor	O- DO-	Each objective represents the steady, consistent condition that the business wants to be in when operating in the new, "normal" mode. It must be measurable to be meaningful. Again, we might have overall business objectives and specific departmental objectives.
Project Goals	Why	Sponsor	G- (IG-)	Each project goal represents a transient condition that the business wants to achieve during the course of conducting the project. When the project is completed, the project goal disappears. It, too, must be measurable to be meaningful.
Major Business Objects	What	Sponsor		The major "things" that the business needs the application to deal with.
Major Functional Transformations	How	Sponsor		At this level, we will assume that if we have a "Thing," we will need a "Maintain Thing" and "List Thing" business task. We are interested in recording business functions that are not so easily deduced. Calculate Payroll would qualify as a major functional transformation in a payroll application.
Major Business Events	When	Sponsor		Business events that occur and that we want the business to respond to in some (pre-scripted) manner.
Major Business Locations	Where	Sponsor		The physical locations where the project work will take place and / or any system component will be deployed. Sometimes, we put a list of "location types" rather than actual locations. For example, we might say "All Stonebridge Technology Offices" rather than list each office individually.
Major Business Actors	Who	Sponsor		An organizational unit, or a personal or organizational role that will interact with the system. Roles are usually preferable to units, and persons (by name) are never appropriate. Computer systems, however, are appropriate.
Goal & Objective Measurement Criteria	How	Sponsor	MC-	Subjective or objective criteria that are pre-defined and for which actual performance can be accurately compared to.
Definition of Terms	What	Sponsor		A working definition for any term in the project scope document that will not be immediately, clearly, and consistently understood by the business staff members of the project team.
Document Sign-Off	Who	All		This is where the key parties on the project affirm that they are in agreement with the contents of this document. If they won't agree at this point, the odds are not good that they will agree after you build the application.

Problem Statement

We define the problem statement as a brief allusion to the pain that the organization is feeling that motivates it to undertake a project. A great amount of detail is neither needed nor desirable in this information slot.

Here are some sample problem statements, along with who had them:

Who: Anyone who builds custom items or needs a custom item built. Our example is for software; if it was for a car, replace the word "system" with the word "car."

Problem Statement: Requirements gathering is a difficult enough task without having to struggle to organize and present the results back to all interested parties. It is difficult to track where (or even whether!) each requirement actually gets implemented. In addition, when business requirements change in order to stay competitive, it is hard to understand what parts of the system may now be obsolete and need to be reviewed. Furthermore, after a system is built and its project team disbanded, much of the knowledge about why the chosen system design was made is lost.

Who: Someone who needs something build for them, because they can't do it themselves.

Problem Statement: We need a software application custom built for our company in order to support our unique blend of products and services. We cannot build it in-house because our staff lacks the necessary skills and/or they are already fully booked on other projects.

Who: Anyone who manages accounts receivables.

Problem Statement: We sell on credit to our customers, but they don't always pay on time. We could keep up with it manually when we were a small company, but now that we're much bigger, we just can't. We need to streamline accounts receivables handling as well as our credit line determination processes.

Here are some questions that often get the information you need:

• What are your biggest problems?
• What other problems are you facing?
• <Golly!^[10]> That sounds really complicated! Is making that happen a real problem?
• Is there anything that just takes too long or is just too expensive that seems appropriate to mention here?
• What would you most like to change? Why?

The answers you get back may not actually get placed in the problem statement. They may get recorded as risks, policies, rules, events, or objectives. Go ahead and record them under the appropriate category as they show up -- that will speed you up later in the project.

Mission Statement

We are often lucky enough to find the mission statement framed on the wall in the lobby or in the employee handbook -- assuming someone can actually find their employee handbook. Determining the "mission statement" is not intended to be a nine-month corporate-wide study involving all levels of management and hordes of high-priced Big 6 consultants who wear expensive suits and play golf with the CEO.

A simple sentence or two that explains what the company produces and what value that their products and services provide will do. In a pinch, replace the word "stuff" from the sample mission statement with the product types the company sells.

Here are some questions to help get a mission statement (or the makings of one) out of others. We'll start with my personal favorite.

• Does your company already have a mission statement defined? What is it?
• Perhaps there is one in your employee handbook?
• What value does your organization provide to its customers?
• In very general terms, what does your organization produce?

Every organization produces something. For example, the U.S. military produces security and, on occasion, domestic tranquility. However, documenting the true output of some organizations in writing won't always be appreciated. You are sure to encounter some organizational departments that only produce jobs for the lazy incompetents who work there.

Business Objectives and Project Goals

A lot of people use the terms 'goals' and 'objectives' as if they are the same thing. That's an interesting observation, because that person is equally likely to say the phrase "goals & objectives," which would be pretty redundant if the two terms are one and the same thing! We consider them to be two different things.

Each objective represents the steady, consistent condition that the business wants to be in when operating in the new, "normal" mode. We might have overall business objectives and specific departmental objectives.

Each project goal represents a transient condition that the business wants to achieve during the course of conducting the project. When the project is completed, the project goal disappears.

Both must be measurable to be meaningful. (We discuss how to measure in "Goal and Measurement Criteria.")

Here are some sample Objectives and Goals:

Goal: Implement the system by <date>.

Objective: Be a market leader in our line of business. (Assumes they are and want to stay that way.)

Goal: Become a market leader in our line of business. (Assumes they are not and want to become that way.)

Goal and Objective: Become a market leader in our line of business and stay that way.

How important is it to determine whether it is really a goal or an objective? Not all that much. All will be revealed in the fullness of time.

If it is a project goal, it will go away shortly after the project is completed and the goal is met -- and no one will care.

If it is an objective, people will still care about continuing to achieve it even after they already have achieved it.

So, make your best guess and don't worry in the slightest if you are wrong.

Objectives are prefixed with O- or DO-, depending upon whether they are for the organization or a department within it (respectively). We prefix project goals with G-.

In addition, the IG- prefix represents an individual's goal, rather than the organizations' goal. Normally, IG- goals would not, repeat not, be included in the document. We do feel that it is a good practice for you to "know" your personal goals (and those of other key players on the project), as they apply to the project even though you do not write them down. We wrote down ours for you so you would know what we intended to get out of this project.

Here are some questions to find out the goals and objectives:

• What are the overall business objectives?^[11]
• What are your departmental objectives?
• Does your company already have a list of business objectives prepared?
• Does your company already have a mission statement defined? (Perhaps in your employee handbook?) What is it? (Goals and objectives are often written into mission statements although they shouldn't be.)
• What are the goals for this project?
• How would we know we have succeeded?
• How would completing this project help out the organization?
• Is this a one-time achievement, or is there an ongoing need to achieve it? (This helps to tell the difference between a goal and an objective.)

Again, these questions will often provoke answers that will provide information besides goals and objectives. Record the other data in the appropriate place and carry on!

Major Business Objects

These are the major "things" that the business needs the application to deal with. Some technical folks like to call them "Objects"; others prefer the term "Entities." Personally, I prefer "Thing."^[12]

However handy the term, object-oriented is all the rage, so I'll defer to the marketing gonzos and use the term "Object."

Here are some sample Objects from other applications:

• Invoice
• Check
• Bill of Lading
• Inventory Item

In relational modeling terms, an Invoice is often described as two entities: Invoice Header and Invoice Line Item. This document is certainly not the place to do that! In business terms, it is an Invoice. This is a business deliverable, not a system design deliverable. So, Invoice it is!

There are plenty of good books about data modeling, so we won't be covering this subject in a great deal of detail.

Here are some questions to help you quickly get a list of potential Business Objects:

• What documents do you need to send to others, either inside or outside your organization?
  • Do we need to keep a record that we sent them?
  • ...or what they looked like when we did?

    (That last question is one of the fundamental differences between a business object and a report.)

• What documents do you receive from others, either inside or outside your organization?
  • Do we need to keep a record that we received them?
  • ...or what they looked like when we did?

Not all of the information that you will get needs to go into the scope document. Go ahead and record it for later, though.

Many of the items under other headings within this document may end up as objects. Actors, locations, and events are prime candidates. However, that's a little secret for the technicians to use later; there is no need to be redundant in the scope document.

Major Functional Transformations

At this level, we will assume that if we have a "Thing" we will need a "Maintain Thing" and "List Thing" task. These do not need to be recorded in the project scope document, although they do need to be listed in the project plan for the next phase of development. (With the full list of tasks that need to be analyzed safely recorded in the project plan, we can still justify the amount of time it will take to complete the system.)

Instead, we are interested in recording business functions that are not so easily deduced. "Calculate Payroll" would qualify as a major functional transformation in a payroll application. "Select Customers for Mailing List" would be one for a direct mail advertising system.

The name of each transformation will often follow one of these formats:

Action Verb ==> Business Object

or

Business Object ==> Action Verb ==> Business Object .

Avoid verbs like handle, process, and do, as they are usually so vague as to be meaningless.

Major Business Events

When a business event occurs, the business needs to respond to it. For many events, we want the business to respond to it in a pre-arranged manner rather than just making it up as they go along.

Business events are often initiated by an actor from outside the organization. Events should be listed in this format:

Actor ==> Action Verb ==> Business Object.

Here are some sample business events:

• Customer makes a complaint.
• Customer might place an order.
• Accounting receives an invoice.

  (Note we don't care about the event "Vendor sends invoice." because we don't know about it. We only know when we receive it.)

Here are some questions that can help you to identify business events.

• What are some of the major events your business needs to respond to?
• Who starts the ball rolling?
• What happens that requires you to respond? Who initiates it?

Major Business Locations

A Business Location is one of the physical locations where the project work will take place and/or any system component will be deployed. Sometimes, we put a list of "location types" rather than actual locations. For example, we might say "All Company Offices" rather than list each office individually.

Here are some questions to help you find out the locations you need to worry about:

• Where will the users of the application be located?
• Will people use the system from their homes or from portable devices?
• Is Internet access required? Are the users known ahead of time, or is the system for use by just anyone?
• Where will development occur?
• Where will the computing equipment be located?
• Is there an emergency backup site? Where is it?

Major Business Actors

A Business Actor is an organizational unit, or a personal or organizational role that will interact with the system. Roles are usually preferable to units, and persons (by name) are never appropriate. Computer systems, however, are appropriate.

Why use roles instead of people? Because a person may perform many roles and their replacement, when the person moves to another job, may not have the skills to perform the same roles. Here are some sample roles:

Table 4 — Sample Business Actors

 

Type	Name
Personal	Accounts Payable Clerk
Personal	Accounts Payable Supervisor
Personal	Accountant
Personal	Chief Financial Officer
Organizational	Accounts Payable
Organizational	Accounting

In a project covering the entire accounting infrastructure, the organizational roles are probably the only ones that need to be mentioned in the scope document. That keeps the size of the document to a minimum. However, you should record the relevant personal roles when you learn about them.

Goal & Objective Measurement Criteria

Why have agreed measurement criteria before the project is built? What if we have a project goal that the system will have a fast response time? How fast is fast, exactly? Do we mean a three second response time for a data record to be queried and displayed on the screen, or do we want sub-second speed?

This simple goal could have far-reaching effects upon how the system is implemented. It's cheap to agree up front on what is meant by "fast." It could be very expensive to discover sub-second response was needed at implementation time when a three-second response time was planned for.

Measurements may be precise and they may be accurate. There may be a "causative association" or just a "correlation". In addition, they may be subjective or objective. All these terms are important to understand when choosing measurements.

Precision and Accuracy

First, we will cover precision and accuracy. If I estimate I will finish a task tomorrow morning at 8:15 AM, that is a very precise estimate. If, however, I do not complete it until 11:00 AM, then it would not have been very accurate estimate.

If I had estimated that I would complete the task "sometime tomorrow morning", that would not have been very precise, but it would have been accurate. Thus, precision deals with the granularity of the measurement and accuracy deals with the correctness of it.

Causative Association

Stabbing someone in the arm with a knife will make them bleed. That is an example of a "causative association." The action causes the result to occur. The result does not need to be certain, as in the example above, to have a causative association.

By contrast, a correlation means that two unrelated items seem to act in a similar manner. For years it has been observed that the U.S. stock market rises when women's hemlines are rising, and falls while they are lowered. Neither situation "causes" the other, but they have tended to "co-relate" to some other phenomena.

That doesn't mean that correlations are automatically bad measurements, it just means that they are less reliable unless the reasons for their correlation are properly understood.

Subjective or Objective

That leaves subjective and objective measurement to explain. First of all, we are using the term "objective" in a totally different context from that of "goals and objectives."^[13]

An objective measurement criterion is something that is easily counted and therefore requires little or no "judgment." Example: The student learned the course material if they received a grade of "A" or "B" would be an objective measure. They either did, or did not, receive that grade.

A subjective measure might be needed when wanting to know whether someone is "a good programmer." Our measurement becomes objective if we measure their productivity and error rate; it remains subjective if we make a judgment based upon a "gut feel."

Objective measurements aren't necessarily better. If, like some schools, the student is given an "A" just for breathing through the duration of the course, our objective measure might not accurately measure what the student knows. (In other words, there is a correlation between grades and knowledge, but not a causative association.)

Here are some questions to ask:

• How would we know we have achieved this?
• How could we measure this?
• Are there any weak points in using that measurement?
• Is the suggested measurement so well defined that 9 out of 10 people asked to provide their judgment would agree?

  (Use this for subjective measurements; ask for 100% agreement on objective criterion.)

• How could we automate the measurement?
• How much effort or cost will it take to use this particular measurement?
• Is there a somewhat less reliable, but more affordable way to measure this?

Definition of Terms

Note that the project scope document does not contain any "excessive verbiage." That is intentional. Project sponsors rarely have an excess of time to spend on any one topic. They need their information "short and sweet" and they appreciate those who deliver it that way.

However, just because those items aren't defined in the project scope document doesn't mean that you shouldn't record them. Each of these items must have a brief definition recorded for it, similar to the definitions found in the project scope document appendix: Definition of Terms.

That said, it is just as important to have the definition provide meaning. Consider the following term and its definition:

"Thing Type: A Type of Thing."

Entering in a definition like that is worse than useless, because it adds no value and just consumes time to write it. The definition must explain what is meant and why someone would care to know that information.

Here's another example:

"Application User: A person who uses an application for an authorized purpose."

What does the definition add? First, we know a user must be a person, not a program. Second, the person is expected to have an authorized purpose for using the system. That adds quite a bit more than "Application User: A user of the application."

Here are some questions to help you determine if your definitions are useful:

• What purpose does knowing this information serve?
• Why would anyone need to know this?
• Does it represent a "real thing" or a "definition about a real thing" or a "definition about a definition?"
• Does it use another term that hasn't been defined?
• Is the definition just a sentence that rearranges the words in the term?

Why did we say that brief definitions are required for all the items on the project scope document? Wouldn't that just be extra work? Wouldn't that just slow down the process? Actually, the brief definitions speed up the process considerably and add extra value to the project as a free side-effect of recording them.

Let's consider how that could be!

First of all, if you really understand the terms, writing a brief, one or two sentence definition shouldn't take very long. With a bit of practice, you can really zip through them in a minute or two apiece. I spent about an hour defining all the terms used in the project scope document (the appendix and those terms defined in "Table 3 — Project Scope Document Components."

Then again, I've got lots of practice at this. Expect to spend about three hours for a similar amount of work until you've done it for a while. Tip: You can always look it up in the dictionary or thesaurus!

Of course, if you don't really understand a particular term, you will know right away that you do not — because you will not be able to define it. This is your first quality assurance check. A single misunderstanding between team members here could easily consume three hours to fix later in the project.

Given that there were 20 definitions for this document, what are the odds that all of the project team would have the exact same understanding of what the term entails? Failing to mutually understand just one term out of 20 is just a 5% failure to communicate. That's quite a fine job of communicating, and not likely to be achieved often. With truly excellent (if not unattainable) team communication assumed, we have broken even on the time it takes to define the terms.

Now, what if we all agree as to the meaning, but we didn't properly understand the term at all? Often, when we try to define an object, we discover the existence of other objects hidden in our partial understanding of it. (Not hidden in the object, mind you, but hidden in our failure to immediately understand its true nature.)

Again, just one mistake here could easily consume three hours to correct later in the project. We are now at least 3 hours ahead in our actual project delivery timeline by taking the time to properly define the terms. We could be a month ahead if the mistake we just caught was a big one.

Note the very careful choice of words we made when we referred to our "actual project delivery timeline." Note that we didn't say we would be ahead in our "project schedule." That's because project schedules are usually based upon wishful thinking and subconscious appeals to a merciful God, not the likelihood of things going wrong and planning for mistakes to be made (and then corrected). We know we are human and that we will make mistakes. The more complex the application we have to build, the more mistakes we will make. It is foolish to pretend to make progress when all we are really doing is compounding errors upon errors until we discover (once again!) that nothing works very well when we perform a system test.

Getting back to projected time savings, how many technicians will be added to the project through implementation? Does each of them have the requisite business knowledge to understand each of the terms in the scope document? If not, how will they find out? Will you give them a verbal explanation? That might be more time-effective if only one person is to join the project or all new project staff join at the same time. If you have to explain things more than once, you will find it is faster to just hand them a copy of the project deliverables and tell them to read the appropriate portions.

And, of course, as things get hectic and you get worn out and inundated with subject area details, it becomes harder and harder to maintain the proper focus.

What, exactly, are we supposed to be accomplishing?
Is what we are doing at this level of detail consistent with what we scoped out?
What did that term mean again?
I understood it at the time...

All of these common situations will take much less time with a properly done project scope document, complete with supporting definitions.

About the time things get hectic and you get worn out, you may be given a technical writer to prepare the documentation. Of course, they will know absolutely nothing about the business or your application. If documentation has to be delivered with the product, how will they write it? They will be too ignorant! Every term you define up front is another term that they won't pester you about later, when you least have time to talk to them. More time savings!

Of course, if you don't deliver documentation and you are going to remain on staff, you will never be free of the application. Every maintenance analyst and programmer who wanders through the application will have to interrupt you for information. If you want to work on new challenges, you will do better on them if you don't leave an undocumented ball-and-chain attached to your work schedule.

And, of course, if you do get into a project scope dispute, it's incredibly handy to have those definitions already written down. You may still have to include the new functionality, but your ability to negotiate additional time, budget, and resources will be much better than it otherwise would be. If your goal is to deliver the needed functionality on time and within budget, this one investment could easily save you a 25% overrun of the total project budget. Think about it!

In short, defining the terms used in the document improves your understanding of the problem domain. It is a fast and effective quality check that removes potentially costly errors while they are still very cheap to fix. It saves you time and effort every time a new person joins the project team, you get confused, or someone tries to change the scope on you (but keep the time, budget and resources the same). Not bad for a three hour investment!

The example we gave to illustrate the mathematics of compounding errors was a simple one. What would happen if we had a larger application? First of all, in our simple example, we were always optimistic about our ability to do things right and the likelihood of anything really going wrong. For a simple application with an experienced team, that might be a reasonable assumption. The larger and more complex the application, the less likely it is that an overly optimistic scenario will unfold. Instead, mistakes will happen with greater frequency and they will be bigger mistakes. However, the estimates for time to define a term remain largely the same. Thus, the larger or harder the project, the better the timesavings you will get!

Document Sign-Off

Many years ago, long before I had learned the full range of requirements-gathering techniques we present here, I was instructed to sit in on a meeting to scope out a new application that would bridge the operational gap between the departments of two senior vice-presidents. Both VPs were in the meeting and took an active part in the proceedings. At the conclusion of the meeting, I returned to my cubicle where my own boss asked me about what it would take to build the application that they wanted.

My response surprised him: "Throw them into a room with a knife apiece, lock the door, and only open the door when one is left alive. Build what the one who survives instructs you to build. Either that, or assign me to sit in meetings with them for the next 6 months until I wear them down and they come to agreement to escape the meetings. At that time, we will start making progress on the application."

Personally, I thought my answer was clear and succinct. (It was also subjective and precise. As to accuracy, well, it might have taken 3-8 months to wear them down.) It was also, apparently, unsatisfactory, as my manager went to the next meeting instead of me. When he returned from the meeting, I asked him for his assessment of the situation. He smiled and said that he couldn't spare me just to sit in meetings for the next six months. We focused on different projects for the next year.

It's very important, if you are responsible for building an application, that all the key parties agree on what needs to be done or at least on what will be done (which isn't always the same thing.) If that agreement isn't in place between the key parties, the project will almost certainly fail. If you are an important technician on the project, rest assured that you would be blamed for it rather than the VPs!

The trick is to make their disagreements visible early in the process so that they must either cancel it before many resources are wasted or come to agreement with one another. If it is obvious that the key business leaders are unsure of what business direction to take, then it is much easier to get them to recognize they need to come to agreement first.

Back to the story! A year later, my manager shrugged and sent me off to a meeting with the same VPs to discuss the same application. Nothing had changed except my ability to deal with the situation better. I realized that not only did the VPs involved have different organizational interests (which caused many of their differences); they did not trust one another. Each one of them was afraid to take a position because the other might use it against them. After all, good business practice requires the management of risk -- and risk means that something could go wrong. Once I understood this was the true problem, I could manage the process better.

What did I do differently? Instead of asking each VP to sign off on the project documents, which would put them at risk, I went to each one of them privately and asked them if they would approve the document if no one else had any objections to the document. Each one of them agreed that they would. No objections were raised by anyone, so I went back and told them that no one had any objections. They could then sign off in equal safety and did so. (The project was a success.)

1.1.4 Exit Criteria

How do you know that you are done? Sadly, that isn't an easy question to answer. Let's try it from the opposite angle. How do you know that you are not done?

If you cannot pass all of the items in the exit criteria, you are not done. If you can, you might be done (and will need to act as if you are.)

Given that we've come to the end of the document and its explanation, it's time for us to exit, too!

Table 5 — Project Scope Document Exit Criteria

 

Exit Requirement	Comment
Grammar has been checked.	The names of all the items in the document are properly spelled. The definitions are syntactically correct.
Definitions exist for all items.	Each and every item mentioned has a proper definition written down.
Definitions are useful in business terms.	A total stranger reading the term and its definition will understand what the term means and can provide a real business example to demonstrate the meaning.
Items are cross-checked with one another.	For example, no functional transformation refers to a business object that has not been defined. Business events are not performed by actors who have not been defined.
Scope document is believed to be complete and correct by all parties.	All notes have been crosschecked against the scope document. Standard data or business models, if available, have been used for comparison. Actual working document samples have been crosschecked for missing items.
Signatures	The key players agree that the document accurately reflects the high-level requirements of the system.

References:

[10] Use the culturally appropriate exclamation of dismay and commiseration upon hearing about some horribly convoluted situation. [return]

[11] Always start off with the easiest and most obvious questions first! Sometimes you get lucky! [return]

[12] To be fully accurate in all contexts, I prefer Morticia Addams to "Thing." [return]

[13] Hey! Don't complain to us. We didn't invent these terms and the confusion that they cause! We're just telling you about them. [return]

© 2000, Stonebridge Technologies, Inc.