Review the decision points (Decision Point Table) with the stakeholders and set the priority on each decision point. Depending of the complexity of the business process the team should prioritize which rule harvesting to tackle first. A good practice is to start with a simple, well understood decision point, to help training the team on the practice, but keep also in mind that the management wants to see the business value of what the team is working on. So a decision point that is important by bringing a value, should be in the top of the list.

If needed review the business context to keep the business needs and reassess the priority accordingly. It is important to start by extracting rules that is bringing immediate value to the business users, to get their buy in, and motivation to continue to do this painful work. Do not hesitate to start also with the most complex business scenario. It helps convincing business users and rapidly enriches the business object model. It is important to set the expectation among the stakeholders that not all the rules will be discovered during this phase. The goal is to complete a rule set up to 40-60% to have some tangible decision on standard business event to process. The Rule Writers or the development team will enhance the Rule Set later on.

One good practice is to implement the decision logic using rules for the main stream of business processing, letting the exceptions to the human. It will be always possible to add rules to manage some standard exception later on.  A typical case is in the underwriting type of rules. An expert will quickly extract some basic rules that always need to be true to accept the Application. As soon as the discussions start to be around the "but there is a case where ..." it will be important to add this in the exception management.