Tag: Agile

Delivering Analysis: Working With the System

Written by Anna Rajander on March 9, 2023. Posted in Articles.

Business analysis is an evolving profession characterized by change. However, not all businesses embrace evolution and change in the same way. This can result in business and delivery practices constraining the use of newer, more agile approaches to business analysis. This article presents some ideas and techniques to help business analysts identify, understand, and work with constraining business practices.

The Challenge

You may have heard the serenity prayer. It goes something like this:

God, grant me the serenity to accept the things I cannot change,
the courage to change the things I can,
and wisdom to know the difference.

The origins of the serenity prayer date back to the 1930s and 1940’s. It is one of the most well-known and quoted prayers in the Christian world, with versions adorning posters, fridge magnets and trinkets across the globe. And while the prayer predates the business analysis profession by decades, the sentiment of the prayer is relevant for many analysts – even those of us who aren’t religious.

Business analysis is a profession of change. Indeed, the IIBA defines business analysis as the “practice of enabling change” in an enterprise. Whether it be learning a new technique or method, or applying skills to a new business domain, business analysts are encouraged to constantly experiment, learn and adapt. We are often looking for opportunities to apply new skills or techniques, or engage with enterprises that are using newer, more agile delivery methods. This constant exposure to change can make business analysts very comfortable with change.

It can therefore be frustrating when we find ourselves in environments where prevailing business practices prevent us from delivering analysis in the way we would like. Outdated systems, over-zealous governance, rigid templates and document heavy processes can constrain our ability to used more modern, agile delivery methods and techniques. And inflicting change on stakeholders using outdated delivery practices can seem like a double standard! Yet, working against such practices and processes can cause even more problems, resulting in business resistance, conflicts with stakeholders, delays, and even failure to deliver.

Identifying Constraining Business Practices

Business analysts need to fully understand the business context in which they are delivering change. This includes understanding the business and delivery practices being used to define, design and implement change, and how they impact business analysis. Early identification of constraining business and delivery practices gives business analysts an opportunity to find ways of working with them – rather than against them.

There are several common business analysis techniques that can be used to help identify and understand restrictive business and delivery practices. For example:

SWOT Analysis – A SWOT analysis can be used to help identify business practices that may impede or constrain business analysis activities (in other words, are a threat to the delivery of good analysis), identify opportunities to improve business practices, and identifying any strengths/weaknesses that may help/hinder delivery given the constraints.
Process Analysis and Modelling – Understanding when and how analysis activities will engage with constraining business practices can support the creation of efficient business analysis plans that meets all delivery requirements.
Stakeholder Analysis – Remember the saying It’s who you know – not what you know? This is too often true – particularly when it comes to governance and approvals processes. Understanding who the influential stakeholders are and engaging them early can often alleviate and even remove constraints.
Root Cause Analysis – There is usually a reason why things are done the way they are, although it may not always be obvious. Uncovering that underlying reason for a given business practice can help analysts a) identify areas for improvement, or b) accept it for what it is.

Conclusion

Understanding business and delivery practices that constrain business analysis can help analysts:

Identify and champion opportunities for business improvement
Identify ways of working with or within existing business practices that may better support analysis, or
Accept and work with prevailing business practices as efficiently as possible.

To paraphrase the serenity prayer – accept the things you cannot change, change the things you can, and understand the difference!

Anna Rajander, Dec 2022

Resources:

Serenity Prayer – Wikipedia, accessed Dec 2022.
A Guide to the Business Analysis Book of Knowledge (BaBOK) v3, IIBA, 2015.

Top Business Analysis Skills To Learn in 2023 To Thrive in a Volatile Economy

Written by Ananya Pani on February 22, 2023. Posted in Articles.

With the economic landscape ever-evolving and uncertainty in the air, it pays to know which business analysis skills are essential for success. In such a business environment, having the right skills can be the difference between success and failure. As 2023 approaches, it’s more important than ever to develop the right business analysis skills that will help you stand out from competitors and thrive in these uncertain times. With new technologies and approaches emerging all the time, developing the right business analysis skills has become more important than ever before. In this article, we’ll explore the top business analysis skills you’ll need to master in order to stay ahead of the pack. Find out how you can get ahead of the curve by acquiring these valuable skills now!

What is Business Analysis?

The term ‘business analysis’ is used in many different ways, but at its core, business analysis is all about bringing positive change, improving business performance with technology adoption, Process improvement and removal of inefficiencies in the cycle. It also encompasses improvement of revenue, market reputation, user experience, understanding how businesses work and how they can be improved. It’s about finding ways to do things better, faster, or cheaper.

Image Source – Freepik.com

Business analysts typically have strong analytical and problem-solving skills, and are able to see the ‘big picture’ while paying attention to detail. They need to be good communicators, great facilitators as well as collaborators, able to explain complex concepts in simple terms, asking the right questions and also be good listeners.

As businesses become more complex and the pace of change increases, the need for business analysts will continue to grow. If you’re thinking of a career in business analysis, or are already working as a business analyst, it’s important to stay up-to-date with the right skills, latest methods and tools.

Essential Skills for Business Analysts in 2023

As the world economy becomes increasingly volatile, businesses must be agile and adaptable to survive. Business analysts play a vital role in helping organizations in changing gears, understand and respond to change and adapt to the new business needs. In 2023, the most successful business analysts will be those who have developed the following essential skills:

Data Analytics: With the increasing amount of tech penetration and the huge amount of data available, business analysts are expected to be skilled to interpret, analyze data, see patterns in them and come up with actionable insights from them. To be able to do all this they need to be proficient in data analytics tools and techniques such as data interpretation and visualization. They will need to be able to not only interpret and communicate the results of these analyses to key stakeholders but also present actionable insights for strategic decision making.

Agile methodologies: Agile methodologies have proven to be effective in adapting to change, taking

frequent customer feedback and prioritizing delivery accordingly. And as a result, today more than 70% projects adopt agile methodology and their adoption will continue to grow. Business analysts need to be conversant with the principles of agile analysis and be able to work effectively within agile teams.

Financial Analysis: In a volatile economy, it is important for business analysts to understand financial analysis and be able to assess the financial impact of different business decisions. They will need to be able to evaluate investment opportunities, assess risks involved, and make recommendations based on financial data. They need to have the ability to know which are the initiatives that can help in quicker turn around for revenue and which changes can bring cost control thus making a better cash flow situation for the organization.

Strategic Thinking: Business analyst as a role requires higher level of thinking as well as attention to details to see the opportunities of improvement. Hence, they will need to be able to think strategically about the long-term goals of the organization and be able to develop plans to achieve those goals. They will need to be able to evaluate the potential impact of various business options and make recommendations based on data and best practices.

Adaptability: The ability to adapt to changes in their environment is a critical skill for success in a volatile economy. Business analysts will need to be able to quickly respond to changing conditions, be flexible to acquire skills to perform well in their approach to solving problems.

Cross-functional Collaboration: Business analysts are the change makers bringing positive changes to the organization thereby making the organization’s process faster and better. To achieve these objectives, they will need to be able to work effectively with teams from different departments, hierarchy, backgrounds, and be able to translate technical concepts and requirements into language that is accessible to a wide range of stakeholders.

Communication Skills: Business analysts are the ones who are required to influence stakeholders and users to come to agreement for the business decisions, and this requires being a great communicator. Effective communication is and will remain a critical skill for business analysts in 2023 and years to come. They will need to be able to clearly and effectively communicate complex ideas and data to stakeholders, and be able to negotiate and manage conflicting interests.

In conclusion, the skills that business analysts need to focus on in 2023 will continue to evolve, but the skills outlined above will likely be critical for success in a volatile economy. It’s important for business analysts to stay up-to-date about emerging trends and to continuously grow their skills and knowledge to stay ahead of the curve.

How to Safely Escape from the Assumption Trap in Requirement Analysis?

Written by Sumi Prasad on February 1, 2023. Posted in Articles.

There is a saying “Assumption is the mother of misunderstandings”. With that being said, it is common for business analysts to make assumptions to move forward with the requirements analysis. Because assumptions can help improve the efficiency and effectiveness of requirement analysis, reduce uncertainty, and identify potential risks, if not properly managed and communicated, It can become a double-edged sword.

Let’s evaluate,

What are assumptions in business analysis?

Assumptions are statements without evidence or verification that are accepted to be true.

For instance, assuming that the new software will be compatible with existing hardware and operating systems. Or assuming that the user will find the new feature easy to use or assuming that the product will meet non-functional requirements, such as security and accessibility.

Based on the business, context, time, customer, process, etc. assumptions can vary. Some examples include the following:

Assumptions about the customer: their needs, motivations, preferences, market segments.
Assumptions about the requirements/problem: nature, impact, pain points, tasks involved.
Assumptions about internal resources: culture, technical capabilities, time, budget, availability.
Assumptions about the solution: ease of use, UI design, technical constraints, functional and non-functional aspects.

What are the advantages of making assumptions in requirement analysis?

Enhance the efficiency and effectiveness of requirement analysis by focusing on the most critical and relevant aspects.
Ensure that scope is confined and complexity is avoided.
Provide better insight into the customer’s requirements. Considering different scenarios and making educated guesses can help in gaining a deeper understanding of the customer’s needs.
Create flexibility in the process of gathering requirements. As such, ability to adapt to changing circumstances and respond better to unexpected challenges and opportunities that may arise during the development process.
By documenting and communicating assumptions, stakeholders and team members can ensure that everyone is on the same page, making informed decisions.
Identify potential risks during the discovery phase and avoid surprises at the last minute.
Reduce uncertainty by allowing analysis to continue even if you don’t have a complete picture

What are the downsides of making assumptions in requirement analysis?

If assumptions are not clearly stated or communicated, it can lead to misunderstandings among stakeholders and team members. This can result in misaligned expectations and rework.
If assumptions are made with biases for example the business analyst assumes that the stakeholder has a certain level of knowledge or understanding, they may use technical language or make assumptions about the stakeholder’s needs without verifying them, which can cause misunderstandings of the requirements.
If assumptions are not clearly documented or communicated can lead to confusion and a lack of clarity about the requirements. This can make it more difficult for the product team to accurately plan and execute the project.
If assumptions are not properly addressed, it can result in incomplete requirements, which can lead to issues during the development phase. For example, if a key assumption is not considered, it could result in the development team building a solution that does not fully meet the needs of the users.
If assumptions are not properly managed, it can increase the risk of project failure. For example, if an assumption about the availability of resources turns out to be incorrect, it could lead to delays or other issues that impact the schedule and budget.

The above list of downsides is presented using an “If” statement intentionally in order to emphasize that making assumptions is not a pitfall but rather an important part of requirements analysis and gathering. It becomes a problem if not effectively managed and communicated with the stakeholders.

Business analysts should be explicit about their assumptions and verify them with relevant stakeholders. Various techniques can be used to accomplish this, such as asking questions, using user stories to describe requirements in detail, and involving the customers in the requirement gathering process.

Some tips for effectively managing the assumptions that you are making during the requirement analysis.

Spend time and critically evaluate the assumptions that you are making as you progress with the analysis.
Write down the assumptions that you are making in a concise manner at all stages. This will help to ensure that they are easily understood by others and can be referred back to later.
Make sure to communicate the assumptions that you have documented with the relevant stakeholders.
Review the assumptions that you have made to ensure that they are still valid. If any assumptions turn out to be incorrect, be sure to update them and communicate the changes with stakeholders.
Mention date when documenting the assumptions, which will help to review and validate the assumptions at later stage (E.g.: As of <date>, At the time of writing <date>, As at the <date>, At the <date> of writing/drafting/reporting).
It is important to be proactive in asking questions and verifying understanding, and to be aware of one’s own biases and seek out diverse perspectives.
There are times when assumptions are made unknowingly or by overlooking certain factors. It is possible to uncover such hidden elements through careful analysis and attention to detail. No matter how obvious and straightforward something seems, it still needs to be mentioned. In some cases, simple statements and questions can reveal hidden assumptions.
Make realistic assumptions. For example, assuming that the new product will be 100% efficient with no waste or errors is unrealistic.

To summarize, taking assumptions into account is an essential element of business analysis because it simplifies problems and accelerates analysis. Nevertheless, it is imperative to understand the pitfalls of assumptions and carefully consider their validity. Explicitly acknowledging, managing, communicating, and reviewing assumptions helps businesses minimize the risk of making inaccurate decisions.

Best of BATimes: BRD Vs FRD

Written by Arpan Rewatkar on January 18, 2023. Posted in Articles.

Documentation is the most important aspect for any BA.

The documentation is useful to depict the requirements and the detailed discussion about new features and change request if any. There are many different types of documents that a BA prepares. Some of the important ones are listed below –

Business Requirement Document (BRD)
User Stories
Use Case Specification Document
Functional Requirement Document (FRD)
Requirements Traceability Matrix (RTM)
Market Requirements Document (MRD)
Product Requirements Document (PRD)

Apart from these there are several other documents that is created by Business Analyst. It helps in understanding the business process and business events. A business events is a trigger that gives birth to the requirement. These requirements are then fulfilled by opting for IT solution.

Diagrammatically the documents can be pictured as a simple sheets of papers which contains some useful matter.

Let’s take a look at the similarities and striking differences between BRD and FRD.

Business Requirement Document

BRD highlights “Business Requirements” – i.e., high-level business goals of the organization developing the product or solution with the help of IT.
In other words it describes at very high level the functional specifications of the software
A formal document illustrating the requirement provided by the client
The requirements could be collected either by verbal or written or both
Created by a Business Analyst (usually) who interacts with the client
Entire work is executed under the supervision of the Project Manager
It is derived from the client interaction and requirements

The BRD is important since it is the foundation for all subsequent project deliverable, describing what inputs and outputs are associated with each process function. It describes what the system would look like from a business perspective. Following are the most common objectives of BRD –

To arrive at a consensus with stakeholders
To provide input into the next phase of the project
To explain how customer/business needs will be met with the solution
Holistic approach to business needs with the help of strategy that will provide some value to the customer

Basically, stakeholder’s requirements can be small or big. Thus it needs to be break wherever it requires and should be taken as multiple requirements.

Format of BRD –

There are many formats or templates that the organization follows. However, it depends upon the practices that is carried in the organization. For a product based company the BRD format is different as compared to service based firms. Standard format which is followed in most organizations are shown below. It is important to note that for clear understanding of the document we should include list of acronyms used.

The BRD template contains –

document revision
approvals
RACI chart
introduction
business goals
business objectives
business rules
background
project objective
project scope
in-scope functionality
out-scope functionality
assumptions
constraints
risks
business process overview (modelling diagrams for instance, Use Case and Activity Diagram)
legacy systems
proposed recommendations
business requirements
appendices
list of acronyms
glossary of terms
related documents

Now let’s try to dig more in FRD..

Functional Requirement Document

FRD highlights “Functional Requirements” i.e., functionality of the software in detail
Depending on the product, FRD document can be between 10 to 100 pages
It too describes at a high level the functional and technical specification of the software
Usually created by Business Analyst under the supervision of technical expert, for instance System Architect
In a small and medium sized organizations a BA take care of this
Few companies did not create FRD, instead they used BRD as it is detailed enough to be used as FRD as well
FRD is derived from the BRD

Actually, the process to reach the expectancy of the BRD is an FRD itself. Here an analyst after discussing with stakeholders and project manager ponder on questions like –

How we develop the expected requirement(s)?
What are the features and functionalities?
What are the tools and/or systems used and their dependencies?
How will the customer reacts when they start using the solution?
Any assumptions or constraints?

Most common objectives of FRD –

Depict each process flows for each activity interlinking dependencies
Holistic view for each and every requirements, steps to built
Estimating detailed risks for each new change request
Highlight the consequences if the project health is weak to avoid scope creep

The FRD should document the operations and activities that a system must be able to perform.

Format of FRD –

Likewise BRD, FRD has a somewhat different format focusing more on risks and interfaces. Although there is no such standard format that a Business Analyst should opt for. Companies belonging to different domains use their own template. For instance, you would find many points would be repeating as in BRD.

But there should be no confusion for BA to prepare this document.

The FRD template contains –

Introduction – It should contain Purpose, Scope, Background, References, Assumptions and constraints, document overview
Methodology
Functional Requirements
Modelling Illustrations – Context, User Requirements, Data Flow Diagrams, Logical Data Model/Data Dictionary, Functional Requirements
Other Requirements – Interface Requirements, Hardware/Software Requirements,
Glossary

Now the use of BRD or FRD in organizations depends on the organization policies, practices followed by the project team and stakeholders. As in my organization all projects are being hoped from Waterfall to Agile. If the stakeholders is positive with the documents then BA will design the same. But if there is a need for the continual delivery of working product then documentation will not be preferred.

However, documentation will remain a valid artefact of any project in distant future.

Published: 06/12/2017

An Introduction to Business Process Normalization

Written by Edmund Metera on December 22, 2022. Posted in Articles.

Business Process Normalization[1] is an analysis technique that leads to sound, modern business process and workflow structures.

Business analysts, process analysts, systems analysts, and process owners use Business Process Normalization to more effectively elicit, perceive, unequivocally define, and model sound, modern business process structures, and workflow configurations. Proficiency with this analysis technique benefits their process management, digital transformation, and regulatory compliance projects.

What is a Business Process Anyways?

For decades, business analysts, process analysts, and their projects’ stakeholders have tried to define business processes according to various characteristics. Business processes have been said to transform inputs into outputs. They can be decomposed into smaller parts. They start. They “flow”. They end. They have customers. They can cross organizational boundaries. They can be automated. They can be manual. They are measurable. While all those statements may be true, none of them are sufficient enough to elicit, perceive, and unequivocally define and produce high-quality business process structures.

There will be about as many points of view and opinions about what any business process is as there are stakeholders in that process, at least at the start of the process analysis. As always, business analysts and process analysts need to be able to consistently perceive processes and facilitate the journey of business process elicitation, definition, and modeling, with their stakeholders. However, the pace and the technologies of modern, digital transformation, low-code and no-code projects demand that business process and workflow elicitation, and definition be done in an efficient, competent way, instead of ad-hoc questioning and trial and error.

Times have changed

Traditional procedural notions and flowcharting notations have become archaic. They were invented in the days of procedural language programming – in the last millennium. Those notions don’t always work in today’s business and technical environments. Today’s distributed business structures (has anyone been working remotely recently?), technologies like the Internet of Things (IoT) and Edge, mobility, and cloud computing services have radically modernized the business process landscape. Today, a high-quality business process structure is one that has been conceived, structured, and can be readily configured as a modern, collaborating network of event-driven, outcome-oriented services, not just as a sequential procedure.

The Universal Business Process Definition

Let’s look at housing. Any house, no matter its scale, degree of abstraction, location, building materials, and all its unique details, etc. must have a foundation, walls, and a roof to be a house. If it’s missing any of those, it is not acceptable as a house. And for obvious productivity and quality reasons, those basic structural elements are established first, before it is practical to invest time and money in a home’s other architectural, engineering or construction refinements.

The same is true for business processes and workflow structures. Any business process must have a sound, cohesive structure of basic elements to be considered a business process. Its basic structural elements should be elicited and consensus reached, before pursuing all of a process’s possible details and refinements. Even after all desired process refinements have been applied, the process will still have its defining structural elements. This holds true for any process structure or model at any degree of abstraction (i.e conceptual, logical, or configuration), a process’ scale, or the unique details about a business process or workflow.

So, what are the basic business process-defining elements? Paraphrasing the Universal Business Process Definition[2], any business process (i.e., business activity for that matter) is 1) a repeatable collection of work activities, 2) initiated in response to a business event that, 3) achieves an expected outcome, 4) for a customer of that process. These four common-sense rules define all processes, workflows, and activities regardless of a process’ or activity’s scale, the process model’s degree of abstraction, the overarching project methodology, the modeling participants, and the organizations and the technologies that will implement the process or workflow.

Uses of the Business Universal Business Process Definition

Business analysts and process analysts use the Universal Business Process Definition’s four common-sense rules throughout their business process modeling journey and they work out and arrive at high-quality, robust, predictable, and operational business process structures. They use it to guide their elicitation agendas with business stakeholders. They use it to frame their observations of business processes. They use it to normalize what they and their stakeholders have named as candidate processes. They use it to resolve ambiguity among stakeholders and to organize business activities into the optimal, modern business process and workflow structures. This is akin to understanding and applying the Business Normal Forms[3], long used by business analysts and systems analysts to work out and optimally organize data attributes into entities and to produce high-quality relational data structures.

The resulting business process structures are high-quality structures because they have been elicited, perceived, and defined by asking and answering the right questions. They can be implemented equally well as traditional sequential procedures or as today’s, distributed business structures and networked technical (like cloud services) architectures. As event-driven, outcome-oriented business process structures, they are consistent with modern networked, collaborative business relationships and cloud technologies.

Business Process Normalization

Business Process Normalization is the analysis technique of testing the contextual meaning of a candidate business process according to the Universal Business Process Definition’s four rules.

A business analyst or process analyst need not ask a lot of questions to normalize a business process or workflow. They only need to ask a few focused questions (four in fact) and doggedly pursue and gain consensus to the four, sometimes-elusive, answers. The assumed basic structure of a business process will either be affirmed or restructured by the answers to the normalization questions. If any of the four tests have not yet been satisfactorily answered, then the analyst will need to elicit more clarity to satisfactorily answer the four process-defining tests.

Once all four tests have been sufficiently answered, the process has been normalized. Ambiguities have been resolved. A sound, fundamental business process or workflow structure has been understood. The answers to the four tests can then be used to write a contextually accurate, unequivocal, plain-language process definition. No two processes will likely have the same definition within the same domain of analysis. The normalized process’s defining structure will be the foundation of a contextually accurate, high-quality business process model, configured business procedure, or automated workflow.

Benefits of Business Process Normalization

The benefits of using the four-part Universal Business Process Definition’s rules and the Business Process Normalization technique are that they are relevant for today, it is efficient, it boosts contextual quality, it minimizes redundant and non-value-adding activities, it aids in well-written process descriptions, and it improves the potential for reusable business services.

Relevant for Modern Business Structures and Technologies. Processes that have been normalized according to the Universal Business Process Definition are event-driven and outcome-oriented. They are structured so that they can be readily implemented across enterprises’ geographies and boundaries. They are easily modeled using modern notations, like BPMN. They can be readily translated into modern networks of collaborating services (such as SaaS services in the cloud), just as well as traditional sequential procedures and workflow designs.

Efficient – Whenever discovering and defining business processes among a group of stakeholders, it’s more effective to be asking the right questions than a lot of questions. The Universal Business Process Definition frames the elicitation and normalization agenda with four simple questions. The process modeling work comes down to doggedly pursuing and getting consensus to the questions’ answers among the right business stakeholders.

Boosts Contextual Quality – Assuming that everyone will understand the same meaning for the name of a business process is insufficient. By normalizing a business process according to the Universal Business Process Definition’s four rules, the contextual knowledge and consensus about that process become unequivocal among readers of that definition.

Minimizes Process Redundancy. An enterprise may have different processes that do the same thing. They are just named differently. Any two candidate business processes that, through process normalization, answer Business Process Normalization’s four tests with the same answers are very justifiably two different names for the same process. They should be closely re-examined to decide if one of them can be, in due course, feasibly eliminated.

Minimizes Non-value-adding Activities. People, departments, and enterprises tend to propose or perform activities that they do, instead of what is needing to be done. The value of their activities toward achieving a process’ or workflow’s expected business outcome may be unclear. According to the Universal Business Process Definition, a process includes the activities that lead to a process’s expected outcome. Candidate activities that are not needed to achieve a process’s outcome should be closely re-examined and either be discarded, or they may belong in another process.

Aides in Well-Written Business Process Descriptions. The answers to the four business process normalization questions can be simply written in plain-language sentences to form consistently written, clearly written, and contextually meaningful, process descriptions. (Examples of such process descriptions can be found here.)

Improves Potential for Reusable Services – According to the Universal Business Process Definition, activities are themselves perceived and defined as event-driven and outcome-oriented processes. Each is defined in part and bounded by its initiating event and expected outcome. Because of this event and outcome-oriented structure, activities have the potential to be recognized as reusable services, which may be reused in more than one larger process.

Learn more …

You can establish or improve your business process modeling competence and learn the Business Process Normalization technique, by reading:

Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN, (Metera, 2018, 2022). This how-to guide’s topics include the step-by-step Universal Business Process Modeling Procedure, razor-sharp elicitation agendas, the Universal Business Process Definition, Business Process Normalization, basic and refined process modeling patterns using BPMN, and Universal Business Process Model Quality Checklists.

Find related topics at ProcessModelingAdvisor.com. The site’s purpose is to help you establish or improve your business process modeling competence. It includes articles, process model examples using BPMN, checklists, and access to out-of-the-box IIBA-endorsed and bespoke business process modeling training.