Tag: Requirements

The Unbiased Analyst

Written by Anna Rajander on August 13, 2020. Posted in Articles. 3 Comments on The Unbiased Analyst

Whether it be interviews, surveys or questionnaires, business cases, observations, or root cause analysis – any technique can introduce bias into a business analysis initiative.

Bias can result in the collection and synthesis of erroneous information leading to the delivery of sub-optimal, discriminatory, and/or inadequate solutions. It is therefore important that Business Analysts are aware of the different types of bias and the risk they pose to any analysis.

The following outlines some common forms of bias, as well as provides some simple approaches for mitigating the risk of introducing bias into an analysis.

Selection Bias

In cases where there is a large group of stakeholders, it is often not practical to elicit information from every individual. Instead, information is elicited from a selection of group members.

Selection bias is where individuals are more or less likely to be selected from the larger group. The risk posed by selection bias is that the information solicited from the selected individuals is not representative of the larger group.

Any business analysis technique that involves selecting individuals to represent an entire group is at risk of introducing selection bias. For example:

Surveys and questionnaires often depend on individuals taking the time to respond, which may be depended on a range of variables, including being aware of the survey/questionnaire, having access to complete the survey/questionnaire, having the time to respond, and/or having the ability to respond.
Interviews usually involve selecting individuals or asking for volunteers from a larger group.
Observations may introduce selection bias based on when and/or where the observation takes place.

It is also important to be aware that any elicitation that involves self-selecting is inherently biased towards those who chose to be involved.

Response Bias

Response bias is a general term that accounts for range of bias that influence the response of participants away from an accurate or truthful answer. Some areas that may contribute to response bias include:

Recall – human memory can be unreliable, particularly if the information being recalled is complex, regards an event that took place a long time ago, or involves information that may be considered traumatic.
Perception – this is where a response is influenced by what is perceived as a ‘good’ or ’bad’ answer. The responder essentially changes their response or behavior based on what they think the interviewer/observer wants to hear/see, ultimately leading to the collection of erroneous information. An individual’s response can also be impacted by how a question is framed. For example, using overly negative language, positive language, or language that is associated with a particular ‘side’ can influence response.

Any business analysis technique that involves collecting information direct form stakeholders may be at risk of introducing response bias.

Personal Bias

Personal bias is where an individual unintentionally or unwittingly introduces unwarranted opinions and feelings into a situation, making objective opinions difficult. Business Analysts are at risk of introducing bias into an analysis because of their own views and believes.

Some particular areas of personal bias include:

Observer Bias – this is bias introduced when an individual’s point of view or understanding impacts how they perceive a situation. For example, an observer may misinterpret a situation because the language used has a specific meaning in the given context that the observer is not aware of.
Confirmation Bias – this is the tendency for an individual to seek out evidence that confirms their own personal views, while downplaying or discounting evidence to the contrary.
Overconfidence – this is where the credibility and/or knowledge of an individual or source is overestimated.

Introducing personal bias into analysis is a risk for any Business Analyst regardless of the technique being used.

Avoiding Bias

The following is a non-exhaustive list of ways Business Analysts can mitigate, counteract or avoid introducing bias into analysis:

Understand your stakeholders – take the time to understand your stakeholder groups, including understanding attributes that may impact the particular needs of individuals within a group. Attributes to consider include demographic information such as age, geographic location, socio-economic status, and/or access to technology. Techniques such as stakeholder maps may assist in identifying attributes and decomposing stakeholders into more relevant sub-groupings.
Don’t rely on a single technique – when eliciting information from a large population of stakeholders, consider using multiple techniques across non-mutually exclusive groups. For example, follow-up surveys with interviews, consider confirming results from an observation using a follow-up questionnaire etc.
Support with hard evidence – where you are soliciting complex or historical information from stakeholders, confirm with hard evidence wherever possible, such as using emails, audit logs, meeting minutes and/or policy documents.
Census, not survey – where possible and practical, consider making responses to surveys and questionnaires ‘compulsory’, essentially turning them into a census. This approach can also be applied to interviews and observational studies where a stakeholder group is small.
Use advisory groups – where available, include advisory groups, unions, or other available advocacy group in your elicitation exercise to represent stakeholders. Advisory groups are more likely to have in-depth knowledge about a stakeholder group that may allow them to identify areas analysis may have failed to address. Advisory groups may also be useful when validating the findings of an elicitation exercise and understanding if further elicitation is required.
Understanding the context – take the time to understand the full context of the situation you are analysing, including the terms, acronyms and phrases that have a specific meaning to stakeholders. Consider keeping a glossary of terms and making sure it is validated by stakeholders to ensure language isn’t taken out-of-context.
Be self-aware – take the time to reflect on your own personal perspective and how it may influence your analysis. Where you are aware of a personal bias, consider finding and confiding in a colleague who can critique your approach to ensure it remains unbiased. Consider removing yourself from initiatives where you have a clear conflict of interest.

Conclusion

Bias is a risk to any business analysis initiative. However, with a little planning and self-awareness, any risk of bias can quite easily be mitigated or avoided.

Getting Requirements Right with KickOffs and Desk Checks

Written by Maria Rios on July 16, 2020. Posted in Articles.

Have you ever been at a restaurant and received something different than what you ordered?

I’ve had unwanted sour cream on my nachos and swiss cheese in my omelet instead of provolone. Even if it was close to what I requested, I often returned my food to the kitchen to get it fixed. Waste of time for both me and the cook, not to mention I would be hungry by the time I got my food.

A similar experience has happened to me with software development. As an Agile organization, we regularly hold lead reviews and story grooming sessions. Despite numerous meetings, I sometimes found myself in a situation where what a developer coded is not exactly what I asked for. How is that possible after hours of discussions? The answer is simple. Human nature. What one hears may be interpreted differently by someone else. Memory isn’t always reliable for stories reviewed a few days or weeks before. Also, until a person is the one working on a story, he/she may not be listening 100 percent during team activities.

As any developer and QA engineer can tell you, building something that doesn’t match the requirements requires rework and retesting, which impacts a team’s ability to meet sprint commitment. So how can we minimize wasted time? My department has adopted the following practices which have reduced the botched order syndrome significantly:

Story Kick-Off
Story Desk-Check

Story Kick-Off

A story kick-off is done prior to coding to ensure that the developer, QA and the BA/Product Owner are in alignment regarding expectations. Asking the following questions helps to ensure a successful kick-off.

Are the requirements clear?

As the BA, I review again all assumptions, the acceptance criteria and any supporting documents, such as UI and report mock-ups. Everyone’s memory is refreshed, and the opportunity exists to answer questions and to ensure everyone is on the same page. In addition, the wording within the story may be modified or additional notes added to provide clarity.

Do we have all the technical tools and information needed to finish this story?

Our developers perform preliminary investigation prior to a kick-off to determine what is needed from a technical aspect. When issues affecting completion of the story are identified, negotiations around requirements commence. For example, we may find that a new function cannot leverage existing code as initially anticipated. I often ask whether the extra effort can be absorbed in the current story without impacting timelines. The outcome may involve conversion of an acceptance criteria into its own story or pulling the story from the sprint altogether for additional refinement.

Are there any blockers?

We normally identify story dependencies ahead of time and plan sprints accordingly. Due to resource constraints, we sometimes find ourselves playing blocking or dependent tasks within the same sprint. If called out during kick-off, it reminds us to coordinate activities across the team to help ensure timely completion.

Will assistance be needed from other departments in order to complete coding or testing?

If yes, we like to inform those groups at kick-off, so they have a few days to plan accordingly. As an example, we may need DevOps to bring a connection down to test failure scenarios.

Story Desk-Check

A story desk-check is performed when coding is completed but not yet pushed to a test environment. The participants include the same people involved with the initial kick-off. Activities include the following:

The developer demos the functionality that he/she has built while cross-checking against the requirements of the story.

Have all the acceptance criteria been met? Does the output, such as UI screens or reports, match the mock-ups? Are any bugs encountered during the demo? If identified at that time, the developer can more easily fix issues in their local environment before it even gets to QA. Problems found sooner contributes to less bug finding during testing which equates to time saved.

Provides the opportunity to tweak a requirement.

A demo sometimes identifies requirements which sound good in theory but does not work well in reality. For example, we may find that an error message that I’ve requested is hard to see. I could ask that the error be moved to a more prominent location or be highlighted in red. If the impact to the sprint is small, the developer and QA can agree to the modification and the story is updated. For larger efforts, I create a new story to be placed in the backlog and prioritized.

Helps QA prepare for test execution.

The developer provides input on how a story can be tested. Are there tools available to help them verify the data? What configuration or setup is needed prior to testing? Impact to existing functionality is also called out so that they can be retested to ensure nothing is broken by the new code.

Other groups participating in the desk-check, such as DevOPs, become aware of when their assistance will be needed and can schedule their time with QA.

Two years after initial implementation, kick-offs and desk-checks continue to be an important part of our development process. It is extremely satisfying to see how minutes invested up front saves us from hours of rework later. There’s always room for improvement, but in the meantime, I am happy to say that what development now gives me is usually exactly what I ordered!

COTS – Challenges or the Solutions?

Written by Divya Kishore on July 9, 2020. Posted in Articles. 1 Comment on COTS – Challenges or the Solutions?

Raise your hand if you have ever been assigned as a business analyst (BA) to a Commercial off the shelf (COTS) application project?

Again, raise your hand if as a business analyst, you have felt like you are neither a subject matter expert on the business side nor on the application/solution side?

COTS applications/solutions are more and more commonly being adopted by global organizations since the belief is that, when there is something readily available in the market, then why recreate the wheel and build a customized solution? Here I don’t want to get into pros and cons of a Custom vs COTS application and rather outline how the COTS pathway has impacted the role of a business analyst in many ways as listed below.

Common Challenges and Potential Solutions for a COTS business analyst:

1. Challenge: Resistance to explaining current/as is business process

2. Challenge: Center of attention is application design/configuration

3. Challenge: High dependency on vendors/implementation partners

4. Challenge: Lack of understanding of a business analyst role by the team

5. Challenge: BA not involved in application/vendor selection

In summary, the goal is not to ensure that the application is designed and set up to accommodate the current processes of an organization but rather to have a closer look at the current processes and see how these can be changed to gain the true business value.

“Don’t make the application work for you but rather see how you can work with the application”.

A way to manage Risks in Requirement Management Lifecycle Risk Champions

Written by Chintan Jariwala on July 2, 2020. Posted in Articles.

As a Business Analyst, you would already have worked with Risks; and if you have not, it is a miracle.

Assumptions are essential part of requirements and Business Analysts’ one of primary tasks is Requirement Management which included eliciting, analysing and documenting requirements.

What is a Risk:

Risk describes an occurrence or uncertain event which may influence the ability to achieve the goal.

In Requirement Analysis, Business Analyst, with the help of other stakeholders, determines the risks. Being said that, it is very critical how a business analyst manages risks to achieve the business goal.

In principal, the project team and stakeholders need to take informed decisions based on the information at hand to achieve the project goal. Hence, it becomes essential to understand what the risk is all about and ways to manage them. Risks, positive or negative, should be understood thoroughly to define the level of tolerance, and to identify the responses.

There is another way to manage the risk by Business Analyst is to engage with Risk Champions.

A way to manage Risks: Collaborate with a Risk Champion:

Risk Champion is a person who by expertise or authority champions an aspect of the risk management process, but who is not the risk owner. They are a bridge to engage the business, to take care of aspects of the risk management process on behalf of the business and to ensure that business is aware about the impact, positive or negative, to the business. They are equipped/impowered to find the impediments available in the different part of the organization which in return helps to identify the strategy to manage the risk. They need to be involved when the business needs to take any big/small decision impacting multiple department of the organization. Many companies assign Risk Champions for each major functional area of the business, including sales, marketing, operations, HR, IT, legal/regulatory and the financial departments. These champions can be charged with assessing risk both in their individual functional areas and as a cross-functional team.

Apart from Risk Champion, there will be a Risk Owner who will be a Business Analyst, Project Manager, Product Owner, or a Process Owner generally.

Risk Champions should have most of following traits to be successful:

Risk coordinator: Ability to work with multi-functional team for risk management
Understands risk: A good understanding of risk management concepts, principles, and processes. They need to be aware of the compliance requirements as well if the industry is working under regulations.
Experts: Expert in their function / process in which they are champions.
Good soft skills: Strong leadership and motivational qualities; and Good communication skills. Good analytical skills to assist with the analysis of root causes to risk problems.
Influencers: Ability to influence the decision makers to keep the organizational needs above all. They need to work very closely with the head of the function they represent.

How it all works:

Business Analyst with the help of Project Manager, Product Owner, or a Process Owner identifies the risks.
The Business Analyst, who is now the risk owner, engages with the Risk Champion to determine the way to handle the risks.
Business Analyst and the Risk Champion will work with cross functional Risk Champions & stakeholders, in a workshop, to identify the severity and probability of the risk occurrence and any budget requirement.
In this workshop, they will decide the action items for all the stakeholders to take to prepare & execute all the risk management plan.
The Risk Champion, who is working with the Business Analyst, will keep an eye on the progress on all the action items along with the business analyst.
Another session of workshop will be arranged to take the decision using the identified the severity and probability of the risk occurrence and budget requirements.
After the decision has been identified, the plan will be sent to the executive body for approval.
The executive body will evaluate the plan and the champions are required to clarify all the questions raised by the executive body.
After the approval, the plan will be ready to be executed under the supervision of the Risk Champion, who will keep all other Risk Champions in the loop.

Factors to consider:

Pros:

They will provide direct and honest feedback keeping organizational needs in mind.
A well-designed approach which can work in any cross functional venture.
Everyone is aware about the plan and the progress.
Risk Champions will make sure that project team does not deviate from the approved plan.

Cons:

The process is time consuming.
Requires resources with specific skills and dedicated time.
Business Analyst will have to invest his/her time in the Risk management activities along with the Risk Champion.
It can reduce the importance of risk champions if he/she does not have required skillset.

Conclusion

The inclusion of Risk Champions has worked in our organization and it has made our decision-making process robust.

However, in my opinion, not all organization needs nor can afford this structure.

This framework will work greatly in those organizations which are working under any regulatory body including, but not limited to, banks, broking companies, financial services companies.

Risk Championship framework can also work outside the project i.e in the BAU environment with great results.

As a Business Analyst, I always believe that the effect of risk management on any project is underestimated. However, at the end, it is just a framework which is as good as any framework if it has resources with required skills and experience.

In my opinion, Risk Champions are not rival to Business Analyst as they are essential Business Analyst themselves with expertise in Risk management.

Design Thinking in a Waterfall World

Written by Oluwakorede Asuni on June 24, 2020. Posted in Articles.

As much as we like to think we are now in a dynamic and agile world, most delivery initiatives are still some shades of agile and all shades of waterfall.

These initiatives could have adopted an agile outlook and naming convention, but the businesses they support are often still predominantly waterfall – going from one clearly defined task to another until realizing value. Think for example, order to cash, just in time logistics etc.

We often have some outliers, mostly modern businesses without legacy overloads and whose core business is digital or relies heavily on digital who may have cracked the agility question.

Waterfall is seen by most agile advocates as a relic of a time that had been and that should be forgotten and buried.

Waterfall is expensive, time consuming and unforgiving of errors.

Design thinking, on the other hand may be equally as expensive especially for organizations with legacy burdens switching over to an agile way of work, has picking up errors early built right into its DNA and offers opportunities to succeed quickly or fail fast.

A variation of the plan-do-check management methodology – the decision is easy to reach if one strips down the elements of the methodology into its bare bones fundamentals –design thinking allows the business or the delivery team to involve the customer for whom a product or service is being designed early on in the delivery effort. Design thinking offers up an opportunity to build a product truly needed by the customer and not one that was assumed the customer needs.

The question one ponders then is whether an enterprise or delivery team can only be one or the other? Or be both?

An important point of departure is that agility is a mindset, a mindset written into an organisations’ DNA and not only those of its project delivery teams. Agility does not rest solely on the tools and techniques that an organisation or its teams chooses to work with, rather it relies heavily on the collective agreement between teams and individuals; the capacity to work quickly, to experiment all the time, to learn fast and to be honest with itself all the time.

That said, with an agile mindset, design thinking techniques can be applied within each phase of the waterfall methodology.

For example, in the requirements phase of a waterfall project, the elements of design thinking’s empathise, define and ideate can readily be adopted. A bold team may and should also prototype and test their assumptions and some of the features of their product/service with real customers. Done well, the requirements phase of a waterfall project doesn’t then just end with a signed off requirements specification, but also the knowledge of what the customer truly wants backed with empirical data. And potentially the design and implementation phases have a ton of knowledge of the market to go on with – in essence most of the work in these phases of waterfall delivery would have been completed during the define stage as done as described above.

The actual waterfall phases of design and implementation then just becomes opportunities for refinements of the work done in the requirement phase using design thinking, and for honouring the legacy requirements of phase gates.

The refinement efforts in each of the design and implementation phases could also leverage design thinking. For example, the design phase of waterfall could leverage prototyping and test multiple user experience approaches – building on the work started during requirements. And in the implementation phase will build based on the output from the design phase which has determined with a high degree of accuracy what the customer truly wants.

The test phase of the waterfall delivery effort, may end up being systems’ tests (regression and systems integration tests) and confirmatory usability tests – as actual usability tests would have been completed upfront during requirements and design phases where the team had brought in the real customers to empathise with, define and ideate with, prototype for and tested with.

One can then safely conclude that waterfall can co-exist with design thinking (and really most other agile techniques) if the organisation’s mindset focused on agility and not processes for the sake of processes.