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).

This posting can only offer a brief description, of course, but I will be happy to answer questions, and FICO offers training courses in DRAW and the surrounding methodology as part of our Operational Excellence programme [sorry - end of advert ;-)].

Resources

No special facilities are required by way of accommodation or software. The workshops can be held in any quiet meeting-room with a flip-chart and whiteboard.  Interaction is improved if the participants sit around a table, rather than all sitting facing the leader as in a presentation.  The DRD can be sketched on the board during the workshops, and drawn out formally later using any commonly available diagram editor (I use Microsoft Visio).

The success of DRAW is entirely dependent on the calibre and commitment of the people involved, so it is important that the right team is assembled for the workshops.  I will assume that the project involves staff from two parties:  a supplier and a client.  These might be separate groups within the same organisation.

Supplier:  Although DRAW can be carried out by a single consultant, it is better to have a second person as scribe, and I would recommend that the following staff are available at least part-time:

• Project Manager:  responsible for project planning, management of supplier staff and status reporting
• Rules Analyst:  responsible for defining the functional requirements and possibly for the rule service design
• Technical Architect:  responsible for defining technical requirements and technical architecture.

The Rules Analyst will lead the workshops, conduct the analysis and produce the outputs. The Technical Architect should ideally be present throughout, but must attend any meetings concerning data sources and interfaces. The Project Manager should be present for the initial meeting and for any decisions on scope.

Client:  The client should commit to making the following staff available at least part-time:

• Project Sponsors:  ultimately responsible for the business success of the project
• Project Manager:  responsible for day to day project management, liaison and reporting
• Operational Experts:  contributing subject-matter expertise; instrumental in driving and fostering user acceptance and involvement
• Business Analysts:  responsible for business design and definition of functional requirements
• IT Analysts:  providing IT support, e.g. interface development, hardware configuration, environment preparation.

Most of the input will come from the Project Sponsors, the Operational Experts and the Business Analysts. IT Analysts should be available support the workshops and analysis as required, e.g. with data mapping and legacy systems expertise.  The Project Sponsors and Project Manager must be present when the scope is agreed.

Scheduling

DRAW works best in small groups (6-10 people), rather than large workshops.  You should start with one or more plenary workshops to draw out the top-level requirements, then pursue more detailed analyses with sub-groups or individual specialists as necessary.  It is not necessary to explore the whole network with each person:  individual areas of expertise or responsibility may correspond to different regions of the network.  It is however a good idea to cross-check results with multiple staff:  individuals will miss items and there may be differences of opinion which reveal important issues which need to be clarified.  After the results have been analysed and documented, the draft DRD should be presented at a final plenary session for general agreement.

Although it is possible to carry out a very high-level DRAW in a single day, it is more typical for it to require a number of workshops over several days.  A good approach is to set aside a week, but schedule only about half of the time;  I usually schedule workshops for the mornings, leaving the afternoons free for overruns or follow-up work.  Be flexible.  It is unlikely you will be able to conduct all the interviews according to a pre-arranged schedule; as the network is revealed you may find it useful to contact and interview additional people.

In principle, DRAW consists of a standard sequence of stages:

1. Identify the decision points
2. Define the top-level decisions
3. Decompose the decisioning
4. Describe all the nodes in detail
5. Define the decision service boundaries.

These are described below.  Of course, no real workshop will run quite this smoothly:  things will emerge which require you to backtrack and modify or add detail to the results of previous stages. This is not a problem, so long as the basic principles are followed (for example, any decision, whenever it is added to the DRD, has to be defined and decomposed).

Stage 1:  Identify the decision points

Start by inviting the client to describe their business process, and what they hope to achieve from this project. Try to understand the drivers:  What transformations does the client intend to bring about in their business?  What benefit do they hope to achieve through Decision Management?

Investigate in detail all the points in the business process where decisions will be required of decision services:  these are the decision points.  Give each decision point a name, and define:

• The stage in the business process where this decision point occurs
• The decision-making carried out at this stage
• The intended role of the decision service in the decision-making
• The role of any users or other system components.

Document the results using some sort of business process flow or workflow diagram, as in the example below.  Here there are two decision points:  Decide Pre-Bureau Eligibility and Decide Post-Bureau Status.

Decision points in the workflow

Stage 2:  Define the top-level decisions

For each decision point, establish the decisions which the client requires to be made by decision services, expressed in the most general possible terms.  Wherever similar decisions are made at multiple decision points, try to generalise the decisions across those contexts.  Even if there are expected to be multiple decision services do not at this stage attempt to allocate decisions to particular services, just identify which decisions have to be made.

Give each decision a name, then establish the following:

• A question which characterizes the decision, expressed clearly in natural language, with a defined set of answers
• Any other results which are required to be returned with the answer
• The decision points at which the decision has to be made, and any variation in the required decision across these.

In our example above, the first decision point makes the decision Is the application eligible?, and the second makes the decision How should we deal with this application?.  The answers to both questions are ACCEPT, REFER or DECLINE, which are used to route the application appropriately in the workflow.

Stage 3:  Decompose the decisioning

Now we can build our DRD.  Start by drawing the top-level decisions exposed in stage 2 on the board as separate, unconnected boxes.  In our example these are Is the application eligible?, and How should we deal with this application?.  Then follow an iterative process.  Choose any decision which has not yet been addressed, and ask the client:  “What information is required to take this decision?”.  Fully explore the following possibilities:

• Business knowledge (guidelines, policies etc currently existing in human heads, documents or legacy systems)
• Data (specific data describing the case or external reference data)
• The results of other decisions (sub-decisions).

Add nodes to the DRD as required:  knowledge, data or decision.  Each new decision node should be defined like the top-level decisions and labelled with its question.  It can then be addressed in its turn.  Note that because this process is recursive, and only analyses one decision at a time, it is not more difficult to decompose a large decisioning requirement:  it just takes longer.

For example, when you ask the client “What information do you need to decide how to deal with the application?”, they might reply “Well, you need to know whether the application is eligible, whether the risk is acceptable, and whether the repayment is affordable.  We have policy rules saying what to do in each case.” This tells you to link Is the application eligible? to How should we deal with this application?, add two further sub-decision nodes (Is the risk acceptable? and Is the repayment affordable?), and provide a Policy rules knowledge node.

Building the DRD

When the process is complete you will have a complete DRD, identifying the decisions required, the areas of knowledge involved in the decisions, and the areas of data required by the decisions.

Stage 4:  Describe all the nodes in detail

Revisit all the nodes in the DRD and discuss them in detail with the client, one by one.  For each decision node, agree on a more detailed description which explains how its required knowledge and data are used in reaching the decision.  For each knowledge and data node, investigate the information required, and record:

• The source of the information (systems, documents, or personnel)
• An estimate of its size and complexity (e.g. number of rules or data items)
• The maintenance requirements (who will be maintaining it, and how often)
• Any other important background (e.g. the accuracy and completeness of the information source, any possible modifications within the timescale of the project).

Note that at this stage the objective is not to collect actual knowledge (e.g. particular business rules or pages of equations), but just to describe the required areas of knowledge and identify the sources for subsequent discovery.  However, it is likely that the client will offer example rules, and if so these should be recorded.  Similarly, the objective for the data nodes is to identify areas of data, not a full object model.
 
Stage 5:  Define the rule service boundaries
 
Having defined the decision structure and supporting information, decide which areas are to be implemented as part of a decision service and which are to remain as external systems.  Do not at this stage try to decide how many decision services there should be and how decisions should be allocated between them, simply identify which nodes are to be implemented and which are not.  This will provide you with the “scope boundary” as shown in the previous posting.
 
Some useful rules of thumb are:

• The top level decision nodes will be implemented in decision services (this was our starting assumption).
• Most of the sub-decisions will be implemented in decision services, but services may call out to external decision-making processes e.g. web services or human authorities.
• Most knowledge nodes will be implemented in the decision services (as rulesets or functions), but some very simple rules can be implemented as queries on a database.
• Most data nodes will be information sources outside the decision services, but some may be implemented for convenience within the services if no other system requires access to them.

Boundary analysis involves provisional architectural design decisions, so the boundaries may be subject to change later in the design process. By recording the results of this analysis clearly in the project scope, any such requirements can be made the subject of a change request and properly costed.