In this scenario, business modeling (process models and data models) had already been done for the modeling team. The team’s job was to insert decisions into this preexisting framework.But this approach had a serious flaw. Decision discovery came spilling “out of the box.” A DecisionsFirst modeling approach was used, and this revealed problems with how the processes and data were modeled and organized. Clearly, there is a tremendous upside in considering some minor (and some major) changes to the other models, but the business and technology teams were adamant about preserving the sanctity of the “box” or framework. But the project was implemented with only a fraction of the possible value because of this artificial “scope” imposed on a supposed business transformation project.

Lesson learned: Although existing processes and data models are rich sources for decision discovery and subsequent modeling, they should not limit initial decision modeling. A DecisionsFirst modeling approach reveals problems with how processes and data are organized. Processes and data models need to be reconciled after several iterations of decision modeling. Decisions, processes, data, events, and other key factors are all different views of the same real-world business—and all these things need to be taken into consideration in a holistic way to maximize business value.

Case 2: “Your models have no place in my methodology. You have wasted everyone’s time.”

In this case, the technology implementation team had a well-established—and sacrosanct—methodology that started with requirements written out as User Stories. If anyone questioned the methodology, curses would rain upon them through eternity! So, the team ignored decision requirement models done by the modeling team and effectively restarted the project with User Stories documentation workshops.

Not only was this an enormous waste of time and effort, upsetting business owners who had sat through long-winded and unnecessary workshops, the User Story approach proved ineffective for decision automation requirements. Decision modeling with the Decision Model and Notation (DMN) standard is specifically intended to fix this issue.

A lot of time, effort, and goodwill was dissipated in philosophical and methodological debates, which quickly took an unpleasant, political turn. Team members locked horns about whether requirements should be described in terms of decision models (and process and entity models), or written out as User Stories. The project was somehow implemented but left the team unhappy, hurt, and completely soured on the process.

Lesson learned: Methodologies need to be updated to recognize that User Stories are for application use cases and decision models are the most precise and complete description of decision requirements. They work together and are not substitutes for one another. Decision modeling—and the Decision Model and Notation (DMN) standard—can fix this gap.

Case 3: “Sorry, my model is not done yet (not ‘complete’ yet).”

This particular team deserves kudos for being great modelers and true believers in the power of good modeling upfront. But wait. Not everything was smooth sailing. They got stuck in their attempts to model every possible situation. They had a bad case of modeling mania.

Not only did the model become unwieldy, complex, and formidable, but project budget and timelines were significantly impacted. Even worse, the subject matter experts who were required to support modeling found themselves exhausted by the effort, suffering from modeling fatigue. Initial enthusiasm and faith eroded into active avoidance of modeling sessions. Senior experts gradually fell out of the meetings, and modeling become a classic death march, with no end in sight. It really looked like the zombie apocalypse was at hand.

It took some brave and brutal intervention from senior leadership to literally snatch the model from the modeling team’s grip and hand it over to the implementation team.

Lesson learned: Modeling is, by definition, a representation of reality. Reality is complex and will always have a subset of exceptions and edge cases that do not fit neatly into a relatively simple modeling pattern that normally covers 95% to 99% of cases. Implementation teams should keep a check on themselves and, ideally, have a general idea of when modeling is “done enough” to start implementation. Modeling is always iterative and will never be truly “done,” but projects need to be “done.”

Learn more about what is required to develop and complete an effective Decision Requirements Model using DMN notation. Read the white paper “Decision Modeling with DMN” today.