A Note to Business Analysts about ‘Decision’
Perhaps the following point about the term decision is already clear to all, but at the risk of stating the obvious, I’ll make it anyway. There’s a major collision of terminology with respect to decision as used by different communities.
In the context of their own communities both usages are correct. Unfortunately, the collision often results in confusion about the appropriate focus – and about which methods to use – for both audiences.
In situations such as this, the best practice is to define the concept in question for each community. Terms considered to be obvious usually aren’t. It’s not clear to me that this has been done explicitly in the business analyst community.
Another best practice is to qualify the term every time it’s used. So we always say operational business decision when talking about the business context, not just decision. That also distinguishes the concept we mean from other potential sources of confusion – e.g., strategic business decisions and system-level decisions or IT decisions.
I believe what the business analyst community means by decision is strategic project decision or strategic change decision. But I can’t really be sure since as I say the term doesn’t seem to have been defined.
- In the business analyst community, decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
- In the larger business community, decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.
Tags: business anaysis, decision, decision analysis, decision engineering
Ronald G. Ross
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.