hp invent: The business analyst:The pivotal IT role of the future

7/30/2019 hp invent: The business analyst:The pivotal IT role of the future

http://slidepdf.com/reader/full/hp-invent-the-business-analystthe-pivotal-it-role-of-the-future 1/16

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 itsown, now viewed as a value provider as opposed toa cost drain. With the stakes so high, IT organizationsare faced with an extraordinary combination ofpressures to deliver value to their organizations interms of added revenues, avoided costs, lower taxes,higher productivity, less employee turnover, less riskexposure, etc. Competitive advantage is now linkedto an organization’s ability to rapidly deploy ITsolutions, and to change those systems as the

business need evolves. IT projects must not onlydeliver high quality products faster, better, andcheaper (traditionally the responsibility of the projectmanager), they are also under intense scrutiny topositively impact the bottom line (increasingly, the

joint responsibility of the project manager, projectsponsor, and the business analyst).



3

IntroductionProjects play an essential role in the growth andsurvival of organizations today. It is through projectsthat we create value in the form of improved businessprocesses and new products and services in responseto changes in the business environment. Since dataand information are the lifeblood of virtually allbusiness practices, IT projects are often the keymechanism used to turn an organization’s vision and

strategy into reality. Executives have their eye on theIT portfolio to ensure that they: (1) invest in the rightmix of projects, (2) optimize their resources, (3)develop expert capabilities to deliver flawlessly, andultimately, (4) capture the expected added value tothe business. Since there appears to be a never-ending demand for new IT products and services,executives across the spectrum are adopting thepractice of superior business analysis to increase thevalue IT projects bring to the business. The talents,competencies, and heroics of project managers andtechnologists alone cannot drive value into the

organization. For business needs and goals to beconverted into innovative solutions that truly bringwealth to the enterprise, a stronger bridge must bebuilt between the business and the technicalcommunities.

The project performancepartnershipEvery IT project, whether in-house or outsourced,COTS purchase or custom development, or complexsystems integration, needs exceptional requirements

management. In the spirit of high-performing teams,business analysts align themselves with professionalproject managers, the best developers, and businessvisionaries to determine the most appropriate, cost-effective, and innovative solution. As this core teamforms, a project performance partnership emergesthat rivals the world’s great teams, (e.g., tiger teams,special operations teams, professional sports teams,and parametric teams). At the center of the team isthe dynamic twosome: the project manager and thebusiness analyst. One has an eye on themanagement of the project, while the other focuseson management of the business requirements. Thewise project manager welcomes this teaming trend,understanding that inadequate information relatingto requirements leads to poor estimates, and makestime and cost management virtually impossible.

Why is the business analyst emerging as the centralIT competency of the future? Because requirementsplay a vital role in engineering IT systems, and five ofthe top eight reasons why projects fail are tieddirectly to poor requirements (The Standish Group,1998). It is the business analyst who manages the

entire Systems Requirements Life Cycle, fromunderstanding the business need to ensuring that thedelivered solution meets the need and adds value to

the bottom line. Clearly, the business analyst has acritical role throughout the Business SolutionDevelopment Life Cycle, not simply during therequirements phase. (See Figure 3, Business SolutionDevelopment Life Cycle Mapped to the SystemsRequirements Life Cycle, on the final page of this White Paper.)

It is through the leadership of the business analystthat requirements are captured and fully understoodby the technical team before solutions are designedand implemented. The business analyst serves as theliaison between the business community and thetechnical solution providers throughout the project lifecycle. As projects become larger, cross functional,global, and more complex, organizations arerealizing that requirements management skills areindispensable. With the current trend in outsourcingIT development, the role of the business analystbecomes even more critical in today’s IT environment.

Enter the professionalbusiness analyst When you hear about far-reaching innovation,cutting-edge technology, and high-growth IT careers,don’t just think in terms of architecture anddevelopment prowess. We are discovering thattechnical skills can be relatively easy to outsource,but organizations cannot abdicate control of theirbusiness requirements. In virtually every organization,the pivotal leadership role of the business analyst isbeginning 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 ofvaluable IT projects, the focus is on flawless projectexecution to maximize the value delivered to theorganization. All too often, however, IT projectsuccess is elusive. Projects are late, over budget, ormay never even be delivered. Sometimes work isincomplete, does not meet requirements orexpectations, and does not deliver the benefits orreturns on investment expected by the organization.This rather dismal IT delivery record can no longerbe tolerated.

What are the key organizational capabilitiesexecutives must build to improve deliveryperformance and meet business expectations? Forproject success, several capabilities are essential:

• Effective and targeted project management andsystems engineering processes, tools, andtechniques;

• Appropriate executive decision making at keycontrol gates;

• Exceptional project leadership and high-performingteams;

• Collaboration and respect between the businessand IT communities; and



Why is the business analyst emerging as the central ITcompetency of the future? It is the business analyst whomanages the entire Systems Requirements Life Cycle,from understanding the business need to ensuring thatthe delivered solution meets the need and adds value tothe bottom line.

4

• Business analysis processes that ensure thedevelopment team will have a clear understanding ofthe customer’s overall business and information

needs. Where do we get the exceptional business analystswho can bridge the chasm between the business andtechnical communities? As the project managementdiscipline matures into a strategic business practice,so must our business analysts evolve into strategicleaders of change.

Will the real business analystplease stand up?Frequently, expertise in the technical area of theproject is the key requirement for the position ofbusiness analyst. In this case, business analysis istreated as a subset of the technical discipline. Timeand again, projects encounter difficulties not from lackof technical expertise, but from an inability to gather,understand, analyze and manage businessrequirements, and convert them into useable systemspecifications. Projects are often initiated, and designand construction of the solution is underway, before ITteam members have a clear understanding of thebusiness need. Often, tolerance is low for technicalfailure and high for inadequate and ever-evolvingrequirements. All too often, IT projects suffer fromrequirements creep due to the “Let’s start coding andsee how it turns out” syndrome. While this may beappropriate when conducting agile development, itoften falls short for complex business systemsinitiatives.

Business requirements analysis differs from traditionalinformation systems analysis because of its focus,which is exclusively on adding value to the business.In particular, project managers rely on businessanalysts to assist in providing more detailed project

objectives; business needs analysis; clear, structured,useable requirements; trade-off analysis; requirement

feasibility and risk analysis; and cost-benefit analysis.Poor requirements definition emerges without this keyliaison between business and IT departments,

resulting in a disconnect between what IT builds andwhat the business needs.

To meet the challenge, technically adept engineersoften are asked to make the professional transition tothe disciplines of project management and businessanalysis. Often, these individuals assume a trio ofleadership roles on projects: technical lead, projectmanager, and business analyst. Inevitably, afterrequirements are captured at a high level and theproject plan is being executed, technical activitiestend to elicit the majority of attention. When thathappens, requirements and project managementsuffer, and the initiative is positioned to become arunaway project.

From analyst to project leaderIt is increasingly clear that while technical knowledgeareas are necessary, they are insufficient forsuccessfully managing requirements on the large,enterprise-wide, complex, mission critical projectsthat are the norm today. Just as a business leadermust be multi-skilled and strategically focused,business analysts must possess an extensive array of

leadership skills. The business analyst is nowassuming a leadership role, and is quickly rising to asenior position in the enterprise (whether placed inthe business unit or the IT organization). As the ITcontribution moves beyond efficiency to businesseffectiveness, the business analyst becomes thecentral figure on the project team who must be “bi-lingual” in speaking both business and technicallanguages. To perform in this pivotal role, thebusiness analyst must possess a broad range ofknowledge and skills.

Browsing through the more than 5,000 job postingsfor business analysts on Monster.com turned up thisjob description:



5

“The main purpose of the role will be to design andspecify innovative solutions which meet the businessrequirements allowing the business benefit to be

attained; and to facilitate divisional communicationand awareness of the standards and qualityexpectations within the System Analyst teams.”

Many job titles were also uncovered, includingbusiness analyst, business systems analyst, businesssystem planner, and even principal solutionsarchitect. Regardless of the job title, a strong,experienced business analyst is critical to IT projectsuccess. Simply put, without a well-understood anddocumented requirements baseline, it is virtuallyimpossible to meet project objectives. A baseline isthe set of functional and supplemental requirementsthat the project team has committed to implement ina specific release (Wiegers, 2003). It has been saidthat if an IT organization only has resources andbudget to put into a single life cycle area to improveproject performance, that area should berequirements definition and management. Dependingon the level of responsibility and placement in theorganization, business analyst duties include thefollowing:

• Identify and understand the business problem andthe impact of the proposed solution on theorganization’s operations

• Document the complex areas of project scope,objectives, added value or benefit expectations,using an integrated set of analysis and modelingtechniques

• Translate business objectives into systemrequirements using powerful analysis and modelingtools

• Evaluate customer business needs, thus contributingto strategic planning of information systems andtechnology directions

• Assist in determining the strategic direction of theorganization

• Liaise with major customers during preliminaryinstallation and testing of new products andservices

• Design and develop high quality business solutions While the business analyst is fast becoming arelatively senior position in the business world,historically it has been considered a mid- to low-levelrole. A recent survey revealed an increasing demandfor senior individuals who can perform the ever-widening range of business analysis functions. Sincebusiness analysts walk in both business and ITworlds, they arrive from various fields. Some comefrom the ranks of programmer/analyst positions,while others have conventional business expertisesupplemented by some IT training. To successfully fillthe business analyst role, one must acquire masteryof a unique combination of technical, analytical,business, and leadership skills. (See Figure 1,Business Analyst Knowledge and Skill SetRequirements.)

Business analysis in practiceDuring the requirements discovery and definition,requirements are determined and documented at avery high level. The requirements gathering processexplores the solution without commitment to any

specific product selection. Requirements definition ismost effective as a joint effort among users,customers, stakeholders, and developers (Hadden2003). Defining, analyzing, and documentingrequirements is a highly creative and iterative processthat is designed to show what the system will do, butnot how it will be done. Therefore, the requirementsin their textual and graphical form represent a modelof the system, serving as an intermediate stepbetween the business need and the solution design.

The requirements development process is typically

subdivided into business need identification, scopedefinition, elicitation, analysis, specification,documentation, validation, management, and

Technical

Systems engineering concepts andprinciples

Complex modeling techniques

Communication of technicalconcepts to non-technicalaudiences

Testing, verification, andvalidation

Technical writing

Rapid prototyping

Technical domain knowledge

Analysis

Fundamentals of business analysis

Ability to conceptualize andthink creatively

Techniques to plan, document,analyze, trace, and managerequirements

Requirements risk assessmentand management

Administrative, analytical, andreporting skills

Cost / benefit analysis

Time management andpersonal organization

Business

Business process improvement andreengineering

Strategic and business planning

Communication of businessconcepts to technicalaudiences

Business outcome thinking

Business writing

Business case development

Business domain knowledge

Leadership

Fundamentals of projectmanagement

Capacity to articulate vision

Organizational changemanagement; management ofpower and politics

Problem solving, negotiation,and decision-making

Team management, leadership,mentoring, and facilitation

Authenticity, ethics, and integrity

Customer relationshipmanagement

Figure 1Business Analyst Knowledgeand Skill Set Requirements



6

maintenance and enhancements. These sub-disciplines encompass all the activities involved withgathering, evaluating, and documentingrequirements (Young, 2001).

Business need As initiatives are selected, project sponsors andproject managers are assigned to new programs andsupporting projects. Pre-project analysis is required todetermine the most appropriate solution to achieve

the strategic goals. Activities include more detailedanalysis of the business need, feasibility studies,solution trade-off analysis, and development of high-level business requirements. The results of theseanalyses are often captured in Feasibility Studies,Benchmark Studies, Competitive Analysis Reports,Needs Analysis and high-level Business Requirementsdocuments.

Business domain scope definitionInitial requirements definition typically originates inthe early stages of the project when the productdescription is created, and is ideally captured ininitiating documents: the Business Case, ProjectCharter, or Statement of Work. All requirementsshould be traceable to these original sources. Prior toeliciting requirements, the business analyst andproject manager partner to conduct initial planningand scoping activities to: (1) gain perspective of theneeds and environment of customers, users, andstakeholders; (2) review, or create if non-existent, theBusiness Case, Project Charter, and Statement of Work (or similar scope definition document); (3)understand the business vision, drivers, goals, andobjectives for the new/changed system; (4) assembleand educate a requirements team comprised of keybusiness and technical stakeholders; (5) understandand document the scope of the project; (6) define thedocuments and models to be produced, and begin todevelop the Requirements Management Plan; (7)define/refine the checklist of requirements activities,deliverables, and schedule; and (8) plan for changethroughout the life cycle.

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

Business requirements are the essential activities of

the enterprise that must be supported by the system.Business requirements are derived from business

goals. The development of business scenarios is aneffective method for understanding businessrequirements. A critical success factor in the value ofthe system after deployment is the extent to which itsupports business requirements and facilitates theorganization in achieving business goals. Elicitationand discovery activities include:

• Identifying the customers, users, and stakeholders todetermine who should be involved in therequirements gathering process

• Understanding the business goals and objectives toidentify the essential user tasks that support theorganizational goals.

• Successful systems support the businessrequirements and facilitate achievement oforganizational goals

• Identifying and defining requirements to understandthe needs of the users, customers, and stakeholders.This is the activity of capturing the businessrequirements for a target system, as viewed by thecustomers, business users, and stakeholders.Business requirements are the critical activities of anenterprise that must be performed to meet theorganizational objectives, and they are solutionindependent. Business scenarios (a.k.a., usage-based scenarios) are often used as a technique toensure an understanding of business requirements.

• The Business Requirements Document and theRequirements Management Plan are the key outputsof this activity.

Requirements analysis

Requirements are first stated in simple terms, and arethen analyzed and decomposed for clarity.Requirements analysis is the process of structuringrequirements information into various categories,evaluating requirements for selected qualities,representing requirements in different forms, derivingdetailed requirements from high-level requirements,and negotiating priorities. Requirements analysis alsoincludes the activities to determine required functionand performance characteristics, the context ofimplementation, stakeholder constraints andmeasures of effectiveness, and validation criteria.

Through the analysis process, requirements aredecomposed and captured in a combination oftextual and graphical formats. Analysis represents themiddle ground between requirements and design(Ambler, 2005). Analysis activities include:

• Studying requirements feasibility to determine if therequirement is viable technically, operationally, andeconomically.

• Trading off requirements to determine the mostfeasible requirement alternatives

• Assessing requirements feasibility by analyzing

requirement risks and constraints and modifyingrequirements to mitigate identified risks. The goal is



7

to reduce requirement risks through early validationprototyping techniques.

• Modeling requirements to restate and clarify them.Modeling is accomplished at the appropriateusage, process, or detailed structural level.

• Deriving additional requirements as more islearned about the business need.

• Prioritizing requirements to reflect the fact that notall requirements are of equal value to the business.

Prioritization may be delineated in terms of critical,high, average, and low priority. Prioritization isessential to determine the level of effort, budget,and time required to provide the highest priorityfunctionality first. Then, perhaps, lower priorityneeds can be addressed in a later release of thesystem.

Requirements specificationRequirement specifications are elaborated from andlinked to the structured requirements, providing arepository of requirements with a completed attribute

set. Through this process of progressive elaboration,the requirements team often detects areas that arenot defined in sufficient detail, which unlessaddressed can lead to uncontrolled change to systemrequirements. Specification activities involveidentifying all the precise attributes of eachrequirement. This process ensures an understandingof the relative importance of each of the qualityattributes. The system specification document ordatabase is an output of the requirements analysisprocess.

Attributes are used for a variety of purposesincluding explanation, selection, filtering, andvalidating. In addition, attributes enable theassociation of data with objects, table markers, tablecells, modules, and projects (Stevens, Brook, Jackson,& Arnold, 1998). Attributes may be user defined orsystem defined. Attributes allow the requirementsteam to associate information with individual orrelated groups of requirements, and often facilitatethe requirements analysis process by filtering andsorting. Typical attributes attached to requirementsmay include:

• Unique identifier that does not change. Thereference is not to be reused if the requirement ismoved, changed, or deleted

• Acceptance criteria describe the nature of the testthat would demonstrate to customers, end users,and stakeholders that the requirement has beenmet. Acceptance criteria are usually captured fromthe end users by asking the question, “What kindof assessment would satisfy you that thisrequirement has been met?”

• Author of the requirement refers to who wrote it

• Complexity indicates how difficult the requirementwill be to implement

• Ownership specifies the individual or group thatneeds the requirement

• Performance addresses how the requirement mustbe met

• Priority of the requirement rates its relativeimportance at a given point in time

• Source of the requirement identifies who requestedit. Every requirement should originate from a sourcethat has the authority to specify requirements

• Stability is used to indicate how mature therequirement is. This is used to determine whetherthe requirement is firm enough to begin work on it

• Status of the requirement denotes whether it isproposed, accepted, verified with the users, orimplemented

• Urgency refers to how soon the requirement isneeded

Requirements documentationRequirements documentation must be clear andconcise since it is used by virtually everyone in theproject. Selected types of requirements may need to beexpressed formally using technical language, e.g.,legal, safety, and security requirements. This isacceptable, as long as they are mapped back to therequirements that are more easily understood.However, in most cases the language used todocument system requirements should be as non-technical as possible. A diagram can express structureand relationships more clearly than text, whereas forprecise definition of concepts, clearly articulatedlanguage is superior to diagrams. Therefore, both

textual and graphical representations are essential fora complete set of system requirements. Transforminggraphical requirements into textual form can makethem more understandable to non-technical membersof the team. This is one of the few times in the systemlife cycle when duplication is advisable.

Requirements are categorized into types dependingon their source and applicability. Understandingrequirement types helps in analyzing and prioritizingrequirements. While some requirements aremandatory, others may be nonessential.Understanding requirement types also enables thetechnical team to conduct trade-off analysis, estimatethe system cost and schedule, and better assess thelevel of changes to be expected. Finally, reviewing thelist of requirements types can aid the business analystin identifying areas that may require furtherinvestigation. Typically, requirements are broadlycharacterized as functional or supplemental (a.k.a.nonfunctional).

• Functional requirements describe capabilities thesystem will be able to perform in terms of behaviorsor operations – a specific system action or

response. Functional requirements are bestexpressed as a verb or verb phrase. Functionalrequirements are written so as not to unnecessarily



8

constrain the solution, thus providing a firmfoundation for the system architects.

• Supplemental requirements stipulate a physical orperformance characteristic and serve as constraintson system capabilities. Constraints pose restrictionson the acceptable solution options. Constraints mayinclude the requirement to use a predeterminedlanguage or database, or specific hardware.Constraints may also specify restrictions such asresource utilization, message size and timing,software size, maximum number of and size of files,records, and data elements. Business constraintsinclude budget limitations, restrictions on thepeople who can do the work, skill sets available,

etc. Technical constraints include any enterprisearchitecture standards to which the system mustadhere.

Documentation activities involve translating thecollective requirements into written requirementsspecifications and models in terms that areunderstood by all stakeholders. This task typicallyinvolves substantial time and effort as eachstakeholder may have different expertise,perspectives, and expectations of the requirements.

Requirements validationRequirements validation is the process of evaluatingrequirement documents, models, and attributes todetermine whether they satisfy the business needsand are complete enough that the technical team cancommence work on system design and development.The set of requirements is compared to the originalinitiating documents (business case, project charter,or statement of work) to ensure completeness. Beyondestablishing completeness, validation activitiesinclude evaluating requirements to ensure that designrisks associated with the requirements are minimizedbefore further investment is made in systemdevelopment. An often-used analysis technique tovalidate requirements is prototyping.

Requirements management A major control gate for projects occurs upon exitingthe requirements phase and transitioning torequirements management. This involves presentingrequirements for review and approval at a formalcontrol gate review session. At this point, the projectschedule, cost, and scope estimates are updated,and the business case is revisited, to provide thesalient information needed to determine whethercontinued investment in the project is warranted.Upon securing approval to proceed, the businessanalyst baselines the requirements, implements aformal requirements change control process, andtransitions into requirements management activities in

support of solution design efforts. Who is responsible for managing requirements? Alltoo often, there is a fatal flaw in effectively managingIT project requirements. Once defined, requirementschanges must be managed throughout the businesssolution life cycle. In addition to managingrequirements, the relationship between the productscope and project scope must be understood andmanaged. For example, a critical project often meritsformal, thorough, and time-consuming scopingactivities, while a routine project might requiresubstantially less documentation and analysis. Thebusiness analyst and project manager workcollaboratively to define and manage the productand project scope. Requirements managementactivities include:

• Allocating requirements (also referred to aspartitioning) to different subsystems or sub-components of the system. Top-level requirementsare allocated to components defined in the systemarchitecture such as hardware, software, manualprocedures, training, etc.

• Tracing requirements throughout system design anddevelopment to track where in the system eachrequirement is satisfied. As requirements are

All too often, there is a fatal flaw ineffectively managing IT projectrequirements. Once defined, requirementschanges must be managed throughout thebusiness solution life cycle.



9

converted to design documentation, the sets ofrequirements documentation, models,specifications, and designs must be rigorouslylinked to ensure that the relevant business needsare satisfied.

• Managing changes and enhancements to thesystem. Managing requirements involves being ableto add, delete, and modify requirements during allproject phases.

• The business analyst continues to facilitate thevalidation and verification of requirementsthroughout the project. This purpose of verificationand validation is to ensure that the system satisfiesthe requirements, as well as the specifications andconditions imposed on it by those requirements.• Validating requirements to provide evidence that

the designed solution satisfies the requirementsthrough user involvement in testing,demonstration, and inspection techniques. Thefinal validation step is the user acceptancetesting, led and facilitated by the business

analyst.• Verifying requirements to provide evidence that

the designed solution satisfies the requirementsspecification through test, inspection,demonstration, and/or analysis.

System maintenance and enhancementThe business analyst’s job does not end when the ITsolution is delivered and operational; she alsomaintains key responsibilities in the following areas(Mooz, Forsberg, & Cotterman, 2003):

• Maintenance – service provided to prevent andcorrect defects in the IT system• Enhancements – changes to increase the value

provided by the system to the business• Operations and Maintenance – the phase in which

the system is operated and maintained for thebenefit of the business. Documentation producedin this phase includes system validationprocedures, system validation report, maintenancereports, annual operational reports, anddeactivation plan and procedures. The businessanalyst plays a major role in managingenhancements to the system, and in determiningwhen the system should be replaced and thereforedeactivated.

Requirements engineeringconsiderationsTo understate the obvious, requirements engineeringis a difficult and risky business. Ideally, we would liketo get a clear and thorough picture of therequirements before development, obtain customersign-off on these requirements, and then set upprocedures that limit requirements changes followingsign-off. However, regardless of the care taken in

requirements engineering, requirements are going tochange due to several circumstances:

• The business environment is dynamic. In today’seconomy, fundamental business forces are rapidlychanging the value of system features. What nowmight be a good set of requirements may not be soin a few months or a year.

• Everything in IT systems development depends onthe requirements. The assumption that fixed

requirements are not the norm also means thebaseline plan is subject to change.• Estimation is difficult for IT projects as they are

basically research and development endeavors.The nature of IT systems is intangible, and the realvalue is difficult to predict.

Realizing the difficulty in defining and managingrequirements, and having described the businessanalysis practices, it is imperative that we discussthree additional concepts: agile development, theiterative nature of requirements generation andsystem development (especially for software-intensivesystems), and the element of scalability.

Agile DevelopmentOver the past few years, there’s been a rapidlygrowing interest in agile (a.k.a. “lightweight”)methodologies. Described as an approach to rid ITdevelopment of burdensome bureaucracy (Fowler,2003), or alternatively a license to hack, agilemethodologies have generated interest throughoutthe IT world.

The emphasis in agile methods differs substantiallyfrom traditional, heavyweight engineering methods.The most notable divergence is that they are lessdocument-oriented, usually emphasizing a lesseramount of documentation for a given task. Moreover,agile methods often spotlight source code as a keypart of documentation. Additionally, there are twomore fundamental distinctions:

• Agile methods are adaptive rather than predictive.Engineering methods plan out a large part of thesolution in great detail, and then manage changesthroughout the project. Agile methods attempt to

adapt and thrive on change.• Agile methods are people-oriented rather than

process oriented. The goal of engineering methodsis to define a process that is repeatable andindependent of the development team. Agilemethods focus on the skill of the development team,trying to make the process more tightly support theteam in its work.

The world of agile analysis challenges businessanalysts to become the communication mentors andcoaches of project teams. To do this, one of the

tenets of agile development must be followed: that ofactive stakeholder participation throughout theproject life cycle. The focus changes from our



10

venturing forth to find out what customers want, tohelping them determine what they want and need.The obvious enabler to active stakeholderparticipation is co-location of the business anddevelopment team. However, the business communitycannot always free critical resources to work with thedevelopment team on a fulltime basis. In this case,the business analyst will conduct interviews andworkshops with the business community in its ownenvironment, with key members of the development

team present to hear “the voice of the customer.” What is agile analysis? The business analyst followsthe same practices outlined above, whileincorporating these traits (Ambler, 2005):

• Communication Rich.Analysis is communicationrich, valuing face-to-face meetings andteleconferencing over documentation and e-mail.

• Highly Iterative.Agile analysis is highly iterative. Analysis and design activities are dependent oneach other, and in practice are matured in aniterative manner. Indeed, since estimating is part ofanalysis, it is impossible to estimate the cost of asolution without knowing the solution design.

• Constant Feedback.Agile analysis is highlyincremental, so that components of the solution canbe implemented for customer feedback beforecommitting to further investment in development.Hence, estimation and prioritization of requirementsin increments is a must. This approach facilitatestrade-off analysis and critical decision making onthe part of the customer.

• Just Enough.Agile analysis follows the premise thatgood is good enough. It is the art of applying justthe right amount of rigor—no more and no less.

Ambler presents this definition of agile analysis:

“Agile analysis is a highly iterative and incrementalprocess where developers and project stakeholdersactively work together to understand the domain, toidentify what needs to be built, to estimate thatfunctionality, to prioritize the functionality, and in theprocess, optionally producing artifacts that are justbarely good enough.”

So, when is it appropriate to use agile methods(Fowler, 2003)? Current thinking suggests that thesemethods should be used when the followingconditions are present; the absence of one or moreof these circumstances will likely put the agileapproach at risk.

• Transitioning to More Rigor.When you have beenfollowing the code-and-fix method, using agilemethods will apply some discipline to the process.The agile approach has the advantage of beingeasier to implement than a more rigorous method.Much of the advantage of agile methods stemsfrom their light weight. Simpler processes are more

likely to be followed when little or no process hadbeen employed in the past.

• Small Core Team.The development team must besmall, high-performing, dedicated full time, highlyskilled, and empowered to make most projectdecisions.

• Unknown Requirements.Agile approaches areappropriate when requirements are uncertain orvolatile. Logic dictates that if requirements areunstable, you cannot have a stable design, or beable to rigidly adhere to a planned process.

• Highly Invested Stakeholders.It is important for thecustomer to understand that when requirementschange, following a predictive process is risky. Inaddition, the customer must be willing to beinvolved during the entire development process.

• Incremental Development.Agile methods work wellwhen you are working iteratively and incrementally.

Iteration Although the steps appear to be sequential in this

discussion of business analyst practices, they areunquestionably performed iteratively. Iterating is thebest defense when attempting to control anunpredictable process. The business analyst needs tobuild in candid feedback mechanisms at frequentintervals in order to reveal the status of requirementsand development.

The key to this feedback is an iterative approach torequirements generation. During the requirementsphase, the IT architects are working on earlyiterations of the solution design. As the business

analyst conducts requirements trade-off analyses, thearchitect does the same on solution options. Thus,prototyping is the first step in iterative development.

Whether called incremental, evolutionary, staged, orspiral methodology, these techniques are iterative innature. Early prototypes are produced, followed byincremental working versions of the final systemcontaining a subset of the required features.

These working sub-systems possess limitedfunctionality, but are otherwise true to systemrequirements. The value of iterative development is

found in regular customer reviews and feedbackfollowing each iteration.

The best validation that requirements have been metis a tested, integrated system. Documents and modelsoften contain undetected defects. When usersactually work with a system, flaws become evident,whether caused by a system defect or amisunderstood requirement.

For the project manager, a new approach toplanning is essential. Rolling wave planning is theorder of the day, where short-term plans cover asingle iteration and are quite detailed, while lateriterations are planned at only a high level. Iterative



development provides a firm foundation in eachincrement that becomes the basis for later waves ofplans.

Iterative, agile, incremental development is the latestdefense in the quest for IT achievement. Results can

be dramatic. Business value is delivered faster andcheaper. Customers can see constant progress.Frequent feedback keeps the project aligned withbusiness needs since flexibility and change are builtinto the project. Value-based prioritization ensures themost important features of the solution are deliveredfirst. Feedback is central; it’s about learning faster,not working faster.

Scalability Whether a light or heavy methodology is used, allthe activities discussed above are performed. They

are likely to be executed in a broad sense at projectinitiation, and progressively elaborated as the projecttraverses its life cycle. For small, straightforwardprojects that are easily understood, a minimalamount of requirements documentation and models isappropriate. Indeed, the rule is that the smaller theteam, the less formal the documentation. However,for significant, complex, high-risk projects, a full setof approved requirements documentation is in order.For low-to-moderate risk projects, the rigor should bescaled appropriately, applying more formality andstructure in the higher risk areas of the project. SeeFigure 2, Project Sizing Grid. The related sizingformula appears after the grid.

Recipe for project success Whatever the nature of your project, a businessanalyst can’t go wrong if she remembers to scale theproject by following the recipe for success adaptedfrom The Standish Group International, Inc. in their

1999 report: Unfinished Voyages, a Follow-Up to theCHAOS Report. Their message is clear: size matters. When structuring a project or major project phases,the project manager and business analyst shouldstrive 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 anddevelopers, coached by an involvedproject sponsor

Bake:No longer than six months, nomore than six people, at no more than$750,000

11

Estimated Time

Core Team Size

Cost

Schedule

Complexity

Strategic Importance

Level of Change

Dependencies

Significant, High-Risk Project

Level of Change = Enterprise, ortwo or more categories in LargeColumn

Low Risk (Small)

< 6 Months

< 7

< $750,000

Schedule is flexible.

Easily understood problem andsolution. The solution is readilyachievable.

Internal interest only

Impacts a single business unit.

No major dependencies orinterrelated projects.

Low-to-Moderate Risk Project

Four or more categories inmedium column; or one categoryin Large column, and three ormore in Medium column

Low-to-Moderate Risk (Medium)

6 - 12 Months

7-12 Core Team Members

$750,000 - $1 million

Schedule can undergo minorvariations, but deadlines are firm.

Either difficult to understand theproblem, the solution is unclear,or the solution is difficult toachieve.

Some direct business impact and/or relates to a low priority initiative.

Impacts > 1 business units.

Some dependencies or interrelatedprojects, but considered low risk.

Low Risk Project

Remaining combinations

Significant, High Risk (Large)

12 - 24 Months

> 12 Core Team Members

> $1 million

Deadline is fixed and cannot bechanged. Schedule has no room

for flexibility.

Both problem and solution aredifficult to define or understand,and the solution is difficult toachieve.

Relates to key strategic initiatives.

Enterprise impacts.

Major high-risk dependencies orinterrelated projects.

Figure 2Project Sizing Grid

Project Attribute

Figure 2aProject Sizing Formula



Business analyst challenges Any discussion of the business analyst role isincomplete without addressing the pitfalls of fillingthis difficult and vital function. Although the businessanalyst is expected to scope the system, translatebusiness needs to developers, translate technicalissues to business representatives, model anddocument requirements, act as communicationbroker, serve as political mentor, test and validate the

solution (and in general, represent customers, users,and stakeholders), the position can sometimes wieldtoo much power (Ambler, 2005). For manyorganizations, the addition of senior businessanalysts has greatly improved the elicitation anddocumentation of requirements. However, there arecommon problems that often occur. It pays thebusiness analyst to take heed of these pitfalls.

• Knowledge and Skills. Business analysts often lacknecessary skills due to the IT practice of thrustingstrong technologists into managerial positions.

• Barrier vs. Bridge. Business analysts sometimesassume too much influence over project decisions.Some business analysts may stand between thetechnical and business communities, instead ofserving as a facilitator and enabler by bringingthem together at the table. In such cases, thebusiness analyst acts as a communication barrierversus a bridge.

• Lagging Business and Technical Acumen. Businessanalysts quickly become generalists in both thebusiness and technical arenas. Maintainingcredibility with both communities requires stayingcurrent with both technology advances andbusiness trends.

• Analysis Paralysis. Business analysts are oftentempted to overanalyze, stretching out the analysisperiod rather than iterating. Several iterations withfeedback from both business and technicalcommunities are worth more than a single, all-encompassing analysis. Sometimes this leads thebusiness analyst to make promises based ontheoretical models that may not work in practice.

The grooming of thebusiness analystHow do IT organizations develop the exceptionalbusiness analysts needed to bridge the chasmbetween the business and technical communities? Aswith any other leadership role, competency comesfrom acquiring education and training, seekingmentoring and coaching, and jumping in head firstto learn the discipline. Because the role requires bothbusiness and technical expertise, formalqualifications for business analysts include studies ofcomputing and management information systems,coupled with traditional business administrationcourses. In addition, business analyst education,

training, and real-world experience should includethe following (Sodhi & Sodhi, 2003):

• Knowledge of the overall requirements generationprocess• Requirements initiation• Systems requirements elicitation• Requirement types• How to write good requirements• Documenting requirements• Requirements definition• System requirements documentation

• Requirements feasibility and reliability• Cost/benefit analysis• Alternative solution analysis• Feasibility and reliability risk analysis

• Managing system requirements• Tools and techniques• Technical specifications• Test plans• Requirements traceability process• Requirements and system development• Requirements and systems engineering processes

• Systems engineering planning• Requirements management controls• Requirements analysis for IT systems• Requirements functional analysis and allocation• Requirements and systems design• Requirements and systems implementation

Map out your businessanalyst development programLook for leading-edge business analysis trainingofferings focused on increased performance, bestpractices, and project results. The courses should bebased on sound systems engineering principles,focused on leadership and facilitation skills, rich inlean-thinking, agile tool sets, targeted toward real-world IT situations emphasizing outsourcingchallenges, and filled with tailoring techniques forsmall, medium, and large, high-risk projects.

The course offerings should be designed to providepractical guidelines and skills that lead to immediateresults for writing, defining, analyzing, andmanaging IT systems requirements. Based on real-world experiences and case studies, courses for thebusiness analyst should offer practical strategies,well-tested methods, and tools for implementingrequirements management techniques.

Whether you are an individual developing yourcareer or a manager advancing your organization’sIT business analysis capability, select education andmentoring offerings that will increase the value yourprojects contribute through advanced businessanalysis. Seek consultants who will work with you to

select the best mix of courses and reinforcementstrategies that will provide immediate impact to yourorganization.

12



Final wordsGaps in technology, techniques, and tools are not thefundamental reasons why projects fail. Rather, projectfailure most often stems from a lack of leadership,and poor choices made by people. Undeniably, thebusiness analyst and project manager are evolvinginto the IT project leaders of the future. But teamleadership is different from traditional management,and teams are different from operational work

groups. The key issues are no longer centered oncontrol and management, but rather collaboration,consensus, and leadership.

Team leaders must have an understanding of howteams work, and the dynamics of team development.They must develop specialized skills that are used tobuild high-performing teams. When building software-intensive systems, well managed teams undoubtedlyaccomplish more work in less time than do poorlymanaged teams (Bechtold, 1999). Traditional businessmanagers and technical leads cannot necessarilybecome effective team leaders without appropriatetraining and coaching. There is no shortage of rolesthat the business analysis leader of teams can play.Some suggest that they are the new wave of ITmanagement, assuming roles that include sponsor,promoter, trainer, teacher, team member, inventor, andentrepreneur.

Leading researchers and scholars consider projectsuccess as the way to ensure organizational success.Conversely, significant project failure often leads tothe demise of companies. Organizations on theleading edge are improving project performance bybetter training and equipping their business analysts. A specific career path for business analysts leadingto senior executive positions is one strategy to retainkey talent, while training those who will follow.Enlightened organizations in both the public andprivate sectors are creating cohesive careermanagement plans for business analysts to developtheir potential, match their skills to assignment, trackperformance, and reward them appropriately.

Unlike the past, when organizations embarked uponprofessional training and mentoring only after a crisis

or in conjunction with a major reorganization, ITorganizations are now rising to the challenge andvaluing less technical, more business and leadership-focused competencies. Whatever the driver,components of world-class, professional businessanalysis career programs include most of theseelements: formal off-the-shelf and customizedtraining; mentoring and on-the-job training,advancement based on education, testing, andexperience; defined evaluation and compensationprocesses; and suitable titles and advancementopportunities.

By: Kathleen B. Hass, PMPProject Management and Business Analysis PracticeLeaderManagement Concepts8230 Leesburg Pike Vienna, Virginia 22182

13



References Ambler, S. (n.d.). Agile Analysis. Retrieved Apr. 08, 2005, from Ambysoft Website: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: ManagementConcepts.

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 ManagingRequirements 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



15

Strategic planning

Enterprise analysis

Requirements

Design

Construction

Test

Deliver

Operations andmaintenance

Deactivate

Business need

Test

Deliver

Operations andmaintenance

Business domain scopedefinition

Elicitation

Analysis

Specification

Documentation & validation

Allocate and trace

Mitigate risks

Trade-off analysis

Prototype

Manage change

Trace

Business Solution Life Cycle

Strategic planStrategic goals

Business caseHigh-level product description

Product CharterStatement of work

User class analysisRequirements management plan

Feature prioritization matrixRequirements documentation

Requirements feasibility Alternatives study

Requirements baselineOutsource development decision

Request for proposal (RFP)

Requirements changemanagement plan

Requirements traceability matrixOutsource test decision

Request for proposal (RFP)Test plan

Test casesTest scenarios

Development code based tests

Functional testsSupplemental tests

User acceptance test

System deliveryPost implementation support

System

maintenance/enhancements

Systems Requirements Life Cycle

Value management techniquesFacilitation and consensus building skillsConflict management skillsDecision-making techniquesKey performance indicator developmentStakeholder management skillsRequirements presentation skills

Requirements gathering toolsRequirements facilitation skillsRequirement writing skillsEarly requirement verification techniquesPartitioning/decomposition of

requirementsRisk planning techniquesRisk identification techniquesRisk analysis & response planning toolsPrototyping techniquesFeasibility & alternative analysis

techniques

Change management toolsRequirements allocation techniques

Risk monitoring & control tools

Prototyping techniques

Verification techniques Validation techniques

User surveys and interviews

Change management tools

Skills and techniquesDeliverables

Figure 3Business Solution Life Cycle



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 expresswarranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP