Questions (and Answers) about Decision Modeling
By James Taylor, CEO, Decision Management Solutions
I recently gave a webinar on Integrating Decision Modeling into your Requirements Process—you can watch
the recording, download the PDF
or read the transcript
—and we had some great questions that I wanted to answer.
Is decision modeling considered as a technique in requirements process?
Yes – decision modeling is a technique that lets you explicitly document the decision making you need in a solution using a simple yet powerful notation that decomposes the decision-making into more manageable pieces, tracks the information involved and clearly identifies where the decision-making know-how is coming from.
How do we eventually document this information? and What are common helpful tools for decision modeling?
The best way to document decision models is using a decision requirements diagram and supporting documentation that describes each element. It’s an emerging space so the tools available are changing rapidly but you could check out our product DecisionsFirst Modeler
for instance or IBM’s BlueWorks Live.
How well does this apply to an Agile Methodology?
One of the great things about a decision model is that it supports iterative development of the rules and analytics for your decision-making needs. Instead of collecting a big bucket of rules in a waterfall approach you can drill into each area of the model as an iteration, expanding it and documenting its rules.
Is there an explicit link for the information requirements to the project data dictionary or domain data model?
Absolutely. The outcome of each decision and each information source or input data element should be linked to a definition in your data model or data dictionary. Decision models complement data models, they don’t replace them.
Does a decision model cover the traceability of the decision that has been taken for a specific case?
Generally no – decision models are about repeatable decisions and about designing how you want to make them not about tracing how a specific instance of the decision was made.
Once your system is already complicated by standalone rules and over connected decisions, what are the best steps to re-design and fix this?
Generally the best approach is to identify a specific decision and then try and remove the process complexity that relates solely to that decision, moving it into a decision model as you go. Once you have the outline of a decision model you can start mapping your existing rules to one of the decisions in the model. You shouldn’t try and fix it all at once but one decision at a time.
Should we be expecting this decision modeling to be part of the BABOK® Guide version 3?
A decision modeling technique has been proposed for A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) version 3 along with some updates to the business rules and analytic sections to reflect the power of decision models to improve these approaches. We won’t see the final shape of the BABOK® Guide version 3 until the public review is finished, however.
I work in a (very) small organization with a considerable amount of inertia in terms of our processes and practices. How do you typically "sell" the need for decisioning systems to small businesses?
This is a tough one. Unless you make a decision often enough there’s not much of a payoff for modeling it. Identifying the decisions that are most numerous and figuring which performance metrics they impact is the best lever in small companies or large ones. If you can tie better decisions to improved business results, especially if the decision is one made by junior staff, you can normally get some energy behind better understanding of that decision.