Project Management

Business Analysis: Models for Everyone

From the Building the Foundation: The BOK on BA Blog
by , , ,
A new collaborative blog featuring the contributions from the core team members of PMI's Foundational Standard in Business Analysis. This blog will provide the community with insight into PMI's development of the standard to generate professional discussions about the content in advance of the scheduled reviews.

About this Blog

RSS

View Posts By:

Laura Paton
Joy Beatty
Cheryl Lee
Sue Burk

Recent Posts

PMI's Newest BA Standard and the PMI-PBA Credential

An Update On PMI's Consensus Based BA Standard: The Final Phase

The Link Between Business Analysis and Project Management Processes

Party Like a Business Analysis Rock Star!

PMI’s Business Analysis Standard – What You Have to Gain

Categories

BOK, Business Analysis, business analysis, business analysis BOK, business analysis BOK PMI-PBA, business analysis guide, business analysis standard, PBA, PMI-PBA

Date

linkedin twitter facebook Request to reuse this  

Categories: Business Analysis


I’ve been anxiously awaiting the time to write this post because it is about something near and dear to my heart – analysis models! Models are by no means new to the business analysis profession, but I’m thrilled to say that the use of them has become much more prevalent – almost mainstream – over the last five to ten years. Given that, you would naturally expect the PMI foundational standard in business analysis to have a home for them, much like they are in section 4 on Requirements Elicitation and Analysis of Business Analysis for Practitioners: A Practice Guide.

As described in the practice guide, models are visual representations that efficiently arrange and convey information in a concise manner. Models can be in the form of diagrams, tables, or structured text. Models are used in planning, analysis, design, construction, training, coaching, and many more roles. There are many types of analysis models and the following table shows the ones we found to be most prevalent, and are therefore covered in the practice guide. The models are grouped by categories in this table to help you think about the kinds of models that exist more precisely than just listing them. Most projects, programs and portfolios will need to use at least one model from each of these categories. In fact, the table of models is sort of a model in itself because it organizes information for better understanding!

Category

Definition

Example Models

Scope models

Models that structure and organize the features, functions, and boundaries of the business domain being analyzed

  • Goal and business objectives model
  • Ecosystem map
  • Context diagram
  • Feature model
  • Organizational chart (described in Business Analysis Planning)
  • Use case diagram
  • Decomposition model (described in Business Analysis Planning)
  • Fishbone diagram (described in Needs Assessment)
  • Interrelationship diagram (described in Needs Assessment)
  • SWOT diagram (described in Needs Assessment)

Process models

Models that describe business processes and ways in which stakeholders interact with those processes

  • Process flow
  • Use case
  • User story

Rule models

Models of concepts and behaviors that define or constrain aspects of a business in order to enforce established business policies

  • Business rules catalog
  • Decision tree
  • Decision table

Data models

Models that document the data used in a process or system and its life cycle

  • Entity relationship diagram
  • Data flow diagram
  • Data dictionary
  • State table
  • State diagram

Interface models

Models that assist in understanding specific systems and their relationships within a solution

  • Report table
  • System interface table
  • User interface flow
  • Wireframes
  • Display-action-response

Table source: PMI, Business Analysis for Practitioners: A Practice Guide

The when, why, and who of it

As analysts, models help us create order out of information so that we can find inconsistencies, gaps, and extraneous information. Analysis models also help us to represent information so that others can consume it. Our business stakeholders, construction teams, testing teams, executive teams, and managers all use models to understand what the product needs to do and why.

But wait, what about agile?

Sue’s recent post highlighted how business analysis is applicable in both predictive (such as waterfall) and adaptive (such as agile) life cycles. As she points out, models are useful in both life cycles! The choice of models, formality of their representations, or timing of their use might vary from adaptive life cycles to predictive life cycles. But frankly, those same things vary from any waterfall project to any other waterfall project also. There is no “one size fits all” approach to modeling. In agile approaches some scope and goal setting models are more likely to be created early in the project to get a lay of the land. However, more detailed models to identify acceptance criteria are used just in time to plan iterations as part of elaborating backlog items.

All industries

If you work outside the software or IT arenas, you might be wondering whether analysis models are even applicable. The short answer is absolutely! However, some models are better than others. For example, some form of process flows or use cases can be used to describe how users will use or interact with anything – be it a shopping center layout, an insurance claims process, a city intersection, a turn signal on a car, or a rocket ship. On the other hand, some models such as display-action-response models are only useful if there is some kind of a user interface to be specified.

I once met some engineers from a company that builds heavy machinery. They didn’t work on software, but rather they were in the product design department for the physical machines. Once introduced to analysis models, they quickly adopted business objectives models, process flows, and feature diagrams to improve their requirements and design work.

What to expect

PMI’s foundational standard in business analysis will explain analysis models in general, describe why we create them and how we analyze them, and offer a visual template for many types of models. Business Analysis for Practitioners: A Practice Guide offers more depth on when you use each of the models, how you use each of them in relation to requirements, and an example of each model. The two publications in combination will provide a wealth of knowledge for those just getting started in the modeling space or a quick lookup reference for the more experienced professional.

Like I said earlier in the post, there are so many different types of analysis models. I’d love to hear what the community thinks about models. What are your favorite models? Are we missing any key ones that you’d like us to consider for inclusion in the standard? Do you really like or not like any of the ones I listed here?


Posted by Joy Beatty on: June 30, 2016 11:55 AM | Permalink

Comments (8)

Please login or join to subscribe to this item
avatar
Pravin Kumar Shrivastava Associate Vice President| Aithent Technologies Pvt Ltd Gurgaon, Haryana, India
Thanks for sharing the article. This is good and consolidated information.

avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
Great post. Let me say what I think trying to add something. And please, do not be angry with me. First, what I understood, is that the PMI is trying to create some BOK regarding to business analysis (perhaps that is not right). A BOK is about "good practices". "Good practices" means there is a general agreement that the aplication of that can enhance the chances of success. So, those is the list of things that the BOK has to contain. I mean, is not about like or dislike. It is about to put there a subset of knowledge, tools and techniques which have a general agreement about their application. About your list, if you ask me, I have used alll of those in multiple situations. And all of these works. But I fully disagree in putting them inside a category because those are tools and you can use the tools that best fits for a situation. For example, you can use Use Case as interface model.

avatar
Khalid A. Elzairy GM| ECO Consultant Office Elwasta, Bani Sweef, Egypt
Thanks for sharing the article.

avatar
Joy Beatty Vice President of Operations| ArgonDigital (formerly Seilevel) Austin, Tx, United States
Sergio, thanks for your comment - sorry I'm slow to get back to it! So I completely agree that models have many uses. And you could use use cases to describe interfaces for sure. The categorization shows where it is most commonly applied, but by no means a rule you can't use it elsewhere.

Now the reason behind categorization is that there are far too many models to be able to remember them all and figure out when to use them all. If I say "Hey, here are 30 models....go use them as needed" it's not as helpful if I say "Here are 30 models, organized into 5 categories and you should consider using at least one model from each category." This is based on the concept of Miller's Magic Number that suggests we need to organize any information in groups of 5-9 things at most...so we have a chance of processing the information in a useful way. The information here is the list of models.

avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
Thank you very much for your answer Joy. Now I understand your point. Thanks for your time.

avatar
Stéphane Parent Self Employed / Semi-retired| Leader Maker Prince Edward Island, Canada
Thank you for this structured approach to modeling.

avatar
Rolf Dieter Zschau Business Analysis & Solution Lead| Volkswagen Group Charging GmbH Unterschleissheim, Germany
Thank you for that perfect summary of modelling, Joy.
At a first glance, I missed object and class models in the data model category - as counterparts of ER models in the UML or OOA/OOD oriented part of the world. I've used either ER or object models depending on the environment and on team comfort. I've used them often as "notion models", too, when structuring a domain new to me or new to the team.

avatar
Diego Tussi Project Manager| . Sao Paulo, Sp, Brazil
Thank you. Excellent article.

Please Login/Register to leave a comment.

ADVERTISEMENTS

One word sums up probably the responsibility of any vice president, and that one word is 'to be prepared'.

- Dan Quayle

ADVERTISEMENT

Sponsors