"Easier said than done" — this is a phrase I heard myself mumbling as Ron Ross presented the principles of good business rules during the BBC conference in October of 2010.  It had been a tough decision to take time away from my current project for a conference.  Our project was quickly falling behind schedule, and tensions were high between our business rules team and the operations group.  Thankfully, I had the opportunity to attend the first World Congress on Decision Tables that was part of the conference.  I left that day's sessions with wrist cramps from jotting down so many notes, and I started creating decision tables that evening from the hotel room. 

I was familiar with decision tables and had attempted to use them for the rule design in the past but found they quickly grew too large and were difficult for others to comprehend.  Through the sessions that day, I saw how to take decision tables and make them work in a complex rule development project.  As a result, our project that had been failing became a wild success, completing early and achieving a $2.9 million ROI in the first year. 

In this article, I'll walk you through the specific benefits our team experienced and the process we followed to achieve the following results: 

Time spent gathering requirements — reduced from 1 month to 1 week

Volume of implemented rules created — reduced by over 60%

Time testing — reduced from 2 months to 2 weeks

Our department provides outsourcing services to 25 clients across 3 servicing centers.  The project objective included automating the processing of incoming information in order to reduce the turnaround time and improve consistency in outcomes.  In addition, all internal processes were to adopt a common operating model while still allowing for client-specific variations. 

Requirements gathering — reduced from 1 month to 1 week

Each group had specific variations that had to be accommodated within the project, and capturing those requirements was taking close to a month.  Business rules and procedures were intertwined in the documentation.  The implementation of the business rules did not always reflect the desired behavior from the operational groups.  The rule analyst and the operations managers each felt the other group was at fault for misinterpreting the data or for providing incorrect data.  Review meetings often became tense and uncomfortable.  The end result was that the team was running behind schedule. 

The requirements process had been to sit with the operations department and document what decisions and actions were taken for each unique type of incoming data.  This resulted in multiple large documents with redundancies around similar processing.  It also prevented leveraging business rules and procedures from other units.  In addition, the process took so long that procedures sometimes changed during the process, and finding all the references to a particular procedure was cumbersome.  The goal of a common operating model across all clients seemed unachievable as there was no clear way to see commonality. 

Through trial and error, we found the right group of questions to create the foundational decision tables for the business rule redesign.  From an exponential volume of scenarios (due to variations in both internal and external teams, client requirements, and government regulations) a set of 24 decision tables and an 8-page process flow allowed all parties involved in the project to come to a broader comprehension of how the information fit in the big picture.  This then enabled the user community to focus on the question at hand. 

In reviewing what had worked and what had not, we found the following key elements in our final decision tables:

• similar types of information
• consistency of values across decision tables
• clear, concise outcomes for each decision table

Decision tables enabled us to capture the true and complete set of business rules and then to separate them into independent decision points.  This provided the operational groups with a clear picture of the automation that would be taking place and ensured that the rule analysts understood the business objectives. 

Our initial decision tables were huge.  One of our first decision tables contained 720 different scenarios! 

We quickly learned to separate the decision tables into direct questions with a smaller set of possible scenarios.  Breaking the decisions down into direct questions also enabled the various departments to find the common ground and helped develop the common operating model.

The figures below show two separate questions regarding matching incoming information to the appropriate claim or loan.  Historically, this information had been provided as a single question, which had resulted in confusion around when a match was considered to have been found. 

The separation of the questions focused the analysts and the operations staff on specific questions.  Discussions then revolved around the specific variables, and changes in requirements could be quickly evaluated to determine the scenarios that the change would impact. 

These decisions were then placed in a process flow, illustrating when this decision took place in the process and what action would take place if a particular outcome was identified. 

This separation allowed the conversation to focus on either what to do once a decision had been made or on what values were part of a decision.  Previously, the intertwining of this information had led to misunderstandings and confusion. 

As a result, only a few meetings were necessary to determine the variations in business rules unique to that client segment and then apply those variations to the documentation to determine if the data gathered was clear and complete. 

Volume of implemented rules created — reduced by over 60%

The new automation brought significant time savings to the operations area but was quickly becoming cumbersome for the rule analysts to manage.  The implemented rule volume was growing exponentially, and yet many rules were identical in purpose, with variations only in style or naming conventions. 

The variations in requirements prior to decision tables had created a false perception that it would be impossible to reuse existing implemented rule sets for multiple clients.  The decision tables illustrated the similarities, and reusable rules were created that then integrated client-specific values or rules.  For example, all clients would take the same action once information reached or exceeded a fixed percentage.  This results in 3 very similar decision tables, each requiring a separate set of implemented rules. 

Each of the 3 outcomes for each of the 3 decision tables results in 9 separate rules. 

By changing the question and the variable, the same business rule can be expressed for all units in a single decision table. 

When gathering requirements, the question transforms from "when and how" to "what".  Instead of when do you take this action, it becomes what is the percent needed to take this action.  The resulting rules can then set the specific value for each unit.  The total number of rules required drops from 9 to 4. 

These principles in rule design based on the decision table structure reduced the total volume of client-specific rules from over 300 to fewer than 80.  The rules could now be built by 2 people in 1 to 2 weeks, with confidence that testing would be successful.  The removal of redundant rules ensured consistency across departments in the phrasing of notes and the structure of rules, enabling end users and analysts to easily transition between units. 

Time testing — reduced from 2 months to 2 weeks

Creating test cases from the requirements had been time consuming, needing to be recreated for each successive client.  There wasn't a comfort level that all possible scenarios had been covered, so random testing was also included.  The test cases from the requirements were apt to be missing pertinent information, which resulted in retesting or unnecessary research.  Significant chunks of time were spent reviewing results to see if the outcome matched the requirements. 

In our new approach, the decision tables generated the test cases; each scenario with a unique set of variables became an independent test case.  The expected outcome was part of the documentation, and any errors found during internal testing were quickly researched and corrected.  A master list of all the decision tables implemented into rules was created, and the team could track the progress of the testing and report on the specific number of test cases created.  

Prior to decision tables, users might fail a test case only to have the information from the requirements eventually show that, while the outcome might not be desirable, it was what was documented as being the required behavior.  So, miscommunication around the requirements had not been uncommon — user testing review meetings had often included discussions around whether the failed test results were due to a change in the requirements or an error in the implementation of the requirements.  Both sides often felt the other side was at fault.  Once decision tables were used to clarify the requirements and to implement the business rules, these types of discussions almost completely disappeared. 

Key steps in the transformation

The transformation process for our project took almost six months.  When I first brought these ideas back to our department, I worked with a few key people to start changing the approach.  The decision tables were first partnered with the existing process and eventually became the cornerstone of each client's requirements.  As time passed, the relationship with the operational units improved, the amount of rework required dropped, and the time to implement began to shrink. 

Through some trial and error, the team found the correct combination of decision tables, process flows, and business rule documentation that enabled a project to end on time.  The team could now implement up to 5 clients simultaneously and complete the entire implementation in less than 2 months.  The requirements gathering became a 1 to 2 day process rather than a month of unpleasant meetings. 

Decision tables are just one piece of the business rule process and may not be noticed as missing in the early stages of a rule project.  But as the complexity and variation of a rule project increases so does the value and necessity of decision tables. 

# # #