Tag: BPM

Storming the Brain

Written by John Vaught on February 7, 2019. Posted in Articles.

You’ve been to a meeting (or twenty) in which the leader tells you that the group is going to brainstorm.

There are rules to storming, of course, which are things such as:

Put all the ideas out there first
Everyone contributes
Pretend like what you just heard was not a dumb idea

If you find yourself in a meeting like this, you can have some fun by asking quirky questions to appear smart in brainstorming meetings:

Shouldn’t we be asking if this ask is the right ask?This seems like a pivot.
But how is it disruptive?
Is this the future?
What’s the big Win?
Isn’t that putting lipstick on a pig?
How does this fit into the roadmap?
We have the cake, but the cake needs sprinkles. What are the sprinkles?
Is it too disruptive?

Sure, you’re going to get some looks when people figure out what you are doing, but that’s because this is the best way to get creative ideas on the table. Grab a group, throw out as many ideas as possible without any judgement, and then crazy creativity happens. Right?

Not according to this article, which boldly states that “Brainstorming is Dumb.”

But it turns out that brainstorming is actually a terrible technique—in fact, people generate fewer good ideas when they brainstorm together than when they work alone.

Alex Osborn came up with the “brainstorming” method in the 1940s and it has now become ubiquitous; few people are asking if it actually works. Turns out that it has the opposite effect – you turn out better ideas alone than using this method. Paul Paulus, a professor of psychology at the University of Texas at Arlington, has this to say about why:

“Brainstorming is a complex process where people are trying to listen, think, add, collaborate, build. It’s cumbersome, it’s difficult psychologically, and people don’t do it very well.”

You may be thinking – why didn’t someone tell me! Well, they have, since as early as 1958.

If it doesn’t work, for goodness sake people, let’s stop doing it! Let’s get real about creativity – it rarely happens at the drop of a hat or because we throw ten people in a room. Creativity is hard work, and it can take time and deep thought.

So does this really mean that I should ignore everyone else and rely on my inner creative genius? Well, sometimes.

SOLUTION #1: IGNORE RULE #1

One study found that should do the opposite of the one thing that Osborn thought was the most important – feel free to debate suggestions as they come in. Criticism is often thought of as a creativity killer, when in fact the studies consistently find that debate lifts ideas and brings up more and better alternatives and as well as diverse ideas.

“In a way, the power of dissent is the power of surprise. After hearing someone shout out an errant answer, we work to understand it, which causes us to reassess our initial assumptions and try out new perspectives.”

This also says something about the mix of people that are best at having these kinds of debates. Those who are strangers do not have the comfort to truth, but those who are too comfortable with each other do not push into new areas. Some familiarity mixed with some newness can provide a freshness, if you know what I mean.

SOLUTION #2: DON’T CREATE A #2

One study looked at the results provided from three-person groups performing a complex problem-solving task. Using the Osborn form of brainstorming you would think that the group that collaborated the most had ideas that were more than the sum of their parts. Wrong. That group had the most mediocre results; this shouldn’t be too surprising when you consider that group dynamics will often bring results back to the average. The other result isn’t too surprising either – the groups with no interactions had some of the best results; but they also had some of the worst. Working alone produced results all over the map.

Here’s where you need to pay attention: the group that interacted intermittently had the consistently best results.

The right mix of individual effort, in deep work, with some group interaction will generally produce overall better results. I know that didn’t rock your world. Of course, you are thinking, I just wasted ten minutes of my time to read about something I already do.

But here’s the kicker – you probably aren’t using the right mix. Most of us are using the mixer when we should be cooking, and vice versa, ending up with scrapple on your plate…

Your most creative work is when you are blocked off from other people and can truly concentrate. Your best time to contrast and compare to make the ideas better is when you are collaborating.

The Problem = we are entering a world where it is getting harder and harder to block off interactions, so we are consistently putting ourselves into the group that produces mediocre results.

Pessimism, a Business Analysts Good Trait

Written by Nicholas Zipp on June 21, 2018. Posted in Articles. 1 Comment on Pessimism, a Business Analysts Good Trait

When most people experience a beautiful sunny day, they think to themselves, “Wow, what a great day!” But to me, a pessimist at heart, I think, “What about my garden?

This sun and heat are going to wilt my flowers and give me a sunburn on top of that!” Is pessimism a good trait for an analyst? Is it wise to put someone whose instinct is to jump to the negative or be nitpicky in the BA role? Would not being an optimistic person be a better fit for a company in need of an analyst’s help? It seems to go against what I, and probably many of you, think would be a bad trait to have but I believe I am a great analyst because of it.

Naturally looking on the flip side, I prefer not to say downside or negative, has it benefits. After all, is it not part of being a good Pessimistic BA (PBA) to look for gaps and to see where processes have gone down the wrong path? How many times have you been asked to gather requirements, only get vague answers? It is not only about asking why, who, what, where, and when?

Analyst. That is our title, it is our mission to analyze.

As a PBA you instinctively dive into what is not being said. “Oh, we are needing to install this XYZ software. Should not be a problem.” Well a PBA might say to themselves, “I bet they are running another competing software and probably did not even bother to make sure that this new software is compatible with their current and legacy systems.” So you start asking questions pointed towards these possible issues. They may or may not result in an issue, but the more everyone in the group talks, the more nagging questions come to mind.

There is a term that I have come to use; strategic pessimism. Strategic Pessimistic Business Analyst; sounds good to me. What is this, what is the idea, and how does this apply to the PBA? Imagine or just remember a time when a stakeholder came to you, asking the world, at the highest priority, and with an astounding three day deadline. Been there? I would guess we all have been.

The first goal is to reassess their priority, that impossible deadline, and must haves. The goal of strategic pessimism is to weed out the must haves to a list of true must haves, should haves, and would like to haves. This is called lowering or making the real expectations known. Contemplating the flip side to the request/project, you help to provide outcomes and plans to deal with any if….thens. Doing all these things tactfully will make realistic expectations and lower anxiety.

Of course, this is not only limited to vetting business processes but to every aspect of the PBA. The PBA loves Epics, User Stories, and Use Cases. I was recently a part of a continued education class when a BA wrote a User Story. The team thought it was a good story. As a PBA that “something does not seem right here” feeling came about me. Starting to rattle off multiple User Stories, branching out from the groups original User Story, effectively turning that Story into an Epic. Instead of a simple example, more work was created. Needless to say, I was not liked that much at that moment. Those questions that run through the PBA’s mind may be adding to the workload but it uncovers needed answers to the possibilities that would otherwise lay resting until discovered after deployed.

Now it would seem that a PBA would not fare very well talking to people. After all great communication is a huge part of an analysts work life. You get better responses by being firm but nice; making that small chit-chat before getting down to the issues at hand. Being a PBA does not mean you do not like to talk to people or that you love to hide in your office with your door closed. If you are an analyst, of any type, by definition, you love to get out and talk to people.

How many times have you followed up with a stakeholder and they said they would get that information to you later today? Did a little voice in your head scream, “I bet I am going to have to follow up with them by end of the day; they will probably forget or avoid it.”? That is the PBA at work. I have such deep hope for them to get back to me; sometimes they do but sometimes they do not. But it is that question that rages up in your mind that keeps you in focus; keeps the project from getting away from you.

Rather it is pessimism or through learned behavior, we learn to read people and anticipate the coming possible roadblocks. We look for undesirable and unthought of outcomes, eliminating unrealistic expectations, and all while helping to deliver the best product possible.

Maybe being pessimistic just works for me and other PBA’s. Maybe being optimistic could be even better or the same. But I truly believe in the end we all have a little pessimism in us. Embrace the flip side!

How I used Five Whys

Written by Sudha Ganesh on February 27, 2018. Posted in Articles. 1 Comment on How I used Five Whys

The Business Analysis Book of Knowledge (BABOK) from IIBA describes Five Whys as ‘a question-asking process to explore the nature and root cause of a problem.’

Although the Five Whys technique has its origins in root cause analysis for problems, it is also a great tool to gather information and learn a new business, project or process.

Two years ago, I joined a new company as a Senior Business Analyst. I was charged with supporting a critical business unit in an intense, fast-paced environment where all documentation was out of date. In a short period, I had to learn the business unit comprehensively: processes, people, and technology. The role was a huge leap forward for me; I became overwhelmed and anxious in the first few weeks.

Here is how the Five Whys technique rescued me.

I started with five basic questions about my business unit

What does the business unit (BU) do?
What are the critical processes within this BU?
What applications does this BU use?
What systems are upstream to this BU’s systems and what systems are downstream?
What are the biggest pain points for this BU?

For each of these questions, the first answer I got was one or two statements. To each answer, I posed a ‘Why’ iteratively, which built up on information I was receiving. After an average of five times of asking Why, I was able to get coherent and detailed information for each original question.

For example, take the first question:

What does the Business Management business unit do?

Business partner answer: ‘We analyze dealer financial data and report on corporate and dealer performance.’

My 1st Why: ‘Why is this analysis important?’

Business answer: ‘After our analysis, we send several types of reports to four major departments: C-suite Leadership, Market Representation team, Incentives group, and Field Managers. Other groups may request analysis and reports from us from time to time. If we have not done it in the past, we do the needed research and report on the analyzed data’. The business partner then went on to describe the various reports that they send to each department.

My 2nd question was a disguised-Why: ‘What happens if C-suite does not get the results or reports promptly?’

Business’ answer: Leadership needs Corporate and Dealer Performance reports (CPR, DPR) to assess profitability, year over year performance, Financial Trends, specific Business Center performance, etc. to keep a finger on the pulse of business as it is happening month-to-month. Without visibility to this key data, leadership cannot make decisions in time that will avert danger or to capitalize on opportunities that are opening up. Leadership uses our data to meet Legal and Regulatory requirements as well, such as create annual reports, releasing information to the board of directors, stakeholders or the government (in enquiries). Business went on to give more details on how the Business Management group’s analyses are used.

My 3rd Why after I reviewed the DPR: ‘Why is this DPR of value?’

Business went on to explain how this report is primarily used by Field and the Market Representation team to drill down into the reasons as to why one or a group of dealer(s) are not meeting sales targets and how to help them improve. Do they need more training? Are the facilities well kept? Is the dealer spending enough on marketing? Is the demographics of the area changing? Should we prepare to terminate this dealer? There could be a slew of other questions, depending on the Sales Locality and Trade Zone of the dealer.

My 4th Why may have been to learn terms specific to the business unit or learn about calculations used by the business or in the reports. I could also get the reason as to why a parameter is being calculated. In some of these conversations, we uncovered that a few calculations were being done in a manner different from the guidelines of the benchmarking organization. Therefore, for these parameters, comparison with a competitor was akin to comparing apples vs. oranges.

If I got all the information I need before the 5th Why was reached, I might have used it to ask “Why don’t we go for lunch now?” Just kidding, but you get the picture. I can say this, though: it is important for a BA to ask Whys creatively instead of strictly follow a technique with the word ‘Why’ prefacing each question, which will get monotonous.

At the end of four weeks, using the Five Whys technique had tamed my fear of the new role and helped fill what seemed like large shoes when I first joined. It was a relief and a feeling of triumph to establish my credibility in both IT and the business unit. In the role of a Business Analyst, all of us want to learn and have to learn rapidly. Knowing about a technique is of little use to us unless we find a way in which each of us can customize it to fit our individual need. Also, remember – there are no limits on what technique you can use in which phase of a project or program. Wish you the best in finding your favorite technique.

Business Process Modeling

Written by Arpan Rewatkar on January 10, 2018. Posted in Articles. 1 Comment on Business Process Modeling

A Business Analyst is the core member of the project team. He is a star of any project. He is a friend of business.

He resolves complexity. He offers solution. He mitigates risk. He delivers value to the customer. In any project a ‘Value’ can be defined by two aspects –

Value is

fit for purpose (is the value delivered satisfies the business need?)
fit for use (is the value delivered correct?)

But delivering value to any stakeholder is not an easy task though. However a BA can build and maintain trust by delivering ‘work samples’ to stakeholders. Here work samples can be referred to any screenshot of the working product or it could be a trial version et cetra. A BA should be vendor neutral in order to maintain transparency among other team members and stakeholders.
In other words a BA should model the requirements and should model the process. How the process works in an organization and what needs to be done to improve the current process. Thus, a concept of Business Process Modelling (BPM) came into existence. Let’s try to figure out BPM.

BUSINESS PROCESS MODELING

Business process modeling (BPM) in systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed or improved.

It is performed by –

Business Analyst
Subject Matter expert (SME)
a team comprising both

(source – Wikipedia.org)

First we need to understand what a process is. A process is flow of events that occur in any business to gain monetary benefits without considering risk and losses. These risk and losses are not owned by the stakeholders. To model these processes for the benefit of business needs is a prime responsibility of a BA. Thus we can summarize by the figure that follows.

You can see that in a business process which is triggered by some business event has inputs like resource and information which gives rise to certain requirements. An actor could be anyone that initiates the business event which realizes the need of something. It could also be an issue that gives rise to the need to either improvise the current process or improve it. A business process should then satisfies the goals and some output which offers value to the stakeholders.

In other words, a Business Process Modeling is a set of activities that describe the order of activities from start to finish with some input and some output correspondingly. A BA can consider the business process model is the final output to meet business needs.

Components of Business Processing model includes –

a goal – every business process has a number of goals to achieve, these goals need to be able to meet business needs
input – input could be use case stories, product backlogs, requirements which are elicited, analyzed and validated
Message (information) – messages are used to complete the activity. In the business process, the message is not consumed, but as part of conversion process. There are various sources from where the messages are generated for instance, external resources, customers, internal organizational units and even other processes.
Resources – it can includes the staff, the machines and other architecture. Unlike the message, the resource is consumed and could be exhausted.
Output – each business process generates some outputs that meets the business needs. The output could be either physical object (for instance, a report or an invoice) or it can be the end of the entire business process.

In modelling language, the stakeholders are referred to as the actors. They can be a person, department, system, or an external entity to the organization. Few are the benefits of Business Process Modelling –

Ensures you understand how an organization runs & performs activities, and relates to the outside world
Identifies areas that are not well understood
Helps identify complex business processes
Helps with the training documentation

BPM Tools

There are 4 different types of tools used in Business Process Modelling –

Context Diagram – These are the high level framework of the interaction of the organization with external entities. Below is the sample context diagram :
a typical contextual diagram
It represents the flow of events with supplier and customer as an external entity. It illustrates the interaction of these entities with the restaurant.
Functional flow diagram – It is a step by step process which depicts the system’s operational flow. Also referred as block diagram. Below is the sample one indicating process step by step –
functional flow depicting each flows
We can see all the possibilities and assumptions have been considered in functional flow diagram. It could be under same department or multiple. But the separation can’t be seen.
Cross Functional flow diagram – Process flows are segregated within different aspects. Here it could be different departments or operations. In manufacturing industries the design department is different, assembling department is a separate entity and finally the testing department is altogether one. But the process flows are interconnected between all these different departments. Have a look at the below sample –

Cross functional-purchasing item sample
Here you can see processes are been transitioned from customer to sales department. The sales department contacting the warehouse for checking the availability of item and finally customer service for after sales support. Also referred to as ‘Activity Diagram’ and ‘Swim-lane Diagrams’.
Use Case diagrams – These are the user perspective modelling diagrams used to model the interaction of the user (actor) and secondary actor with the system. It represents only positive flows, no if-else statements and no negative flows. It is one of the most important tool for Business process modelling. Elements of Use Case diagrams include Actor (Primary/Secondary), use case(s), association, system boundary, system clock. Below is the sample-

use case-sample

Here a customer (actor) using ATM banking system (System boundary) for withdrawing, depositing money and checking balance (use cases).

A BA should note that he should use BPM tools to model the requirements. Thus modeling approaches should be

easy to read
capture the processes
be a foundation for other models
should represent the current state

The way to create effective models is to train the modelers ,explain modeling to business attendees (stakeholders or business sponsors) and check if work has already been done and starting with the known and then integrating details into the current one. This leads to another important aspect for BA which is ‘Change Request Management’.

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.