Continuing to expand on the questions I asked Andrea Scarso co-founder and COO of MoneyFarm when I interviewed him I wanted to focus on the question “How, specifically, do you develop requirements for analytic projects?”
“In my opinion, it is paramount to start from the single and specific decision needed. Then, with a top-down process, to analyze its component elements: hard data, background knowledge and constraints, expected outcomes from models.”
This mix – the information required in a decision, the analytic insight required and the other kinds of knowledge that drive decision making – is central to the way we see Decision Modeling being used for Predictive Analytics Projects. Even just capturing a high level model that documents the various information and knowledge sources available can make a big difference. Drilling down into the details, decomposing the decision into its component parts and then identifying which pieces of information or knowledge are used in each component refines this and increases clarity for analytic projects.
It is really important to realize that the role of decision requirements in the analytical life cycle is to provide business understanding. The best time to create decision models is early – before you have built an analytic model or even started working on the specifics of your analytic. While you can build a model to help you deploy and build support for an analytic model, and we have done this with some clients, the value of a decision model at the beginning is much greater. It is tremendously helpful to understand how constrained a decision is, where an analytic might be usable, how an analytic would have to be deployed to be useful before you start building a model as it helps avoids dead-ends and focuses scarce analytic resources on solvable problems. Incidentally that’s another value for decision models – by bringing in others outside of data science/analytic teams it can help with the ongoing shortage in advanced analytic skills. Now an initial decision model can be built by business analysts or at least the work can be shared between business analysts, data scientists and others. This helps clarify what will be possible, valuable, with a smaller investment of these scare skills.
While decision modeling is important early, Andrea made a good point:
“This process is not always strictly top-down. Sometimes investigating a requirement leads you to re-evaluate the structure of a preceding decision, in a bottom-up and iterative way.”
This is absolutely the case. In a typical project one might create an initial decision model, begin work on an analytic to influence it and then discover new insights into the decision. These then need to be fed into the model so it can be revised and the new model used as the ongoing context for the analytic. This is why we feel it is important to have a multi-user, collaborative environment for managing decision models. DecisionsFirst Modeler, our cloud-based, collaborative decision modeling platform, let’s you build multiple models that share components (allowing multiple views to be built that reuse decision, information or knowledge elements), shows who is working on an object or diagram and let’s everyone leave comments as they go. This makes decision modeling an iterative, ongoing activity. This contrasts strongly with the kind of one-time, throw-away requirements document most projects build that is not maintained and rapidly becomes out of date.
Don’t forget the upcoming IIA Webinar: Improve Analytic Results with Decision Modeling
Andrea went on to make one final comment about his approach:
“Moreover, my personal approach, whenever it is possible, also encompasses the consideration of another level: the process level, in which the decisions are set.”
He’s absolutely right. For most projects the decisions you model are going to be used in business processes – the business process provides the context. Decision Management Solutions is one of the submitters on the forthcoming decision modeling standard (Decision Model and Notation) and this standard has emphasized that decisions relate to business processes (often modeled using the equivalent business process standard, the Business Process Model and Notation). Whether mapped at the overall process level or specifically within a process task, decisions often get made inside business processes and this is worth knowing and modeling. While the approach described in Decision Modeling for Predictive Analytics Projects focuses on the decision modeling piece, DecisionsFirst Modeler allows you to import lists of processes and map your decisions into those processes so you can manage this context.
With that I’ll give Andrea the last word this time too:
“I think that modeling the decisions as part of the requirements should be an obvious and essential step in any analytic project.”
If you want to use Decision Modeling to improve your analytic projects, check out our Decision Modeling services and sign up for a 60 day free trial of DecisionsFirst Modeler, our cloud-based, collaborative decision modeling platform. If you need more general help adopting predictive analytics, check out our services to help you get started with predictive analytics.
Comments on this entry are closed.