Back to List

Diagramming & Modelling Tips for Business Analysts

Kurt Wondra Kurt Wondra  |  
Nov 20, 2018
Among the many responsibilities of Business Analysts, including Backlog Management and Communicating and Collaborating with our teams, the skill of diagramming and modelling is one which seems to be more taboo than mainstream. Have you ever wondered why that is?
One observation I’ve had through the years is that Business Analysts (BAs) are great at the written word. You name it, we can type anything from problem statements to acceptance criteria, functional specifications, project charters, cost justification documents, and more.  However, when it comes to something a bit more ambiguous and subjective like diagramming and modelling, there tends to be more hesitation and worry.

More Art than Science

It’s important to remember that diagramming and modelling is more of an artform than it is a science. There are many more than one single way to successfully diagram or model something. That doesn’t mean that your way is wrong or that my way is wrong; it just means we’re able to have some creative discretion along the way. Nevertheless, all BAs will eventually find themselves needing to put together a visual representation to aid with their teammates’ and stakeholders’ understanding.
Here are some of the most common examples:
  • Data Flow Diagramming – Helps paint a picture of where data originates, where it is transformed, and where it is ultimately consumed (either by business users or by other applications and systems).
  • Process Modelling – Helps illustrate how a set of business users manage a given process. Usually there are multiple decision points and different actions to be taken based upon the decisions made.
  • Prototyping – This is a way to quickly demonstrate what a future-state user interface may look like for your project. Prototyping can help both in planning visual components to be built, as well as used as a guide for developers when it comes to implementation.
  • Scope Modelling – Provides a way to represent the scope of an initiative through visual means. This method can establish a shared understanding of scope that can be viewed on one page rather than having to draft and distribute a multi-page written document explicitly outlining in-scope and out-of-scope components.

Time to Roll Up Those Sleeves

Don’t shy away from diagramming and modelling! While this skill is a hard one to master, it doesn’t mean that we should avoid it altogether. Focus on progress, not perfection. The remainder of this blog is focused on helping you to get start quickly and effectively. Let’s go!

Getting Started

There are several key considerations you’ll want to pay attention to when it comes to picking a tool to help you diagram and model for your teams and your projects. Some of the considerations I often pay attention to most are detailed below:
  • Save & Edit Later Capabilities – I’ll need the ability to save my documents so that future revisions can be made. If I can save them on my computer, in my OneDrive, or another location for quick future reference, that would be handy.
  • Hit the Ground Running – No one likes to work through red tape to get the tools they need. I don't want to have to write a long email to my boss to say, "Can you buy me this tool? It costs this much, and my justification is X, Y and Z." Rather, I’d like to focus on delivering value to my team as soon as possible; that is a high priority. A tool that I can access quickly for cheap or even free is preferred.
  • Sharing Capabilities – I’ll also need to be able to distribute my visuals in an easy way for others to use (like in a *.png, *.pdf, or *.jpg format).

Through this process, I’ve found a few tools that have been very helpful. One of which I’d like to highlight for you is Draw.IO. Also, I’ve recorded a short video to help illustrate how I use the tool. That video can be viewed below:

Next Steps

Have you used Draw.IO before? Was my tutorial video helpful? What other tools have you used to help with your diagramming and modelling efforts? Feel free to post your thoughts, comments, and feedback below to share with your fellow BA peers. 
Enjoy refining and improving your skills in diagramming and modelling!
Business Analysis


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Blog Article
Skipping Inspection and Adaptation (Agile Transformation Pain Point #20)
Rachael WilterdinkRachael Wilterdink  |  
Jan 31, 2019
Inspecting and adapting is one of the key parts of agile and Scrum. But over time, teams start to feel bored as if every session is the same.   If it does become boring, make sure you switch it up to keep it fresh. The Fun Retrospectives website has lots of ideas. Don’t skip this...
Jan 29, 2019
Jen Kalz is Featured on Mastering Business Analysis Podcast

We are excited to announce that Jen Kalz, Managing Consultant, is a featured guest on today's Mastering Business Analysis Podcast. Jen has known Dave Saboe, the man behind the Mastering Business Analysis site and podcast, for the last several years. She and Dave often speak at the same...
Blog Article
Distributed Global Challenges (Agile Transformation Pain Point #19)
Rachael WilterdinkRachael Wilterdink  |  
Jan 24, 2019
So far, I've been primarily discussing co-located teams, which is ideally better. However, this is the real world, and it's a global economy – most people don't have the luxury of being co-located.   If you have a team with dispersed team members, set up your working...
Blog Article
Accruing Technical Debt (Agile Transformation Pain Point #18)
Rachael WilterdinkRachael Wilterdink  |  
Jan 17, 2019
Everyone who works in technology probably knows that you already have a big pile of technical debt. The problem is that you are going to have to eventually pay that bill, and some of it is risky.     Dig out a little every Sprint You really need to be careful about technical...
Blog Article
Focusing On Projects Rather Than Products (Agile Transformation Pain Point #17)
Rachael WilterdinkRachael Wilterdink  |  
Jan 10, 2019
This is a difficult transition for waterfall companies to wrap their heads around. It's a big mindset shift that needs to happen to be truly successful. I'm not saying that you can't have an agile Scrum team that works on projects with a distinct beginning and end. That might be a...