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

Business Analysis vs Business Intelligence

There is huge difference between Business Analysis (BA) and Business Intelligence(BI) because BA has larger scope as it is application to all types of projects (including BI) where as BI covers only software applications used to analyze an organization's raw data (data mining, analysis and reporting related project) to make effective decisions.

Business Analysis:
"A set of task and techniques to understand products, services, operations, organization structure, policies, and culture to recommend a solution to the stakeholders to achieve their business goals."

The business goals could be generate additional revenue, reduce operational cost, to implement new regulations, to reduce operational roadblocks,  faster and effective decision making process, improve customer services, improve brand value, to increase customer base...

These goals can be achieved either by enhancing existing solution by adding feature or functionality, fixing issues or problems in exiting solutions or implementing new regulations or improving the process, building a new solution for introducing new products or services or developing new decision support system to make effective decisions.

It covers strategy analysis, requirement engineering and IT analysis to define and recommend a solution to the problem or an opportunity within the organization.

Business Analyst primarily identify and define the problem using various BA techniques and recommend solutions for that so that organization can achieve its goals and objectives.

• Bottom up approach: There is problem identified by users/customer in existing system and it is reported to managers. After detailed investigation, there is a need to enhance the existing solution partly or fully
• Top-Down approach: There is new opportunity idenfited by management to expand the exiting product line or implement new products/services. After detailed investigations, the appropriate solution is defined and implemented.
• Peer-to-peer: There is productivity issue identified by mid-level managers and needed decision support systems. After detailed investigations, the appropriate business intelligence solution is need to make effective decisions. This is where BI will play a role.

The scope of Business Analysis is larger than Business Intelligence as it can be applied to any kinds of problems or opportunity including BI.

Knowledge and Skills: Business Analysis, Domain Knowledge (to collaborate with stakeholders and domain subject matter experts, and technical know-how (SDLC, Testing, Data modeling, data management and others…to collaborate with IT team)

Business Analysis vs Business Intelligence
Source: ANISAN Technologies (www.anisans.com)

Business Intelligence: "a set of techniques and tools for the acquisition and transformation of raw data into meaningful and useful information for business analysis purposes"

Whereas Business Intelligence job is more technical role that involves several related activities, including data mining, online analytical processing, querying and reporting to analyze an organization's raw data using a variety of software applications. The BI specialist will work towards putting up effective system to extract, load, transform (ETL) and generate reports from heterogeneous data source such as SAP, PREST, ETU, RH, ORACLE...

Knowledge and Skills: technical skills like coding and knowledge of data analysis tools/ languages like R, SaS, Python etc.

What Business Analyst needs to know about Agile Approach?

Here is the brief blog written on "What Business Analyst need to know about Agile approach?" in Q & A form. It is helpful for you to know about Agile in-depth and will also be helpful in preparing you for your Business Analysis interview. This blog will focus more on Scrum as it is more popular and widely used Agile approach. My next blog will have summary of other Agile approaches.

Please explain - what is Agile.
Agile is an approach to project management that is used in developing software solution. It is group of methodologies based on incremental and iterative approach to help the team to respond to the unpredictability of building a software solution. It also helps the team to explore the solution as requirements continuously evolve through assessment and adaption while producing the software solution through a series of demonstrable, executable releases of product/project.

The process can be custom-made by development or client or organization optionally based on the technical constraint, organizational standards, team’s comfort, or project scope, budget.

The point to remember that every iteration progressively contributes to developing and delivering the solution.

Following are some of the ‘Agile’ methodologies:

· Extreme Programming
· Scrum
· Lean Software Development (LSD)
· Feature Driven Development (FDD)
· Dynamic Systems Development Method (DSDM)
· Agile Unified Process (AUP)
· Adaptive Software Development (ASD)
· Kanban

Scrum is most commonly used Agile approach in the modern IT environment.

What are agile manifesto?

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Explain Scrum. How did you use it in your last project?

We used Scrum as it is the most preferred agile framework. We applied in managing and controlling iterative and incremental software solution (projects).

(for additional information: Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed considerably to the evolution of Scrum.

The “Scrum’ is derived from rugby game where the ‘scrum’ means of restarting play after a minor infringement.)

We applied common strategies of Agile as follows:

• Sprint consisted of 3-4 weeks that was delivered in the form of workable component or feature.
• Informal communication: It was close interaction among small team (2-12). 
• Light and informal communication: Along with informal communication and informal process were followed. These meeting were frequent and face-to-face to understand the progress from every team members and resolved the issues, if any.
• Change management: was informal and changes were welcome at late stages
• Customer collaboration: Each iteration or sprint was delivered to user to access. The changes or improvement were done during the following release(s).
• Informal Process: Every sprint or iteration was part of product or solution. End of the release the component, the remaining components were assessed and prioritized for the next development. If any new component was added and was found to be important, it was accommodated before other complements were developed depending on the prioritization. This prioritization was part of every post release activity and no changes were added once the Sprint was in the process.
• From technical perspective, every iteration or Sprint was considered as a mini-project that went through entire lifecycle phases (define, requirement analysis, design, development, test and deployment) in compressed and fast paced mode.

What is Product Backlog?

‘Product Backlog’ is a prioritized Backlog containing the end user requirements. It is also a prioritized list of features (requirements or bug fixes, non-functional requirements, etc.) that contains short descriptions of all functionalities desired to be implemented to deliver the working or potentially shippable increments of the software product or solution.

This is used in place of traditional requirement specifications such as BRD (business requirement document) or a product roadmap or SRS (Software Requirement Specification).
The product owner owns the product backlog. Product owner along with cross-functional team estimate and sign off to deliver potentially shippable increments.
Stakeholders and other team members can add stories / features / functionality / requirements to the product backlog in the form of ‘To-Do’ list.
Product backlog is enough to start work in Scrum instead of lengthy formal documentation used in traditional project management approach.

#	User Story	Priority	Estimation
1	As an authorized user, I want to access ‘manage beneficiary’	1	2
2	As an authorized user, I want add a beneficiary	2	3
3	As an authorized user, I want to edit beneficiary	3	1
4	As an authorized user, I want to set transfer limit to the beneficiary	5	1
5	As an authorized user, I want to receive alter on my registered mobile phone after completing the transfer	6	2
	Total		9

• Each story adds a value to the user/customer.
• Each story is prioritized and developed in an order.
• Any team members can add a story and delete (his/her) story at any time during the project life cycle. 
• However, a “Sprint” (or iteration) can’t be changed by adding or removing story. 
• The product backlog is analyzed and re-prioritized after every “Sprint” and based on the prioritization, the stories are selected for development for the next “Sprint”
• The Product backlog is updated during entire project life cycle.
• All stories are estimated.
• All the stories are complete within and no low level tasks are added in the product backlog.

What do you understand the term ‘an epic’ in an agile project?

There are many requirements scattered across the multiple areas of the complex solution or product. The segregation and grouping of the User Stories belonging to the same domain is known as ‘an Epic’. An Epic is complete when all the User Stories are added and concluded.

What is the User Story in Agile?

A User Story is a requirement / feature / functionality described in the form of a story. User Story explains ‘who’, ‘what’ and ‘why’ of a particular requirement.

For example: As an authorized user, I want to access ‘manage beneficiary’ to add the new beneficiary.

This will define:

Who - authorized user,

What - access ‘the manage beneficiary’ functionality,

Why - to add the beneficiary

During the life cycle, these user stories are identified, prioritized, and selected for a Sprint for implementing. They are further specified into tasks, estimations and other details related to tasks.

What is Sprint?

Sprint is an iteration or basic unit of scrum approach. It is typically consist of 3-4 weeks or 30 days. Software solution / software product is delivered through successive sprints.

What is a sprint backlog?

Similar to Product backlog, a sprint backlog is a list of features and requirements that team shall achieve in the next sprint. It is based on requirements priority and development team’s ability to complete the work.

What is the sprint-planning meeting?

The sprint meeting is conducted at the beginning of every sprint. The product owner, scrum master, and development team member(s) meet to understand the capability of the team, create the ‘sprint backlog’ by prioritizing the items, plan and delegate the work for the sprint. Although some mention 8 hours required for the sprint-planning meeting, but, there can’t be a fixed duration of the same as the components may not take same duration to discuss and finalize.

What is Daily Scrum Meeting?

As name indicates, these are short terms strategies. Every day during the sprint, the team assembles to discuss the progress of the sprint and strategy, if necessary. It is short (average 15 min long) and informal that can be even done at the team member’s desk.

Each member in turn answers three questions:

1. What did I do since the last Scrum meeting?

2. What do I plan on doing between now and the next Scrum meeting?

3. Do I have any roadblocks?

What is Scrum (Kanban) Board? What is a ‘Story Board’?

This board represents the progress in the ‘Agile’ approach.

You can create virtual or manual story board by placing note on each section.

The column indicates the stage and row indicates the User Story/task in a particular stage.

This is an excellent way to represent the status of the User Stories/tasks along with the project.

Design	Development	QA Testing	UAT	Deployment	Done
Task L	Task H	Task E	Task C	Task B	Task A
Task M	Task I	Task F	Task D
Task N	Task J	Task G
Task O	Task K
Task O

Or

Product Backlog	In Sprint (Development)	Delivered
Task F	Task C	Task A
Task G	Task D	Task B
Task H	Task E
Task I

Explain Sprint Review Meeting.

At the end of sprint or on the last day of the ‘Sprint’, there are two ‘sprint review meetings’ – one for customer review and demonstrations and other for team to review for the possible improvements. The adequate time is allowed (some can calculate by deriving the value from.

The duration of the meetings may vary. For each week of sprint duration, apply one hour of meeting time for the customer review. For the retrospective, apply .75 hours (45 minutes) for each week of Sprint duration. For example, a 30-day Sprint would result in a four-hour review and three hour retrospective. A two weeks Sprint would result in a two hour review and a one-and-a-half hour retrospective. Additionally, the team should spend no more than one hour preparing for the review.

These are the meetings that review - what was achieved in the course of the sprint and what is left.

What is Sprint Retrospective (meeting)?

Team members analyze the past sprints to understand the "lesson learned"  from the previous project to avoid similar mistakes and improve continuously.

What is Scrum Framework?

It outlines broad guidelines for scrum projects with few rules (dos and don't), roles (Product owner, Scrum master, scrum team), artifacts (deliverables or prioritized backlog) and events (Scrum Planning Meeting, Scrum Meeting, Sprint Review Meeting etc.) to deliver a software solution or products via iterative, interactive, and incremental approach.

This framework provides guideline for the role, nature of customer collaboration, communication.

It works on a principle of:

- Continuous improvements - inspect & adapt policy to engineering processes, product, and requirements.

- Change Management – is an integral part of project life cycle.

Thus, the framework allows defining only high-level requirements at beginning and low-level requirements at later stage/during implementation.

Communication: Scrum Product Owner collaborates with scrum master and scrum team to identify and prioritize the user stories/functionalities.

Why do we use a sprint burn-down chart?

It is graphical presentation of the progress of the sprint that is updated daily during the sprint.

Explain the Scrum Team and their role?

Scrum Team comprises of Product Owner, Scrum Master and the Development Team.

Product Owner:

Product Owner is a primary stakeholder of the software product/solution. He works intently with the team to create product backlog by identifying, adding, modifying and prioritizing the user stories.

Scrum Master:

Scrum Master works as a facilitator to the project team. He manages resources, enforces the scrum rules on the team, lead the scrum meeting, and guide the team as required.

Scrum Team:

The team decides what and how much they can do in a given project iteration or a Sprint. The team is responsible for developing and delivering the sprint.


What the term ‘Spike’ in scrum?

Spikes are time bound planned activities or sessions between the Sprints created for analyzing or answering queries.

What is the Velocity of a sprint?

It is the capability of the team to complete the work during a particular Sprint that is derived from analyzing the historical data.

What is ‘Tracer Bullet’?

The ‘Tracer Bullet’ is a ‘Spike’ or analyzing session using latest technology, latest architecture and latest best practices in the industry to produce top quality product.

What do you know about ‘Impediment’?

Impediments are ‘the causes’, which are hindering the team or team member to achieve their goals or maximum capability.

What do you mean by ‘ScrumBag’?

‘ScrumBag’ is the person or group or any factor responsible for ‘Impediment’.

Do you know ‘Invest’ in Scrum?
‘Invest’ suggests the characteristics of a good ‘User Story’ based on following criteria:

Autonomous: No other ‘User Story’ is depending on.

Zero-Trade-Off – No further negotiation required for this

Value – User Story brings in sizable value to the end product.

Scalability – The User Story can fit various sizes easily

Testability – It is testable to verify the success criteria of implementation of the User Story.

What is Planning Poker?
It is bringing consensus among the team on estimation of a particular User Story during planning phase.

Planning Poker Cards are distributed to the team members. Each card has a number that is associated with estimations in the form of either hours or days. Once a User Story is selected, every team member is asked to display their card that conveys their estimation for that User Story. If all the cards display the same number, that number (estimation) is finalized as ‘estimation’ for the User Story.

In case the cards displayed have different numbers for a User Story, estimations are discussed and finalized by brining everyone on an agreeable term.

Reference: 

1. Agile Estimation and Planning by Mike Cohn

2. Scrum Institute 

(http://www.scrum-institute.org)