Chapter 8: Starting a solution

* Optimal response for a future product should include:

-          Most VALUABLE service from the outsider’s view

-          Lowest COST from the organization’s view

-          Most PLEASING AND ENCOURAGING manner from user’s view

-> BA should consider the boundary or scope to produce the optimal response

(Tam Dinh)

Scenario Templates

Difference between Alternatives and Exceptions in the Scenario Template?

Alternatives are the acceptable variations in the process which won't affect the project outcomes and they are optional features involved in a project. For example: When withdrawing cash from an ATM machine, getting the receipt is the alternative available to the user. The user can deny or accept the option to obtain the receipt and that decision won't have any effect on the final outcome, which in this case is receiving the cash.

Exceptions refer to the unwanted result in the process. This has an effect on the final outcome and even a single exception has the potential to change the final result of the project. For example: When withdrawing cash from ATM, if cash gets stuck in the ATM this would be considered as an exception. This has the potential to change the final outcome which in this case is user failed to receive cash.

Written by Pavandeep Singh Boparai

Chapter 7 - Six Thinking hats

How six thinking hats can help Business Analyst to determine requirements?

There are six different thinking hats which can help each Business Analysts as follows:

White Hat: With white hat business analyst analyze available data and analyze the past trends and tailor it to the project they are currently working.

Red Hat: In Red Hat, Business Analyst look upon their problems in the project and they compare how others could have reacted to that problem and how they can manage that situation.

Black Hat: In the black hat, negative outcomes of their decisions are looked upon and they can create a risk management plan to avoid that situation. This helps them to prepare for potential risks involved in the project.

Yellow Hat: This is completely inverse of black hat and in this one can look upon all the possible benefits from their decision and it can help business analysts to keep going when something is going difficult.

Green Hat: In this Business Analysts develop creative solutions to a problem and it is really beneficial when the decision of Business Analyst is criticized and it encourages them to come up with creative solutions to a particular problem.

Blue Hat: This represents process control and this can be used by Business Analysts when something is going wrong and they can direct activity into Green Hat thinking

Written by Pavandeep Singh Boparai

Chapter 6 - Brown Cow model

What is a brown cow model and what does Brown Cow model do?

The brown cow model takes four views of work separated by how and what also by now and future.

How now: In this model, the implementation of work is described including physical artifacts, people and processors used to do work.

What now: This abstract depicts the real business policy or the essence of work. This quadrant shows the business as if no machines, people and organizational departments existed. This helps business to understand what the current business model is doing.

Future what: This view shows the business how it will be after the change and but still without the technology that might be used to implement that business. In this, the business analyst can discuss with stakeholders precisely what the owner would like to do without worrying about how technology might do it.

Future how: In this quadrant, the idealized future view of business policy is augmented with technology and people needed to bring it into the real world.

Written by Pavandeep Singh Boparai

Chapter 5 -Trawling for Business Requirements

Responsibilities of Business Analyst as work is looked at.

As a Business Analyst, one needs to look upon various kind of tasks as he/she is the bridge between different departments of the firm and assisting project team to get appropriate resources for the success of the project. Along with that when work is looked at by a Business Analyst, he needs to consider these responsibilities:

Talk: Business Analyst needs to communicate with different departments of the firm. He needs to communicate with all the stakeholders as well and he can help the project team in getting additional help from other departments.

Understand: As Business Analyst talks to different stakeholders he need to understand what they mean and what are their requirements. It is very important for him to understand the prospective of other end users as he is the person providing resources to the project team.

Determine: One of the difficult tasks is to determine the needs of someone and as a Business Analyst it is very important that you analyze the information provided by stakeholders to understand what they need and what they don't. Improper requirements are always one of the major reason for project failures and it also utilizes a lot of resources.

Learn: As Business Analyst look upon work he can learn better about the work.

Written by Pavandeep Singh Boparai

Chapter 4 - Business Use Cases

Who is a project sponsor and customer? What is the major difference between them?

A project sponsor is a person who invests in the project in order to get Return on Investment. Along with that, he is also responsible for the success of the project. He provides Business Use cases for project teams to work upon and clarify business priorities and strategies. In some cases, he can also provide additional resources for the project. Every project have at least one project sponsor and he acts as the voice of the project.

A customer is referred to end user of the product or the person who might be paying to use that service. A project team works on the project to fulfill the requirements of their customers. There could be different kind of customers like a firm developing software for their employees and a firm designing smartphone to sell to people to make money. Project success depends upon the feedback of their customers and there is at least one customer involved for every project.

Written by Pavandeep Singh Boparai

Chapter 3 - Project Blastoff

Why do projects have a project blastoff?
Project Blastoff meeting better is known as a project kickoff meeting that is held before initiating any project. It includes stakeholders involved in the project and it has the following objectives:

Identify the work area: Identifying work area can also be referred to estimating the scope of the project. Stakeholders involved in the project discuss about what work to do and it helps the project team to identify the work area and eliminating the unnecessary work.

Purpose of the project: It is very important to clarify the project requirements before initiating any task. By project blastoff meeting, Business Analysts can gather proper requirements and help the project team by developing user stories explaining what the product is intended to do, and what benefit it brings to the business. This statement of purpose is an explanation of why the business is investing in the project, along with the business benefit it wants to achieve.

Identify the stakeholder: It is very important for a Business Analyst to know about who the stakeholders are because they are the people to be affected by the project. It includes the person who is investing in the project, the person(s) providing requirements of the project, using the product and impacted by the project. As a business analyst, one should be aware of all the stakeholders involved.

Written by Pavandeep Singh Boparai

Chapter 2: The Requirement Process

Exploring, discovering, communicating and understanding the requirements are necessary in order to build custom systems or making changes to the pre existing software.

o   Right products require right discovery

It is always better to get an idea of the weakness of the project (its risk and cost) before being swept away by the excitement of the benefits that the new product is intended to bring.

Scenarios show the functionality of a business process by breaking it into a

series of easily recognizable steps, written in English (or whatever language

you use at work) so that they are accessible to all stakeholders.

Requirements are the foundation for all that is to follow in the product development cycle.

The intention is to canvas all the people involved in the project and ask these questions: 

1. What did we do right?  
2. What did we do wrong? 
3. If we had to do it again, what would we do differently?

Chapter 1: Some Fundamental Truths

There are eleven truths considered as parts of business requirement gathering.

The focus of business requirement gathering is understanding the business problem and then finding a solution.

Truth 4: There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter.

It is very difficult for an individual user to understand the broader ramifications of deploying a piece of software. Typically software users do not know enough about the wider business to decide whether this incarnation of software will cause problems in some other part of the business. 

Truth 11: BA will change the way users think about a problem. BA helps stakeholders understand and question the requirements.

When BAs have clear and measurable requirements, and when they reflect all this truth back to the stakeholders, it will change (for the better) their thinking about their business problem. Once people have a better understanding of the real meaning of their requirements, they are likely to see ways of improving them.