Tag: BPM


10 Principles for Working with Processes

Process: “a series of actions or events performed to make something or achieve a particular result, or a series of changes that happen naturally” Source: Cambridge Dictionary

When used correctly, process modelling is an invaluable activity, and along with process maps can be a powerful way of communicating of what is happening or should happen. At its simplest it helps us to decompose a process into a sequence of steps, with a defined start and end, and understand the various events that trigger specific actions. They can also help us to identify the users (‘actors’) and what their involvement is.

This provides the basis for analysis and optimization.

However, it can be easy to fall down the path of over-complication, especially when it comes to drawing up a process. Meaning that instead of being helpful, they can be time consuming and not fit for purpose.


Therefore, here are my set of 10 principles for working with processes, whether that be through a discovery activity to define an ‘as-is’ or through a design phase to build up a set of potential ‘to-be’ processes.

  1. Understand the purpose and why, before anything else — what are the models going to be used for? Is it to share with others to seek a consenus view on how something works? Is it to enable you to perform analysis activities off the back of? Is it to identify to a list of users (‘actors’) in an existing process?
  2. Consider your audience, and use notation frameworks sparingly. Notation frameworks such as UML and BPMN, can be helpful in the right circumstances. Especially as a ‘behind the scenes’ analytical aid. But, bear in mind, they often confuse many who haven’t had the same training.
  3. Focus on ‘just enough’, don’t let perfection be the enemy of good. Low-fi is generally fine, share early. Iterative process modelling is often the best form.
  4. Think about accessibility, when sharing process maps—not everyone may have a Visio or Lucid license. Consider the best tool so that everyone who needs to access it, can access it. If in doubt, export it as a PDF before sharing.
  5. Levels, know when you need them and when you don’t — you don’t need to model every level every time. However, you may need to understand something at a higher level first, before you can break it down further. All goes back to the purpose!
  6. Beware relying on previously documented processes — Beware of re-using or relying on the information in a previously modelled processes unless you have a robust process library, that is regularly maintained and with stringent change control. Processes have a shelf life!
  7. Consider sample size, like you would with any other type of research — there are documented processes, and then there are workarounds that users and customer actually do. Not everyone may approach or engage with it in the same way, so consider how many people you should speak to, in the same way you would with any other type of research activity.
  8. Talk to users who ‘do’ the processnot just the person who ‘owns’ the process. Expectations vs reality are often very different.
  9. Obsess over the events that trigger a process. They might be automated, such as triggered at a set time or upon a specific action being completed. They could be manual, triggered by an interaction from a user. Whatever, they are — invest time in understanding what they are, how they work and assess whether they’re helpful.
  10. Reference your contributors — its theirs, not yours — whether they’ve helped you to to understand how a current process works, or if they’ve been involved in designing an improved or new process. Not only is it polite, to reference those who you’ve collaborated with along the way, it‘s a helpful record when looking back. It may also prompt others, to suggest additional people who should be involved.




Lastly, remember processes are different to customer journey maps, service maps, business capabilities. Don’t be fooled into thinking that you don’t need to understand processes, if you have a good grasp on the customer journey or business capabilities. They provide different thinking and perspectives, and will uncover different information. Especially in discovery settings, processes are the closest you can get to understanding what is actually happening for all users involved. They also consider both visible and invisible triggers and events.


Why Business Agility Starts with Strong Data Governance

Data is now one of the most valuable assets corporations own, yet, it is still often treated as a waste product.

As data increasingly guides decision-making and digital advances automate business processes, so the integrity of data assets becomes more important. All organizations, regardless of size or sector, need to shift from viewing data as an inconvenient cost center to an asset that is reliable, accessible, secure and usable. To ensure organizations can proactively manage their data in all its disparate guises and locations, they need a structured approach with defined rules and policies governing how it is handled and stored.

The Case for Data Governance

Bad governance is costly. Poor data management impairs an organization’s ability to conduct business, whether that involves managing customers, delivering timely products, spotting market opportunities or operating as efficiently as possible.

Gartner predicts that through 2025, 80 percent of organizations looking to advance their digital business will fail because of their outdated approach to data and analytics governance. If that estimate is correct, businesses are actively missing opportunities and putting themselves at risk.

What Barriers Do Businesses Face?

Faced with increased internal demand for answer to complex questions combined with external pressures to demonstrate value and ROI, organizations are turning to data for the answers. However, harnessing data to deliver actionable insights starts with improved data stewardship. Furthermore, amid a rapidly changing regulatory climate, data management and governance are also critical to ensure businesses don’t fall foul of their regulatory obligations.


Establishing Good Data Governance

Good data governance is about creating a system of data management that addresses all these challenges. Few data and analytics leaders would disagree with the push factors for data governance, but market unpredictability and the sheer pace of innovation has made it harder to benchmark data governance efforts and establish best practice. Having invested in data and analytics, business and IT leaders now urgently need to ensure good governance in order to meet their goals of operational efficiency, increased growth or improved CX.

Establishing a data governance framework is a multidisciplinary exercise. It requires strategic input, data engineering, cloud management, data privacy and compliance expertise. Whether a business is setting up data governance systems from scratch or amending existing processes, there are four guiding principles that can help them wherever they are on their digital maturity journey.

  1. Align Data Governance to Business Goals

The most common pitfall for data governance projects is the failure to match the mission statement to business goals. It may sound obvious but quantifying the business value of the any information transformation required is essential to success. Too often data governance has been perceived as something carried out by the data people, far removed from the rest of the business. However, when business and IT leaders fail to align their thinking at the strategy and goal-setting stage, they risk ending up with tactics and metrics that do not reflect business goals.

Example: metrics that measure data transformation (“X data points de-duped, Y data points corrected”) rather than linking data quality or data management to customer experience.

  1. Establish a Data Governance Blueprint

Does the business have a holistic view of the information requirements by each business process and stakeholder? Amid shifting regulatory requirements and growing data volumes, it is easy for a data governance framework to get outdated. Focus on establishing clear stewardship of data, information, business and security risk. Once data requirements are understood, identify a data management roadmap to organize, maintain and sustain the underlying data so it can deliver the capabilities identified in your blueprint.

  1. Leverage Technology and Automation

Improving data integrity at speed is achievable through smart tool selection. In the burgeoning RegTech sector, for example, there are many examples of solutions that address the need to comply with regulations such as GDPR, KYC and anti-money laundering (AML); bolster security using biometrics, 2FA, blockchain and AI; and automate unnecessary, expensive manual interventions in the data management lifecycle.

  1. Embrace a Cross-functional Approach

Formalizing cross-functional teams for data governance is an important first step to strong data stewardship. Balanced decision-making, which involves weighing up (IT, security, compliance) risks against business opportunities, is the hallmark of true multidisciplinary collaboration, but it only happens if everyone’s committed to the same goals. Training and education are good for raising awareness of issues around data integrity, but don’t go far enough. The next step should be to involve teams in data accountability, transparency and ethics discussions and foster a more data-centric, collaborative culture as a result.


Compliance and Competitiveness Drive Governance

In industries such as healthcare and BFSI, strong data governance has become an imperative in order for these organizations to adapt to changing regulatory environment. Regulatory volatility has made it much harder for these organizations to improve data integrity in a timely manner across business functions. Pioneering organizations in these sectors have led the way with strategies that prioritize an active data governance approach, leveraging cross-functional decision-making and the latest automation technologies to adapt to changing environments fast.

Compliance has been a key driver for data governance until recently but now companies are beginning to understand the importance of data stewardship for value generation as much as risk mitigation. Any business that is committed to its digital transformation goals around improving data-driven decision-making  – indeed any business that has invested or is planning to invest in data and analytics – should make data governance a major focus for 2022.


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
Source: https://www.prodpad.com/blog/how-to-build-a-product-roadmap-everyone-understands/

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
Source: http://dotmocracy.org/dot-voting/

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.