Last week a customer expressed several questions about their new project for their business rules engine. The more we dug into their problems, the more I realized they were suffering from basic yet enduring challenges every new rule project faces. Essentially, it’s the same set of problems we all face when staring at a blank piece of paper. At some point, you start. Here are some of my tips on how to start a rule project.
Identifying Key Players: The Heart of Your Rule Project
Who are the folks that will write the rules? Explore who are the real experts in your organization. These folks often know data, processes and people. They are trusted ‘A’ players with little time and already have a job. The leverage and influence these candidates have on the success of a rule project cannot be over-stated. Find a way to recruit them into full-time rule authors. They will become the ambassador to the business and help strengthen the trust between stakeholders.
Securing Project Funding: A Pillar for Rule Project Success
Funding the team is equally important to recruiting. It’s not enough to acquire your licensing, you still need people working full-time executing for the business. Part-time staff can help; however, while they still have a regular job, sharing does not work in the long run. In time, this team can grow into a center of excellence and lift all teams working on rule projects.
Stakeholder Engagement: Building Trust and Accountability
Identify your stakeholders and play back your progress to them on a regular basis. Stakeholder playbacks build trust, establish accountability and opens a channel for success and new thinking to occur. This is the group that will decide “what’s next”, “what’s done”, and help with organizational changes to build the team.
Leadership in Rule Projects: Guiding Your Team to Success
Recruit your best leader. It’s possible this person is not technical; however, they take on tasks, understand moving parts and navigate the organization like an expert. Rule projects tend to touch a lot of teams. This leader is open-minded, transparent and results-oriented. Folks need to think differently about their relationship to the project (its inputs and outputs). You need someone that easily helps others understand the change that’s taking place.
Collaborative Rule Writing: A Team Effort from the Start
Write rules together. Teams that start writing rules exclusively with developers often never transition to business users. Ownership begins with the blank slate and everyone needs to experience the early stages of the project to build confidence. It’s tempting to move rapidly with the technical folks that helped with a POC. Resist this and put your effort into team-building and stakeholders.
Focusing on the Right Problems: Aligning with Business Goals
Once you have your stakeholders identified, establish that the team is focused on the right problems. There are times when a Decision Automation solution is purchased to solve architectural and requirements problems; however, folks soon learn it’s a platform for strategically aligning business goals and making them operational across systems. Having said this, the team needs to answer several questions. For example, how does the team know that the output of a decision is desirable? How does it drive or affect the behavior of the organization? Across an aggregate of data, how can you prove it’s better? To accomplish this, you need to clearly state why you are doing this. Make your assumptions known as a group and then work on hypotheses that lead to shared goals and execution. Eventually you will write goals for the team that include what you want, how you will measure and the time frame for execution.
Defining Data Models and Vocabulary: The Language of Rule Projects
Once the team is established, focus on entity structure (the data model), terms and vocabulary with the business. Operational rules require levels of precision that everyone must understand. Once these meanings are shared, the effort begins to scale out. Conversations between teams no longer trip over synonyms, generalizations and abstractions.
Aggressive Rule Authoring: Learning Through Doing
Author rules aggressively as a team. You can’t learn if you’re not engaged with your business problem. Don’t worry about “doing it right,” that will emerge later. Any help given down the road will be much more productive if your team has struggled through the initial rule project.
Avoiding Premature Optimization: Value in a Working System
Don’t optimize early, a working system is more valuable than not. Opportunities to improve logic and lower execution times are best done when the entire decision is available for review. Keep scope breadth to a minimum and establish the system end-to-end. This could mean foregoing some rule content in favor of integration activities.
Speed to Production: The Goal of Every Rule Project
You want the rule application in production quickly—even if the first client application isn’t complete. Try not to correlate the lifecycle of the rule application with the first client application—especially if you know there will be several consumers of the same decision. This moves the team quickly into production governance planning.
The Role of Test Data in Rule Project Completion
Test data is the only way to know you’re done. Understand that there is a tipping point of complexity after which only tests can explain completeness and behavior. At some future point, consider using sanitized production data to hone in on business goals, A/B testing and metrics. This may very well be the same data you use later for machine learning activities.
Documenting Integration Best Practices: A Resource for the Future
If you have complex integration scenarios (such as connectivity with a mainframe) then document it and share the work as a best practice for new hires and other teams.
Please share your thoughts on this below or on LinkedIn. If you are in the early stages of project research, consider working with us, we conduct a workshop specifically designed for stakeholders chartered to solve tough strategic problems.
