"Why on Earth did I get involved with that Business Rules project???"  — Day 1 on a traditional modernizing project.   Joe stares at the empty spreadsheet.   He has been underwriting business for over 20 years and only one thing comes to mind…

What do I do now?

Does that sound familiar?  No wonder it does.  Summarizing a lifetime of knowledge and savoir-faire into a dry spreadsheet may sound overwhelming simply because it is.

A "Business Rules" project

Problems started when Joe thought about his project as just a "Business Rules" project.  Losing focus on the business, Joe was stepping into a technology world he did not belong to, and that made him uncomfortable ... and as a result, quite unproductive.

The end goal is not to use technology.  We all know that, of course, but we sometimes lose sight of what we are really trying to do.  Rules Architects and Business Analysts alike too often jump too deep too soon into their projects.  They both look for how to get this project implemented as if they were developers simply using a new syntax.  Writing code is obviously not second-nature for a business person.  So why do people start that way?

Can tools help?

BRMS tools come with interfaces for the business users.  There are very few exceptions and I would not qualify those that do not have a business user interface as 'Business Rules'.  Most of the time, you end up with two interfaces:  one for the business user (of course) and also one for the technical use (read 'Developer'), so that he/she can set up the business layer on top of the technical syntax.

One pitfall I have seen again and again over my 15 years in that industry is that developers think about implementation first and treat the business user interface as an afterthought.^[1]  This leaves business users with some level of frustration that could be addressed by better empowering them from the get-go.  This is partially a tools limitation but, more importantly, a methodology issue.

Can methodology help?

I distinguish two different types of methodology that can be involved:

• Implementation Methodology.  This covers the techniques used during the course of the project implementation.  The Business Rules methodology may be relying on a formal 'Agile' methodology (for example) but could also be ad-hoc, based on your own experience — or a combo of both.  My recommendation here is to involve the Business Users really early on, instead of waiting for a first-phase implementation, fully coded by developers with little understanding of what the business user will need to, and be able to, manage.
  
  
• Knowledge Acquisition Methodology.  This covers the steps performed ahead of any implementation.  The aim is to gather the intelligence about your project that will drive the requirements.  I liked Gladys's article on Business Rules vs. Business Requirements.^[2]  A methodology for mining those business rules could have helped Joe.  It can provide a framework to elicit the knowledge from business users in any format that appeals to them:  applications, spreadsheets, documents,…

The earlier you involve people like Joe in your Business Rules projects the higher your chances of success.  But beware of the pitfalls:  "having a business user onboard" does not mean simply providing him with a spreadsheet to dump his/her knowledge into.  The Art of knowledge elicitation relies on your ability to relate to their business and to have them describe what they do, need to do, or want to do … such that technology is not in the way.  They must feel comfortable and in control.

Key take-aways:

• Turn the Tables:  It is not about the technology — it is about Joe.
  
  
• Treat Business Users like Kings:  Focus on them — they will focus on the business.
  
  
• Success is Infectious:  If they make an impact, they will want more.

[1]  The article #1 Pitfall in Decision Management goes into further detail on the importance of a business user interface.  URL: http://bit.ly/aJhaos  

[2]  Gladys S. W. Lam, "Business Rules vs. Business Requirements," Business Rules Journal, Vol. 7, No. 5 (May 2006), URL:  http://www.BRCommunity.com/a2006/b290.html  

# # #