The business analyst:

The pivotal IT role of the future

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).
 the bottom line. Clearly, the business analyst has a
Introduction critical role throughout the Business Solution
Projects play an essential role in the growth and Development Life Cycle, not simply during the
survival of organizations today. It is through projects requirements phase. (See Figure 3, Business Solution
that we create value in the form of improved business Development Life Cycle Mapped to the Systems
processes and new products and services in response Requirements Life Cycle, on the final page of this
to changes in the business environment. Since data White Paper.)
and information are the lifeblood of virtually all
business practices, IT projects are often the key It is through the leadership of the business analyst
mechanism used to turn an organization’s vision and that requirements are captured and fully understood
strategy into reality. Executives have their eye on the by the technical team before solutions are designed
IT portfolio to ensure that they: (1) invest in the right and implemented. The business analyst serves as the
mix of projects, (2) optimize their resources, (3) liaison between the business community and the
develop expert capabilities to deliver flawlessly, and technical solution providers throughout the project life
ultimately, (4) capture the expected added value to cycle. As projects become larger, cross functional,
the business. Since there appears to be a never- global, and more complex, organizations are
ending demand for new IT products and services, realizing that requirements management skills are
executives across the spectrum are adopting the indispensable. With the current trend in outsourcing
practice of superior business analysis to increase the IT development, the role of the business analyst
value IT projects bring to the business. The talents, becomes even more critical in today’s IT environment.
competencies, and heroics of project managers and
technologists alone cannot drive value into the Enter the professional
organization. For business needs and goals to be
converted into innovative solutions that truly bring
business analyst
wealth to the enterprise, a stronger bridge must be When you hear about far-reaching innovation,
built between the business and the technical cutting-edge technology, and high-growth IT careers,
communities. don’t just think in terms of architecture and
development prowess. We are discovering that
The project performance technical skills can be relatively easy to outsource,
but organizations cannot abdicate control of their
partnership business requirements. In virtually every organization,
Every IT project, whether in-house or outsourced, the pivotal leadership role of the business analyst is
COTS purchase or custom development, or complex beginning to shape the future of IT. So don’t blink —
systems integration, needs exceptional requirements or you’ll miss out on the IT opportunity of a lifetime.
management. In the spirit of high-performing teams, Once management has developed a portfolio of
business analysts align themselves with professional valuable IT projects, the focus is on flawless project
project managers, the best developers, and business execution to maximize the value delivered to the
visionaries to determine the most appropriate, cost- organization. All too often, however, IT project
effective, and innovative solution. As this core team success is elusive. Projects are late, over budget, or
forms, a project performance partnership emerges may never even be delivered. Sometimes work is
that rivals the world’s great teams, (e.g., tiger teams, incomplete, does not meet requirements or
special operations teams, professional sports teams, expectations, and does not deliver the benefits or
and parametric teams). At the center of the team is returns on investment expected by the organization.
the dynamic twosome: the project manager and the This rather dismal IT delivery record can no longer
business analyst. One has an eye on the be tolerated.
management of the project, while the other focuses
on management of the business requirements. The What are the key organizational capabilities
wise project manager welcomes this teaming trend, executives must build to improve delivery
understanding that inadequate information relating performance and meet business expectations? For
to requirements leads to poor estimates, and makes project success, several capabilities are essential:
time and cost management virtually impossible.
• Effective and targeted project management and
Why is the business analyst emerging as the central systems engineering processes, tools, and
IT competency of the future? Because requirements techniques;
play a vital role in engineering IT systems, and five of • Appropriate executive decision making at key
the top eight reasons why projects fail are tied control gates;
directly to poor requirements (The Standish Group,
• Exceptional project leadership and high-performing
1998). It is the business analyst who manages the
teams;
entire Systems Requirements Life Cycle, from
understanding the business need to ensuring that the • Collaboration and respect between the business
delivered solution meets the need and adds value to and IT communities; and

3
Why is the business analyst emerging as the central IT
competency of the future? 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.

• Business analysis processes that ensure the feasibility and risk analysis; and cost-benefit analysis.
development team will have a clear understanding of Poor requirements definition emerges without this key
the customer’s overall business and information liaison between business and IT departments,
needs. resulting in a disconnect between what IT builds and
Where do we get the exceptional business analysts what the business needs.
who can bridge the chasm between the business and To meet the challenge, technically adept engineers
technical communities? As the project management often are asked to make the professional transition to
discipline matures into a strategic business practice, the disciplines of project management and business
so must our business analysts evolve into strategic analysis. Often, these individuals assume a trio of
leaders of change. leadership roles on projects: technical lead, project
manager, and business analyst. Inevitably, after
Will the real business analyst requirements are captured at a high level and the
project plan is being executed, technical activities
please stand up? tend to elicit the majority of attention. When that
Frequently, expertise in the technical area of the happens, requirements and project management
project is the key requirement for the position of suffer, and the initiative is positioned to become a
business analyst. In this case, business analysis is runaway project.
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,
From analyst to project leader
understand, analyze and manage business It is increasingly clear that while technical knowledge
requirements, and convert them into useable system areas are necessary, they are insufficient for
specifications. Projects are often initiated, and design successfully managing requirements on the large,
and construction of the solution is underway, before IT enterprise-wide, complex, mission critical projects
team members have a clear understanding of the that are the norm today. Just as a business leader
business need. Often, tolerance is low for technical must be multi-skilled and strategically focused,
failure and high for inadequate and ever-evolving business analysts must possess an extensive array of
requirements. All too often, IT projects suffer from leadership skills. The business analyst is now
requirements creep due to the “Let’s start coding and assuming a leadership role, and is quickly rising to a
see how it turns out” syndrome. While this may be senior position in the enterprise (whether placed in
appropriate when conducting agile development, it the business unit or the IT organization). As the IT
often falls short for complex business systems contribution moves beyond efficiency to business
initiatives. effectiveness, the business analyst becomes the
central figure on the project team who must be “bi-
Business requirements analysis differs from traditional lingual” in speaking both business and technical
information systems analysis because of its focus, languages. To perform in this pivotal role, the
which is exclusively on adding value to the business. business analyst must possess a broad range of
In particular, project managers rely on business knowledge and skills.
analysts to assist in providing more detailed project
objectives; business needs analysis; clear, structured, Browsing through the more than 5,000 job postings
useable requirements; trade-off analysis; requirement for business analysts on Monster.com turned up this
job description:

4
Figure 1 Technical Analysis Business Leadership
Business Analyst Knowledge
and Skill Set Requirements Systems engineering concepts and Fundamentals of business analysis Business process improvement and Fundamentals of project
principles reengineering management

Complex modeling techniques Ability to conceptualize and Strategic and business planning Capacity to articulate vision
think creatively

Communication of technical Techniques to plan, document, Communication of business Organizational change

concepts to non-technical analyze, trace, and manage concepts to technical management; management of
audiences requirements audiences power and politics

Testing, verification, and Requirements risk assessment Business outcome thinking Problem solving, negotiation,
validation and management and decision-making

Technical writing Administrative, analytical, and Business writing Team management, leadership,
reporting skills mentoring, and facilitation

Rapid prototyping Cost / benefit analysis Business case development Authenticity, ethics, and integrity

Technical domain knowledge Time management and Business domain knowledge Customer relationship
personal organization management

“The main purpose of the role will be to design and • Liaise with major customers during preliminary
specify innovative solutions which meet the business installation and testing of new products and
requirements allowing the business benefit to be services
attained; and to facilitate divisional communication • Design and develop high quality business solutions
and awareness of the standards and quality
While the business analyst is fast becoming a
expectations within the System Analyst teams.”
relatively senior position in the business world,
Many job titles were also uncovered, including historically it has been considered a mid- to low-level
business analyst, business systems analyst, business role. A recent survey revealed an increasing demand
system planner, and even principal solutions for senior individuals who can perform the ever-
architect. Regardless of the job title, a strong, widening range of business analysis functions. Since
experienced business analyst is critical to IT project business analysts walk in both business and IT
success. Simply put, without a well-understood and worlds, they arrive from various fields. Some come
documented requirements baseline, it is virtually from the ranks of programmer/analyst positions,
impossible to meet project objectives. A baseline is while others have conventional business expertise
the set of functional and supplemental requirements supplemented by some IT training. To successfully fill
that the project team has committed to implement in the business analyst role, one must acquire mastery
a specific release (Wiegers, 2003). It has been said of a unique combination of technical, analytical,
that if an IT organization only has resources and business, and leadership skills. (See Figure 1,
budget to put into a single life cycle area to improve Business Analyst Knowledge and Skill Set
project performance, that area should be Requirements.)
requirements definition and management. Depending
on the level of responsibility and placement in the Business analysis in practice
organization, business analyst duties include the
During the requirements discovery and definition,
following:
requirements are determined and documented at a
• Identify and understand the business problem and very high level. The requirements gathering process
the impact of the proposed solution on the explores the solution without commitment to any
organization’s operations specific product selection. Requirements definition is
most effective as a joint effort among users,
• Document the complex areas of project scope,
customers, stakeholders, and developers (Hadden
objectives, added value or benefit expectations,
2003). Defining, analyzing, and documenting
using an integrated set of analysis and modeling
requirements is a highly creative and iterative process
techniques
that is designed to show what the system will do, but
• Translate business objectives into system not how it will be done. Therefore, the requirements
requirements using powerful analysis and modeling in their textual and graphical form represent a model
tools of the system, serving as an intermediate step
• Evaluate customer business needs, thus contributing between the business need and the solution design.
to strategic planning of information systems and
The requirements development process is typically
technology directions
subdivided into business need identification, scope
• Assist in determining the strategic direction of the definition, elicitation, analysis, specification,
organization documentation, validation, management, and

5
maintenance and enhancements. These sub- goals. The development of business scenarios is an
disciplines encompass all the activities involved with effective method for understanding business
gathering, evaluating, and documenting requirements. A critical success factor in the value of
requirements (Young, 2001). the system after deployment is the extent to which it
supports business requirements and facilitates the
Business need organization in achieving business goals. Elicitation
As initiatives are selected, project sponsors and and discovery activities include:
project managers are assigned to new programs and
• Identifying the customers, users, and stakeholders to
supporting projects. Pre-project analysis is required to
determine who should be involved in the
determine the most appropriate solution to achieve
requirements gathering process
the strategic goals. Activities include more detailed
analysis of the business need, feasibility studies, • Understanding the business goals and objectives to
solution trade-off analysis, and development of high- identify the essential user tasks that support the
level business requirements. The results of these organizational goals.
analyses are often captured in Feasibility Studies, • Successful systems support the business
Benchmark Studies, Competitive Analysis Reports, requirements and facilitate achievement of
Needs Analysis and high-level Business Requirements organizational goals
documents.
• Identifying and defining requirements to understand
the needs of the users, customers, and stakeholders.
Business domain scope definition This is the activity of capturing the business
Initial requirements definition typically originates in
requirements for a target system, as viewed by the
the early stages of the project when the product
customers, business users, and stakeholders.
description is created, and is ideally captured in
Business requirements are the critical activities of an
initiating documents: the Business Case, Project
enterprise that must be performed to meet the
Charter, or Statement of Work. All requirements
organizational objectives, and they are solution
should be traceable to these original sources. Prior to
independent. Business scenarios (a.k.a., usage-
eliciting requirements, the business analyst and
based scenarios) are often used as a technique to
project manager partner to conduct initial planning
ensure an understanding of business requirements.
and scoping activities to: (1) gain perspective of the
needs and environment of customers, users, and • The Business Requirements Document and the
stakeholders; (2) review, or create if non-existent, the Requirements Management Plan are the key outputs
Business Case, Project Charter, and Statement of of this activity.
Work (or similar scope definition document); (3)
Requirements analysis
understand the business vision, drivers, goals, and
Requirements are first stated in simple terms, and are
objectives for the new/changed system; (4) assemble
then analyzed and decomposed for clarity.
and educate a requirements team comprised of key
Requirements analysis is the process of structuring
business and technical stakeholders; (5) understand
requirements information into various categories,
and document the scope of the project; (6) define the
evaluating requirements for selected qualities,
documents and models to be produced, and begin to
representing requirements in different forms, deriving
develop the Requirements Management Plan; (7)
detailed requirements from high-level requirements,
define/refine the checklist of requirements activities,
and negotiating priorities. Requirements analysis also
deliverables, and schedule; and (8) plan for change
includes the activities to determine required function
throughout the life cycle.
and performance characteristics, the context of
implementation, stakeholder constraints and
Requirements elicitation and discovery measures of effectiveness, and validation criteria.
Requirements are always unclear at the beginning of
Through the analysis process, requirements are
a project. It is through the process of progressive
decomposed and captured in a combination of
elaboration that requirements evolve into maturity.
textual and graphical formats. Analysis represents the
Requirements elicitation involves conducting initial
middle ground between requirements and design
requirements gathering sessions with customers,
(Ambler, 2005). Analysis activities include:
users, and stakeholders to begin the documentation
process. Requirements gathering techniques include: • Studying requirements feasibility to determine if the
discovery sessions, interviews, surveys, prototyping, requirement is viable technically, operationally, and
review of existing system and business documents, economically.
and note taking and feedback loops to customers, • Trading off requirements to determine the most
users, and stakeholders. feasible requirement alternatives
Business requirements are the essential activities of • Assessing requirements feasibility by analyzing
the enterprise that must be supported by the system. requirement risks and constraints and modifying
Business requirements are derived from business requirements to mitigate identified risks. The goal is

6
 to reduce requirement risks through early validation • Ownership specifies the individual or group that
prototyping techniques. needs the requirement
• Modeling requirements to restate and clarify them. • Performance addresses how the requirement must
Modeling is accomplished at the appropriate be met
usage, process, or detailed structural level. • Priority of the requirement rates its relative
• Deriving additional requirements as more is importance at a given point in time
learned about the business need. • Source of the requirement identifies who requested
• Prioritizing requirements to reflect the fact that not it. Every requirement should originate from a source
all requirements are of equal value to the business. that has the authority to specify requirements
Prioritization may be delineated in terms of critical, • Stability is used to indicate how mature the
high, average, and low priority. Prioritization is requirement is. This is used to determine whether
essential to determine the level of effort, budget, the requirement is firm enough to begin work on it
and time required to provide the highest priority
• Status of the requirement denotes whether it is
functionality first. Then, perhaps, lower priority
proposed, accepted, verified with the users, or
needs can be addressed in a later release of the
implemented
system.
• Urgency refers to how soon the requirement is
Requirements specification needed
Requirement specifications are elaborated from and
linked to the structured requirements, providing a Requirements documentation
repository of requirements with a completed attribute Requirements documentation must be clear and
set. Through this process of progressive elaboration, concise since it is used by virtually everyone in the
the requirements team often detects areas that are project. Selected types of requirements may need to be
not defined in sufficient detail, which unless expressed formally using technical language, e.g.,
addressed can lead to uncontrolled change to system legal, safety, and security requirements. This is
requirements. Specification activities involve acceptable, as long as they are mapped back to the
identifying all the precise attributes of each requirements that are more easily understood.
requirement. This process ensures an understanding However, in most cases the language used to
of the relative importance of each of the quality document system requirements should be as non-
attributes. The system specification document or technical as possible. A diagram can express structure
database is an output of the requirements analysis and relationships more clearly than text, whereas for
process. precise definition of concepts, clearly articulated
language is superior to diagrams. Therefore, both
Attributes are used for a variety of purposes textual and graphical representations are essential for
including explanation, selection, filtering, and a complete set of system requirements. Transforming
validating. In addition, attributes enable the graphical requirements into textual form can make
association of data with objects, table markers, table them more understandable to non-technical members
cells, modules, and projects (Stevens, Brook, Jackson, of the team. This is one of the few times in the system
& Arnold, 1998). Attributes may be user defined or life cycle when duplication is advisable.
system defined. Attributes allow the requirements
team to associate information with individual or Requirements are categorized into types depending
related groups of requirements, and often facilitate on their source and applicability. Understanding
the requirements analysis process by filtering and requirement types helps in analyzing and prioritizing
sorting. Typical attributes attached to requirements requirements. While some requirements are
may include: mandatory, others may be nonessential.
Understanding requirement types also enables the
• Unique identifier that does not change. The technical team to conduct trade-off analysis, estimate
reference is not to be reused if the requirement is the system cost and schedule, and better assess the
moved, changed, or deleted level of changes to be expected. Finally, reviewing the
• Acceptance criteria describe the nature of the test list of requirements types can aid the business analyst
that would demonstrate to customers, end users, in identifying areas that may require further
and stakeholders that the requirement has been investigation. Typically, requirements are broadly
met. Acceptance criteria are usually captured from characterized as functional or supplemental (a.k.a.
the end users by asking the question, “What kind nonfunctional).
of assessment would satisfy you that this
• Functional requirements describe capabilities the
requirement has been met?”
system will be able to perform in terms of behaviors
• Author of the requirement refers to who wrote it or operations – a specific system action or
• Complexity indicates how difficult the requirement response. Functional requirements are best
will be to implement expressed as a verb or verb phrase. Functional
requirements are written so as not to unnecessarily

7
 All too often, there is a fatal flaw in
effectively managing IT project
requirements. Once defined, requirements
changes must be managed throughout the
business solution life cycle.

constrain the solution, thus providing a firm Requirements management

foundation for the system architects. A major control gate for projects occurs upon exiting
• Supplemental requirements stipulate a physical or the requirements phase and transitioning to
performance characteristic and serve as constraints requirements management. This involves presenting
on system capabilities. Constraints pose restrictions requirements for review and approval at a formal
on the acceptable solution options. Constraints may control gate review session. At this point, the project
include the requirement to use a predetermined schedule, cost, and scope estimates are updated,
language or database, or specific hardware. and the business case is revisited, to provide the
Constraints may also specify restrictions such as salient information needed to determine whether
resource utilization, message size and timing, continued investment in the project is warranted.
software size, maximum number of and size of files, Upon securing approval to proceed, the business
records, and data elements. Business constraints analyst baselines the requirements, implements a
include budget limitations, restrictions on the formal requirements change control process, and
people who can do the work, skill sets available, transitions into requirements management activities in
etc. Technical constraints include any enterprise support of solution design efforts.
architecture standards to which the system must
Who is responsible for managing requirements? All
adhere.
too often, there is a fatal flaw in effectively managing
Documentation activities involve translating the IT project requirements. Once defined, requirements
collective requirements into written requirements changes must be managed throughout the business
specifications and models in terms that are solution life cycle. In addition to managing
understood by all stakeholders. This task typically requirements, the relationship between the product
involves substantial time and effort as each scope and project scope must be understood and
stakeholder may have different expertise, managed. For example, a critical project often merits
perspectives, and expectations of the requirements. formal, thorough, and time-consuming scoping
activities, while a routine project might require
Requirements validation substantially less documentation and analysis. The
Requirements validation is the process of evaluating business analyst and project manager work
requirement documents, models, and attributes to collaboratively to define and manage the product
determine whether they satisfy the business needs and project scope. Requirements management
and are complete enough that the technical team can activities include:
commence work on system design and development.
The set of requirements is compared to the original • Allocating requirements (also referred to as
initiating documents (business case, project charter, partitioning) to different subsystems or sub-
or statement of work) to ensure completeness. Beyond components of the system. Top-level requirements
establishing completeness, validation activities are allocated to components defined in the system
include evaluating requirements to ensure that design architecture such as hardware, software, manual
risks associated with the requirements are minimized procedures, training, etc.
before further investment is made in system • Tracing requirements throughout system design and
development. An often-used analysis technique to development to track where in the system each
validate requirements is prototyping. requirement is satisfied. As requirements are

8
 converted to design documentation, the sets of requirements engineering, requirements are going to
requirements documentation, models, change due to several circumstances:
specifications, and designs must be rigorously
• The business environment is dynamic. In today’s
linked to ensure that the relevant business needs
economy, fundamental business forces are rapidly
are satisfied.
changing the value of system features. What now
• Managing changes and enhancements to the might be a good set of requirements may not be so
system. Managing requirements involves being able in a few months or a year.
to add, delete, and modify requirements during all
• Everything in IT systems development depends on
project phases.
the requirements. The assumption that fixed
• The business analyst continues to facilitate the requirements are not the norm also means the
validation and verification of requirements baseline plan is subject to change.
throughout the project. This purpose of verification
• Estimation is difficult for IT projects as they are
and validation is to ensure that the system satisfies
basically research and development endeavors.
the requirements, as well as the specifications and
The nature of IT systems is intangible, and the real
conditions imposed on it by those requirements.
value is difficult to predict.
• Validating requirements to provide evidence that
Realizing the difficulty in defining and managing
the designed solution satisfies the requirements
requirements, and having described the business
through user involvement in testing,
analysis practices, it is imperative that we discuss
demonstration, and inspection techniques. The
three additional concepts: agile development, the
final validation step is the user acceptance
iterative nature of requirements generation and
testing, led and facilitated by the business
system development (especially for software-intensive
analyst.
systems), and the element of scalability.
• Verifying requirements to provide evidence that
the designed solution satisfies the requirements Agile Development
specification through test, inspection, Over the past few years, there’s been a rapidly
demonstration, and/or analysis. growing interest in agile (a.k.a. “lightweight”)
methodologies. Described as an approach to rid IT
System maintenance and enhancement
development of burdensome bureaucracy (Fowler,
The business analyst’s job does not end when the IT
2003), or alternatively a license to hack, agile
solution is delivered and operational; she also
methodologies have generated interest throughout
maintains key responsibilities in the following areas
the IT world.
(Mooz, Forsberg, & Cotterman, 2003):
The emphasis in agile methods differs substantially
• Maintenance – service provided to prevent and
from traditional, heavyweight engineering methods.
correct defects in the IT system
The most notable divergence is that they are less
• Enhancements – changes to increase the value document-oriented, usually emphasizing a lesser
provided by the system to the business amount of documentation for a given task. Moreover,
• Operations and Maintenance – the phase in which agile methods often spotlight source code as a key
the system is operated and maintained for the part of documentation. Additionally, there are two
benefit of the business. Documentation produced more fundamental distinctions:
in this phase includes system validation
• Agile methods are adaptive rather than predictive.
procedures, system validation report, maintenance
Engineering methods plan out a large part of the
reports, annual operational reports, and
solution in great detail, and then manage changes
deactivation plan and procedures. The business
throughout the project. Agile methods attempt to
analyst plays a major role in managing
adapt and thrive on change.
enhancements to the system, and in determining
when the system should be replaced and therefore • Agile methods are people-oriented rather than
deactivated. process oriented. The goal of engineering methods
is to define a process that is repeatable and
Requirements engineering independent of the development team. Agile
methods focus on the skill of the development team,
considerations trying to make the process more tightly support the
To understate the obvious, requirements engineering team in its work.
is a difficult and risky business. Ideally, we would like The world of agile analysis challenges business
to get a clear and thorough picture of the analysts to become the communication mentors and
requirements before development, obtain customer coaches of project teams. To do this, one of the
sign-off on these requirements, and then set up tenets of agile development must be followed: that of
procedures that limit requirements changes following active stakeholder participation throughout the
sign-off. However, regardless of the care taken in project life cycle. The focus changes from our

9
venturing forth to find out what customers want, to likely to be followed when little or no process had
helping them determine what they want and need. been employed in the past.
The obvious enabler to active stakeholder • Small Core Team. The development team must be
participation is co-location of the business and small, high-performing, dedicated full time, highly
development team. However, the business community skilled, and empowered to make most project
cannot always free critical resources to work with the decisions.
development team on a fulltime basis. In this case,
• Unknown Requirements. Agile approaches are
the business analyst will conduct interviews and
appropriate when requirements are uncertain or
workshops with the business community in its own
volatile. Logic dictates that if requirements are
environment, with key members of the development
unstable, you cannot have a stable design, or be
team present to hear “the voice of the customer.”
able to rigidly adhere to a planned process.
What is agile analysis? The business analyst follows • Highly Invested Stakeholders. It is important for the
the same practices outlined above, while customer to understand that when requirements
incorporating these traits (Ambler, 2005): change, following a predictive process is risky. In
• Communication Rich. Analysis is communication addition, the customer must be willing to be
rich, valuing face-to-face meetings and involved during the entire development process.
teleconferencing over documentation and e-mail. • Incremental Development. Agile methods work well
• Highly Iterative. Agile analysis is highly iterative. when you are working iteratively and incrementally.
Analysis and design activities are dependent on
Iteration
each other, and in practice are matured in an
Although the steps appear to be sequential in this
iterative manner. Indeed, since estimating is part of
discussion of business analyst practices, they are
analysis, it is impossible to estimate the cost of a
unquestionably performed iteratively. Iterating is the
solution without knowing the solution design.
best defense when attempting to control an
• Constant Feedback. Agile analysis is highly unpredictable process. The business analyst needs to
incremental, so that components of the solution can build in candid feedback mechanisms at frequent
be implemented for customer feedback before intervals in order to reveal the status of requirements
committing to further investment in development. and development.
Hence, estimation and prioritization of requirements
in increments is a must. This approach facilitates The key to this feedback is an iterative approach to
trade-off analysis and critical decision making on requirements generation. During the requirements
the part of the customer. phase, the IT architects are working on early
iterations of the solution design. As the business
• Just Enough. Agile analysis follows the premise that
analyst conducts requirements trade-off analyses, the
good is good enough. It is the art of applying just
architect does the same on solution options. Thus,
the right amount of rigor—no more and no less.
prototyping is the first step in iterative development.
Ambler presents this definition of agile analysis:
Whether called incremental, evolutionary, staged, or
“Agile analysis is a highly iterative and incremental spiral methodology, these techniques are iterative in
process where developers and project stakeholders nature. Early prototypes are produced, followed by
actively work together to understand the domain, to incremental working versions of the final system
identify what needs to be built, to estimate that containing a subset of the required features.
functionality, to prioritize the functionality, and in the
process, optionally producing artifacts that are just These working sub-systems possess limited
barely good enough.” functionality, but are otherwise true to system
requirements. The value of iterative development is
So, when is it appropriate to use agile methods found in regular customer reviews and feedback
(Fowler, 2003)? Current thinking suggests that these following each iteration.
methods should be used when the following
conditions are present; the absence of one or more The best validation that requirements have been met
of these circumstances will likely put the agile is a tested, integrated system. Documents and models
approach at risk. often contain undetected defects. When users
actually work with a system, flaws become evident,
• Transitioning to More Rigor. When you have been whether caused by a system defect or a
following the code-and-fix method, using agile misunderstood requirement.
methods will apply some discipline to the process.
The agile approach has the advantage of being For the project manager, a new approach to
easier to implement than a more rigorous method. planning is essential. Rolling wave planning is the
Much of the advantage of agile methods stems order of the day, where short-term plans cover a
from their light weight. Simpler processes are more single iteration and are quite detailed, while later
iterations are planned at only a high level. Iterative

10
Figure 2 Project Attribute
Project Sizing Grid

Low Risk (Small) Low-to-Moderate Risk (Medium) Significant, High Risk (Large)

Estimated Time < 6 Months 6 - 12 Months 12 - 24 Months

Core Team Size <7 7-12 Core Team Members > 12 Core Team Members

Cost < $750,000 $750,000 - $1 million > $1 million

Schedule Schedule is flexible. Schedule can undergo minor Deadline is fixed and cannot be
variations, but deadlines are firm. changed. Schedule has no room
for flexibility.

Complexity Easily understood problem and Either difficult to understand the Both problem and solution are
solution. The solution is readily problem, the solution is unclear, difficult to define or understand,
achievable. or the solution is difficult to and the solution is difficult to
achieve. achieve.

Strategic Importance Internal interest only Some direct business impact and/ Relates to key strategic initiatives.
or relates to a low priority initiative.

Level of Change Impacts a single business unit. Impacts > 1 business units. Enterprise impacts.

Dependencies No major dependencies or Some dependencies or interrelated Major high-risk dependencies or

interrelated projects. projects, but considered low risk. interrelated projects.

Significant, High-Risk Project Low-to-Moderate Risk Project Low Risk Project

Figure 2a
Project Sizing Formula
Level of Change = Enterprise, or Four or more categories in Remaining combinations
two or more categories in Large medium column; or one category
Column in Large column, and three or
more in Medium column

development provides a firm foundation in each

increment that becomes the basis for later waves of
Recipe for project success
plans. Whatever the nature of your project, a business
analyst can’t go wrong if she remembers to scale the
Iterative, agile, incremental development is the latest project by following the recipe for success adapted
defense in the quest for IT achievement. Results can from The Standish Group International, Inc. in their
be dramatic. Business value is delivered faster and 1999 report: Unfinished Voyages, a Follow-Up to the
cheaper. Customers can see constant progress. CHAOS Report. Their message is clear: size matters.
Frequent feedback keeps the project aligned with When structuring a project or major project phases,
business needs since flexibility and change are built the project manager and business analyst should
into the project. Value-based prioritization ensures the strive to follow these guidelines to reduce project risk.
most important features of the solution are delivered
first. Feedback is central; it’s about learning faster,
not working faster.
Ingredients: Minimization,
Scalability communications, standard processes
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 Mix with: Full-time core team members:
initiation, and progressively elaborated as the project business analyst, project manager,
traverses its life cycle. For small, straightforward
projects that are easily understood, a minimal
business visionary, architects and
amount of requirements documentation and models is developers, coached by an involved
appropriate. Indeed, the rule is that the smaller the project sponsor
team, the less formal the documentation. However,
for significant, complex, high-risk projects, a full set
of approved requirements documentation is in order. Bake: No longer than six months, no
For low-to-moderate risk projects, the rigor should be more than six people, at no more than
scaled appropriately, applying more formality and
$750,000
structure in the higher risk areas of the project. See
Figure 2, Project Sizing Grid. The related sizing
formula appears after the grid.

11
 training, and real-world experience should include
Business analyst challenges the following (Sodhi & Sodhi, 2003):
Any discussion of the business analyst role is
incomplete without addressing the pitfalls of filling • Knowledge of the overall requirements generation
this difficult and vital function. Although the business process
analyst is expected to scope the system, translate • Requirements initiation
business needs to developers, translate technical • Systems requirements elicitation
issues to business representatives, model and • Requirement types
document requirements, act as communication • How to write good requirements
broker, serve as political mentor, test and validate the • Documenting requirements
solution (and in general, represent customers, users, • Requirements definition
and stakeholders), the position can sometimes wield • System requirements documentation
too much power (Ambler, 2005). For many • Requirements feasibility and reliability
organizations, the addition of senior business • Cost/benefit analysis
analysts has greatly improved the elicitation and • Alternative solution analysis
documentation of requirements. However, there are • Feasibility and reliability risk analysis
common problems that often occur. It pays the
• Managing system requirements
business analyst to take heed of these pitfalls.
• Tools and techniques
• Knowledge and Skills. Business analysts often lack • Technical specifications
necessary skills due to the IT practice of thrusting • Test plans
strong technologists into managerial positions. • Requirements traceability process
• Barrier vs. Bridge. Business analysts sometimes • Requirements and system development
assume too much influence over project decisions. • Requirements and systems engineering processes
Some business analysts may stand between the • Systems engineering planning
technical and business communities, instead of • Requirements management controls
serving as a facilitator and enabler by bringing • Requirements analysis for IT systems
them together at the table. In such cases, the • Requirements functional analysis and allocation
business analyst acts as a communication barrier • Requirements and systems design
versus a bridge. • Requirements and systems implementation
• Lagging Business and Technical Acumen. Business
analysts quickly become generalists in both the Map out your business
business and technical arenas. Maintaining analyst development program
credibility with both communities requires staying
Look for leading-edge business analysis training
current with both technology advances and
offerings focused on increased performance, best
business trends.
practices, and project results. The courses should be
• Analysis Paralysis. Business analysts are often based on sound systems engineering principles,
tempted to overanalyze, stretching out the analysis focused on leadership and facilitation skills, rich in
period rather than iterating. Several iterations with lean-thinking, agile tool sets, targeted toward real-
feedback from both business and technical world IT situations emphasizing outsourcing
communities are worth more than a single, all- challenges, and filled with tailoring techniques for
encompassing analysis. Sometimes this leads the small, medium, and large, high-risk projects.
business analyst to make promises based on
theoretical models that may not work in practice. The course offerings should be designed to provide
practical guidelines and skills that lead to immediate
The grooming of the results for writing, defining, analyzing, and
managing IT systems requirements. Based on real-
business analyst world experiences and case studies, courses for the
How do IT organizations develop the exceptional business analyst should offer practical strategies,
business analysts needed to bridge the chasm well-tested methods, and tools for implementing
between the business and technical communities? As requirements management techniques.
with any other leadership role, competency comes
Whether you are an individual developing your
from acquiring education and training, seeking
career or a manager advancing your organization’s
mentoring and coaching, and jumping in head first
IT business analysis capability, select education and
to learn the discipline. Because the role requires both
mentoring offerings that will increase the value your
business and technical expertise, formal
projects contribute through advanced business
qualifications for business analysts include studies of
analysis. Seek consultants who will work with you to
computing and management information systems,
select the best mix of courses and reinforcement
coupled with traditional business administration
strategies that will provide immediate impact to your
courses. In addition, business analyst education,
organization.

12
Final words
Gaps in technology, techniques, and tools are not the By: Kathleen B. Hass, PMP
fundamental reasons why projects fail. Rather, project Project Management and Business Analysis Practice
failure most often stems from a lack of leadership, Leader
and poor choices made by people. Undeniably, the Management Concepts
business analyst and project manager are evolving 8230 Leesburg Pike
into the IT project leaders of the future. But team Vienna, Virginia 22182
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 than do poorly
managed teams (Bechtold, 1999). Traditional business
managers and technical leads cannot necessarily
become effective team leaders without appropriate
training and coaching. There is no shortage of roles
that the business analysis leader of teams can play.
Some suggest that they are the new wave of IT
management, assuming roles that include sponsor,
promoter, trainer, teacher, team member, inventor, and
entrepreneur.

Leading researchers and scholars consider project

success as the way to ensure organizational success.
Conversely, significant project failure often leads 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 assignment, track
performance, and reward them appropriately.

Unlike the past, when organizations embarked upon

professional training and mentoring only after a crisis
or in conjunction with a major reorganization, IT
organizations are now rising to the challenge and
valuing less technical, more business and leadership-
focused competencies. Whatever the driver,
components of world-class, professional business
analysis career programs include most of these
elements: formal off-the-shelf and customized
training; mentoring and on-the-job training,
advancement based on education, testing, and
experience; defined evaluation and compensation
processes; and suitable titles and advancement
opportunities.

13
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.

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.

14
Figure 3
Business Solution Life Cycle
Business Solution Life Cycle Systems Requirements Life Cycle

Deliverables Skills and techniques

Strategic planning
Strategic plan
Strategic goals

Value management techniques

Business case
Enterprise analysis Business need Facilitation and consensus building skills
Conflict management skills
High-level product description Decision-making techniques
Product Charter Business domain scope Key performance indicator development
Stakeholder management skills
Statement of work definition Requirements presentation skills

User class analysis Requirements Elicitation Requirements gathering tools

Requirements facilitation skills
Requirements management plan Requirement writing skills
Early requirement verification techniques
Feature prioritization matrix Analysis Partitioning/decomposition of
Requirements documentation requirements
Requirements feasibility Risk planning techniques
Alternatives study Specification Risk identification techniques
Risk analysis & response planning tools
Requirements baseline Prototyping techniques
Outsource development decision Feasibility & alternative analysis
Request for proposal (RFP) Documentation & techniques

validation

Design Allocate and trace Change management tools

Requirements allocation techniques
Requirements change
management plan
Requirements traceability matrix Mitigate risks
Outsource test decision
Request for proposal (RFP)
Test plan Trade-off analysis Risk monitoring & control tools
Test cases
Test scenarios
Prototype Prototyping techniques

Construction Manage change

Development code based tests

Trace

Functional tests Verification techniques

Supplemental tests Test Test Validation techniques
User acceptance test

System delivery Deliver Deliver User surveys and interviews

Post implementation support

System Operations and Operations and Change management tools

maintenance/enhancements maintenance maintenance

Deactivate

15
These materials, developed and copyrighted by Management Concepts, Inc, are licensed to Hewlett-Packard Company for customer delivery.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP
shall not be liable for technical or editorial errors or omissions contained herein.
4AA1-5102ENE, October 2007