11.3.2 Business Analysis Scope
.1 Change Sponsor
Information technology changes may be requested or sponsored by business sponsors, IT departments, or as a collaboration between the two. These changes should align to organizational strategy and business goals. It is possible for an IT department to initiate change to align with technical strategy or reach technical goals, but an overall organizational strategy alignment is still crucial for change success.
The following list represents possible change sponsors:
- technical team,
- technical executive,
- application owner
- process owner,
- business owner,
- internal product manager, and
- regulatory representative (such as a corporate legal department).
Enterprises may use many methods to initiate changes related to information technology. Frequently, large enterprises define a program or project management office within the IT department, which intakes requests and prioritizes efforts on behalf of the department.
.2 Change Targets
Business analysts identify all possible departments, processes, applications, and functions which can be impacted by the proposed change. A business analyst not only focuses on details of the initiative, but also keeps an eye on the larger picture and the potential impact (both business and technical) of the change. This involves a level of process and functional analysis with specific focus on both technical interfaces as well as process hand-offs.
.3 Business Analyst Position
Within an IT initiative, the business analysis activities may be filled by personnel with one of several types of backgrounds or job titles within the organization.
This assignment may be dependent upon the type of change, the level of experience, knowledge needed, or simply the personnel available to staff the effort. The personnel may be assigned to the business analysis tasks due to the experience described below, and may complete some or all of the business analysis responsibilities for a given change.
It is possible that all business analysis tasks for an IT project may be completed by a person with only one of these backgrounds:
- a business analyst who works specifically with the business users of an IT system,
- an IT business analyst who is the designated liaison between the technical team and the business group which uses the application,
- a subject matter expert (SME) experienced with the current software implementation,
- a software user experienced with the daily activity of how the software is used and can focus on usability,
- a systems analyst who has experience within the business domain, but does not have experience with the specific application,
- a business process owner who has a depth of experience with the business capabilities or processes, but may not have any technical or IT experience,
- a technical person with a depth of technical experience, or
- a COTS representative who will allow for customized implementations of a packaged solution, and leverage the knowledge of the vendor’s package and past implementation experience.
.4 Business Analysis Outcomes
Within an IT initiative, a business analyst may consider business processes impacted by the change, as well as the data and business intelligence information collected by the system. Business analysts working in the initiative thoroughly plan the business analysis effort and the deliverables that support the change effort.
The change approach being utilized has a direct impact on business analysis deliverables or outcomes. Many organizations have a defined system or solution development methodology which, to some extent, dictates the deliverables which are required at each project milestone. Even within the context of this structure the business analyst may seek to complete additional deliverables beyond those required by the change approach or organization specific process, and employ techniques which support the comprehensive understanding of the change effort needed.
Business analysts working in the IT discipline are responsible for delivering any of the following:
- defined, complete, testable, prioritized, and verified requirements,
- analysis of alternatives,
- business rules,
- gap analysis,
- functional decomposition,
- use cases and scenarios, and/or user stories as appropriate,
- interface analysis,
- prototypes,
- process analysis,
- process models,
- state models,
- decision models,
- context models or scope models, and
- data models.
Additional deliverables not included in the above list but relating to any of the outputs of business analysis techniques used may also be considered deliverables of the business analyst.
11.3.3 Methodologies
The methodologies followed by information technology organizations vary widely.
In general, solution development methodologies fall into two generic approaches:
- Predictive: structured processes which emphasize planning and formal documentation of the processes used to complete the change. Each phase of the process or sequence is completed before advancing to the next phase.
- Adaptive: processes which allow for reworking within one or more of the overall structured process cycles. Most adaptive models are both iterative and incremental, focusing on growing the product in both breadth and depth.
A hybrid methodology may also be utilized. A hybrid may include an overall vision for the whole initiative (as in predictive), as well as a definition of details within individual cycles or iterations (as in adaptive).
The following table identifies several established methodologies or approaches that a business analyst practicing in an information technology environment may encounter.
| Methodology | Brief Description |
|---|---|
| Homegrown or Organization Specific | A methodology which is derived from components of other established methodologies or approaches may be created by an information technology organization to govern information technology-based initiatives. |
| Requirements Engineering (RE) | Establishes a structured approach for requirements development and management and is used in predictive, adaptive, and agile environments. |
| Structured Systems Analysis and Design Method (SSADM) | A predictive development methodology that focuses on established logical modelling and the separation of requirements from solutions as central to systems analysis and specification. |
| Unified Process (UP) | An adaptive development approach. The inception and elaboration phases are of particular interest to business analysts. UP is not considered agile but is an adaptive methodology. |
Table 11.3.1: Information Technology Methodologies
11.3.4 Underlying Competencies
A business analyst working within IT may possess skills related to IT development such as programming, creating a database, creating a system or solution architecture, software testing experience, or other technical skills. However, development-related skills or technical skills are not necessary for a business analyst to be successful within an IT environment. It is important for the business analyst to have a strong understanding of the detail required within a requirements package to support technical solutions, as well as an understanding of what is technically feasible within the constraints of an organization’s technical architecture. These skills will enable a business analyst to work with all stakeholders to design a business solution framework which will also allow the technical team the flexibility to design a technical solution.
Business analysts use influencing and facilitation skills when working with stakeholders. Negotiation skills are frequently used when working with business and technical staff to come to agreements and decisions if the costs of a solution (either in budget, time, or architectural impact) conflict with the desired business outcome.
Systems thinking is a crucial competency for business analysts practicing in an IT environment. Systems thinking supports the ability of the business analyst to see the larger picture including any other applications or technical aspects which may be impacted, the details of the specific need, and possible technical solutions.
Systems thinking also supports the ability to identify impacts to people, processes, and software which are not necessarily directly changed as part of an IT development effort, and to analyze the risks and possible outcomes of those impacts.
