Business analysis

Business Analysis is a structured methodology that is focused on completely understanding the customer's needs, identifying how best to meet those needs, and then "reinventing" the stream of processes to meet those needs. Its purpose is to develop business process improvement (BPI) as a key strategy and a management tool, capable of supporting the organization's vision, mission, goals, and objectives, and to promote the use of technology throughout the organization.

Business analysis also helps an organization to improve the way in which it conducts its functions and activities in order to reduce overall costs, provide more efficient use of scarce resources, and better support its customers. It introduces the notion of process orientation, of concentrating on and rethinking end-to-end activities that create value for customers, while removing unnecessary non-value added work

Benefits of business analysis

According to Michael Hammer and James Champy, in their seminal work, "Reengineering the Corporation (1993)", business analysis "does not seek to make businesses better, through incremental improvements — 10 percent faster here or 20 percent less costly there". The aim of business analysis is "a quantum leap in performance — the 100 percent or even tenfold improvements that can follow from entirely new work processes and structures".

Some of the world's premier corporations have used the principles of business analysis to save hundreds of millions of dollars a year, to achieve unprecedented levels of customer satisfaction, and to speed up, and make more flexible, all aspects of their operations.

Roles of business analysts

As the scope of Business Analysis is very wide, there has been a tendency for business analysts to specialize in one of the three distinct sets of activities which constitute the scope of Business Analysis.

1. Strategist
Organizations need to focus on strategic matters on a more or less continuous basis in the modern business world. Business analysts, serving this need, are well-versed in analyzing the strategic profile of the organization and its environment, advising Senior Management on suitable policies, and the effects of policy decisions.

2. Business Systems Developer
Organizations may need to introduce change to solve business problems which may have been identified by the strategic analysis, referred to above. Business analysts contribute by analyzing objectives, processes and resources, and suggesting ways by which, re-design (BPR), or improvements (BPI) could be made. Particular skills of this type of analyst are "soft skills", such as knowledge of the business, Requirements Engineering, Stakeholder Analysis, and some "hard skills", such as Business Process Modelling. Although the role requires an awareness of technology and its uses, it is not an IT-focused role.

Three elements are essential to this aspect of the business analysis effort: the redesign of core business processes; the application of enabling technologies to support the new core processes; and the management of organizational change. This aspect of business analysis is also called "business process improvement" (BPI), or "reengineering".

3. IT Systems Developer
There is the need to align IT development activity with Business Systems development activity. A long-standing problem in business is how to get the best return from IT investments, which are generally very expensive and of critical, often strategic, importance. IT departments, aware of the problem, often create a Business Analyst role to better understand, and define the requirements for their IT systems. Although there may be some overlap with the "Business Systems Developer" role, the focus is always on the IT part of any change process, and generally, this type of business analyst gets involved, only when a case for change has already been made and decided upon.

In any case, the term, "Analyst", is lately considered somewhat misleading, insofar as analysts (i.e. Problem Investigators) also do design work (Solution Definers). Hence, the term, "Business Systems Architect" is coming into use for the "Business Systems Developers".

Business process improvement

File:ProcessAnalysis.png

A business process improvement (BPI) typically involves six steps:

1. Selection of Process Teams and Leader
Process teams, comprising 2-4 employees from various departments that are involved in the particular process, are set up. Each team selects a process team leader, typically the person who is responsible for running the respective process.

2. Process Analysis Training
The selected process team members are trained in process analysis and documentation techniques.

3. Process Analysis Interview
The members of the process teams conduct several interviews with people working along the processes. During the interview, they gather information about process structure, as well as process performance data.

4. Process Documentation
The interview results is used to draw a first process map. Previously existing process descriptions are reviewed and integrated, wherever possible. Possible process improvements, discussed during the interview, are integrated into the process maps.

5. Review Cycle
The draft documentation is then reviewed by the employees working in the process. Additional review cycles may be necessary in order to achieve a common view (mental image) of the process with all concerned employees. This stage is an iterative process.

6. Problem Analysis
A thorough analysis of process problems can then be conducted, based on the process map, and information gathered about the process. At this time of the project, process goal information from the strategy audit is available as well, and is used to derive measures for process improvement.

Goal of business analysts

Ultimately, business analysts want to produce the following outcomes:

Reduce waste and complete projects on time
Improve efficiency
Document the right requirements

One way to assess these goals is to measure the ROI or return on investment for all projects. Keeping score is part of human nature as we are always comparing ourselves or our performance to others, no matter what we are doing. According to Forrester, more than $100 billion is spent annually in the U.S. on custom and internally developed software projects. For all of these software development projects, keeping score is also important and business leaders are constantly asking for the return or ROI on a proposed project or at the conclusion of an active project. However, asking for the ROI without really understanding the underpinnings of where value is created or destroyed is like “putting the cart before the horse”.

Reduce Waste and Complete Projects On-Time
The biggest worry and most troublesome concern for Line of Business Executives is the waste of resources that occurs when projects are cancelled. Some project cancellations are widely reported and acknowledged in the media – the most notorious example in 2005 being the failed $170 million FBI project to update their case management system. Since no one wants to admit failure, especially public companies, the vast majority of internal corporate project cancellations are performed quietly and are not as widely reported as the FBI case. However, it is generally understood by most business people that cancellations do occur regularly in their organizations. A related topic is deciding when to cancel a project. Earlier identification and action will permit project resources to be re-deployed to other projects. Based on the number of projects that a company is pursuing at any given time, the total value of cancelled projects could be as much as 10% of the total annual IT development budget. Cancelled projects are not generally analyzed when developing ROI calculations.

Project delays are costly in three different dimensions:

Project costs – For every month of delay, the project team continues to rack up costs and expenses. When a large part of the development team has been outsourced, the costs will start to add up quickly and are very visible. For internal resources, the costs of delays are not as readily apparent as labor costs are essentially ‘fixed’ costs.

Opportunity costs – Opportunity costs come in two flavors – 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 misleading ROI calculations. Of the two opportunity costs, the lost revenue is the most egregious – and the impacts are greater and longer lasting.

Improve Project Efficiency
Efficiency can be achieved in two somewhat related dimensions – by reducing rework or extra work needed in a project to fix errors due to incomplete or missing requirements and by shortening project length.

Rework is one of the largest headaches facing CIOs and it has become so common at many organizations that it is actually built into the project budget and timeline. Estimates of rework on typical projects ranges between 20% and 30% of total project budget. Rework impacts the entire software development process from definition to coding and testing. One of the reasons for rework is that the requirements gathering and definition process is broken in most organizations and there is a huge disconnect between the business and technical sides of a project. While various technical solutions have helped make developers, coders and testers more efficient, very few solutions have been targeted at the business analysts who are tasked with delivering the requirements

Shortening project length produces two outcomes. For every month that a project can be shortened, the cost of the project resources can be avoided and released to work on other projects. This actually produces a double-whammy effect – savings on the current project and accelerating the start of future projects resulting in more project output. The other side of this equation is to achieve project benefits faster. It does not matter whether the project benefits are based on revenue enhancements or cost reductions, shorter projects mean benefits will be reached faster. Similar to what was already discussed earlier for the line of business executives, being able to reap the project benefits earlier can produce very large returns.

Document the Right Requirements
Business Analysts want to make sure that they define the application in a way that meets the 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 above. 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 unwanted 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.

External links

Business Analysis Resources

International Institute of Business Analysis

Business Analyst Certification Programs