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
Pre-assigning Work to Team Members (Agile Transformation Pain Point #14)
Rachael WilterdinkRachael Wilterdink  |  
Dec 13, 2018
This pain point is something you definitely don’t want to do. Agile and Scrum teams are meant to be self-organizing. They should volunteer to pick up assignments, not be assigned. Development team members are volunteering to do stories, and they might want to learn something new &ndash...
Blog Article
Taking on Too Much Work in a Sprint (Agile Transformation Pain Point #13)
Rachael WilterdinkRachael Wilterdink  |  
Dec 06, 2018
Some teams are super ambitious, and they just think they can climb a whole mountain in a single Sprint, but the whole goal with agile is to maintain a sustainable pace. Take on only what you really think you can get done within your Sprint. Don't overestimate your velocity, and don't...
Blog Article
Not Having a Definition of "Done" or "Ready" (Agile Transformation Pain Point #12)
Rachael WilterdinkRachael Wilterdink  |  
Nov 29, 2018
Most people who are familiar with agile are familiar with the concept of definition of Done. This is something that the team should create when they are first formed, and they should continually be inspecting and adapting that at each of their retrospectives. They can update that definition of...
Blog Article
Forgetting to Have the "Conversation" (Agile Transformation Pain Point #11)
Rachael WilterdinkRachael Wilterdink  |  
Nov 15, 2018
You may have heard the three C's of agile: the card, the conversation, and the confirmation. Many people will have the card: they'll write the story, but they'll forget about the other parts. They'll just write it in a silo and not get any feedback. They won’t actually...
Blog Article
Struggles with Story Writing (Agile Transformation Pain Point #10)
Rachael WilterdinkRachael Wilterdink  |  
Nov 08, 2018
Story Writing struggles are so common and impactful that we offer a half-day training workshop on it for organizations.   Avoid technical stories Many Product Owners don't have a lot of experience writing requirements, and if you're a BA like I am coming from a waterfall world...