Tag: Agile

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.

[1] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera)

[2] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera)

[3] The Data Modeling Handbook (Reingruber and Gregory)

Good at Drawing or Good at Visualizing – There is a Difference!

Written by Line Karkov on December 15, 2022. Posted in Articles.

I often use simple diagrams and icons enhanced with text done with pen on paper instead of long presentations. It is a skill that I have practiced over some years now. Sometimes, colleagues tell me that I am good at drawing, but the fact is that I am not good at drawing. I am good at visualizing, and I am also fairly good at listening. This article is about what I mean by that.

Let me demonstrate with an example. The two drawings below are similar to two illustrations I did earlier this year. They are translated into English and made generic in content to make them understandable without knowledge of our business. I have also left out the detailed text that is included on the originals. Not only do they make no sense out context, but it also emphasizes the simplicity of the actual drawing.

Earlier this year, my manager asked me to do a drawing of our IT strategy. We work in an organization that is in the non-profit sector and we are not an IT organization. Out of 200 employees, 10 of us work with IT – all development is outsourced. The audience of this strategy was a management team where only my manager has a background as an IT professional. So, we needed to make it visual and easy to relate to. Part of our strategy is to rely as much as possible on software-as-a-service, so that we always have evergreen applications, and we don’t need to take care of upgrades etc. ourselves. “Evergreen” is a great image that is easy to understand and also easy to draw. I decided to include that in the visualization. When we talk about enterprise architecture and strategy, it is common to perform gap analysis and plan for closing that gap. A gap is also easy to draw. So, my first draft looked like the drawing below, with some text added on each side to about the goals of the initiatives and the applications that were impacted.

My manager presented this to our CEO, who said: “It’s a pit that we are filling with dirt?”. Having primarily worked in IT organizations, I have never questioned this metaphor of the gap. But he was right. When you think about it, it isn’t really that inspiring to just fill a gap. Ok, we needed something else. I have earlier used a Greek temple to illustrate IT architecture strategy. I like the comparison of solid, sustainable IT architecture with classic architecture with its timeless qualities. My first thought was an aqueduct transporting water to our evergreen application landscape. But I liked the idea of something that could transport our organization and was afraid that the aqueduct was too abstract. So, I decided to illustrate it with a bridge inspired by Roman architecture. The pillars of the bridge are made out of the initiatives on our roadmap. One pillar is made up of the initiatives for improving our services, and the other the initiatives for improving administration. Together, they will enable the organization to walk across from a withered to an evergreen field. That resulted in this drawing (again, with additional text next to the side of the pillars related to the goals):

This was the drawing that was presented to the management and later to the board. I think it is a better drawing than the first one and that is not because it technically is a better drawing than the first one. But because the metaphor was more fit for purpose. This is what I mean, when I say that my strength is not drawing, but visualizing. The ideas for how to visualize various topics comes from listening to how people talk about their work, the topic for the visualization, and the feedback that I get. You might notice that the first drawing includes seven initiatives, the second only six. This is an example of how the structure can sometimes dictate content. We had to prioritize and leave an initiative out that is more related to infrastructure but was included for its significant impact on business users.

Below is a drawing that my son Thorbjørn did recently. He is 10 years old.

I think we can all agree that he technically is better at drawing, than I am. Look at the facial expressions and walking legs as examples. So, just to emphasize the point even further: You do not need to draw as well as a 10-year-old to apply your drawing skills at work. You probably do to be a professional graphical facilitator, but that’s a completely different story.

As business analysts, many of us are well trained at visualizing. We use this skill when we do process maps, application landscapes, mockups, conceptual models or logical data models. Use this to your advantage, and you will find, that it is possible to learn the drawing skills that enable you to apply visual thinking in your business analysis practice.

Curious about visual thinking, but don’t know where to start? I wrote these articles last year, which might give you some inspiration:

Start your visual facilitation journey with letters. – Business Analyst Articles, Webinars, Templates, Jobs (batimes.com)

The icon library: My favorite analogue tool – Business Analyst Articles, Webinars, Templates, Jobs (batimes.com)

Avoid Illusory Constraints And Incentives

Written by Adrian Reed on November 23, 2022. Posted in Articles.

If you were learning to drive in the UK, chances are you’d get in touch with a driving instructor. Over here, many of the driving schools they work for have company names starting with the number 1 (often ‘1st CompanyName Driving School’). I suppose if I were a driving instructor my default company name would be “1st Reed” or something similar.

It might seem curious as to why there are so many driving schools with “1st” in their company names. We might assume it’s a signal that people who learn with them pass their driving test first time… but I suspect there’s another legacy reason, which goes back twenty years or more. You see, when I learned to drive, you didn’t Google a driving instructor, you used the Yellow Pages.

For anyone unfamiliar with the Yellow Pages, it used to be a thick local telephone directory of different companies. It probably still exists, but twenty years ago it was an essential reference for every household and could usually be found close to the (corded) landline telephone. It was printed on thin yellow paper, and had thousands and thousands of companies listed.

You’d search for a category (‘driving instructor’) and then (with the exception of paid ads) the companies were generally listed in alphabetical order. And company names starting with numbers were given preference, so a company named “1st Aardvark Driving School” would be listed above “Aardvark Driving School”… hence the incentive to start a company name with the phrase “1st…”.

The Constraints and Incentives Of Yesterday Might Be Irrelevant Today

Today, I would guess that very few people search for a driving school using a paper telephone directory, so this necessity to preface a company name with ‘1st’ is no longer valid. Not only this, it could actually hinder findability…. Imagine if you heard somebody say their company name was “First Reed”. Would the URL be 1stReed.com, FirstReed.com, First-Reed.com, or something else? What keyword would you type into Google to search for them?

I wonder if issues of ‘digital findability’ might also start to affect musicians. With more and more people using voice-activated assistants, bands might get more airplay if they have a band name and a song name that is “voice assistant friendly”. Don’t believe me? Try to get an AI assistant to find music by 90s band Campag Velocet and you’ll likely see the problem.

The point here is that constraints and incentives of yesterday (“We must start our company name with ‘1st’” or “Unusual band names sell records!”) might actually be disadvantages today. The incentives and constraints have changed, and those that recognize that can use it to their advantage.

What This Means For BAs: The Importance of Healthy Challenge

This is where good business analysis helps. It often feels that there is a human tendency to revert-to-norm and to “do what we’ve always done”. In our world as BAs, this might relate to the way work is undertaken, the way a process works, or the way that technology is used.

In these situations there is a huge opportunity to tactfully challenge: to ask does it still need to be that way? And also ask what are the implications if it is implemented that way? Are we ‘baking in’ a constraint that is no longer relevant?

This starts by identifying those tacit assumptions and constraints and seeing whether they are really still valid. Techniques such as ‘five whys’, the brown cow model, or just informally asking questions with curiosity and listening deeply to the response can help a great deal.

Whichever techniques we use, having the confidence to build rapport and tactfully challenge accepted practices is key. Sometimes there might be a valid reason for the status quo… but if there isn’t, we might be able to help co-create a better way with our stakeholders. And if we can create something better, cheaper, slicker, better… that has to be a good thing!