Business Analyst: Are you designing for a disaster...

What intentional and unintentional errors in business analysis can lead to...and what impact it can have. This blog provides a guide to help the business analyst understand the consequences of errors in requirements and designs.

Unintentional:

One of the most unlikely incidents occurred due to a software bug in the Therac - 25 medical radiation therapy device in 1985-87. This machine was used to administer radiation doses on patients, and in several cases the faulty device administered excess quantities of radiation. In some cases, it exceeded 100 times more than the intended dose, and resulted in several injuries and three deaths.

(Source: https://en.wikipedia.org/wiki/Therac-25)

Technology is like a 'Gift of Fire,' as correctly mentioned by Sara Baas in her book where she gave many examples of such disasters.


Correlating to her thought, it would be appropriate to ask a business analyst, “are you designing for a disaster?”


Many business analysts working on a project, especially a large project, fail to see the complete picture. This alone can lead their company or their client to the disaster.

Along with software design, development and testing, requirement analysis and design is key part of developing software solutions.


It is the business analyst who elicits a particular requirement or functionality document, confirms, and sign it off before communicating the requirements to the technical team. The requirement states precisely how it works under normal conditions, in an alternate process and possible error it may have.

What are the rules applied to the requirement? What is acceptable and not acceptable in terms of data, rules, format and so on?If the error lies in the requirement/functionality, intentionally and unintentionally goes undetected, could it lead to major disaster depending on the project/product it is used?For example, a decimal place mentioned incorrectly in a requirement document in banking software that deals with millions of transactions could potentially make a serious impact with loss of few millions dollars.

A particular requirement or function used in laser arm robotic surgery could be seriously impaired.

Defective transportation software could potentially cause loss worth millions and delay.

A space ship or flight software could cause an accident if any fault occurs in the system.

These are just a few examples of the thousands of potentially damaging situations that could arise if the software requirements are not documented and implemented correctly.


Intentional:


Of course, there could be intentional error in the requirements for designing the software solution to mislead authority. The most notorious example is how Volkswagen managed to manipulate the car emission system for two decades. Of course, when they are caught, they have to cough up close to 18 billion dollars in penalties, not considering the loss of face and brand value.

Oops...How brilliantly one can misuse the use of software... The team of business analyst/stakeholders/project manager who designed software never thought it would ultimately cost billions...

(Source: http://time.com/4046994/volkswagen-emissions-golf-crisis/)


Undetected hole in the ozone layer over Antarctica: This is another serious issue that impacts the whole world. The software that was used by NASA to map ozone layers had been designed to ignore certain values that deviated greatly from expected measurements.

Therefore, the hole in the ozone layer went undetected until 1985, even though the project was launched in 1978. It was only found after the scientists at NASA reviewed the data for abnormal results and found the error and the big hole.

(Source: http://royal.pingdom.com/2009/03/19/10-historical-software-bugs-with-extreme-consequences/)

The business Analyst's role goes far beyond the requirement lifecycle, as their role and responsibilities are not limited to just requirements or the solutions...but the total solution and its overall impact on the organization and beyond. Their contribution could possible make or break the organization.

Please read my book for more details: Business Analysis: The Question and Answer Book available on Amazon and other places in Kindle and paperback.

#BusinessAnalysis #Design #Disaster #SoftwareDevelopment #RequirementManagement #ProjectManagement

What is the difference between incident and problem?

Based on ITIL standards,

Incident - An incident is an unplanned disruption or degradation of service.

Problem - A problem is a cause of one or more incidents.

Incident Management
It’s considered as incident only it extends and impact on regular business process. They are flagged as emergency if they impact on critical services.
It needs to be resolved immediately.
It can be resolved using either permeant or temporary fix
Incidents can turn into a problem when it reoccurs or likely to reoccur.

Problem Management
Unresolved and repeated incidents become a problem that needs long terms fix.
A problem need policies and/process to resolve it to prevent it from reoccurring it.
Problem may be known or unknown
It can be remained unsolved or used an alternate option if the cost of resolving the solution is higher than the benefits it would bring in. (cost vs benefit analysis)

Incident vs problem.

Incident: If your 3 years phone breaks down, you need to fix it as you haven’t taken a backup. The technician fix it for you for USD 40.

Problem: There is battery and other hardware component issue, so the technician ask you to replace battery and the other component that combined would cost you USD 180. While the current value of your phone is USD 150 that you originally bought it for USD 500 as a newly launched model at that time)

You may take a backup immediately and make a decision if you want to fix your phone or buy the same model that now would cost you USD 350 (because, currently there is a new model in market).

If you read the example carefully, you understand that the incident needs immediate fix and problem can be prolonged till next incident occurs or you are ready to resolve it using other options (buying new battery and component or new phone, either the same model or new model). However, you will keep a close watch (i.e. taking backup regular or preparing yourself the new phone ) since you are aware of the problem due to the past incident.

#incident, #problem, #risk, #project management, #business analysis, #business analyst, #sandhyajane, #ANISANtechnologies, #ANISAN, #training, #certification, #BusinessAnalysiscareer, #Certified Business #Analyst, #incident, #problem, #projectmanagementInstitute, #PMI, #IIBA, #BCS, #IREB, #requirementmanagement

BAT (Business Acceptance Test) Vs UAT (User Acceptance Test):

BAT (Business Acceptance Testing) and UAT (User Acceptance Testing) are both much misunderstood terms that often end up getting used interchangeably. However, the two have completely varying meanings.

BAT (Business Acceptance Testing) is primarily focused on assessing the business requirement of an organization and deals with strategy. It is based on approach, dynamics, culture, information technology, statutory requirements, operational framework and customers. It seeks to meet business requirements in a specified business scenario against the Business Case.

One can use Solution Assessment and Validation tasks to validate a solution. If the solution/s consists of more life cycles, the V-model can be used to map the business acceptance criteria and relevant life cycle/iteration.

BAT is derived from business strategy or business requirements. It is directly related to an organization’s mission, goal and objectives. Such requirements are also called Business Requirements (BR) at a higher level. The BAT may include solution covering automated requirements, usability and manual processes. This could also involve ease of doing business or process reducing or altogether eliminating redundant, irrelevant steps/tasks in the process. This is also known as FFBT (Fit for Business Testing) and is conducted by Business Analysts working in that domain or department. It consists of main business requirements along with usability, including auto as well as manual processes.

Business Analysts can use SWOT (Strength, Weakness, Opportunity, Threats) or McKinesey’s 7 S Model or Balanced Score card for analyzing and implementing such requirements.

Business Acceptance Vs User Acceptance

User Acceptance Testing (UAT) is primarily focused on stakeholder or user or user group/s requirements in dealing with a solution. It could be in the form of additional functionality or special needs that may or may not have an impact in other areas.

This is derived from stakeholder requirements and enumerated in detail.

One can use UAT to verify if users or super users are satisfied about their requirements before moving the solution into user community (production environment). Carried out by end-users or testers, this concentrates on meeting customer requirements and is mapped on to the Requirement Document.

The UAT will have functional as well as non-functional requirements (stress, performance, reliability, etc.) to be tested.

UAT is more of an IT oriented test to check if the developed solution satisfies user requirements such as delivery of a new functionality to fulfill users’ need and expectations such as a new workflow or a new field with predefined values.

There are also additional requirements like user clicks in the field and prompt values to be selected to help users save time. For example, when a user adds a zip code, the city and state name should appear automatically in the next fields.

The client and customer ensure that solution satisfies the contractual acceptance criteria before signing off the project upon successful conduct of UAT.

UAT is also used to validate requirements before designing a solution.

References: Business Analysis Book from BCS and www.iee.org

To know more about Business Analysis, read 'Business Analysis: The Question And Answer Book'. This is available on Amazon worldwide in eBook and Paperback version.

Business Analysis - The Question And Answer Book. It is the way you can understand all... over 200 questions and elaborated answers.

This clears your concepts about strategy, business change, business analysis and solution implementation.


In India Order link https://www.amazon.in/dp/B074PRQQ5V or Global Order link https://www.amazon.com/dp/B074PRQQ5V

Business Analysis: The Question And Answer Book

#BusinessAnalysis, #BusinessAnalysisTraining #Businessanalyst #Training #certification #ANISAN #ANISANtechnologies #SandhyaJane #UAT #useracceptancetest #BAT #businessacceptancetest #howtolauchbusinessanalystcareer #businessanalysiscourse #career #businessanalysiscareer #BusinessAnalysis #career #BusinessAnalysiscourse #BusinessAnalyst #Chennai #Delhi #Bangalore #Gurgaon #HongKong #Hyderabad #Mumbai #Pune #SandhyaJane #ANISAN #technologies #BusinessAnalysisTraining #certification #Dubai #sydney #London #Tokyo #Shanghai #Beijing #careerpath #businessnalaysiscareer #BA Sandhya Jane, San Francisco, Bangalore, Beijing, Chennai, Delhi, Dubai, Hong Kong, Johannesburg, Kuala Lumpur, London, Mumbai, Hong Kong, New York City, Shanghai, Delhi, Dubai, Sydney, Tokyo, UK, USA, India, China, Australia, Business analysis consulting, consulting services

When Ignorance is NOT a Bliss...

Referring to ancient teaching...ignorance is not a bliss...

अग्निशेषमृणशेषं शत्रुशेषं तथैव च |
पुन: पुन: प्रवर्धेत तस्माच्शेषं न कारयेत् ||

A fire, a loan, and an enemy must be finished or doused completely, as it is uncertain when and how they will come back to haunt you.

Like a fire, a small bug in your code, system, or product can create a huge problem in the future due to its uncertain growth. Negligence of a small bug or fault in your products can potentially ruin your or your organisation’s reputation.

If we understand this through a Business Analysis perspective, the efforts to fix the requirement defect is 20 times higher if it is accomplished in the development/coding phase and the same is almost 100 times more if it occurs during the user acceptance test (Boehm, 1981). So, this negligence could cost a bundle and put the project in jeopardy in terms of budget and schedule.

If the error goes undetected in a user or live environment, the loss sometimes can't be imagined; for example, if the bug goes undetected in software used for life-saving equipment, it might cost a life (or lives) in worst cases, or a small bug in the transactional application might potentially cost a few millions.

So, friends, it would be more effective if we train our team to catch every defect, irrespective of the size, at the early stages to avoid additional efforts and costs associated with it in the future. In case the defects require replacing or fixing as part of the solution in the user environment, train your team to address them as soon as possible before they become too big to handle.

This proactive culture must be part of the induction-training program. If the organization provides it, customize this training at the department level and, in absence of this topic, introduce a new session on it that can be provided at the end of the induction-training program when an employee joins the team. It will be more effective if it is introduced at the beginning, as it can become part of the employee work-DNA and, potentially, it could save millions in terms of efforts, cost, and reputation.

#sandhyajane #businessanalysis #businessanalyst #requirement #requirementmanagement #defect #softwaredefects #BusinessAnalysis, #BusinessAnalysisTraining #Businessanalyst #Training #certification #ANISAN #ANISANtechnologies #SandhyaJane #communication #collaboration #howtolauchbusinessanalystcareer #businessanalysiscourse #career #businessanalysiscareer #BusinessAnalysis #career #BusinessAnalysiscourse #BusinessAnalyst #Chennai #Delhi #Bangalore #Gurgaon #HongKong #Hyderabad #Mumbai #Pune #SandhyaJane #ANISAN #technologies #BusinessAnalysisTraining #certification #Dubai #sydney #London #Tokyo #Shanghai #Beijing #careerpath #businessnalaysiscareer #BA Sandhya Jane, San Francisco, Bangalore, Beijing, Chennai, Delhi, Dubai, Hong Kong, Johannesburg, Kuala Lumpur, London, Mumbai, Hong Kong, New York City, Shanghai, Delhi, Dubai, Sydney, Tokyo, UK, USA, India, China, Australia, Business analysis consulting, consulting services