A BRMS (Business Rules Management System) project is as complex as any other project and can fail if not planned and implemented the right way. Please see Blaze Advisor Fundamentals for some basics about Blaze. If you want to know why you should use a BRMS then please see my article Why should you use a Business Rules Engine or BRMS?.
One of the key advantages of a BRMS solution is that it allows business users to maintain rules. Often the business users don't realize that there will be some amount of effort and commitment required to keep the system running. Very often the business users do not have capacity to the do the rule changes and do adequate unit testing.
The business users do not anticipate or plan for the time they need to spend on maintaining the rules. The business users must be educated to understand there will an effort required from them to maintain the BRMS. A simple example is that the business users need to know the data structures so that they can understand or write rules.
We often implement brand new systems but then forget to take into account the existing system processes. Most of the mature systems have rigid process in places to make sure that all the happen changes within the quality assurance and delivery frameworks. Many times the business users expect the changes to be deployed faster with BRMS.
If the existing process require that you have proper documentation and quality assurance then a simple rule change will also take the same time as any other normal system changes. When designing the deployment life cycle for BRMS systems we need to consider or amend the existing processes to make sure rules changes can be done faster. In most cases the toll will have the features to do the task but the process do not support faster changes.
Most of the BRMS tools are sophisticated and offer more than they are expected. But sometimes a BRMS tool may have a limitation as most of the tools are propriety and there would be a limit to how much you can customize. If you take the customization too far then maintenance and upgrading the system will be become a nightmare.
A simple example of this is that some tools do not handle XML name spaces well. Sometimes tools do not integrate well with third party tools like SVN . Many organisations have standards on what technology and tools can be used. Business users sometimes expect the rule templates to be handle complex conditions but then want them to be simple to use. You cannot have best of both the worlds. If you make templates complex then the business users will have to spend some time to write rules.
The biggest of the all the culprits. When selling the solution the sales team generally make promises like "faster time to market" or "change at one button click". The sales team often overlook the system limitations. They often overlook existing process and if the tool will be effective in the current environment. Most of the time overselling and setting wrong expectations leads to issues like decreased business interest and distrust in the system.
Maintenance and Upgrades
Many a times good BRMS solutions are developed but then there are no proper maintenance plan designed. You need to plan regular upgrades so that the business benefits from the advantages of the latest version of the tool. Also, it is important to make sure the business gets the tools they need.Many times the BRMS systems are treated as low priority and not maintained. If the systems are not update and maintained business will will not trust the tool.