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: The Question And Answer Book - Launch

Afternoon newspaper, a leading daily published in Mumbai covered book, 'Business Analysis: The Question And Answer Book' and author, Sandhya Jane.

Afternoon article excerpt: Based out of Hong Kong, Sandhya is quite a jack of all and a master of all. "The key to balancing work, writing and parenting is to focus on each and giving each my all in that moment. When I am spending time with my son, I am not thinking of work and when I am working everything else is switched off," she said.

A message for aspiring writers? "Discipline," she quipped. "That is one quality that can take you from point A to point B successfully. Many people have excellent ideas but struggle to implement them. The key to being successful is to go ahead and make that first draft before changing it a million times if need be. However, that first step is the most important and also the most difficult step," she added.

Here is the link to complete article: http://www.afternoondc.in/education-careers/business-analysis-for-dummies/article_203871

How to conduct Stakeholder Analysis?

The basics of requirement management is planning for stakeholder analysis. If you miss this, you will face many hurdles. Stakeholder analysis is key to succeed in your project as missing any stakeholder in the stakeholder analysis means that stakeholders requirements will add to the project as either an additional requirements or a change. Both would have an impact on project timeline and budget. Moreover, the stakeholder may be disappointed for not counting him/her in the first place.

Let us understand how to work on stakeholder analysis...following are few tips of analyzing the stakeholders and creating the list in most effective way.

- By studying the business need (problem or an opportunity) and solution scope document to understand stakeholders and their involvement.

- Outlining the stakeholders’ details by studying the organizational structure or modelling the organization (enterprise architecture) and their relationships, and communication.

- Getting additional details through existing documents related to stakeholder analysis.

- Communicating and collaborating with identified stakeholders to confirm details thus obtained (except for details on their attitude and persona).

Process: First identify the impact of the business need (problem or an opportunity). Once you know the details, that will become your basis to build stakeholders. You also obtain organizational structure to understand the people and their role. You discuss with the main stakeholders to identify the stakeholders or you can obtain the official stakeholders list as some of organizations have formal designated person for every dept who act as stakeholder(s) for them.

You can compile the data in excel and verify the data with the relevant stakeholders.

The data can be compiled using following parameters.

1. # / Stakeholder Number
2. Name
3. Contact Number
4. Email
5. Location
6. Role
7. Responsibiltiies
8. Authority Level
9. Profile or
10. Technical skills / proficiency
11. Preferred environment
12. Special Needs
13. RACI (R - Responsible, A - accountable, C - consulted and I Informed. Some may add S for support, but that is an optional)
14. Additional Description
15. Group / category
16. Influence *
17. Attitude *

Please remember that all the information can be send to stakeholders to validate the data, except last two (influence and attitude) unless you want get fired. This list must be modified by authorized person to avoid complication of loss of data or changes made to the documents.

You can add more parameters to this and create a matrix that can be easily used.

How Business Analyst defines a "business need"?

Here is the short blog on how to how to define the Business Need (either a problem or an Opportunity)

These high level guidelines or parameters will help business analysts defining their Business Needs.

Understand the business:

1.1 Business definition:

Business definition consist of analysis of following information:

1.1.1 What is the 'Entity Type'?
you need to define if the is proprietary or Corporate or Public Limited or Cooperative or Government…
You need to understand what are their governance standards  (such as tax, regulatory process) and requirements. and do they impact on your business need in anyway?

1.1.2 What is the Business Domain?
Is it agriculture or Service, or Hospitality or Defense or  Health Care or Banking or retail or manufacturing, or logistics and so on...

1.2. Products and Services:

1.2.1. Organization Structure (organization units and sub-units and how they are connected to main entity/Head office. People and their association with these entities and their role and position in the organization hierarchy)

1.2.2. Management and its culture (Democratic, lean management, hierarchal, traditional, modern….) Quality policy and standards, quality management process, values and beliefs

1.2.3. Clients, customers and the market: To understand their background and the special needs

1.2.4. Operations and legal and compliance requirement: How the products and services are reached to the end customers?

1.2.5. Organization goals: Long term and short term goals

1.2.6. Core competence: Products and services and other issues. Why these are better selling products compare to their competitors.

1.2.7. Competitive stance: who are competitor and comparison with competitors

1.3. Industry Standards 

  1.3.1 Current Industry Benchmark

  1.3.2 Current and potential future trends in the industry

1.4 New regulations

All these information and data is very useful to analyze the business in comprehensive manner. Without this analysis, the Business Analyst cannot provide the correct business solution that is appropriate the organization.

1.5 Background of Business Need (problem/opportunity):

When we identify the problem or the opportunity we have following area to work on:

1. The Record the problem or opportunity area.

2. Source of the problem or the opportunity:

3. Background of the problem: How it has arisen? Or how the opportunity has been generated.

Impact analysis or identify business value or Business Impact Analysis (BIA):

4.1. Area (department, functions): which part of the organization or which functions are getting affected with business need. For example, the problem is in retrieving sales data for retail chain store, check if the problem is in one region or it is across the region. Or it could be one ‘field’ or some more fields.

4.2. Stakeholders: Who (role – user or customer, signing off authority) are getting affected directly or indirectly? Are there more number of stakeholders is getting impacted with the problem or opportunity. The nature of impact needed to consider before the business need is fully defined. Pls refer stakeholder analysis in planning phase for more details.

4.3. Business Operations: where the impact is? One process or entire business processes are affecting? Is it industry wide impact (example. Change in service tax may affect the pricing and accounting process of the organization. Whereas, implementation of Basel II and Basel III would affect entire banking industry irrespective of size or location).

The best way to approach the problem is to complete the “Gap Analysis” where current business processes are compared against new (required) business processes and the organization’s current and future capability required implementing the same.

5. Financial and non-Financial impact of proposed solution

5.1 Will it increase revenue?

5.2 Will it decrease expenses?

5.3 Will it bring in new customers?

5.4 Will it bring in more money from existing customers?

5.5 Will it improve employee moral?

5.5.1 Not all the problem solving will result into business value such as financial and brand value. Sometime, resolving problem may result into improving the process that result into making things easier for employee in performing their daily work. Repeated work, instant access of data to make decision, decision support system.

5.5.2 Redundant process or lengthy or cumbersome process can be improved to make employees easy to do their daily work without unnecessary hurdles for additional approval or so on. This may result into improved employee moral with additional challenging project/work in their professional life.

6 Brand and image impact: problem within existing products or services or problems related to customers or problems related to operations ie delivery of products / services to the end customers.

6.1 Will it increase shareholder/taxpayer value? Increased customer satisfaction or improved products of services may result into increased revenue. Reduced operations cost could result into increased revenue. Both the cases, there will be direct or indirect impact on shareholder value.

7 Policy, Legal and compliance

7.1 Any new compliance or policy change may result into change in exiting operations or need for new business operations. Either way it may result into need of new business systems.

Once you analyze the business need on above parameters, you will have an understanding of business need and it's impact on the business. This analysis will support the stakeholders to make a decision - go/no-go.

More details in next blog - how to create a business need documents using these parameters and support the solution scope.

Reference:

http://www.uie.com/articles/business_value/

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)