Don't use a canon to kill mosquitoes

In 1999, I watched a movie featuring the brilliant British actor Sean Connery and the talented Catherine Zeta-Jones titled "Entrapment." A nugget of wisdom from that movie has stayed with me: a quote attributed to Confucius from over 2500 years ago. Initially, its deeper meaning eluded me, but it settled in my subconscious. It wasn't until I ventured into software development and subsequently, business analysis, that I grasped its essence: not every tool is suitable for every job, just as not every medicine can cure every patient, even if the symptoms appear similar.

In my capacity as a trainer for Business Analysis based on the PMI Guide to Business Analysis, I'm often posed with the question—especially when discussing the analysis knowledge area—why is there a need for so many analysis models?

For those unfamiliar, the analysis knowledge area in the PMI standard is expansive. To give you a glimpse, let's delve into the "Create and Analyze Models" process. This process introduces 19 distinct models for a business analyst to choose from, contingent on the business nature, environment, situation, and stakeholders.

As illustrated above, these models fall into six primary categories:

- Process: Models under this category help in depicting business processes. They offer insights into current processes ("As-Is state") or suggest enhancements or entirely new processes ("To-Be state"). They also aid in communicating efficiently with stakeholders. Examples include Process Flow, Use Case, and User Story.

- Scope: Central to business analysis, scope models help delineate what's included and excluded in a solution or set of requirements. They facilitate stakeholders' understanding of requirement significance, prompting them to either add or remove items. Models under this category include the Context Diagram, Ecosystem Map, Goal Model, Business Objectives Model, Feature Model, and Use Case Diagram.

- Rule: Every business operates under a set of rules. When these rules aren't well-defined, conflicts arise. To understand the "As-Is" state or the current state, it's paramount to identify and document these business rules. They often guide decisions and are typically structured as Yes/No questions. Models like the Business Rule Catalog, Decision Tree/Decision Table are used here.

- Function: Requirements stem from the need for specific functionalities. Function models, often in tandem with scope models, help understand functionalities provided by a system or solution. They can highlight functions that may need enhancement. This category comprises the Function Decomposition Model and Function/Feature Tree Model.

- Interface: Beyond just user interfaces, this category covers system or application interfaces and machine interfaces. It's essential to understand how different systems or stakeholders interact and define these interactions. Models like the Report Table, System Interface Table, User Interface flow, Wire frame/Display-Action-Response, and N2 Diagram fall here.

- Data: In today's age of big data and data analytics, understanding organizational data is paramount. This encompasses how data is structured, stored, transferred, presented, its longevity, cleanliness, and reliability. To achieve this, the right data model is essential. This category houses the Entity Relationship Diagram, Data Flow Diagram, Data Dictionary, and State Table/State Diagram.

Other models like the Sequence Diagram, Activity Diagram, and State Machine Diagram might come into play, contingent on your specific domain. The crux is to keep it succinct and pertinent, ensuring effective communication with stakeholders. Hence, the plethora of models ensures you always have the right tool at your disposal.

In conclusion, always remember: Don't use a canon to kill mosquitoes.