James Taylor's Decision Management

James Taylor

Live form Brainstorm - Business Rules and Requirements Management at the IRS

user-pic
Vote 0 Votes

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

The folks from InScope and SAIC presented next on Business Rules and Requirements Management at the IRS. Now the IRS' rationale for change involved a number of things, all pretty typical except perhaps for the rule engine one.

  • Cost and schedule overruns
  • Inconsistency
  • Decreasing maintenance budget (by 80%)
  • "rule engine frenzy" - used the technology without understanding rules
  • Communication problems, often very late in the schedule

Technorati Tags: , , ,

To make this work they created an office, methods, standards, tools etc. Did they have any experience first? They tried some pilots to show success and tried to learn themselves also not just use consultants. Also set up a requirements management office but merged them into one as there was too much overlap. The separation between them did not help and having one office, taking a holistic approach and maintain common models and traceability. They had to help the IRSunderstand difference between business rules and requirements. This is something about which I have blogged repeatedly. The presenters argued that there is similarity - both trying to extract business knowledge to help build the right system. That said, they are quite different, and the presenters two key differences seem right:

  • Requirements describe the system required where business rules declare the approach the business should take.
  • Business rules live based on cause - regulation, policy etc. Requirements live with the system.

They decided that to make this work at IRS they needed to adapt the existing methodology to handle business rules, something I think is a best practice. Business rules still need a proper project and systems framework. They also focused on organizational, location, process and rule models as a set. On the rules side they built a hierarchical model (not sure that works but it is probably OK for a logical model), dependencies (although this is mostly documentation as rules are declarative so modeling dependencies can be redundant), conceptual terms etc. They then linked to the process model but this seems to make the dependencies redundant. They also needed to put out a Requirement Statement so figured out how to produce one.

Was the management of requirements and rules a cause of confusion?

The presenters had some good advice for introducing new approaches like this:

  • Change management was, of course, a big issue. Need to build relationships, take the time to introduce ideas gradually to key people helped promote the ideas.
  • Staged, planned introduction of idea with multiple ways to communicate and included successful projects as part of the communication.
  • They also had to handle the "been there done that" mentality that this is just another new idea and will go the way of the last one. Need to show you have learned the lessons and take the time it takes.
  • Don't try and make the method/approach perfect before starting to use it

The approach seems to have helped the IRS get a grip on some of the duplicate work, reuse artifacts across projects, improve review quality and done well enough to get new projects to want to take the approach. It is still a very manual process and no automation yet but it seems like they made some good progress.

Leave a comment

A blog about the use of decision management technologies like predictive analytics and business rules to deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics. View more


Sponsored Link

Business Analysis

Subscribe

 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Monthly Archives

ADVERTISEMENT