Skip to main content

Tag: BPM

Can You Picture It? Yes with a Swimlane Diagram!

There is the adage “a picture is worth a thousand words” and there is some truth to this.  A picture is not just for capturing great moments like the company holiday party or a selfie with a friend.  It also provides an effective way of showing a process to people.

We see process pictures in our daily lives.  For instance, if anyone has ever brought home a piece of furniture from Ikea, you will recall they provide assembly instructions in the form of a picture, so you know how to put it together.  With the recent pandemic, you have likely noticed the signage that businesses put up on their doors, walls and floors to provide instructions to clients on how to social distance, wash your hands, wear a mask and how to queue for service.

PMTimes_May13_2022     PMTimes_May13_2022

As Business Analysts, we have strong and well-developed communication skills – both oral and written.  Our BA toolkits are filled with the many tools and techniques that we love and frequently use.  When it comes to reviewing a business process with a diverse audience, having it in the form of a picture is one of the best ways to visually explain it.  One of the techniques that does a fabulous job of this is the swimlane diagram.

I have been involved in many business transformation projects and the swimlane diagram is one of my most used techniques for capturing and analyzing business processes.  They provide an illustrated process summary and are easily understood by both business users and technical teams.

“A swimlane diagram is a type of flowchart that delineates who does what in a process.  Much like the lanes of a swimming pool, a swimlane diagram provides clarity and accountability by placing process steps within the horizontal or vertical “swimlanes” of a particular employee, work group or department.  It shows connections, communication and handoffs between these lanes and it can serve to highlight waste, redundancy and inefficiency in a process.”

“Swimlanes were first introduced back in the 1940s in what was called a multi-column workflow chart.  Later in 1990, Geary Rummler and Alan Brache brought forward swimlanes diagrams in their published book Improving Performance.”  Since then, the swimlane concept has become a widely used process modelling technique.  Swimlanes can also be referred to as Rummler-Brache diagrams or cross-functional flowcharts.

The BABOK highlights the swimlane diagram as a business process modelling technique used in flowcharts, Business Process Modelling and Notation (BPMN) and Unified Modelling Language (UML) activity modeling methodologies.  There are other modelling techniques that use the swimlane concept as well such as a Service Blueprint, Customer Journey map and LOVEM (Line of Visibility Enterprise modelling) methodology.

At one time, Microsoft Visio and iGrafx were the primary applications used to design these types of diagrams.   However, today there are a variety of cloud-based service options that provide the same functionality either for no cost or for a subscription fee.

The great thing about a swimlane diagram is that it doesn’t need to be overly complicated.  At a bare minimum, all you need to capture a simple process is:

  • The actors involved (eg. Roles, groups, departments, people)
  • The basic steps / activities (using an action)
  • The decision points (typically in the form of a question)


Once you have that, map out the sequential steps as they happen through the appropriate swimlanes from the start to end.  There you have it – a visual representation of a business process.  You can elaborate on this simple diagram to add in further details / identifiers (ie. phases, dates, timelines, rules, systems, notes, etc) as well as follow specific process modelling methodology notation.


Some of the benefits to using a swimlane diagram to capture business processes are:

Summary on a Page

  • Provides a visual picture that tells the story of a business process
  • Highlights the various stakeholders / roles, decisions and the hand offs between them
  • Allows for comparison of different states (eg. current vs future)

Easy to understand

  • Describes the steps in a concise and sequential manner
  • Provides clarity on the activities and who’s responsible
  • Both business and technical teams are able to grasp it

Facilitates process improvement

  • Highlights where delays / bottlenecks occur, areas of rework, mistakes or wasted time
  • Identifies any missing stakeholders or steps
  • Provides as a baseline for improvement

While the swimlane diagram has its advantages, there are a couple of pitfalls to be aware of.  A swimlane diagram can become quite complex and hard to manage if it isn’t structured properly.  Also, some business problems may not be apparent in a high-level diagram and swimlane diagrams can become quickly outdated or hard to maintain if it isn’t kept up to date.

Overall, the swimlane diagram is one of the best tools to provide a snapshot of a business process.  This process picture provides a summary that facilitates an understanding for both business and technical teams of what roles/people, activities and handoffs are involved.  Swimlane diagrams are readily used by Business Analysts and non-Business Analysts alike for this reason.  If you are just starting out on your BA career journey, this is definitely a technique to add to your toolkit.


5 Characteristics of Effective Business Analysts

“Business Analyst” is not just a title. Is not a job. It is a mindset, a concept and a structured process executed by people in different positions inside an organization. It’s more like, an approach of making the things happen from the realization of business need towards the final implementation.

It’s easy to call yourself business analyst but difficult to be a good and effective business analyst. The field can be great fun, and very rewarding, but you need to be prepared. People who take on business analysis roles typically believe they need three things: skills and experience, a bit of marketing, and an interest in working in a variety of environments. However successful business analysts know they need much more than a technical expertise and specific skills. They need a mindset and a specific attitude in order to serve with the best possible and feasibly way their clients business needs.

What is expected from business analysts can vary widely. And what they actually need you to do can be completely different from what they expect. Business analysis is an exciting, dynamic form of work. You can have a positive impact on your clients and be well paid for your effort. But you have to be appropriately equipped.


To be an effective and successful business analysis you need to continuously develop some specific characteristics.

The first is technical depth. It’s critical that you have the technical background to satisfy your clients’ needs. This means you have experience in a variety of environments. The more breadth of experience you have in your technical area, the easier it will be to apply your skill as a business analyst.

Second, effective business analysts need to understand quickly and accurately what’s happening in their client’s environment. Your power of observation needs to be well tuned. Being able to listen carefully and patiently, observe the behavior of your clients, and make sense of what is happening is very important.

Third, effective business analyst care about the welfare of their client’s business and the clients themselves. You need to be able to put yourself in your client’s shoes and appreciate the difficulties they may be facing or have faced. While what you do may seem routine to you, it probably isn’t routine for your client. You need to appreciate that fact and behave accordingly.

Another important characteristic is emotional intelligence. Often clients will engage you because they’ve had substantial difficulties. They may have a skill shortage, or they may not be sure how to manage what you’ve been asked to deliver. All these conditions create stress. On top of that, you’ll be striving to learn as much as you can as quickly as you can, so you’ll be under stress as well. Dealing with all that requires personal emotional maturity and the ability to assess and deal with the emotional state of your client.

Also, you have to develop the observation and effective listening as a personal characteristic, make recommendations based on sound business judgment, and be patient. As trust builds, the direction your client provides will likely become more reasonable. Work out your contract. Understand your client’s needs and desires, and establish a good relationship with your contract manager, and you could put on your superhero costume to celebrate your success. Observation helps towards a really robust problem definition statement. So as you look at your problem-solving, and you’re getting ready to start pursuing that initial set of ideas, you need to go through that prioritization and pick the highest value one that’s going to have the biggest impact on your overall solution.

Business analysis is performed on a variety of initiatives within an enterprise. Initiatives may be strategic, tactical, or operational. Business analysis may be performed within the boundaries of a project or throughout enterprise evolution and continuous improvement. No matter their job title or organizational role business analysts are responsible for discovering, synthesizing, and analyzing information in order the best solutions to be derived and the clients’ needs to be accommodated in the best possible way.

Developing a Roadmap for a New Product

If you’re a Business Analyst or a Product Manager, chances are you have been responsible for developing a business/product roadmap at some point in your career.

In some organizations, particularly those that either (1) have growing or mature products or (1) those that are predominantly waterfall, product roadmaps are developed with crystal vision and high precision for 2–3 years down the road. There’s also a little room for change (i.e. scope creep!) primarily because the roadmap is developed keeping in mind market & innovation trends, competition and profitability and hundreds of resources are already actively working on stuff.

However, what do you do when you’re managing a new product, particularly in a large & established (process-heavy) organization, where everyone’s after you for crystal clear product vision, and you’re barely trying to make the only customer you have, happy?

There are several challenges to developing new products, particularly in the enterprise space, when your first few customers are extremely key to the future of your product and much of the product shapes from the requirements & needs given to you by them. As a business analyst or product lead, you’re often caught in the battle of building features for that first customer, even if you don’t particularly think this might help you scale. Moreover, everyone in the team is looking to you to figure out what to build, both in the near term and the long term and when this get’s particularly challenging is when the customer asks you for a huge feature or integration that requires a lot of ground-work upfront — and also wanted it yesterday!

Nevertheless, as a business analyst, it always helps to plan your roadmap to the best of your knowledge in order to keep your product vision and strategy aligned at all times while giving the rest of your team & organization a preview of what’s likely to come. Here are some roadmapping methods I’ve learned & executed as a PM through my experience in developing new products and solutions while trying to put some method to the madness!

1. Reduce as much ambiguity on the ‘now’, while setting some context on the future.

A roadmap does not necessarily have to span over multiple years or even a full year. And it also does not necessarily have to be time-based. Particularly for new products that are yet to see the light of the day, or are just beginning to, a now-next-later framework works great — the key is to create something that everyone can understand and get a sense of your product vision and why you’re building something.

BA Dec22 2020 1

I have in all-honesty built roadmaps with my team that look something like this, mostly because of varying release cycles and business priorities:

BA Dec22 2020 2
Source: Self-illustrated


2. Take your stakeholders along the ride.

I’ve been in many roadmap planning sessions where the product & design team have put down all of the things we think we want to build on sticky notes, brought the key stakeholders into one room (usually KOLs representing sales, marketing, business development & engineering teams), and had them group things either by product category or by ‘must-haves’ and ‘nice-to-haves’ and dot vote on the top 3 things they would like built. This technique works well particularly when a product is still in stealth mode and you as a PM is figuring out what the MVP version should have.

BA Dec22 2020 3

An even more methodical and quantitative approach to roadmap planning & development can be to define evaluation metrics and identify a rating & score for each feature in consideration. You could either come up with the rating based on your own knowledge of the space or let your team determine a rating for each category. As a next step, you could either self-score all of the items in the list and review with your stakeholders for feedback and changes (which can be more time-efficient) or you could have each stakeholder score the items individually or together as a group. At the end of the process, you should have your prioritized roadmap based on the weighted totals.

BA Dec22 2020 4
Source: Self-Illustrated

3. Resource based roadmapping

Another way to plan your product roadmap can also be from the bottom-up — i.e. resource based roadmapping. Perhaps you work in a large organization and there are offshore resources who are available and allocated to work on your product (because it’s going to be the next big thing!). When this happens, you could use your team’s help to figure out (1) how big a feature is (Large, Small, 1 sprint, etc.) (2) what components does it involve (i.e. client, server, UX, etc) and (3) what value it could bring to your product & customer. This approach is great for those “big ticket items” that your customer would like to have in your product — like an app or service integration or a new algorithm — that need more time & resources to develop and could potentially be done in parallel to your “now & next” items.

Obviously, there are pros and cons to all of these approaches, and a lot of factors go into planning new products besides just customer needs — like competition, growth, revenue generation, etc. and sometimes PMs are also simply “told” to develop products as a response to the market or your competitor. In any case, roadmaps are a great way to visualize your product journey while enabling the rest of your team better plan and organize their work.

The TRIFECTA – Bringing Together People, Process & Technology

Many of us have been at an organization where the business has identified there is a problem or an inefficiency, but the root cause has not been identified.

Sometimes, people feel they don’t have time to spend looking into the issue and then the problem lingers. Other times, the quick fix is let’s hire more people or let’s buy this piece of technology. You might be nodding your head, but these seemingly quick fixes are usually not the long-term solution.

I often get approached by groups that have a problem, but they don’t know what is causing the problem. Recently, I was approached by a group that had spent months trying to improve their operations. They brought in different people to help turn things around, but they still were not seeing the expected improvements. They were at the point, where they were contemplating a new technology solution. While this may sound like a slam dunk for many people, I am a strong believer that you need to figure out your current state before making a recommendation for the future state.

To figure out the current state, it requires bringing together what I call the TRIFECTA. The TRIFECTA is people, process, and technology or some refer to it as the three legs on a stool. The TRIFECTA is essential to having successful business and/or teams. You can have one, but without the others you will struggle to succeed.

People –

You can hire amazing people with great skills and experience, but if you have inadequate processes or technology these people may struggle. When people struggle, they often get frustrated and can potentially quit. You can give a person a canoe, but if you don’t tell them where the water is or give them a paddle and tell them how to use it, they may not make it far.

Process –

You can have wonderfully detailed standard operating procedures (SOP), but if you do not have the people that are invested in following the SOP then it is just words and pictures on paper. If you do have great people and processes, but lack technology you can only scale so far. You can give a person instructions, but if they are in French and you can’t read in French and you don’t have a device to translate them with you are left with a lot of paper that might end up being beneficial to start a bonfire.


Technology –

This is my favorite. “If we just buy “x” system it will fix all of our problems”. I really wish it was this easy, I truly do. However, there is no easy button in life. You can have great applications and software, but if people don’t know how to use it or aren’t bought in on why they should use it then you have this wonderful technology just collecting dust on a shelf. You can buy a bike, but if you don’t learn how to ride it, then you just have a nice a bike.

While pulling together the TRIFECTA might seem like a tedious task, in the long run it often pays off. In the above example, we spent two weeks interviewing team members, mapping out processes, and identifying opportunities. We discovered over 100 opportunities and put together themes for leadership to prioritize. It took a few months to execute the identified changes and technology enhancements, but they have seen improvements across the organization and the process flows hang in the office as a reference and training aid.

Some of you might be thinking we can’t spend two weeks on this because “we have a business to run”, “I already have a full-time job”, or “we will do it later”. Taking the time to meet with teams and talk about the people, processes, and technology that is used in their day to day helps identify problems or inefficiencies. In my experience the root cause is often more than one thing, but a myriad of things, if you don’t talk about them, they can linger.

Some organizations may think that they can throw anyone in and they can do a great job at business process analysis, but it really requires a person with a specific set a skills and behaviors. They don’t have to know anything about your business or process, but they need to be curious and passionate about learning how things work and have a desire to help improve the process. A person that can ask tough questions and help identify where the opportunities are.

Next time you identify that you have systemic issues, pause and think about if it makes sense to pull a small team together to dive in and do some analysis. Getting leadership approval for a team might seem daunting, however if you put together a business case and document the skillsets that would be needed to be successful it will be easier to share the need and vision with your leadership. You may find once you have successfully pulled together the TRIFECTA there is a desire to repeat it in other areas of the business. Having a small team that can be dedicated to business process analysis and improvements is ideal as it allows for these individuals to dedicate their time to work through these specific problem areas. Some of you may already have people in your organization with the necessary skillsets and behaviors that you could leverage to successfully drive these types of efforts. Your leaders may worry that this type of work will dwindle, but having people with diverse skillsets and behaviors can allow them flex with multiple groups like business analysts, lean champions, or continuous improvement teams.

How to Figure the Detail of Process Models

I love that a fellow analyst asked me a question as they were having trouble being asked about putting “narrative on their process model.” 

We started with the first question – WHY?   Simple, yet seriously, we’re so good at OVER analyzing and getting into analysis paralysis that sometimes just trying to figure out what is going on can save others (but especially us!) LOTS of valuable time!

With the first question, the answer was easy – they want more information.  Okay, so then the next questions is then about what the PURPOSE of the model is?  What are you trying to accomplish with your process model?

Good foundational, IIBA® BABOK® Guide v3 (2015) states that the purpose of process modeling is to provide a “standardized graphical model…to show how work is carried out…as foundation for process analysis.”  So are we showing ONLY how work is carried out?  Or are your stakeholders asking for much more?

We have data models and stakeholder RACI matrices and other valuable tools because they’re great at what they’re used for!  They each have their own purpose!  So ask yourself if you’re ever having difficulty with your process model because you’re trying to do WAY more than model a process?


This is the analysis skill – identify what questions are being asked or needing to be answered and facilitate getting that information to the needed decision makers.  If people ask lots of questions about who is doing what on your process, then maybe we do need greater detail on the stakeholder ownership.  Perhaps there is no ownership?  Or don’t overanalyze and just add a new swim lane if it makes the users happy (and of course understand better!).  If people ask lots of questions that revolve around data, do we need a data dictionary and some data modeling or data flow diagrams?  This is common when you meet with stakeholders of different levels of focus.  Too often process steps, decision points, data elements, stakeholders and end products are thrown at the analyst.  Do not feel compelled to write everything on the process model.  Write PROCESS on the process model and make notes on the side.  Then look at your notes.  Are all the notes about data?  Then your own notes tell you that you need some data definition.  And don’t be afraid to acknowledge that there’s a mix of high-level overview requests mixed in with the “give me the technical details down to the line of code” demands.  Just then make your model flow so that each view or screen or page is only showing ONE level.  Then with technology today just link it to the page with the lower level of detail.  Don’t over complicate it trying to take a full course on modeling software or anything.  Simply list high level functions with overall business areas on your main page.  Then for each one of those functions, create a “clean page” with just that function’s information.  And then you can work WITH your stakeholders to define as much information as they at that deeper level, while keeping everyone on the same page at that higher level.  Even better, with this approach, you just created a strategic, overview perspective as well as tactical or operational details.  Now you’ve helped multiple groups from starting with a single model!

See what information comes up from the stakeholders on what is missing or needs to be added to make the process model USABLE.  You are creating a process model for OTHERS to use.  If the level of detail is high and you’re not sure it’ll work – ask!  Share it out and see if people have questions.  If they have none, then you’ve done what is needed to help others get things done!  Analysts process model to facilitate, not own.  The model is the stakeholders’, teams’ or client’s.  It’s for them to get their work done, complete projects and create great new products.  If they ask lots of questions, then help them get the answers.  And as you do, always think what is the most efficient and effective way I can get them the answers.  Just because they want all the information on the same visual, does not mean that it will help them answer their questions.  But to know what to capture appropriately on process models, means you need to know what everyone is trying to accomplish by using your process model.  Make it an actionable document.  Anything you produce should be reusable over and over again – from decision making to operations and troubleshooting – and by people other than you!  That’s the true value! 

So next time someone tells you that your process model is lacking lots of information or needs other data and elements added, ask why and get clarity on the stakeholder’s need and what they hope to accomplish WITH your model.  Then work with them to help develop a model that answers their questions and supports their decision making.