Business Analysis Tasks Knowledge Area Wise

Abstract

Change is the norm, fierce competition is the driver, and lean thinking is the latest call to action. Information Technology (IT) has finally come into its own, now viewed as a value provider as opposed to a cost drain. With the stakes so high, IT organizations are faced with an extraordinary combination of pressures to deliver value to their organizations in terms of added revenues, avoided costs, lower taxes, higher productivity, less employee turnover, less risk exposure, etc. Competitive advantage is now linked to an organization's ability to rapidly deploy IT solutions, and to change those systems as the business need evolves. IT projects must not only deliver high quality products faster, better, and cheaper (traditionally the responsibility of the project manager), they are also under intense scrutiny to positively impact the bottom line (increasingly, the joint responsibility of the project manager, project sponsor, and the business analyst).

Introduction

Projects play an essential role in the growth and survival of organizations today. It is through projects that we create improved business processes and new products and services as a response to changes in the business environment. Since data and information are the lifeblood of virtually all business practices, IT projects are often the key mechanism used to turn an organization's vision and strategy into reality. Executives have their eye on the IT portfolio to ensure that they: (1) invest in the right mix of projects, (2) understand that IT is a strategic resource that has a capacity, (3) optimize their IT resources through targeted resource allocation, (4) develop expert capabilities to deliver flawlessly, and ultimately, (5) capture the added value to the business that was expected.

Since there appears to be a never-ending demand for new IT products and services, executives across the spectrum are adopting the practice of superior business analysis to increase the value IT projects bring to the business. The talents, competencies, and heroics of project managers and technologists alone cannot drive value into the organization. For business needs and goals to be converted into innovative solutions that truly bring wealth to the enterprise, a stronger bridge must be built between the business and the technical communities.

The Project Performance Partnership

Every IT project, whether in-house or outsourced, COTS purchase or custom development, or complex systems integration, needs exceptional requirements management. In the spirit of high-performing teams, business analysts align themselves with professional project managers, the best technical architects, and business visionaries to determine the most appropriate, cost-effective and innovative solution. As this core team forms, a project performance partnership emerges that rivals the world's great teams, (e.g., Navy Seals, tiger teams, special operations teams, professional sports teams, and firefighter and parametric teams). At the center of the team is the dynamic twosome: the project manager and the business analyst. One has her eye on the management of the project, while the other focuses on management of the business requirements. The wise project manager welcomes this teaming trend, understanding that inadequate information relating to requirements leads to poor estimates, and makes time and cost management virtually impossible.

Why is the business analyst emerging as the central IT competency of the future? Because requirements play a vital role in engineering IT systems, and five of the top eight reasons why projects fail are tied directly to poor requirements (The Standish Group 1998). It is the business analyst who manages the entire Systems Requirements Life Cycle, from understanding the business need to ensuring that the delivered solution meets the need and adds value to the bottom line. Clearly, the business analyst has a critical role throughout the Business Solution Development Life Cycle, not simply during the requirements phase. (Exhibit 2, on the final page of this White Paper.)

It is through the leadership of the business analyst that requirements are captured and fully understood by the technical team before solutions are designed and implemented. The business analyst serves as the liaison between the business community and the technical solution providers throughout the project life cycle. As projects become larger, cross-functional, global, and more complex, organizations are realizing that requirements management skills are indispensable. With the current trend in outsourcing IT development, the role of the business analyst becomes even more critical in today's IT environment.

Enter the Professional Business Analyst

When you hear about far-reaching innovation, cutting-edge technology, and high-growth IT careers, don't just think in terms of architecture and development prowess. We are discovering that technical skills can be relatively easy to outsource, but organizations cannot abdicate control of their business requirements. In virtually every organization, the pivotal leadership role of the business analyst is beginning to shape the future of IT. So don't blink—or you'll miss out on the IT opportunity of a lifetime.

Once management has developed a portfolio of valuable IT projects, the focus is on flawless project execution to maximize the value delivered to the organization. All too often, however, IT project success is elusive. Projects are late, over budget, or may never even be delivered. Sometimes work is incomplete, does not meet requirements or expectations, and does not deliver the benefits or returns on investment expected by the organization. This rather dismal IT delivery record can no longer be tolerated. The key organizational capabilities executives must build to improve delivery performance and meet business expectations include effective and targeted project management and systems engineering practices, appropriate executive decision making at key control gates, exceptional project leadership and high-performing teams, collaboration and respect between the business and IT communities, and business analysis practices that ensure the development team has a clear understanding of the customer's overall business and information needs.

Where do we get the exceptional business analysts who can bridge the chasm between the business and technical communities? As the project management discipline matures into a strategic business practice, so must our business analysts evolve into strategic leaders of change. Frequently, expertise in the technical area of the project is the key requirement for the position of business analyst. In this case, business analysis is treated as a subset of the technical discipline. Time and again, projects encounter difficulties not from lack of technical expertise, but from an inability to gather, understand, analyze and manage business requirements, and convert them into useable system specifications. Projects are often initiated, and design and construction of the solution is underway, before IT team members have a clear understanding of the business need. Often, tolerance is low for technical failure and high for inadequate and ever-evolving requirements.

Business requirements analysis differs from traditional information systems analysis because of its focus, which is exclusively on adding value to the business. In particular, project managers rely on business analysts to assist in providing more detailed project objectives; business needs analysis; clear, structured, useable requirements; tradeoff analysis; requirement feasibility and risk analysis; and cost-benefit analysis. To meet the challenge, technically adept engineers are often asked to make the professional transition to the disciplines of project management and business analysis. Often, these individuals assume a trio of leadership roles on projects: technical lead architect, project manager, and business analyst. Inevitably, after requirements are captured at a high level and the project plan is being executed, technical activities tend to elicit the majority of attention. When that happens, requirements and project management suffer, and the initiative is positioned to become a runaway project.

From Systems Analyst to Business Leader

It is increasingly clear that while technical knowledge areas are necessary, they are insufficient for successfully managing requirements on the large, enterprise-wide, complex, mission-critical projects that are the norm today. Just as a business leader must be multi-skilled and strategically focused, business analysts must possess an extensive array of leadership skills. The business analyst is now assuming a leadership role, and is quickly rising to a senior position in the enterprise (whether placed in the business unit or the IT organization). As the IT contribution moves beyond efficiency to business effectiveness, the business analyst becomes the central figure on the project team who must be "bi-lingual," speaking both business and technical languages. To perform in this pivotal role, the business analyst must possess a broad range of knowledge and skills.

Many job titles are used to identify the role responsible for business analysis, including business analyst, business systems analyst, business system planner, requirements engineer, and even principal solutions architect. Indeed, in some organizations, the roles of business analysis and system architecture are combined. Regardless of the job title, a strong, experienced business analyst is critical to IT project success. Simply put, without a well-understood and documented requirements baseline, the set of functional and supplemental requirements that the project team has committed to implement in a specific release (Weigers, 2003), it is virtually impossible to meet project objectives. Therefore, if an IT organization only has resources and budget to put into a single life cycle area to improve project performance, that area should be requirements definition and management. Depending on the level of responsibility and placement in the organization, business analyst duties include the following:

Identify and understand the business problem and the impact of the proposed solution on the organization's operations;
Document the complex areas of project scope, objectives, added value or benefit expectations, using an integrated set of analysis and modeling techniques;
Translate business objectives into system requirements using powerful analysis and modeling tools;
Evaluate customer business needs, thus contributing to strategic planning of information systems and technology directions;
Assist in determining the strategic direction of the organization;
Liaise with major customers during preliminary installation and testing of new products and services ;
Design and develop high quality business solutions.

While the business analyst is fast becoming a relatively senior position in the business world, it has historically been considered a mid- to low-level role. A recent survey revealed an increasing demand for senior individuals who can perform the ever-widening range of business analysis functions. Since business analysts walk in both business and IT worlds, they arrive from various fields. Some come from the ranks of programmer/analyst positions, while others have conventional business expertise supplemented by some IT training. To successfully fill the business analyst role, one must acquire mastery of a unique combination of technical, analytical, business, and leadership skills.

Business Analysis in Practice

The requirements gathering process explores the solution without commitment to any specific product selection. Requirements definition is most effective as a joint effort among users, customers, stakeholders and developers (Hadden, 2003). Defining, analyzing, and documenting requirements is a highly creative and iterative process that is designed to show what the system will do, but not how it will be done. Therefore, the requirements in their textual and graphical form represent a model of the system, serving as an intermediate step between the business need and the solution design. The requirements development process is typically subdivided into business planning and scope definition, elicitation, analysis, specification, documentation, validation, management, solution delivery, and maintenance and enhancements. These sub-disciplines encompass all the activities involved with gathering, evaluating, and documenting requirements (Young, 2001).

Business Planning

As strategic goals are set and initiatives are selected, project sponsors and project managers are assigned to new programs and supporting projects. Pre-project analysis is required to determine the most appropriate solution to achieve the strategic goals. Activities include more detailed analysis of the business need, feasibility studies, solution trade-off analysis, and development of high-level business requirements. The results of these analyses are often captured in Feasibility Studies, Benchmark Studies, Competitive Analysis Reports, Needs Analysis Documents, and initial, high-level Business Requirements Documents.

Business Domain Scope Definition

Initial requirements definition typically originates in the early phases of the project when the product description is created and is ideally captured in initiating documents: the Business Case, Project Charter, or Statement of Work. All requirements should be traceable to these original sources. Prior to eliciting requirements, the business analyst, systems architect and project manager partner to conduct initial planning and scoping activities to: (1) gain perspective of the needs and environment of customers, users, and stakeholders; (2) review, or create if non-existent, the Business Case, Project Charter, and Statement of Work (or similar scope definition document); (3) understand the business vision, drivers, goals, and objectives for the new/changed system; (4) assemble and educate a requirements team comprised of key business and technical stakeholders; (5) understand and document the scope of the project; (6) define the documents and models to be produced, and develop the Requirements Management Plan; (7) define/refine the checklist of requirements activities, deliverables, and schedule; and (8) plan for change throughout the life cycle.

Requirements Elicitation and Discovery

Requirements are always unclear at the beginning of a project. It is through the process of progressive elaboration that requirements evolve into maturity. Requirements elicitation involves conducting initial requirements gathering sessions with customers, users, and stakeholders to begin the documentation process. Requirements gathering techniques include: discovery sessions, structured workshops, interviews, surveys, prototyping, review of existing system and business documents, and note taking and feedback loops to customers, users, and stakeholders.

Requirements Analysis

Requirements are first stated in simple terms, and are then analyzed and decomposed for clarity. Requirements analysis is the process of structuring requirements information into various categories, evaluating requirements for selected qualities, representing requirements in different forms, deriving detailed requirements from high-level requirements, and negotiating priorities. Requirements analysis also includes the activities to determine required function and performance characteristics, the context of implementation, stakeholder constraints and measures of effectiveness, and validation criteria. Through the analysis process, requirements are decomposed and captured in a combination of textual and graphical formats. Analysis represents the middle ground between requirements and design (Ambler 2005). Analysis activities include: (1) studying requirements feasibility to determine if the requirement is viable technically, operationally, and economically, (2) trading off requirements to determine the most feasible requirement alternatives, (3) assessing requirement risks and constraints and modifying requirements to mitigate identified risks, (4) modeling requirements at the appropriate usage, process, or detailed structural level to restate and clarify them, (5) deriving additional requirements as more is learned about the business need, and (6) prioritizing requirements to reflect the fact that not all requirements are of equal value to the business.

Requirements Specification

Requirement specifications are elaborated from and linked to the structured requirements, providing a repository of requirements with a completed attribute set. Through this process of progressive elaboration, the requirements team often detects areas that are not defined in sufficient detail, which unless addressed can lead to uncontrolled change to system requirements. Specification activities involve identifying all the precise attributes of each requirement. This process ensures an understanding of the relative importance of each of the quality attributes. The system specification database or repository is an output of the requirements specification process.

Attributes are used for a variety of purposes including explanation, selection, filtering, and validating. In addition, attributes enable the association of data with objects, table markers, table cells, modules, and projects. Attributes may be user defined or system defined. Attributes allow the requirements team to associate information with individual or related groups of requirements, and often facilitate the requirements analysis process by filtering and sorting. Attributes also facilitate the process to organize requirements so that they can be allocated to system components and traced throughout the design, development and test cycles. Typical attributes attached to requirements include a unique identifier, acceptance criteria, author, complexity, ownership, performance, priority, source, stability, status and urgency.

Requirements Documentation

Requirements documentation must be clear and concise since it is used by virtually everyone in the project. The language used to document system requirements should be as non-technical as possible. A diagram can express structure and relationships more clearly than text, whereas for precise definition of concepts, clearly articulated language is superior to diagrams. Therefore, both textual and graphical representations are essential for a complete set of system requirements. Transforming graphical requirements into textual form can make them more understandable to non-technical members of the team.

Requirements are categorized into types depending on their source and applicability. Understanding requirement types helps in analyzing and prioritizing requirements. While some requirements are mandatory, others may be nonessential. Understanding requirement types also enables the technical team to conduct trade-off analysis, estimate the system cost and schedule, and better assess the level of changes to be expected. Finally, reviewing the list of requirements types can aid the business analyst in identifying areas that may require further investigation. Documentation activities involve translating the collective requirements into written requirements specifications and models in terms that are understood by all stakeholders. This task typically involves substantial time and effort as each stakeholder may have different expertise, perspectives, and expectations of the requirements.

Requirements Validation

Requirements validation is the process of evaluating requirement documents, models, and attributes to determine whether they satisfy the business needs and are complete to the point that the technical team can commence work on system design and development. The set of requirements is compared to the original initiating documents (business case, project charter, or statement of work) to ensure completeness. Beyond establishing completeness, validation activities include evaluating requirements to ensure that design risks associated with the requirements are minimized before further investment is made in system development. An often-used analysis technique to validate requirements is prototyping.

Requirements Management

A major phase gate for projects occurs upon exiting the requirements phase. Phase exit involves presenting requirements for approval at a formal control gate review session. At this point, the project schedule, cost, and scope estimates are updated, and the business case is revisited, to provide the salient information needed to determine whether continued investment in the project is warranted. Upon securing approval to proceed, the business analyst transitions into requirements management activities. Once requirements are baselined, requirements changes must be managed throughout the solution development life cycle. The business analyst and project manager work collaboratively to define and manage the project and product scope. Requirements management activities include allocating requirements to sub systems or sub-components, tracing requirements throughout the project, managing changes to requirements, and continued validation and verification of requirements. The business analyst also plays a major role in the user acceptance test process.

Solution Delivery, Maintenance and Enhancement

The business analyst plays a critical role in solution delivery. Implementing a new business system often requires significant changes to how the business unit functions. The business analyst works with the business unit managers and end users to draft and execute an implementation plan to train the users and manage the cultural changes required to achieve the business benefits expected from the new system. The business analyst's job does not end when the IT solution is delivered and operational; she also maintains key responsibilities in the operations and maintenance phase (Mooz, Forsberg, & Cotterman, 2003), most notably managing enhancements to the system.

Requirements Engineering Considerations

To understate the obvious, requirements engineering is a difficult and risky business. Ideally, we would like to get a clear and thorough picture of the requirements before development, obtain customer sign-off on these requirements, and then set up procedures that limit requirements changes following sign-off. However, regardless of the care taken in requirements engineering, requirements are going to change. Realizing the difficulty in defining and managing requirements, and having described the business analysis practices, it is imperative that we discuss three additional concepts: agile development, the iterative nature of requirements generation and system development (especially for software-intensive systems), and the element of scalability.

Agile Development

Over the past few years, there's been a rapidly growing interest in agile methodologies (Fowler, 2003). Agile methods differ substantially from traditional engineering methods. The most notable divergence is that they are less document and process intensive. What is agile analysis? The business analyst follows the same practices outlined above, while incorporating strategies that result in rich communication, iteration, constant feedback and minimal documentation (Ambler, 2005). When is it appropriate to use agile methods? Current thinking suggests that these methods should be used when (1) you can organize into a small, co-located core team, (2) requirements are difficult to understand, (3) the customer is highly invested and involved in the project, and (4) the solution can be delivered in increments. The absence of one or more of these circumstances will likely put the agile approach at risk (Fowler, 2003).

Iteration

Although the steps appear to be sequential in this discussion of business analyst practices, they are unquestionably performed iteratively. Iteration is the best defense when attempting to control an unpredictable process. The business analyst needs to build in candid feedback mechanisms at frequent intervals in order to reveal gaps and defects in requirements. The key to this feedback is an iterative approach to requirements generation. During the requirements phase, the IT architects are working on early iterations of the solution design. As the business analyst conducts requirements trade-off analyses, the architect does the same on solution options.

Whether called incremental, evolutionary, staged, or spiral methodology, these techniques are iterative in nature. Early prototypes are produced, followed by incremental working versions of the final system containing a subset of the required features. These working sub-systems possess limited functionality, but are otherwise true to system requirements. The value of iterative development is found in regular customer reviews and feedback following each iteration.

Scalability

Whether a light or heavy methodology is used, all the activities discussed above are performed. They are likely to be executed in a broad sense at project initiation, and progressively elaborated as the project traverses its life cycle. For small, straightforward projects that are easily understood, a minimal amount of requirements documentation and models is appropriate. Indeed, the rule is the smaller the team, the less formal the documentation. However, for significant, complex, high-risk projects, a full set of approved requirements documentation is in order. For low-to-moderate risk projects, the rigor should be scaled appropriately, applying more formality and structure in the higher risk areas of the project.

Recipe for Project Success

Whatever the nature of your project, a business analyst can't go wrong if she remembers to scale the project by following the recipe for success adapted from The Standish Group International, Inc. in their 1999 report: Unfinished Voyages, a Follow-Up to the CHAOS Report. Their message is clear: size matters. When structuring a project or major project phases, the project manager and business analyst should strive to follow these guidelines to reduce project risk.

Ingredients:	Minimization, communications, standard processes
Mix with:	Full-time core team members: business analyst, project manager, business visionary, architects and developers, coached by an involved project sponsor
Bake:	No longer than six months, no more than six people, at no more than $750,000

The Grooming of the Business Analyst

How do IT organizations develop exceptional business analysts? As with any leadership role, competency comes from acquiring education and training, seeking mentoring and coaching, and jumping in headfirst to learn the discipline. Because the role requires both business and technical expertise, formal qualifications for business analysts include studies of computing and management information systems, coupled with traditional business administration courses (Sodhi & Sodhi 2003). Look for leading-edge business analysis training offerings focused on increased performance, best practices, and project results. The courses should be based on sound systems engineering principles, focused on leadership and facilitation skills, rich in lean-thinking, agile tool sets, targeted toward real-world IT situations, and filled with tailoring techniques for small, medium, and large, high-risk projects.

Final Words

Gaps in technology, techniques, and tools are not the fundamental reasons why projects fail. Rather, project failure most often stems from a lack of leadership and poor choices made by people. Undeniably, the business analyst and project manager, along with the system architect, are evolving into the IT project leaders of the future. But team leadership is different from traditional management, and teams are different from operational work groups. The key issues are no longer centered on control and management, but rather collaboration, consensus, and leadership. Team leaders must have an understanding of how teams work, and the dynamics of team development. They must develop specialized skills that are used to build high-performing teams. When building software-intensive systems, well managed teams undoubtedly accomplish more work in less time (Bechtold 1999). Traditional business managers and technical leads cannot necessarily become effective team leaders without appropriate training and coaching.

Leading researchers and scholars consider project success as the way to ensure organizational success. Conversely, significant project failure can lead to the demise of companies. Organizations on the leading edge are improving project performance by better training and equipping their business analysts. A specific career path for business analysts leading to senior executive positions is one strategy to retain key talent, while training those who will follow. Enlightened organizations in both the public and private sectors are creating cohesive career management plans for business analysts to develop their potential, match their skills to assignments, track performance, and reward them appropriately.

References

Ambler, S. (n.d.). Agile analysis. Retrieved Apr. 08, 2005, from Ambysoft Web site: http://www.agilemodeling.com/essays/agileAnalysis.htm.

Ambler, S. (n.d.). When does(n't) agile modeling make sense? Retrieved Apr. 08, 2005, from Ambysoft Web site: http://www.agilemodeling.com/essays/whenDoesAMWork.htm.

Bechtold, R. (1999). Essentials of software project management. Vienna, VA: Management Concepts. Fowler, M. (2003). The new methodology. Retrieved Apr. 08, 2005, from martinfowler.com Web site: http://www.martinfowler.com/articles/newMethodology.html.

Hadden, R. (2003). Leading culture change in your software organization. Vienna, VA: Management Concepts.

Mooz, H., Forsberg, K., & Cotterman, H. (2003). Communicating project management: the integrated vocabulary of project management and systems engineering. Hoboken, NJ: John Wiley and Sons.

Sodhi, J., & Sodhi, P. (2003). Managing IT systems requirements. Vienna, VA: Management Concepts.

Sodhi, J., & Sodhi, P. (2001). IT project management handbook. Vienna, VA: Management Concepts.

The Standish Group, (1999). Unfinished voyages: a follow-up to the chaos report. Retrieved Apr. 08, 2005, from The Standish Group Web site: http://www.standishgroup.com/sample_research/unfinished_voyages_1.php.

Stevens, R., Brook, P., Jackson, K., & Arnold, S. (1998). Systems engineering: coping with complexity. Indianapolis, IN: Pearson Education, Prentice Hall PTR.

Wiegers, K. (2003). Software requirements: practical techniques for gathering and managing requirements throughout the product development cycle. 2nd ed. Redmond, WA: Microsoft Press.

Young, R. (2001). Effective requirements practices. Addison-Wesley information technology series. Boston: Addison-Wesley.

Business Solutions Life Cycle Mapped to the Systems Requirement Life Cycle

Exhibit 2 – Business Solutions Life Cycle Mapped to the Systems Requirement Life Cycle

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Business Analysis Tasks Knowledge Area Wise

Source: https://www.pmi.org/learning/library/business-analyst-pivotal-role-future-7452

Collier Anecters