Author: Edmund Metera

A Checklist for Business Analysis Planning

Written by Edmund Metera on February 18, 2021. Posted in Articles.

Use the Universal Business Analysis Planning Checklist as You Plan Your Business Analysis Approach.

Every project is a unique, temporary endeavor.

The business process management, regulatory compliance and digital transformation projects that business analysts may play a role in all come with different goals, scopes, teams, timelines, budgets dependencies and risks. Though many projects follow similar methodologies they are all tailored for project scope constraints and to take advantage of available resources, opportunities and lessons learned from prior work.

Each business analyst also comes with a unique set of skills and experiences. Almost all business analysts have great communications skills and at least some experience-based business domain knowledge. That’s why they became business analysts in the first place. Every business analyst has uniquely acquired knowledge of business analysis techniques and business domains through personal study, practice and experience. Many have also been trained in elicitation, requirements management, modeling, measurement, analysis and documentation techniques. An ever-growing number have received professional certifications, such as the IIBA Certified Business Analysis Professional (CBAP) or the PMI Professional in Business Analysis (PMI-PBA).

What is Business Analysis Planning?

The most skilled business analysts are not only competent in many business analysis techniques but also consciously tailor their business analysis approach for each project that they engage in. They have learned to consider key project dynamics along with their own competencies and to tailor their planned business activities and deliverables to suit each project’s unique dynamics. Regardless of your own level of business analysis experience, maturity, and whether you are formally trained, certified or not, you can still consciously assess each project’s dynamics and tailor your forthcoming business analysis work to get the most productivity and value out of your business analysis efforts in each project.

The most significant project dynamics include:

The methodology, or sequence of stages or major milestones, and the business analysis products or outcomes that are expected by the end of each stage/milestone (and before starting the next).
The budget and schedule, not only to meet them, but to take advantage of contingency or schedule slack opportunities, to increase the value, quality or to learn.
The key project stakeholders and relationships that are new and changed and forming, to take a proactive role in fostering and building relationships with and among that team.
The types and combinations of elicitation techniques that will be best suited for producing or validating business analysis deliverables.
The business domain knowledge and experiences of the diverse key project stakeholders, including your own unique set of business analysis competencies.

The Universal Business Analysis Planning Checklist

You can be more effective in planning your business analysis approach if you follow a consistent, clear agenda that considers the common project dynamics.

The Universal Business Analysis Approach Planning Checklist covers the most common project dynamics. You can use this as an agenda to elicit and discover a comprehensive view of a project’s key dynamics, its opportunities and use what you discover to adapt/tailor your business analysis approach.

As an exercise, think of a project that you have recently worked on, you are currently working on, or will soon be working on. Answer questions in the following checklist for yourself.

Project Life Cycle

What are the planned stages of this project?
What stage are we currently in?
What is the business analysis deliverable (or set of deliverables) that I am responsible for producing in this stage?
What is the intended use of my business analysis deliverable(s) and who will use it?

Schedule and Effort Budget

How much effort can I spend and by what target date am I expected to produce my business analysis deliverable(s)?
Is that about what I also estimate it will take?
Is either my effort or date estimate higher than the effort budget or target date? If so, how might I adapt my effort, scope, activities or configuration of my deliverable(s)?

Project Stakeholders and Relationships

What are the key roles is on the project team and who is in them?
- Does this project have an executive sponsor, project owner or product owner, project manager, specialists and business subject matter experts?
- What are the names and titles the persons in these project roles?
Are significantly new relationships being are created in this project?
- Who’s new to each other on this team?
- Are there local and who’s remote team members?
What are peoples’ responsibilities?
- Who is responsible for producing, accepting or needs to be consulted or informed of each of the project’s key deliverables, particularly the business analysis deliverable(s)?

Elicitation Techniques

Which elicitation techniques are available to me use?
- Documentation Reviews – What documentation or prior work products are available to review?
- Interviews and Workshops – Who can I interview or include in a workshop, and what questions would I need to ask?
- Observations – Where and what kinds of observations may be needed and how could I arrange for them?
- System reviews – What system(s) are available to review and for what information?
- Surveys – Who could I engage in a survey and using what types of questions?
What are my own business analysis competencies?
- Considering this project’s stakeholders and relationships, the elicitation techniques available to me, and my own core competencies, which elicitation techniques are best suited gather and validate my business analysis information?

Organizational Assets

What specialized tools for elicitation, documentation and modeling are available to me?
- Collaboration tools, facilities, survey tools?
- Diagramming or modeling software?
What prior business analysis work (e.g., documents, models) that I can draw from?
Does my organization offer training in the subject business domain?

Competencies and Knowledge

Who on the project team has what expert business domain knowledge?
What is my own business domain knowledge?
What are my strongest core business analysis competencies?
Where can you take advantage the team’s diversity of knowledge and competencies?
Who are the best stakeholders in this project to engage in elicitation of content or validation of business analysis deliverables and what is or are the best elicitation techniques to use?

On reflection, are you able to answer these questions for yourself? When you go into your project workplace, who will you include in this conversation?

Conclusion:

Business analysis planning is a recognized business analysis activity. The IIBA Body of Knowledge (BoK) includes the Plan Business Analysis Approach activity within its Business Analysis Planning and Management process. The BoK also lays out the scope of what should be covered by a Business Analysis Approach as “The set of processes, templates, and activities that will be used to perform business analysis in a specific context.”

The time and formality that you apply to business analysis planning is up to you. At the financial institution where I work as a project and program manager, our business analysts typically tailor and document a business analysis plan for each new project to which they are assigned.

I think of business analysis planning as a form of insurance. Spend a little time upfront to assure that the bulk of the rest of your business analysis efforts will be as well spent and effective as possible. Expect the benefits of tailoring a business analysis plan for every project to be that:

It will help you to align your own core business analysis competencies to each project, and
You and the project will gain the most value from your business analysis efforts.

That’s a value-adding proposition.
You are welcome to contribute comments about project dynamics that impact business analysis plans or about the checklist presented through the Contact Us page at www.ProcessModelingAdvisor.com.

5 Business Process Modeling Tips for Digital Transformation

Written by Edmund Metera on March 19, 2020. Posted in Articles.

Business analysts should bring more than an ad-hoc or experience-based business process modeling competence to digital transformation projects. This article will explain why and practically, how.

Many enterprises are on digital transformation journeys.

They are optimizing operating costs, improving capacity, security, scalability, and availability by moving their existing applications onto private or public cloud infrastructures. They are adopting best practices and gaining operational efficiencies by adopting best-of-breed enterprise applications in the cloud. They are integrating technologies like mobility, the internet of things, data analytics and machine learning, robotic process automation, biometrics and more. All in the cloud. This is commonly referred to as digital transformation.

Digital transformation projects differ from process management and regulatory compliance projects. They aim to disrupt by creating new business processes and services rather than improving what exists. They aim to get to market quickly by adopting and integrating existing technologies, systems and services, along with their processes, rather than inventing them. Their business processes are enabled by systems and services that are off-premise, in the cloud.

Disruption – Digital transformation projects typically seek to achieve leapfrog operational improvements rather than incremental ones. They achieve efficiencies and standardization objectives by adopting the processes of already proven, best-of-breed business systems and services. For example, adopting a human resource management system in the cloud will disrupt by altogether abandoning current processes and adopting and standardizing on the best-of-breed processes of the cloud solution.

Pace – Many digital transformation projects have aggressive timelines to deploy their technologies, to keep pace with business competitors or to gain market share. Already-invented and proven software services hosted in the cloud can be subscribed to and deployed relatively quickly. The time and effort spent on deploying business applications may be shortened. The effort shifts to tailoring, integrating, testing integrated components software and adopting change within business operations.

Technology – Technologies such as virtual machines, software as a service, mobile devices, the Internet of Things, biometrics, machine learning and the internet itself are all part of the digital transformation landscape. Virtual servers in the cloud are highly scalable and cost-effective. The range of existing, proven systems and services ready to be subscribed to, adopted and integrated in the cloud continues to grow. The cloud’s systems and services collaborate as a network of event-triggered and outcome-oriented services.

As with other information technology projects, digital transformation projects come with delivery and operational risks. They can have heightened vendor risk, people risk, change management risk, and ultimately business process failure risk. They rely on external vendors’ consultants, or third party consultants who are temporary and outside the direct control of the organization who owns the transformation. The organization’s people who will maintain the newly transformed services when a digital transformation project ends may be left with a knowledge gap in their capability to support the new product or service. The people whose day-to-day operations are affected might not initially be well-enough prepared to use the digitally transformed systems and processes. These can ultimately contribute to business process failure risk. The risk of failure to achieve the expected operational benefits due to poorly designed or executed business processes.

This is why any digital transformation project’s lifecycle may call for a business analyst to prepare conceptual or logical business process models. The models will be used for the same reasons that process models are used in process improvement or regulatory compliance projects: to communicate among the processes’ stakeholders. By communicating the required or designed processes among the digital transformation project’s owners, its suppliers and to people in the organization whose processes are changing

So What?

According to the IIBA, process modeling is one of a business analysts’ competencies. Although most business analysts are good enough communicators and have a well-rounded knowledge of their enterprises’ operations, they only have an ad-hoc or repeatable degree of business process modeling competence. They prepare business process models very infrequently. Some can recollect and repeat the process modeling techniques of their previous process improvement, regulatory compliance or IT projects. If they do, they are used to perceiving business processes as sequential procedures of tasks. There is generally room for improvement.

A business analyst should be able to confidently and efficiently elicit, perceive, model and communicate how a business process or activity is or will be implemented by a digital transformation project. Among their elicitation, subject matter and communication skills, a business analyst should be capable of perceiving any business process or activity as it is or will be implemented in the cloud, as a network of event and message triggered collaborating services.

5 Business Process Modeling Tips for Digital Transformation:

Here are 5 ways to improve your business process modeling competence and become better prepared for producing high-quality business process models that serve digital transformation projects.

1. Come Prepared
2. Get Event and Outcome Oriented
3. Know Your Mission
4. Have Agendas
5. Take Advantage of BPMN

Come Prepared.

Have a defined and proven process modeling competence and tailor it for each digital transformation project.

Start with a defined level of business process modeling competence instead of taking an ad-hoc approach or simply relying on past process improvement or regulatory compliance project experiences. Be able to clearly describe what steps and activities you will take to elicit and document the business process model. Have established elicitation techniques, agendas and modeling patterns that you can use to elicit and model basic business process flows. Be able to predict what modeling steps you will take in developing the business process model. Also, be able to predict what elicitation techniques work well for you. Have clear, concise elicitation agendas. Be prepared to intentionally tailor your approach, elicitation techniques, elicitation agendas and model configuration to the needs of each digital transformation project’s methodology.

Get Event and Outcome Oriented.

Perceive, normalize and define all business processes or activities as event-driven and outcome-oriented services.

Initiating events and expected outcomes are critical to the way that business processes and services collaborate in the cloud. Any business process or activity is a repeatable collection of work activities, initiated by a business event that achieves an expected outcome, for a customer.

Observe and recognize how business events and expected outcomes are implemented as cloud services. For example, you know that whenever you’ve made a credit card purchase online, the credit card authorization service started by receiving a request from an online business process in which you made your purchase. This was its initiating event. Once initiated by that event, the credit card authorization service completed related work tasks, like negotiating with the credit company and a bank. It achieved its expected outcome by sending a response that the payment was accepted or declined. That was the expected outcome and that outcome was consumed by its customer: the site that made the credit card authorization request in the first place.

Use this framework to conceptually and logically frame any business process that you model in a digital transformation project, before spending valuable time and effort eliciting all the other process information that may come up: e.g. who owns it, how it is or will be implemented, what is its service level, how efficient it is, etc.. Not much of all the other logical details matter if the basic framework of the digitized business process or service itself is not well framed: To you, it must have an initiating event and one or more related activities that lead to its expected outcome, for a customer.

Know Your Mission.

Determine the purpose of a business process model in each digital transformation project’s lifecycle.

The scopes, objectives and delivery methodologies of digital transformation projects vary widely. Get clear about what the business process model will be used for, and know who will use it. Determine the tense and the required degree of abstraction that will best suit the model’s intended use. Establish these mission parameters at the start of your elicitation and modeling efforts so that you focus the forthcoming time and modeling efforts on the right types of conceptual or logical refinements for that project and you are in alignment with the mission parameters when you validate your model’s quality.

Have Agendas. It’s not nearly as important to ask a lot of questions as it is to ask the right questions.

Have clear, concise elicitation agendas to elicit basic business process flow and each of the most common logical business process flow refinements. These are the few but key questions you will doggedly elicit the answers to as you are eliciting your process model’s content. Understand why you need to ask and answer those questions. Prepare and communicate your elicitation agenda in advance of engaging key stakeholders in elicitation events like workshops or interviews.

Take Advantage of BPMN.

Take advantage of BPMN to illustrate event and outcome-oriented business process structures and modeling patterns.

Use BPMN’s icons that are specifically intended to illustrate event-driven, outcome-oriented process flows and logical refinements. Use modeling patterns that employ BPMN start events, message flows, intermediate events, and end events, to illustrate modeling patterns such as basic business process flow, external stakeholder interactions, interruptions, delays and exceptions, and expected outcomes.

Know the conceptual and logical process elements and patterns that are relevant to systems in the cloud. Have elicitation agendas and modeling patterns (using BPMN) that you will use to elicit, model and communicate them. Be able to elicit and model the events that start, interrupt, and finish processes and services. Use messages to illustrate collaborations among business processes and services

Establish or Improve Your Process Modeling Competence for Digital Transformation

The Universal Process Modeling Procedure is a step-by-step guide for producing a business process model that will meet its project’s intended purpose. It guides a business analyst or process analyst to establish a clear mission for every process model. It provides you clear elicitation agendas so that you can be asking the right questions at the right times in your model’s development. It tells you what to look for and how to accurately and unambiguously identify, normalise and define any business process and or activity. It includes a validation step with comprehensive and tailorable process model quality criteria. It informs you about key process model stakeholders and how to engage them in the model’s development. It also includes reusable BPMN modeling patterns for the most common types of process model refinements.

Learn more …

About business process modeling competence at www.ProcessModelingAdvisor.com.

Find the book Universal Process Modeling Procedure – The Practical Guide to High Quality Business Process Models Using BPMN at Amazon Books.

Top 6 Process Modeling Mistakes and How To Avoid Them

Written by Edmund Metera on April 16, 2019. Posted in Articles.

There are many examples of very good business process models out there.

They can be found in textbooks, online, tutorials, and product demonstrations. However, in the real world …

Too many business process models fall short of expectations.

Despite significant investments of time and well-intended stakeholder effort, many business process models still end up being not very useful for their intended purposes. Too many don’t accurately enough reflect the business to be useful, or lack sufficient key stakeholders’ buy-in for real decision making, or don’t include the kinds of process information that the model’s readers are looking for, or even confuse their readers with complex or incongruous graphical notation.

Root Causes

None of these types of complaints should be blamed on environmental or project constraints like modeling tools at hand, the level the knowledge or capabilities of business subject matter experts who may be called upon to participate in the model’s development, or even time and effort constraints. Projects are by definition unique temporary endeavours, so these variables are present to varying degrees in all projects. Yes, they influence or constrain any process modeling activity, but a competent business analyst or process analyst is capable of managing and working with or around them.

The root cause of a business process model that does not fit the bill is a business analyst’s or process analyst’s own competence for producing the model while navigating through the typical project dynamics.

Business analysts and process analysts who prepare business process models using ad-hoc methods or past experience are prone to making at least some of these common 6 business process modeling mistakes and having to suffer through their symptomatic process model quality complaints.

The top 6 business process modeling mistakes:

1. Undefined Process Modeling Approach
2. Unclear Model Purpose
3. Not Asking the Right Questions
4. Weak Process and Activity Definition
5. Insufficient Key Stakeholder Participation
6. Insufficient Model Validation

If producing a high quality business process model is not key to your role or your project, then you don’t really need to a high level of process modeling competence. Leave that up to the project’s business analyst. But if it is, then you should be expected to bring a high level of process modeling competence to the table so that you can facilitate and achieve a model that is fit for its project’s intended purpose.

How to Avoid These (and most other) Process Modeling Mistakes

Here are the 6 skills or behaviours that demonstrate a high level of business process modeling competence. They will cause you to steer clear most of the common business process modeling mistakes:

1. Have a defined process modeling approach.

Like other types of analysis, process modeling is a journey of discovery. As a competent business analyst it’s up to you to identify the modeling activities you will perform to lead or facilitate your process model’s journey of discovery. If you don’t already have one then you should adopt and practice a defined process modeling approach.

2. Establish a clear mission for each model.

Process models are typically products of business process improvement/management or information technology projects and all projects are by definition unique, temporary endeavours. As a competent business analyst you deliberately identify the purpose of the process model within your project’s lifecycle and other key mission parameters. You use clear mission parameters to guide your process model elicitation and validation activities.

3. Know what questions you will ask.

It’s not nearly as important to ask a lot of questions as it is to ask the right questions. You should know what few but key questions you will doggedly elicit the answers to as you are eliciting your process model’s content. You should understand why you need to ask and answer those questions. You should be able to prepare and communicate your elicitation agenda in advance of engaging key stakeholders in events like workshops or interviews.

4. Know how to unambiguously identify, normalise and define all processes and activities.

You are able to consistently perceive business processes at any scale and degree of abstraction. You should also know how to normalise any candidate process and once normalised write an unambiguous definition. Further, you understand and have a process definition framework that reflects how today’s network enabled business processes work. You are able to perceive processes as assemblies of activities that are initiated by business events and deliver outcomes. This understanding leads you to define processes and activities that lend themselves as reusable services and you are able to explain why. In this way, you walk the service oriented architecture talk.

5. Know who, when and how you will engage key stakeholders

You identify who the key stakeholders in your process model are. You are clear and deliberate about when and how you engage them in process model elicitation and validation activities. You know how to deliberately engage key stakeholders in the elicitation of the model’s content. You engage key stakeholders in model reviews and resolve their feedback before completing your process models. As a result you are virtually guaranteed to have your models accepted by the business.

6. Know how you will validate your model’s quality.

You know how to identify what the most important quality factors for your model are. You know how you will measure them. You know what questions to ask and of whom to ensure they are sufficiently present in your completed model.

Establish or Improve Your Process Modeling Competency

The Universal Process Modeling Procedure is a step-by-step guide for producing a business process model that will meet its project’s intended purpose. It guides a business analyst or process analyst to establish a clear mission for every process model. It provides you clear elicitation agendas so that you can be asking the right questions at the right times in your model’s development. It tells you what to look for and how to accurately and unambiguously identify, normalise and define any business process and or activity. It includes a validation comprehensive and tailorable process model quality criteria. It informs you about key process model stakeholders and how to engage them in the model’s development. It also includes reusable BPMN modeling patterns for the most common types of process model refinements.