DRA in Project Management

In the good old, bad old days of Knowledge Engineering, the “iterative approach" often meant in practice "keep adding rules until the client runs out of money".  This mindset persisted as our field came to be called Business Rules, when there was a common assumption that one could simply gather whatever rules the "experts" considered pertinent, arrange them into groups, and deploy them as rule services.  Now Decision Management (DM) has turned this deeply misguided idea on its head by stressing that one must first define the business decisions to be automated, before harvesting the specific rules to implement them (see for example James Taylor on "Using Decision Management to improve Requirements”).

Decision Requirements Analysis (DRA) formalises this top-down process, allowing a rigorous specification of the decisioning requirements at the outset of a rules project.  The main benefit is improved project management:  DRA results in better plans, less risk, and tighter control on scope.

DRAW

DRAW (Decision Requirements Analysis Workshop) is a structured workshop technique for defining the decisioning requirements for a rules project, using the DRD described in my last posting.  There are two typical contexts for DRAW:

• It can be carried out as a self-contained activity, to establish the resources required for a potential rules project (e.g. to establish feasibility, to prioritise alternative projects or to produce a road-map for multiple deliveries)
• It can be carried out in the first few days of a rules development project, to define the decisioning requirements (as a Requirements task in waterfall, or an Inception task in RUP).