Business analysis

Focuses on understanding the needs of the business as a whole, its strategic direction, and identifying initiatives that will allow a business to meet those strategic goals. It also includes:

• Creating and maintaining the business architecture
• Conducting feasibility studies
• Identifying new business opportunities
• Scoping and defining new business opportunities
• Preparing the business case
• Conducting the initial risk assessment

Involves planning the requirements development process, determining which requirements are the highest priority for implementation, and managing change.

Describes techniques for collecting requirements from stakeholders in a project. Techniques for requirements elicitation include:

• Brainstorming
• Document analysis
• Focus group
• Interface analysis
• Interviews/Questionnaire
• Workshops
• Reverse engineering
• Surveys
• User task analysis
• Process mapping
• Observation/job shadowing
• Design thinking
• Prototyping

Describes how to develop and specify requirements in enough detail to allow them to be successfully implemented by a project team.

The major forms of analysis are:

• Architecture analysis
• Business process analysis
• Object-oriented analysis
• Structured analysis
• Data warehouse analysis, storage and databases analysis

Requirements documentation can take several forms:

• Textual – for example, stories that summarize specific information
• Matrix – for example, a table of requirements with priorities
• Diagrams – for example, how data flows from one structure to the other
• Wireframe – for example, how elements are required in a website,
• Models – for example, 3-D models that describes a character in a computer game

Describes techniques for ensuring that stakeholders have a shared understanding of the requirements and how they will be implemented.

Describes how the business analyst can perform correctness of a proposed solution, how to support the implementation of a solution, and how to assess possible shortcomings in the implementation.

This is used to perform an external environmental analysis by examining the many different external factors affecting an organization.

The six attributes of PESTLE:

Political (current and potential influences from political pressures)

Economic (the local, national and world economy impact)

Sociological (the ways in which a society can affect an organization)

Technological (the effect of new and emerging technology)

Legal (the effect of national and world legislation)

Environmental (the local, national and world environmental issues)

This is used to perform an in-depth analysis of early stage businesses/ventures on seven important categories:[4]

Market opportunity

Product/solution

Execution plan

Financial engine

Human capital

Potential return

Margin of safety

Is essentially another take on PESTLE. You will notice it factors in the same elements of PESTLE and shouldn't be considered a tool on its own except an author/user prefers to use this acronym as opposed to PESTLE. STEER puts into consideration – the following

Socio-cultural

Technological

Economic

Ecological

Regulatory Factors

This is used to perform an internal environmental analysis by defining the attributes of MOST to ensure that the project you are working on is aligned to each of the four attributes.

The four attributes of MOST are:[5]

Mission (where the business intends to go)

Objectives (the key goals which will help achieve the mission)

Strategies (options for moving forward)

Tactics (how strategies are put into action)

SWOT is used to help focus activities into areas of strength and where the greatest opportunities lie. This is used to identify the dangers that take the form of weaknesses and both internal and external threats.

The four attributes of SWOT analysis are:

Strengths – What are the advantages? What is currently done well? (e.g. key area of best-performing activities of your company)

Weaknesses – What should be improved? What is there to overcome? (e.g. key area where you are performing unsatisfactorily)

Opportunities – What good opportunities face the organization? (e.g. key area where your competitors are performing poorly)

Threats – What obstacles does the organization face? (e.g. key area where your competitor will perform well)

This is used to prompt thinking about what the business is trying to achieve. Business perspectives help the business analyst to consider the impact of any proposed solution on the people involved.

There are six elements of CATWOE:[6]

Customers – Who are the beneficiaries of the highest level business process and how does the issue affect them?

Actors – Who is involved in the situation, who will be involved in implementing solutions and what will impact their success?

Transformation Process – What processes or systems are affected by the issue?

World View – What is the big picture and what are the wider impacts of the issue?

Owner – Who owns the process or situation being investigated and what role will they play in the solution?

Environmental Constraints – What are the constraints and limitations that will impact the solution and its success?

This is often used in a brainstorming session to generate and analyse ideas and options. It is useful to encourage specific types of thinking and can be a convenient and symbolic way to request someone to "switch gears". It involves restricting the group to only thinking in specific ways – giving ideas & analysis in the "mood" of the time. Also known as the Six Thinking Hats.

White: Pure facts, logical.

Green: Creative.

Yellow: Bright, optimistic, positive.

Black: Negative, devil’s advocate.

Red: Emotional.

Blue: Cold, control.

Not all colors / moods have to be used.

Five Whys is used to get to the root of what is really happening in a single instance. For each answer given a further 'why' is asked.

This is used to prioritize requirements by allocating an appropriate priority, gauging it against the validity of the requirement itself and its priority against other requirements.

MoSCoW comprises:

Must have – or else delivery will be a failure

Should have – otherwise will have to adopt a workaround

Could have – to increase delivery satisfaction

Won't have this time – useful to the exclude requirements from this delivery timeframe

This technique is used when analyzing the expectations of multiple parties having different views of a system in which they all have an interest in common, but have different priorities and different responsibilities.

Values – constitute the objectives, beliefs and concerns of all parties participating. They may be financial, social, tangible and intangible

Policies – constraints that govern what may be done and the manner in which it may be done

Events – real-world proceedings that stimulate activity

Content – the meaningful portion of the documents, conversations, messages, etc. that are produced and used by all aspects of business activity

Trust – between users of the system and their right to access and change information within it

The SCRS approach in business analysis claims[7] that the analysis should flow from the high-level business strategy to the solution, through the current state and the requirements. SCRS stands for:

Strategy

Current State

Requirements

Solution

The Business Analysis Canvas is a tool that enables Business Analyst to quickly present a high level view of the activities that will be completed as part of the business analysis work allocation. The Business Analysis Canvas is broken into several sections.

Project Objective

Stakeholder

Deliverable

Impact to Target Operating Model

Communication Approach

Responsibilities

Scheduling

Key Dates

The Canvas has activities and questions the Business analyst can ask the organization to help build out the content.[8]

Processes are modeled visually to understand the current state and the models appear in levels to understand the enablers that are influencing a particular businesses process. At the highest level of the models are end-to-end business processes that would be common to many businesses. Below that business process level would be a level of activities, sub-activities and finally tasks. The task level is the most granular and when modeled depicts a particular workflow. As business processes get documented on the workflow level, they become more heavily influenced or "enabled" by characteristics that impact that particular businesses. These "workflow enablers" are considered to be Workflow Design, Information Systems/IT, Motivation and Measurement, Human Resources & Organization, Policies and Rules, and Facilities/Physical Environment. This technique of process leveling and analysis assists business analysts in understanding what is really required for a particular business and where there are possibilities to re-engineer a process for greater efficiency in the future state.

Project delays are costly in several ways:

• Project costs – For every month of delay, the project team costs and expenses continue to accumulate. When a large part of the development team has been outsourced, the costs will start to add up quickly and are very visible if contracted on a time and materials basis (T&M). Fixed price contracts with external parties limit this risk.[11] For internal resources, the costs of delays are not as readily apparent, unless time spent by resources is being tracked against the project, as labor costs are essentially ‘fixed’ costs.
• Opportunity costs – Opportunity costs come in two types – lost revenue and unrealized expense reductions. Some projects are specifically undertaken with the purpose of driving new or additional revenues to the bottom line. For every month of delay, a company foregoes a month of this new revenue stream. The purpose of other projects is to improve efficiencies and reduce costs. Again, each month of failure postpones the realization of these expense reductions by another month. In the vast majority of cases, these opportunities are never captured or analyzed, resulting in misleading ROI calculations. Of the two opportunity costs, the lost revenue is the most egregious – and the effects are greater and longer lasting.

On a lot of projects (particularly larger ones) the project manager is the one responsible for ensuring that a project is completed on time. The BA's job is more to ensure that if a project is not completed on time then at least the highest priority requirements are met.

Business analysts want to make sure that they define the requirements in a way that meets the business needs, for example, in IT applications the requirements need to meet end-users' needs. Essentially, they want to define the right application. This means that they must document the right requirements through listening carefully to ‘customer’ feedback, and by delivering a complete set of clear requirements to the technical architects and coders who will write the program. If a business analyst has limited tools or skills to help him elicit the right requirements, then the chances are fairly high that he will end up documenting requirements that will not be used or that will need to be re-written – resulting in rework as discussed below. The time wasted to document unnecessary requirements not only impacts the business analyst, it also impacts the rest of the development cycle. Coders need to generate application code to perform these unnecessary requirements and testers need to make sure that the wanted features actually work as documented and coded. Experts estimate that 10% to 40% of the features in new software applications are unnecessary or go unused. Being able to reduce the amount of these extra features by even one-third can result in significant savings. An approach of minimalism or "Keep it Simple" and minimum technology supports a reduced cost number for the end result and on going maintenance of the implemented solution.

Efficiency can be achieved in two ways: by reducing rework and by shortening project length.

Rework is a common industry headache and it has become so common at many organizations that it is often built into project budgets and time lines. It generally refers to extra work needed in a project to fix errors due to incomplete or missing requirements and can impact the entire software development process from definition to coding and testing. The need for rework can be reduced by ensuring that the requirements gathering and definition processes are thorough and by ensuring that the business and technical members of a project are involved in these processes from an early stage.

Shortening project length presents two potential benefits. For every month that a project can be shortened, project resource costs can be diverted to other projects. This can lead to savings on the current project and lead to earlier start times of future projects (thus increasing revenue potential).