- On Business Rules project best practices – Part I – Introduction
- On Business Rules project best practices – Part II – Help and Education
- On Business Rules project best practices – Part III – Scope the project
- On Business Rules project best practices – Part IV – Build a prototype
- On Business Rules project best practices – Part V – Plan the project
- On Business Rules project best practices – Part VI – Divide and Conquer
- On Business Rules project best practices – Part VII – Model and Vocabulary
In the first post of this series, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.
Scope the project
Project managers always work with the “triple constraint” of scope, time and resources and this is the first component of these constraints. It basically answers the following question: What needs to be done?
All project managers should be very knowledgeable about “what needs to be done”, but what we want to extract as a best practice for a business rules project is actually related to other best practices.
One of the first pieces that needs to be focused on is the “build a prototype” best practice (coming soon to a post near you!). In a business rule project we will want to build a prototype or pilot. So part of the current scoping exercise is to try and identify a piece of the pie that will be sufficiently large to be of use, yet sufficiently small so that it is manageable as a first step in this type of project.
The biggest challenge here is probably not to identify which pieces of the business rules can be used in the prototype, but which pieces are required to make this prototype work.
- Which pieces of the complete architecture needs to be in place for the prototype to work?
- Are there other choices that minimize the number of architectural components that need to be involved?
- Can we build on the work of the prototype for subsequent phases?
- And eventually, what is the effort required for the implementation of this prototype?
In short, we need to scope the project as a whole, but also to identify and scope what is required for a prototype to work. We will eventually look at this scope again with the experience of the prototype behind us and re-evaluate the scope and plan the project.
[Addendum based on James Taylor’s comments, 2009-02-14]
James Taylor wrote a comment on this and I think that it is a very good point and decided to add it in to this post.
Focus on the decision(s) you are automating. Start with the decision in mind and it is a lot easier to determine if a given rule source or collection of rules is going to be relevant.
Yes, decisions are the starting point of it all. This advice will help guide you in your project. (And yes I am becoming partisan to the idea of decision management… 😉 )
Scope the business rule harvesting
One of the new pieces of the project that needs to be scoped in a business rules project is the business rules harvesting effort. This is something that you will probably need help in doing the first time around and is important enough that it needed to be discussed separately.
In a webinar called “Scoping a Business Rule Harvesting Project: What Questions Should You Ask?” available on the business rules forum web site, Gladys Lam presents many questions that need to be answered so that the scope of the business rules harvesting work can be established. The webinar is definitely worth a look, but I will repeat some of the questions here:
- What are the objectives for the business rules harvesting?
- What types of rules are present?
- Is there subject area (domain) knowledge available?
- What are the sources of the business rules and how easy are they to understand?
- How many rules are expected?
- Is there a consistent vocabulary (terminology) and model being used (and enforced) today?
- What is the experience in rule harvesting of the people that would be involved?
- How many review cycles are used? Who are the key players?
- What are the traceability requirements?
- How complex are the rules?
- Do the rules need to be re-engineered?
- What tools will be used?
Answering these questions will give you some of the information required for scoping your business rules harvesting project and will help you evaluate your need for external help.
 Lam, Gladys S.W., Scoping a Business Rule Harvesting Project: What Questions Should You Ask? Webinar available at http://www.businessrulesforum.com/webinars_active_viewing.php?view=375