• On-going business rules management by the business
  
  
• System implementation
  
  
• Both

Organizations often initiate projects with the objective of harvesting business rules from source documents, from the heads of people, or from computer code, in order for the business to gain understanding and control of their own business rules.  For those projects, ongoing management of business rules by the business is critical to achieving the ultimate vision.

Most traditional IT projects specify business logic in the form of detailed business rules.  For this type of project, once business rules are specified for system development, the rules are transformed into system code and are embedded in the implemented system.  In this form, it is hard for the business stakeholders to get to the rules.

2. What types of business rules?

• Behavioral rules
  
  
• Decision rules

Behavioral rules are business rules whose purpose is to shape (govern) day-to-day business activity.

3. What is the availability of subject area knowledge and expertise?

• Subject area expertise is available
  
  
• Subject area expertise is not readily available

The subject area experts required are those who have the business knowledge and expertise specific to the scope of the project. 

These subject area experts are especially important if they are the source of the business rules (i.e., the business rules are in their heads).  The subject area expert(s) with the business rules in their heads must be available.

4. How understandable is the source material?

• Understandable
  
  
• Not easily understood

Identify the source.  This can be:

• business documentation (regulations, agreements, policy guidelines, websites, procedure manuals, etc.),
  
  
• use cases,
  
  
• system code.

5. How many business rules?

• By Process tasks/activities
  
  
• By Decision

Be sure to count all sources.  Identify process tasks, activities, and decisions.  Estimate by process tasks, activities, and decisions.  Break down to sub-tasks or sub-decisions, if required.

6. Does the scoped area use consistent terminology?

• Yes
  
  
• Not always

Terminology is the backbone of business rules.  Consistent use of business terminology will ensure consistent, accurate, and precise business rules.  If the business has confusing or undefined terminology, there could be a lot of work required to align terminology with the harvested business rules.

7. Is there already a terminology model?

• Yes
  
  
• No

An already-approved terminology model can save a lot of time on business rules specification.

8. What is the level of rule harvesting experience of business (rules) analyst(s)?

• Has harvested business rules for 2 projects or more
  
  
• Has been trained but has not conducted any project work
  
  
• Has not been trained

The business (rules) analyst needs expertise and experience in Business Rules:

• Harvesting
• Specification
• Analysis
• Management

And in Business Vocabulary:

• Definition
• Modeling
• Management

9. How many external review cycles?

• More than 2 review cycles
  
  
• 2 review cycles
  
  
• Fewer than 2 review cycles

This question refers to external reviews only.  Project team reviews need to happen as often as necessary. 

External reviews can be:

• Business Team Review, involving business stakeholders who are not in the immediate project team;
  
  
• Technical Team Review, involving system designers and developers (for knowledge transfer).

10. What are the traceability requirements for business rule management?

• Do not need to manage any information about the business rules
  
  
• Manage basic 3-5 elements
  
  
• Manage more than 5 elements

Examples of basic traceability elements include:

• Status
• Motivation
• Source
• Violation message /action

Examples of additional traceability elements could include:

• Where are all the places that implement this business rule? (this might need investigation);
  
  
• Jurisdiction that this business rule applies to.

11. How complex are the business rules?

• Low complexity
  
  
• Medium complexity
  
  
• High complexity

Low-complexity business rules might have only 1-2 conditions and do not have much overlapping logic with other business rules.

Medium-complexity business rules might have 3-5 conditions and have some overlapping logic with other business rules.

12. Do the business rules need to be re-engineered?

• Yes
  
  
• No

Are you harvesting the 'as-is' set of business rules?  Or do you have to improve on the as-is business rules to create a 'to-be' set of business rules?

13. What tools will be used?

• Office suite (e.g., Microsoft)
  
  
• Specialized tool for business rules management
  
  
• Enterprise architecture tool
  
  
• Rules Engine

Business rules tend to multiply (seemingly on their own).  Early use of a tool is important.  There are pros and cons for each of the different types of tools.  Be aware of them and set up an infrastructure from the onset.