EVERY NEW RULE PROJECT FACES BASIC YET ENDURING CHALLENGES. 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 TIPS ON HOW TO START A RULE PROJECT:
1. Who Will Write the Rules? Who are the folks that will write the rules? Explore who are the real experts in your organisation. These people 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 overstated. 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.
2. Funding and Recruiting the Team 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.
3. Identify your Stakeholders 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 organisational changes to build the team.
4. Recruit your Best Leader It’s possible this person is not technical; however, they take on tasks, understand moving parts and navigate the organisation like an expert. Rule projects tend to touch a lot of teams. This leader is open-minded, transparent and results-oriented. They 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.
5. 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 individuals that helped with a POC. Resist this and put your effort into team-building and stakeholders.
6. Focus on the Right Problems Once you have your stakeholders identified, establish that the team is focused on the right problems. There are times when a Decision Management solution is purchased to solve architectural and requirements problems; however, people 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 organisation? 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.
7. Focus on Structure 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.
8. Work as a Team 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.
9. Establish the System End-to-End 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 favour of integration activities.
10. Keep on Moving You want the rule application in production quickly—even if the first client application isn’t complete. Try not to correlate the life-cycle 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.
11. Testing 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.
12. Documentation 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.
If you need any further information or are in the early stages of project research, please contact us. We would be happy to help!
Best of luck with your authoring projects! *Original article: https://www.inrule.com/resources/blog/good-beginnings/