Tag: Requirements

Best of BATimes: How to Prevent the Negative Impacts of Poor Requirements

Written by Sergey Korban on September 6, 2023. Posted in Articles.

There is an abundance of stories of failed projects. Research has shown the reasons for IT project failure in the USA, indicated that project success rates were only 34%, with the rest of projects being either “challenged” in some way or failing outright.

The losses can be very significant. For example, British food retailer Sainsbury had to write off its $526 million investment in an automated supply-chain management system. The U.S. Federal Aviation Administration spent $2.6 billion unsuccessfully trying to upgrade its air traffic control system in the 1990s. Ford Motor Company abandoned its purchasing system in 2004, after spending $400 million. In the 8 years since, things probably haven’t changed much.

From the project management perspective, technology projects fail when they do not meet the following criteria for success:

Project delivered on time
Project completed on or under budget
The delivered solution works as required by business stakeholders.

A number of factors are involved in any particular project failure. The most often quoted factors are listed below:

Lack of stakeholder involvement
Unrealistic time scales
Poor requirements
Scope creep
Uncontrolled changes
Insufficient testing.

The quality of requirements can have a lot of impact on the outcome of the project. One high profile project which was significantly affected by the requirements management process was the Chrysler Comprehensive Compensation System which was supposed to handle paychecks for Chrysler’s 87,000 employees but was shut down after several years of development.

The impact is magnified as the BA moves from high-level requirements towards functional and non-functional requirements. The cost of rework of functional requirements is the highest because these requirements define the technical specification and design of the solution.

Here is a visual summary of the impacts:

Project Impacts

Projects are undertaken by the business to satisfy a strategic goal. Poor requirements have the following effects on projects (and subsequently impact the strategic goals of the business):

Scope creep negatively affecting budget and completion time
Low utilization of resources and higher overheads
Inadequate business process design (due to insufficient details about activities)
Poor design and ergonomics of the user interface, resulting in lower productivity
Inadequate software specification, resulting in lower developer productivity
Poor specification amplifies the negative effect of poor requirements when it comes to software testing, leading to higher costs and lower quality of the solution
Time-consuming and costly code rework
Difficulties in solution integration.

Business/Organization Impacts

More generally, the business as a whole is affected in many different ways by poor requirements through the projects that the business undertakes. Here is the short list of negatively affected areas that I have witnessed:

Lost opportunities for the business
Lost advantage relative to competitors
Breaches of regulatory compliance
Poor stakeholder engagement and loss of trust
Reduced business process efficiency due to poor solution design
Negative user experience due to cumbersome UI design
Lack of cohesive IT landscape due to poor integration
Negative impact on the bottom line, generally speaking.

How to Prevent Poor Requirements

In my experience, there are two ingredients in any given project which help me deliver quality requirements. One ingredient is what I know about the business and the project. The other one is the techniques I use to ensure that I deliver great results.

It probably sounds quite vague at this point, so let’s dive into the specifics.

Knowledge Needed for Quality Requirements

The foundation for creating the future solution is a good level of understanding of the current state. Regardless of the methodology you are following, you have to start here. What do you need to know?

Know the Context in which the Business Operates

The business operates in two contexts. One is the external context where market forces define how the business operates and maintains its sustainability. This includes regulatory requirements, competitors and partners.

The second context is internal. It is actually more complex as it includes organizational structure, business processes, governance around the processes (business rules), people involved in the processes, internal politics, organizational culture and overall pace of changes within the business you work for.
Understand the Business Problem or Opportunity

This is the actual driver for the project. Without knowing the real business need you won’t be able to find the solution that solves that problem.
Identify Gaps to be Bridged

Once the business problem and stakeholder concerns are clear, you can draft the future state. When the future state has been confirmed with stakeholders, perform gap analysis. Your focus here is on what should be done within the project scope to resolve the identified problem. It is also good to think about extra value the business can get as a result of the project.

Extra value can be delivered when you have a clear understanding of changes going on in the organization, and how the project you are engaged in fits into the change landscape.

Techniques for Better Requirements

The techniques I’ve settled on in my practice enable me to use stakeholders’ time efficiently and get a clear picture of the current state. Let me share them with you.

Do Your Homework: Before engaging stakeholders in requirements gathering activities, I read all available documentation on business processes, business applications in use, regulatory requirements (if any), internal communication about changes in the organization, as well as other projects that may have dependencies with the project I am in.I also explore information relevant to the industry as a whole to identify possible good practices that I can re-use.I call this exercise my “homework”. The benefits of the homework exercise are that I know the “language” I will use when talking with stakeholders. I also know what to articulate to confirm information that is unclear. I feel confident about my part in the project and I know that I can help the business.
Power Up Communication with Visuals: There is nothing better than diagrams to explore the current state and get an idea about the desired future state. The time savings due to using visuals can be enormous. How much time do you spend to define the future state? If you don’t use diagrams at present, you could probably save a significant portion of that time. Outline organizational boundaries, processes and data they use, add used applications, process and technology interfaces where required, and finally add roles involved in the processes. Now you have a snapshot of the current state.
Use Templates to Support Your Work: Any business analysis task has to be organized to save your valuable time. Templates are of great help here as they let you re-use the common parts of documentation, and customize as necessary. They also serve as a kind of checklist of required documentation, and ensure that you don’t miss anything. My favourite template is the Current State Analysis. It includes analysis findings, identified business need, visualized current state (including the external context) and recommendations on what the solution may look like in terms of capabilities.
Avoid Common Pitfalls: Requirements become poor and vague when they mix project related tasks, statements about the future state, applied rules and solution design. A good way to avoid these common project pitfalls is to plan business analysis, and to document the planned activities and deliverables in the Business Analysis Plan. It’s an integral part of the project plan. However, the Business Analysis Plan does not deal with project tasks.A hierarchical approach has to be taken to the future solution. Firstly, list the required solution capabilities. They can include both changes to business processes and technology services supporting these processes.Secondly, translate these capabilities into a business process design and business requirements for supporting technology services. You always need to tweak a business process if you change software used to support the process.Thirdly, add relevant business rules to justify future business logic.Next, validate the business process design and specified business requirements with the stakeholders.Finally, transform the validated requirements into functional requirements. These will guide the development and implementation of the solution. Don’t forget to describe business data (along with data types) to be used within the solution.

Adding prototypes of the user interface will make the functional requirements more precise and also help establish new terminology to be used in the solution.

These steps are executed in an iterative fashion so they align well with modern “fast” methodologies such as Agile and Scrum.

Summary

Poor requirements may lead to project failure. Functionality that is poorly specified, implementing something that isn’t needed, poor processes, lost development time, missed project deadlines, poor quality of documentation – the list of impacts can go on and on.

I believe that we as business analysts can do our job well and contribute to business success. Sometimes we don’t have enough time to stop and consider why our requirements are poor.
In the article above I listed the key ways to improve requirements. I’ve tested these approaches in many projects and they always produce positive results.

I hope they will help you, too!

Published on: Apr 30, 2013

Best of BATimes: What Problem Are You Trying To Solve?

Written by Larry Blankenship on August 24, 2023. Posted in Articles.

One of the most important lessons I’ve learned to ask during my BA career is “What problem are you trying to solve?” It’s not as straightforward as it might appear.

Often, business partners come with all sorts of preconceptions, which they present as the actual problem. Sometimes they try to be helpful. It’s the BAs job to ask more questions to determine if that’s the real problem.

For example, I had a business partner who told me that the data in an email we were sending to one of our customers was “encrypted”. It would have been easy to waste hours trying to chase that down. I started down that road, until I caught myself and asked “What’s the problem I’m trying to solve?” I asked the business partner to see a copy of the email. It was then that I realized that what she was referring to as being encrypted was actually just raw XML being presented straight to the page. The problem wasn’t that the email was encrypted, it was that it wasn’t easily readable by a human. One parameter change later, and the problem was fixed.

Donald Gause and Gerald Weinberg wrote a seminal work on discovering the real problem called “Are Your Lights On?” I reread it at least once a year, to remind myself how to ask the questions needed to determine the real problem, because sometimes what appears to be the problem at first glance isn’t the real cause.

A recent real-life example was encountered by the Dutch bike manufacturer Van Moof, who found that over 25% of their bicycles were being damaged en route to the customer, especially when being shipped to the US. The company could have invested money in improving their packaging or looking for a new shipping company. Instead, they spent time identifying what the real problem was: the people doing the shipping weren’t being careful with the product, perhaps because they perceived a bicycle as being sturdy enough to withstand rough handling. Or perhaps they didn’t perceive bicycles as being as valuable, so they didn’t feel the need to take extra care when handling them. What was the solution?

In the end, the bicycle company put a picture of a large screen TV behind the picture of the bike. They didn’t indicate that there was a TV in the box. The shippers, who apparently don’t have time to read carefully, treated the updated boxes like there was an actual big screen TV inside them. As a result, damages in transit dropped by 80%.

1. Asking the business or customer what the problem is that they are trying to solve isn’t the end of the process, it’s only the beginning. Here are some ways you can get to the real problem:
Ask what things would look like if the problem was solved. Often, this will let you identify the real problem based on what the business sees as the desirable result. An example given in the book was a building whose tenants complained about the elevator being too slow. The desired solution wasn’t that the elevators be made faster, it was that the tenant’s stopped complaining. In the end, a mirror placed on each side of the elevator offered enough distraction that the perception of the elevator’s speed was no longer an issue.

2. Don’t accept a solution as the problem. Often in my career, the customer brings a solution that they want rather than a problem to be solved. Asking what the problem is that’s trying to be solved often allows for simpler resolutions. For example, one department is complaining that another department’s data entry isn’t accurate. The solution they presented was to add a high number of edits and validity check to the system where the data was entered. This would have required a large quantity of analysis and development time to ensure that the validations were correct and didn’t create additional follow on effects. Instead, time was spent bringing the two departments together to discuss the issues and looking for ways to improve accuracy at the front end. In the end, development wasn’t required, and the problem was solved via process improvement.

3. Spend time on root cause analysis. Sometimes the perceived problem is a symptom, not the actual malady. When I wrote software, a bug would frequently be caused by a change to a variable much removed in the stack from the code I was looking at. Doing root cause analysis will often help you identify what element is actually causing pain. This can also be a matter of overlooking something because “We’ve always done it that way.” The root cause may be the result of some process before or after the pain point that is creating the issue.

In the end, finding the real problem that needs to be solved, can be simple, complicated or somewhere in between. Taking the time to do the right level of investigation is an important part of the BA’s value in the development process.

Published: 2020/06/04

Best of BATimes: Business Analyst vs. Business Analytics Professional: What’s the Difference?

Written by Savaram Ravindra on August 2, 2023. Posted in Articles.

A business analyst and a business analytics professional are not the same. Very often, people get confused about these 2 terms.

Many times, they are used interchangeably. Few start-ups and organizations also seek out a business analyst when they are actually in search of a business analytics professional. Among the analytics enthusiasts who are searching for a job in business analytics, this causes huge confusion. So, it would be better if the difference between a business analyst and a business analytics professional is well-known.

Who is a business analyst?

As defined by IIBA(International Institute of Business Analysis), the business analysis is a discipline of determining the business needs and identifying the solutions to business problems.

A business analyst coordinates between a client and the technical team. A client can be either the internal team that is required to work with the technical team or external, with the requirements to solve a particular problem. The technical team has the ability to either deliver a service or build a product.

The business analyst makes sure that the service or product provided by the technical team meets the client’s present requirements. He/she collaborates with the external and internal stakeholders in the implementation as well as design of the service or product.

Who is a business analytics professional?

A business analyst doesn’t work with data and is mostly concerned about processes and functions. On the contrary, reporting and data are the key components of a business analytics professional’s job.

Let us consider 3 major elements that help us in understanding the difference between a business analyst and a business analytics professional.

Analytical problem solving skills

The business analysts utilize different techniques to analyze the problem and determine the solution. They conduct thorough analysis and deconstruct the solution or problem by making use of various methods. Few examples of this include decision models, business process models and use cases.

On the other hand, business analytics executives use logical thinking, predictive analytics and statistics to solve the business problems.

Let us consider 2 examples that state the way in which the business analytics executives solve the business problems.

If a continuous stream of loan applications are being received by a particular bank, the business analytics professional will develop and implement a model to give a recommendation on which loan applications that bank must lend to.
From a catalogue launch, if a manufacturer of home-goods wants to predict the expected profits, a framework will be applied by the business analytics executive to work on the problem and develop a predictive model to provide recommendation and results.

The capability to tell story with data

The business analytics professionals must be in a position to share the insights they derive from raw data. They must share the insights in a way that is clearly understandable to the end stake holder as most of the times, the end stakeholder will be a non-technical and/or business-centric person. They shouldn’t use technical jargons while communicating and must present the insights in the simplest possible way. The stakeholder can be an internal or external client. Most of the times, they are business professionals with zero technical background and the authority to take decisions rests with them. The business analytics professionals are very good story tellers and they make use of advanced tools like Ds.js, R and Tableau to share their findings or story to the end stakeholders.

On the other hand, the business analysts are good communicators and they make use of excel, word and PowerPoint to create visual models like wireframe prototypes or work-flow diagrams. They are also good at creating technical documentations. But, they don’t develop custom dashboards making use of modern data visualization tools like business analytics executives do.

Programming skills

A business analytics professional works with structured data and utilizes SQL in order to retrieve data from databases. He/she will write SQL queries to analyze and extract data from the transactions database and develop a set of visualizations if the management requires some advanced metrics about their company.

The analytics professional will also have a good expertise on the data science programming languages like Python, Julia, Hadoop and so on. He/she is good at visualizing, analyzing and manipulating data.

A business analyst, on the other hand, has nothing to do with data. Their focus is more on the functions and processes. The significant business analyst value propositions incorporate the calibration and testing, IT re-engineering, process, model requirements, KPIs(Key Performance Indicators), vital pain points, context and business value maps. A business analyst possesses strong knowledge in development frameworks such as SLDC. He/she makes use of Excel to perform quantitative calculations and analysis. The programming skills are not used by the business analysts to perform calculations.

Conclusion

It is evident from the above that both these functions are extremely important for a successful business model. From the business decisions it automates as well as enables, the value of analytics can be derived. Every time, a business analyst will first begin with the business questions but not with data. They are also the domain experts who manage the project from the beginning till the end.

On the other hand, a business analytics professional begins to solve the business problem making use of data first. He/she cares about the retrieval of data, format of data and source of data. Data is the raw material for a business analytics professional.

A business analytics professional and a business analyst work closely to make sure the final project is delivered successfully. This explains the difference between a business analyst and a business analytics professional.

Posted on: 2017/12/27

The Cost of Missing Stakeholders

Written by Jenny Quillian on July 19, 2023. Posted in Articles.

Business Case: Lessons from software implementation which put head office directives before stakeholder needs.

Background

This business lesson was learned at a US non-government organization (NGO) operating refugee camps and support services in East Africa. A few months prior to my arrival the NGO selected an accounting system to be implemented at all local offices. Instructions and software were sent out from the US head office, and my predecessor had been gamely trying to implement the new system but falling behind a little each month. We crossed paths in Nairobi as I was inbound to Mwanza, a dusty town on the shores of Lake Victoria. He was clearly stressed and anxious to be going home. What was I heading into?

NGO’s operate on private donor funding and from US government grants. Money was provided in US dollars and was spent in local shillings. Financial reports are provided in US dollars to the head office and for donor reporting, and in shillings for local authorities. Multi-currency accounting was not the cause of their current issue, but added complexity to the implementation.

The software was installed but a backlog of configuration work and data migration had been created and this was consuming the efforts of the finance office. Production of the donor reports were months behind and the NGO was at risk of losing or disrupting the funding to aid the thousands of refugees in their camps. Payments to local suppliers and workers were also in arrears as time had been consumed by the software change.

The new accounting system was rolled out by the head office to support a strategy for global standardization of accounting and reporting from their international offices. The implementation strategy could be called “out with the old and in with the new”. Use of the old system was abruptly ceased while the new software was installed, and production of the monthly donor reports would be resumed from the new system once the install and data migration was complete. There was no local planning for the initial rollout.

The approach of this paper is to use this business case to illustrate the benefits of applying business analysis tools and techniques to all software projects, regardless of size or location.

Planning– identify stakeholders and business analysis approach.

Always look for all the stakeholders. The NGO head office is a stakeholder in the Mwanza project, and they communicated a business need to achieve global accounting standardization. The funding donors are also stakeholders in the project. The rollout strategy was based on an assumption that the new accounting system was the number one priority for this local office – but donor funds are the life blood of non-profit organizations and any hint of not being able to account for how the money is being spent can cause delays or withdrawals of support. The number one business need for this Finance office was the timely and accurate production of donor reports.

Local workers and suppliers are also stakeholders in the accounting system. Timely reimbursement for labor and materials is needed to maintain the supply of both to run the refugee camps.

It is easy to overlook the need for business analysis in small projects, but this case illustrates the risk of implementing software without some basic analysis of scope and flows. A simple context diagram and stakeholder map would have provided a better perspective for implementation planning.

Requirements – identify all the functional and non-functional requirements.

The requirements given to the local office were:

Install new software
Migrate historical data
Recreate reports

Recognition of additional stakeholders leads to the additional requirements –

Maintain accurate and timely reporting to donors.
Avoid disruption to the delivery of monthly donor reports
Ensure consistency in donor reports
Maintain payments to local vendors and workers
Avoid delays of vendor and worker payments

Strategy – identify the business need, address that need, and align the change strategy within the enterprise.

The business need which dictated the implementation strategy was to achieve global accounting standardization. The missing business need was to maintain continuity of operations during the software change. A new strategy was required that gave equal priority to both needs.

Under the new strategy all work was stopped on the software configuration and data migration until the monthly reports and daily operations were up to date, then these were maintained in parallel during conversion and testing until a clean cutoff was possible. This was achieved within 3 months and there was no disruption to the NGO’s funding or local operations.

Techniques

Create a Context Diagram at the start of the business analysis process then share this early and often with your known stakeholders to help identify what might be missing.

Summary

Identification of all stakeholders is key to successful requirements. Timely identification of all the stakeholders at the start of the project avoids delays and rework when new requirements are identified while development or delivery is in progress.

Complexity Science Terminology Applied to Business Requirements

Written by Ligia Groza on June 28, 2023. Posted in Articles.

Borrowing from the terminology used in the complexity science field, in which systems are classified as Simple, Complicated or Complex, this article provides a short description of these characteristics, and suggests using the same terms, in a different interpretation, in the context of documenting Business Requirements.

In the book “Getting to Maybe: How the World Is Changed: Westley, Frances, Zimmerman, Brenda, Patton, Michael” the following meaning is given to the three types of systems:

<<Simple>> systems are based on a small set of rules or steps to function. They are robust, in the sense that the same input will generate the same output, with little variance. An example would be baking a cake by following a recipe.

<<Complicated>> system have a high number of rules and laws, even thousands, like the project to launch a spaceship to reach the Space Station. These systems can be managed by computers, are considered predictable, but they are not necessarily robust: an error in an input parameter can lead to a different outcome than desired (the spaceship ending up on another place instead of the Space Station).

<<Complex>> systems are those in which the component agents interact amongst themselves and adapt to the new conditions. For example, raising a teenager is complex because teenagers change their moods, they interact with their peers and the environment, and they adapt to the new context. Such systems are emergent, and other examples include languages, a pandemic spread, or the car traffic.

We can adapt this complexity systems terminology to the situation of a Business Analyst who is part of an on-going project to enhance an ERP application (Enterprise Resource Planning) in a specific organization.

In this framework the starting point are the business users who face the real world and have <<Complex>> problems. The role of the Business Analyst is to translate that complexity into a form that is <<Complicated>> but fully described. The final form of this translation is the Business Requirements Document, aligning the understanding of the requirements among the team members, with sections detailing <<Simple>> logical components.

From this perspective regarding the Business Analysts’ work, the categories are:

<<Complex>> problems known by the business users. These problems may touch several areas of the ERP, have unclear or vague rules, or the granularity of the logic and desired actions is not fully explained.

<<Complicated>> requirements with a high number of rules, parameters, procedures, algorithms. With the huge computing power available nowadays, ERP applications are able to handle such complicated systems, and they routinely process huge number of transactions run very fast on large databases.

Using the complexity lens to look at requirements provides benefits such as:

First, this perspective can reduce the frustration within the project team around requirements, by emphasizing the complex and changing nature of the business user’s problems.

Second, it increases the appreciation for the Business Analysts’ role in the team, since their talent and ability to translate <<Complex>> problems into <<Complicated>> requirements are key in this framework.

Lastly, untangling complex problems requires judgment, intuition, and context sensing – all characteristics that are unique to the human mind. In the current environment dominated by Artificial Intelligence applications, a Business Analyst with this view in mind would have less to worry about a being replaced by a robot and losing their job, if they see themselves from the position of contributing to the translation of complex problems into complicated requirements.

Equipped with the tools and techniques recommended by the BABOK, Business Analysts are in a unique position in the process of documenting the business requirements.

The following components of a Business Analyst’s toolkit are particularly useful in the requirements elicitation and documentation described in this framework:

Offering mock-ups and diagrams: Visual representations of the requirements can be highly effective in helping stakeholders understand the proposed solution.
Setting up test cases in the ERP application, to assess how well the information currently provided by the ERP system can support the proposed changes.
Performing a gap analysis between current and future state. This technique helps ensure that the requirements align with the overall business objectives and can serve as a basis for defining the scope and priorities of the project.
Organizing walkthrough sessions to gather feedback and ensure that the requirements are accurately captured. Business Analysts can generate and present iterations of the BRD with revision points, and address follow-up questions from stakeholders.
Asking open-ended questions to encourage stakeholders to share their insights, perspectives, and concerns, which can help uncover hidden requirements and potential issues that may not be captured through closed-ended questions.
Nudging the discussion towards “what” is the ultimate need, instead of the “how” to meet that need. This approach encourages stakeholders to articulate their true requirements and avoid premature solutioning. This approach allows for more creativity and flexibility in exploring different options and arriving at the most appropriate solution.
Being flexible in case the requirements change in time as the project progresses. and appreciate that the scenarios might be unchartered territory for the users themselves.