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.

Scope of supply

DRAW is essentially a scoping exercise, and should therefore be carried out as the very first task in a rules implementation project.  The results can then be recorded in a document which will define the scope of supply, to be signed off by the client before any further work is carried out.  Since it covers only the decisioning requirements (which may not be all the functional requirements) FICO calls this the Decision Definition Document (DDD).  It contains the following sections:

• Business Context: the background to the project including the goals of Decision Management
• Decision Points: a description of the client’s business process, specifying the points at which decisions are required of rule services and the principal decisions to be made at those points
• Decision Requirements: the Decision Requirements Diagram (DRD), supported by verbal definitions of all of its nodes (including estimates of size and complexity of knowledge and data nodes)
• Scope: a statement of the scope of supply, defined as sets of nodes on the DRD, and illustrated with a diagram, as below.

Scope Boundary on the DRD

The DDD is a simple, brief document, but provides a very clear definition of the decisioning requirements, allowing the scope to be tightly controlled.  This is not to prevent changes during the project but to allow them to be properly managed. Every harvested rule should directly determine one of the decisions in scope, belong to one of the knowledge areas in scope, and use only data provided by the data areas in scope.  If rules are discovered which do not fit into these constraints, the agreed change control procedure should be followed to consider the cost of extending the scope to include the new decisions, knowledge areas or data.  Provided a thorough requirements analysis has been conducted such changes should seldom be required.

Planning

Rules discovery is in itself one of the major sources of risk in a traditional rules project, because it is open-ended and often far too large to be managed as a single task.  This risk cascades to many other tasks which are dependent on it.  Introducing DRA before rules discovery allows the production of complete and detailed plans at the outset of a project, with specific discovery, development and testing tasks for each knowledge node on the DRD.  The effort required for these tasks may be estimated using the information in the DDD.

DRA can also provide a higher-level structure to the plan.  If a phased or iterative approach is being used, increments of functionality may be defined as sets of nodes on the DRD.  The objectives of this partitioning are that:

• Each increment can be delivered in one phase or iteration
• Each increment provides some distinct functional benefit to the client
• The increments are loosely coupled: i.e. there are few arrows between nodes in different increments
• Each decision node is in the same increment as the knowledge node(s) it requires.

This example DRD shows the decisioning functionality partitioned into three increments:

Increments on the DRD

A typical project plan under RUP would then have the following high-level structure:

• Inception:  establish the scope of decisoning using DRAW;  establish high-level technical and non-functional requirements;  agree project goals, plan and governance
• Elaboration:  establish the detailed technical requirements and retire the most significant risks by building a simple "empty" prototype decision service integrating with the client architecture
• Construction:  over a number of iterations, gradually add increments of functionality to the prototype until the decision service is complete, performing rules discovery as required for each increment
• Transition:  perform user testing, training and handover.

DRA therefore allows us to achieve a new "iterative approach", more in step with mainstream IT project management principles, which is committed to the delivery of an agreed set of decisions within an agreed budget and timescale.