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

Automated model-driven BPMN approach for Business Analyst

This is my review to research paper “Resource-based Modeling and Simulation of Business Processes” written by Andrea D’Ambrogio. It is an interesting research paper that explores the simulation-based analysis of business processes that covers all the phases in BP lifecycle, starting from design to execution and improvement to post implementation enhancement phases.

The goal of the paper is to introduce a reliability in analysis that considers unexpected failures of resources to execute the process task due to unavailability of a resource allocated to a task.

The paper exploits both model-driven principles and Discrete Event System Specification, also known as DEVS.

This process requires first interpreting the BPMN model with the allocation of task resources described in terms of performance and reliability properties of the task resources and then transforming the annotated BPMN model into a DEVS-based model that in turn analyzes and produces the better outcome. This DEVS-based model can be used effectively by business analysts due to their unfamiliarity with or lack deep knowledge of the formalism. In addition, the author of the paper has proposed the automated model-driven approach, which would overcome the issues related to the manual building DEVS model, which are effort and time consuming, as well as error free. The mapping of BPMN elements to DEVS atomic models are later linked to the process control flow logic to get the final DEVS-coupled model. Work is currently in process to complete the specification of mapping rules for basic BPMN elements.

If this research is applied to advanced BPMN and becomes successful, it will have more scope in writing business requirements, business rules, and designing the systems.

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.

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.

The role of Business Analyst in designing UI/UX prototypes

''What is the role of business analyst in designing UI (User Interface) /UX (user experience) prototypes?' This was an interesting question asked of me to answer by a student. After responding, I thought of writing a detailed blog on this topic to cover many aspects of UI/UX design, as it is one of the most interesting but least visited topics. 

Most of the time, UI and UX are used interchangeably, however, they represent different areas. Let’s take a few minutes to understand and differentiate between them. 

User Interface (UI): User interface design focuses on better interaction with solutions and the design may focus on the placement of menu, look, and feel of the page. 

The goal of user interface design is to make the user's interaction as simple and efficient as possible, in terms of accomplishing user goals (user-centered design). Good user interface design facilitates finishing the task at hand without drawing unnecessary attention to itself. 

User Experience (UX): UX focuses on optimization of a software solution in terms of users' experiences and their feelings associated while interacting with the solution or product. It is human-computer interaction in a useful and meaningful way. For example, effortless identifying of the menus, flexible font size, usage of white space to declutter the website (and readers' minds), or using a familiar color (logo color) to enhance the product ownership. 

UI/UX Design Life Cycle.

User Need: This is an initial activity when need is identified. Business Analyst will understand the user problem or an opportunity. For that, business analyst will refer current state and other relevant documents to understand the current design and related issues and the focus area for proposed solutions.

Elicitation: There are no specific standards available for preparing the UI / UX designs. However, the business analyst can use standards that are specific to the project, their comfort level, and consideration of the internal and external usability standards that may be applicable. The requirements are split into requirements (descriptive text) and model/design (descriptive pictures/models). These are mentioned in IIBA's BABOK Guide version 3 You can use the same standards or customize as needed. 

Business analysts can elicit these requirements through design or models in collaboration with stakeholders and users. The business analyst can provide the details in the form of: 

Requirements: Functionality, features, and data needed in designing UI/UX Design. In addition, the user inputs these and validations needed for the same are also elicited. 

Organization policies and standards (internal and external): Internal policies will include the organization’s standards or policies for creating the UI and usability standards; for example, using colors, fonts, placement of items such as logos and menus, and so on. It will also include menu style, pagination, and navigation across sub-pages. While the external standards will include the standards specified by web browser (Safari 9.1.3 or Internet Explorer 10.0 etc...) operating system (Windows, Mac etc...), external agencies to whom you are sending or receiving feeds, and other requirements... These details need to be part of the requirement and provided to the designer for preparing the prototypes/wireframes. The design style will include menu style, pagination, and navigation across sub-pages. You can use a template/excel sheet to describe the details (for example: first name, input box, size, position) and provide them the basic design in MS Visio.

UI/UX Approach

Design/Prototype Approvals: Once the designs are prepared, the business analyst can use these designs/prototypes and the supporting materials (such as the excel sheet that was provided to technical person to create the prototypes) as a requirement to complete a mock-up and communicate them to the stakeholders. The stakeholders will review both the design and the supporting documents, and provide their feedback to improve, if needed. Once the changes are made and the designs are presented, they are required to verify and validate before starting the approval process. These designs and supporting documents become your verified and validated requirements for UI/UX.

At the end, the stakeholder preference will overrule all other standards in defining the UI/UX design. For example, do stakeholders prefer to follow industry standards such number of clicks for a functionality or detailed functionality, standard placement of menu over customized menu, and more.

User Acceptance (Validation): Ensure that all the windows are prepared and connected; i.e., the flow of the requirement screen by screen using all the flows mentioned in the FRD (basic flow, alternate flow, and exceptions). Some business analysts are creating this type of wireframe. But it is an option, as they can get these completed by the technical person.

Deliver: These approved designs are delivered along with supporting requirements to the technical team to develop. Once the development is completed, they are tested and deployed.

Enrich and Enhance: Once the solution settles in user community (production environment, website, or product delivery/acceptance) with no new bugs or issues reported, the enrichment and enhancement will begin as needed. UI/UX is most dynamic interface in comparison  to other part in solution architecture.  

Principles of UI/UX Design:

UI/UX design principle

Consumer apps can be trendy and catchy to appeal to the customers and business analyst can expect fewer formalities or standards used in these types of apps.

Summary: The UI/UX designs depend on the types of app or solution and stakeholders or user preference.

The designs are presented, reviewed, and confirmed before they enter into the development phase.

The scope of Business Analyst Role

The scope of the business analysis is infinite as it deals with a broad term ‘improving business with or without technology’. Any work within that spectrum is business analysis, for example, it could apply in improving a small process within a department or implementing a relugaltory framework across the industry or building a product (Apple had an app for music but couldn’t use it independently. On other hand, Hitachi developed a mini storage that could hold 1 GB data and they didn’t know what to do with it. Steve Jobs integrated both invention to create iPod that was one of the most successful products during its time).

The scope of business analysis work can broadly categorized into three areas:

1. Strategy Analysis
2. Business Analysis
3. IT System Analysis

(Reference: Debra Paul, Donald Yeats and James Cadle in Business Analysis, Second edition, published by BCS)

Following is the partial list of scope within the lifecycle that covers all the areas mentioned above.

• Business Strategy Analysis - Part I: These Business Analyst come from business/domain background who define the business need, high level solution scope and present the business case to the sponsors. 
• Business Technology optimization and management
• Process management
• Define the business need (problem or an opportunity)
• Define solution scope that would to cater to the business need
• Define and present business case (cost vs benefits analysis)
• Secure funding
• Business Analysis: These Business Analyst come from either business or technical background who start the core business analysis once the business need is defined or project is funded. These Business Analysts, primarily involved in eliciting the requirements and defining the solution. In addition, they are also involved in identifying the IT team (internal or external) and managing them during the solution development and implementation.
• Elicit Requirements, document them, confirm them, scope them, present them and get them approved / signed them off.
• Define solution or BRD or Product roadmap
• Further requirement analysis (FRD, Requirement models and so on…)
• Identify or recommend IT team (internal or external)
• Finalize solution and its scope
• Strategy Analysis - Part II
• Verify and validate the solution against the enterprise need, current ability and new business case analysis (cost vs benefit) to accept the solution
• IT Business system or System Analysis: These Business Analyst come from technical background having software developing (coding) or testing testing skills who primarily collaborate with technical team members to communicate the requirements. They ensure that software solution meets the business requirements solution. They also act as a bridge in translating and transferring  business requirements into solution requirements (functional, non-functional and technical constraints) to help the technical team understand the business requirements. In addition, IT business analysts also collaborate with implementation SME (subject matter experts) to elicit the transition requirements that are needed for transitioning the software solution into user community. 
• Support technical team in requirement and change management
• Oversee the development and testing activities
• Ensure high quality solution is implemented
• Close out documentations
• End user training
• Enrich and enhance the solution during its lifecycle
• Orderly terminate the solution when it reaches to end of its lifecycle
• Strategy Analysis - Part III
• ROI to review the business case (cost vs benefits)
• Lesson learned
• Data Business Analyst - The business Analyst working in decision support systems are working closely with business stakeholders to understand their role and their needs in terms of reports needed for making effective decision. They also work with market research team in projecting market trends - past, present and future. In addition to business analysis skills, they are required to be well versed with SQL, dataware-hosuing or other tools, and advance excel and access to analysis the data. 
  These are BAs who deal with big data and statistics. They tend to crunch numbers using algorithms and data models. Similar to a data scientist, in a sense. They tend to determine market trends and present to business stakeholders on what direction they should take.
  Apart from above, there may be specialized designation assigned to a Business Analyst, such as Business Process Analyst (who focused on process engineering) or Product Business Analyst (who is involved in software product development) depending on the role.