hp invent: the business analyst:the pivotal it role of the future
TRANSCRIPT
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
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 2/16
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).
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 3/16
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
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 4/16
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:
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 5/16
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
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 6/16
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/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 7/16
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
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 8/16
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.
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 9/16
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
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 10/16
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
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 11/16
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
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 12/16
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
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 13/16
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
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 14/16
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
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 15/16
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
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 16/16
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