Top 10 Mistakes Business Analysts Make When Capturing Business Rules: Mistake #7: Not Having a Well-Defined Scope

Gladys S.W.  Lam
Gladys S.W. Lam Co-Founder & Principal, Business Rule Solutions, LLC , Publisher, Business Rules Journal , and Executive Director, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Gladys S.W. Lam

We all know how important having a well-defined scope is for any project activities.  This is especially true for business rules harvesting projects.  An additional process task, decision, or business concept could mean 10 to 100 rules.  In my experience, any change in business scope always means some impact to business rules.  The impact is never small.

Business rules need to be defined at the business level (not simply for just IT implementation).  To do this, the scoping elements must be business friendly.  Identify your scope criteria using business artifacts.  The following are four very common scoping elements.  You can define scope:

1. By Business Process Tasks

This is perhaps the most common way of providing a boundary for business rules.  In a business process model, identify the tasks that require business rules.

For example, here is a simple process flow for shipping antiques:

Each of these tasks may be guided by many business rules:

'Pack Antique Art for Shipping' — There are business rules on what packing materials must be used for what kinds of antiques.

'Assign Security Guard' — There are business rules on differently-valued antiques being assigned to different security levels of guards.

'Notify Insurance Company' — There are business rules on differently-valued or different types of antiques being insured by different insurance companies.

'Notify Customer' — There are business rules on who and where to notify the customer depending on destination.

'Ship Antique' — There are business rules on different types of antiques being shipped by different methods and different types of customers being given different shipping options.

Any one of these tasks can have anywhere from one to hundreds of rules, depending on the complexity of the business.  Be very clear at the onset of the project which of these tasks is within scope for rule harvesting.

There is one thing I have learned about business rule projects.  You can't assume any one task is simple (with fewer business rules).  For example, in almost any business, business rules around an address would be simple and standard.  No one would allocate much time to harvesting address type business rules.  However, at FedEx, they literally have thousands of rules about an address, rules that most businesses won't care about.  So, be careful of your scope.  Do not assume simplicity.

2. By Decisions

Identify the decisions that require business rules.  Some decisions may be determining:

  • Is the customer eligible for membership?
  • Is the customer eligible for a discount?
  • Is the employee qualified to perform the activity?

Again, any of these decisions could require one or hundreds of business rules to determine outcome.  Be clear which one is within scope.

3. By Business Concepts

Any key concept that a business uses can have many rules around it.  For example:

  • Customer
  • Employee
  • Claim
  • Antique

Scoping at this high level is very dangerous.  Can you imagine the number of business rules you might have pertaining to Customer?  The more refined the concepts, the more precise the scoping.  For example:

  • Gold Customer or Delinquent Customer, instead of a just Customer

  • Retired Employee or Temporary Employee, instead of just Employee

  • Bodily Injury Claim or Glass Claim, instead of just Claim

  • Oil Painting or Renaissance Sculpture, instead of just Antique

4. By Source Document

Identify the chapters, the sections, or the pages of a source document that are within scope.  Be aware that a page in a source document can refer to business tasks, decisions, or business concepts that are in other parts of the document that can contain additional rules.  Your scope can easily expand to cover the entire document if no other boundaries are identified.  In order to get a precise scope, you need to combine the source document with one of the other three scoping items suggested above.

In fact, a combination of all four elements would provide the best, the most specific scope.  For example:  The scope for a business rules harvesting project could be:

  • business rules required to determine if a customer is a Gold Customer.

  • business rules that guide shipping antique art to Gold Customers.

  • business rules documented in "Chapter 4 — Gold Customer" of the Customer Service Guide.

Just Remember…

Plainly speaking, here are some of the main things you need to remember:

  • Without clear scope, your business rules project can easily go on and on.  Adding one small scoping element can mean hundreds of business rules and can mean impacts to existing business rules already harvested.

  • When identifying your scoping elements, be as specific as possible.

  • Use combinations of scoping elements to ensure precision and clarity in scope.

# # #

Standard citation for this article:


citations icon
Gladys S.W. Lam , "Top 10 Mistakes Business Analysts Make When Capturing Business Rules: Mistake #7: Not Having a Well-Defined Scope " Business Rules Journal Vol. 12, No. 8, (Aug. 2011)
URL: http://www.brcommunity.com/a2011/b610.html

About our Contributor:


Gladys  S.W. Lam
Gladys S.W. Lam Co-Founder & Principal, Business Rule Solutions, LLC , Publisher, Business Rules Journal , and Executive Director, Building Business Capability (BBC)

Gladys S.W. Lam is a world-renowned authority on applied business rule techniques. She is Principal and Co-Founder of Business Rule Solutions, LLC (BRSolutions.com), the most recognized company world-wide for business rules and decision analysis. BRS provides methodology, publications, consulting services, and training. Ms. Lam is Co-Creator of IPSpeak, the BRS methodology including RuleSpeak®, DecisionSpeak and TableSpeak. She is Co-Founder of BRCommunity.com, a vertical community for professionals and home of Business Rules Journal. She co-authored Building Business Solutions, an IIBA® sponsored handbook on business analysis with business rules.

Ms. Lam is widely known for her lively, pragmatic style. She speaks internationally at conferences, public seminars and other professional events. She is also Executive Director of Building Business Capability (BBC) Conference, which includes the Business Rules & Decisions Forum and the Business Analysis Forum.

Ms. Lam is a world-renowned expert on business project management, having managed numerous projects that focus on the large-scale capture, analysis and management of business rules. She advises senior management of large companies on organizational issues and on business solutions to business problems. She has extensive experience in related areas, including BPM, structured business strategy, and managing and implementing information systems.

Ms. Lam is most recognized for her ability to identify the source of business issues, and for her effectiveness in developing pragmatic approaches to resolve them. She has gained a world-class reputation for fostering positive professional relationships with principals and support staff in projects. Ms. Lam graduated from the University of British Columbia with a B.S. in Computer Science.

Read All Articles by Gladys S.W. Lam
Subscribe to the eBRJ Newsletter
CONTRIBUTOR ARCHIVES
Seven Common Myths About the Zachman Architecture Framework
Being Business-Friendly About the Life of Business Things
Structured Business Vocabulary: Concept Models
The Architectural 'Why' of a Business Capability: Business Mission and Business Goals
Architectural Scope vs. Project Definition
In The Spotlight

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.