Tag: Methodologies

BRD Vs FRD

Written by Arpan Rewatkar on December 6, 2017. Posted in Articles. 1 Comment on BRD Vs FRD

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.

It’s Beginning to Look a Lot Like Collaboration!

Written by Tom McIntire on December 5, 2017. Posted in Articles. 1 Comment on It’s Beginning to Look a Lot Like Collaboration!

Collaboration is one of the most difficult actions we complete in the Business Analysis world.

Working with stakeholders can sometimes feel like a grueling task after weeks of meetings leading up to requirement approvals from stakeholders. I have discussed this topic in previous article I’ve written, but today I’d like to discuss collaboration among other Business Analysts when working on a project that involves multiple authors or writers of the same set of requirements.

In my experience as a business analyst the majority of the work I have completed involves a single business analyst assigned to a project, however, there are some projects that I have worked on that are just too large for a single business analyst to be involved and there are often 2-3 other business analysts working together to meet the project goals. This process can just as complicated as working with other stakeholders on a project. Opinions are many and voiced often. Temperatures run high at times. In the end, strong collaboration surpasses these complications and the end goal is achieved.

Below are some methods or techniques that I have followed over the years to help guide this process:

Plan, Do, Review, and Improve

The four phases of this technique – used to coordinate and publish complete and consistent requirements – are detailed below.

	Phase	Description
1	Plan	The architect or group of authors plan the work to be done once the high-level requirements (HLRs) have been defined. Planning includes the following: Determining and agreeing upon the HLRs for the project. Assigning HLRs or sections to the various requirement authors. Determining the structure in which to write the requirements. Determining a timetable to complete the various sections of the requirements.
2	Do	The authors create all functional requirements that lie within the HLRs or sections assigned to them.
3	Review	The requirement authors review each other’s work. They read through the requirements as if the subject matter were new, asking open-ended questions such as “How does this functional requirement connect to the scope?” and “Why is this requirement important to the scope of the project?”
4	Improve	Consider and implement the suggestions and comments received from the other requirement authors. Requirements should be improved through editing content, grammar, and requirement structure. Note: The Architect will be accountable for ensuring updates are made accordingly.

Requirements Workshops

Requirement Workshops can be very effective for gathering requirements. They are more structured than brainstorming sessions, and participants collaborate to document requirements. A workshop is an effective technique when there is more than one analyst working on gathering and documenting requirements through facilitation and documentation.

Through these sessions both business unit and development subject matter experts (SMEs) collaborate to define and review the business requirements for a system. This allows the two parties to resolve any differences of opinion regarding the design.

More information on Requirement Workshops may be found within the IIBA BABOK V3.0 Guide.

Architect

The architect of a project is responsible for the Requirements Architecture as a whole. He or she will own the role of owner of the requirements.
Responsibilities include:

Determine completeness of the requirements.
Determine consistency of the requirements.
Determine the requirements align with the scope of the project.
Determine the structure of the requirements adhere to the guidelines that your company has set for requirements writing and documenting.
Coordinate with the other requirements authors.

Additional Techniques

Additional techniques for collaborative writing can be found in a number of ways:

Printed and online publications specializing in Business Analysis.
Online academic or scholarly articles from leading business universities.
Industry leading conferences such as ones through the IIBA.
Industry leading webinars from sources such as the IIBA and Bob the BA.

Learning about Business Analysis through the Ages

Written by Éric Provost on November 23, 2017. Posted in Articles. 1 Comment on Learning about Business Analysis through the Ages

Business Analysis is often seen as a young domain of expertise trying to establish itself in the workplace.

Ask two BAs coming from different organizations what their job is about, and you’ll probably get two very different answers.

However, they will probably have one point in common: they will be in the IT department of their organizations. The fact is that Business Analysis is strongly associated with technology these days, although the IIBA definition of it doesn’t talk about technology at all (ie Business Analysis is “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders”).

When you think about this definition, Business Analysis is probably around since humans started to work together toward a common goal. While I was binge-watching the latest season of Game of Thrones, I tried to imagine what Business Analysis might look like in the past, and what we could learn from that.

Business Processes were supporting organizations

Back 500 years ago, running a mill wasn’t an easy job. The miller’s family has to handle many physical tasks, like handling freshly harvested wheat bought from nearby farmers; filling the mill with cereals to make flour; extracting flour from the mill; storing the flour; shipping the flour to the town’s market. Like if it wasn’t enough, they also had to take care of the raw material buying activities, the cash flow management, the selling activities and the after-sales service. Luckily, families were quite large back in the days.

All activities had to be perfectly orchestrated in order for the mill to generate enough revenue for the family. When a problem arose in any of these activities, the family would gather in order to find a solution and bring the processes back on track.

Without such a structure, the mill wouldn’t work as well, producing less flour, and would be able to support the miller’s family.

Information Systems existed… without shiny technology

How does the miller know he has to make more flour? Orders were probably made by his customers that day at the market (the baker from Main St. is a very good client). This information can be used to orchestrate all the production activities at the mill, in order to fulfill these orders. The miller’s wife holds a detailed log in order to keep track of what needs to be delivered to who, and who paid (or not) their flour orders.

Their processes are relying on this information in order to stay efficient. This isn’t surprising, as business processes need information to be executed. This information can be the required input of some activities or can be used as a way to coordinate signals between activities (ex: you need an order to be able to fulfill it).

Without such information, the miller could either make too much flour and ruin the wheat harvest, or don’t produce enough and miss the opportunity to accumulate more money for the bad days. Their low-tech order log was critical for their survival.

Making Business Analysis better by learning from the past

As you might have figured, Business Analysis was relevant to the miller’s organization and raised similar considerations as one would encounter today. Performing the same exercise with other organizations through the ages would probably lead you to acknowledge the same facts.

The amazing thing is that none of these organizations had access to modern technology such as the Internet, electronic devices nor the cloud to support them. Yet, a Business Analyst could have been useful for all of these organizations.

How can we learn from that now that we’re in the 21st century?

There are solutions based only on processes and people improvements. Answers to business problems & opportunities can often be found without using technology. Moreover, these solutions can often be implemented faster than by relying on technology, making them interesting for proofs of concept, or in situations when a business case might not justify a technology-heavy solution.
Information management doesn’t always require technology. Business processes need information to work properly, but this information doesn’t have to be stored in a centralized database or available through a self-service platform. Even if the cost of data storage is lower than ever, in many cases, a simple Excel file, a Sharepoint list or even a paper-based register in a physical binder might be enough to meet the needs of your stakeholders in smaller organizations, or to support a proof of concept before scaling it up in a larger organization.

While these solutions are not always easily scalable (which might be a requirement by itself), not focusing at first on technology could help the business be more agile at a lower cost. Moreover, they will emphasize the importance softer Business Analysis skills to better deal with the impacts on people involved in these solutions.

In the end, it all comes down to finding the best solution to answer all your stakeholder’s requirements, with or without technology.

Functional Decomposition: What Have You Done for Me Lately?

Written by Tom McIntire on October 18, 2017. Posted in Articles. 1 Comment on Functional Decomposition: What Have You Done for Me Lately?

Oh no! Functional decomposition!

It sounds like an evil villain from an elementary school play like tooth decay or gingivitis. Actually, functional decomposition is a BA’s favorite tool. If you haven’t heard of it then you are in for a treat. If you have heard of it, don’t worry there is a still a great lesson to be learned in the following article.

Functional decomposition, according to the BABOK, “Helps manage complexity and reduce uncertainty by breaking down processes, systems, functional areas, or deliverables into their simpler constituent parts and allowing each part to be analyzed independently” (BABOK, 2016).

You may be asking yourself, “What does this mean for me?” Functional decomposition is used to break down a complex process in order to capture all the needed requirements for a project. If you use the tool properly you will be able to break down all the functional areas in order to provide more complete project estimates and requirements.

I have used functional decomposition throughout most of my career as a BA, but sometime in the past few years I stopped using it as I had access to various project management and requirement documenting tools that assisted with the process of gathering requirements and project estimation. The problem is that there wasn’t a real functional decomposition occurring and my projects suffered for it.

It wasn’t until a year ago, after speaking with Bob Prentiss (www.bobtheba.com) through a seminar that I realized what was missing from my routine and could increase the accuracy of my estimates for my projects as well as assisting in avoiding missing requirements. Bob unlocked this part of my brain that had been shut off temporarily almost like a code word in a spy novel to unlock hidden abilities in an agent or in my case hidden potential.

Using something similar to the following diagram you can take your main project and break it down into its functional areas or your requirements.

Notice how the project is broken out into its various functions? Then each function in turn may have sub functions. I prefer to label my items using either color codes or in the example shown number codes. This way I can see how my requirements will flow through my requirements documentation and aides in traceability. I know that I have a Function 1 and that function has Sub Function 1.1 and Sub Function 1.2 helping me in documenting all requirements and aiding me in preventing missed requirements.

The lesson to be learned is to not forget about the available techniques and tools at your disposal when working on a project. We can easily get side tracked by timelines or stakeholders requesting for updates and immediate results that we forget to slow down and use every appropriate tool or technique at our disposal. We need to take time to plan out our requirements in order to provide a better end product. We should be saying to ourselves “Functional decomposition: What haven’t you done for me lately?”

11 Considerations to Help in Make Better Business Decisions

Written by Richard Lannon on September 28, 2017. Posted in Articles.

Recently I had the opportunity to present Making Better Business Decisions at a Project Management and Business Analysis World Conference in Winnipeg, Manitoba.

A topic close to my heart, since I focus on helping business leaders and professionals build business brainpower, make better business decisions and establish a common direction using strategic planning and business analysis best practices.

The interesting thing about this topic is that there are so many endless possibilities when talking and writing about making better business decisions since there is so much information available on the topic. Here are 11 points from that presentation.

Beliefs get in our way.

We tend to think we are better at making decisions than what we are and time and time again demonstrated as fact. We now know that decision making is more of a cognitive process resulting in the selection of a belief or a course of action among several alternative possibilities. Often our decision is influenced by a set of beliefs, values, and attitude. Research shows that we can be really bad decision makers.

That’s illogical Spock.

Sometimes when we look at all the facts and the right decision is an only common sense we tend to make poor decisions. For example, a cab driver will drive their cab less on poor weather days when they have more fares and more on warm weather days when they have fewer fares. The logical choice, drive more on bad weather days to make more money. The reason, a decision ceiling, and culture. We all have one. Know yours.

Factors affect decision-making.

Many factors that impact decision-making. They generally can be listed as workplace trends, technology, and culture. We have all seen the squeeze on in workplace trends; smaller business units, flexible work organizations, shared service and gig economy. Technology always changes; business intelligence, artificial intelligence, and expert systems are altering our approach to decision-making. Culture is always a factor yet sometimes left out of the equation. Depending on the part of the world you live in; decisions are based on speed, decisiveness, individualism or groupthink, organic and an all-for-one approach.

Thinking fast and slow.

I wish I came up with that phrase. But I didn’t. It is from a book by Daniel Kahneman, a 2012 Economic Nobel Prize Winner. It states that the decision brain has a system one and a system two. System one is intuitive, fast, automatic and instantaneous. This system has a lot of influence, guides and steers our lives. System two is slower, rational, logical and analytical. Deliberation and reasoning are its hallmarks. Traditional economists modeled saw people as rational, selfish, with tastes that don’t change much. Kahneman discovered is that we are neither fully rational nor completely selfish and that peoples tastes are anything but stable. System one and two are at odds with one another. Often taking a risk when we shouldn’t. It is worth reading his book, Thinking Fast and Slow to understand the brain in the decision-making process. Especially since in business analysis we often use decision-making models, approaches, and tools to help make decisions.

Models help in the process.

Anyone who knows me, know I use the setability model for planning, analysis, and decision-making across impact zones (see S.E.T. for Success, pp 17). I think models are an important factor in making decisions. Every organization or client I have ever worked with either have models they use in decision-making or they need them. As a professional, who uses business analysis, your job is to provide a model or find out what should be used in the business environment you are in and apply it. Having a standardized decision-making model is a positive benefit to the organization as it provides consistency. It is important to be able to adapt and change your model as things change in the business climate.

It’s all in the approach.

Related to models, your approach to providing solutions. In my presentation I mentioned that are many approaches to use (from 5, 7, 10, 12 step processes) that can be summarized in four steps; define, choose, implement and measure. Defining has to do with framing a problem or opportunity. Framing often has to be done well as it is the difference between seeing the glass as half full or half empty. To choose is to have a choice. With business analysis, the three option choice applies (do nothing, do something or do something else). Implementation comes down to your planning approach (predictive or adaptive). Finally, measure gets down to key performance indicator. It is about knowing whether you will or if you did achieve the result based on all the decisions made.

Critical thinking tools.

We all need tools in our toolbox and decision-making has a lot to do with having the best tool to apply in making key decisions. Most websites provide the same tools when you are seeking something to use to make decisions. They include; swot, pest, pros, and cons, and cost-benefit analysis.

If you do not know how to use these tools you should work on leaning them. They are the standards no different than having a hammer, a saw, measuring tape, level, and pencil; They are tools of the trade.

Confidence gets in our way.

Back to the brain and the way we think. It is thought people fail to take into account complexity and that their understanding of the world consists of a small and necessarily un-representative set of observations. Furthermore, the mind does not account for the role of chance and therefore falsely assumes that a future event will mirror a past event. For example, to use a phrase, my Dad would say, “they are just throwing good money after bad.” In other words, when we have sunk costs we tend to put more into a bad situation, we take higher risks, and we gamble more. When what you see is truly all there is, there is nothing more. We will hope for different results. We become overconfident. The only way to guard against this is by doing your due diligence.

It is an Illusion of control with a planning fallacy.

We all have optimism and loss aversion bias where we think we have greater control over our lives than we do. Something called the illusion of control. The examples cited include people believing that they are less at risk of being a crime victim yet live in a high crime area, smokers believing that they are less likely to contract lung cancer or disease than other smokers, and traders who think they are less exposed to losses in the markets. In this case, we overestimate the benefits and underestimate the costs. The key is to be more mindful of the decision-making process.

Overcoming positives and negatives.

Decision-making is tough because we have the deck stacked against us for making better decisions. There are some things we can do to solve the decision-making challenges. We can be more mindful of our choices. In our organizations, we can embrace the diversity of decision makers and create decision committees. We can have designated decision driver with someone who has no impaired judgment since the decision is irrelevant to them. Finally, we can create control limits on decision-making and obey the decision-making rules.

Final Thoughts.

This article is just a summation of a presentation I did on making better business decisions and outlines the challenges I see in organizations and people in business today. Given some constraints we have today (time, money and resources) there are things we need to do so we are making better business decisions. We could design organizations for decision-making, create decision-making rules and guiding principles, establish flexible decision makes and a common decision-making language, seek to guard against over-confidence and optimism bias and maybe get a coach, a mentor or a decision group for those more difficult choices. Good luck.

Remember, do your best, invest in the success of others and make your journey count. Richard.