2008 Business Analystthe Pivotal Role Of The Future 2 1214327785520885 9


Published on

This is a presentation by Kathleen Hass that highlights her paper by the same name. It was retrieved from the web

Published in: Business, Education
  • Be the first to comment

2008 Business Analystthe Pivotal Role Of The Future 2 1214327785520885 9

  1. 1. The Business Analyst The Pivotal IT Role of the Future Presented by: Kathleen B. (Kitty) Hass, PMP Project Management and Business Analysis Practice Leader [email_address]
  2. 2. <ul><li>The Past – Challenged Projects </li></ul><ul><li>The Future – High Stakes </li></ul><ul><li>The Project Performance Partnership </li></ul><ul><li>The Professional Business Analyst </li></ul><ul><li>Business Analyst Development Program </li></ul><ul><li>Requirements Engineering Considerations </li></ul>Agenda
  3. 3. The Past – a Dismal Record
  4. 4. The Present – Still Troubling Nearly ⅔ of all projects fail or run into trouble.
  5. 5. What the Experts Say – The Root Cause is Poor Business Requirements <ul><li>Meta Group Research - “Communication challenges between business teams and technologists are chronic - we estimate that 60%-80% of project failures can be attributed directly to poor requirements gathering, analysis, and management.” </li></ul><ul><li>Forrester Research - “Poorly defined applications have led to a persistent miscommunication between business and IT that largely contributes to a 66% project failure rate for these applications, costing U.S. businesses at least $30B every year.” </li></ul><ul><li>James Martin - “56% of defects can be attributed to requirements, and 82% of the effort to fix defects.” </li></ul><ul><li>Source: www.iiba.com/events.cfm#pww </li></ul>
  6. 6. <ul><li>Change is the norm </li></ul><ul><li>Fierce competition is the driver </li></ul><ul><li>Lean thinking is the latest call to action </li></ul><ul><li>Success is the only option </li></ul><ul><li>Strategy depends on projects </li></ul>The Future – Fierce Competition
  7. 7. <ul><li>Projects are essential to the growth and survival of today’s organizations </li></ul><ul><li>Projects create value by responding to changing environment, competition, marketplace to </li></ul><ul><ul><li>Improve business processes </li></ul></ul><ul><ul><li>Eliminate waste & drive inefficiencies out of operations </li></ul></ul><ul><ul><li>Offer new products and services </li></ul></ul><ul><ul><li>Flow higher value to customers </li></ul></ul><ul><li>Often business needs can only be satisfied by large change initiatives that have a significant IT component </li></ul><ul><li>Result: a never-ending demand for new IT systems </li></ul><ul><ul><li>IT is viewed as a value provider </li></ul></ul><ul><ul><li>IT is faced with an extraordinary combination of pressures </li></ul></ul><ul><ul><li>How can we eliminate most of the challenged and failed projects? </li></ul></ul>The Future - IT is at the Heart of Business Strategy
  8. 8. <ul><li>Executives have their eyes on the IT portfolio to ensure that they: </li></ul><ul><ul><li>Understand their capacity to deliver </li></ul></ul><ul><ul><li>Invest in the right mix of projects </li></ul></ul><ul><ul><li>Develop expert capabilities & optimize their resources </li></ul></ul><ul><ul><li>Cancel high-risk, under performing projects </li></ul></ul><ul><ul><li>Deliver flawlessly </li></ul></ul><ul><ul><li>Flow value through the business to customers </li></ul></ul><ul><li>The BA role is now about value! </li></ul>Achieve Strategy Through Projects
  9. 9. Can You Relate? <ul><li>How has the past been for you? </li></ul><ul><li>How critical are the projects you are working on? </li></ul>
  10. 10. <ul><li>A bridge is built between the business and technical communities </li></ul><ul><li>The business need is understood before solutions are developed </li></ul><ul><li>The customer is involved in the project throughout the life cycle </li></ul>Breaking the Cycle of Challenged Projects
  11. 11. The New Project Leaders are Strategy Executors <ul><li>In the past, PMs were primarily implementers of solutions </li></ul><ul><ul><li>Narrow orientation focused on technical implementations </li></ul></ul><ul><ul><li>Skills narrow focused on budget, schedule, specs </li></ul></ul><ul><li>Role undergoing major transformation due to new business realities </li></ul><ul><ul><li>Effective project management tantamount to effective business management </li></ul></ul><ul><ul><li>Skills broadened, encompassing all aspects of business management </li></ul></ul><ul><li>Business Analyst role professionalizing </li></ul><ul><li>Project leadership teams emerging </li></ul>
  12. 12. How Well Do We Execute Strategy? <ul><li>Studies indicate that less than 10% of strategies successfully formulated are effectively executed </li></ul><ul><ul><li>85% of executives spend less than one hour per month on strategy </li></ul></ul><ul><ul><li>95% of the workforce don’t understand their organization’s strategy </li></ul></ul><ul><ul><li>60% of organizations do not link strategies to the budget </li></ul></ul><ul><ul><li>70% of organizations do not link strategies to incentives </li></ul></ul><ul><ul><li>Source: David Norton, Project Balanced Scorecards – a Tool for Alignment, Teamwork and Results . ProjectWorld & The World Congress for Business Analysts Conference Proceedings, November 2005 </li></ul></ul>
  13. 13. <ul><li>Combining disciplines leads to success </li></ul><ul><ul><li>Business analyst </li></ul></ul><ul><ul><li>Project manager </li></ul></ul><ul><ul><li>Business visionary </li></ul></ul><ul><ul><li>System architect/technical lead </li></ul></ul><ul><li>Each taking the lead depending on the project needs </li></ul><ul><li>Determined to break the cycle of challenged projects </li></ul>The Project Performance Partnership
  14. 14. Traditional Project Team Business Team & End-users IT Architecture Team Test Team Project Manager Business Sponsor Business Analyst Team Leads Test Manager Architect Business Visionary Development Team
  15. 15. Core Project Team Concept Business Team & End-users IT Architecture Team Test Team Project Manager Business Sponsor Business Analyst Team Leads Test Manager Architect Business Visionary Development Team SMEs
  16. 16. <ul><li>A senior position in the enterprise placed either in </li></ul><ul><ul><li>Business units </li></ul></ul><ul><ul><li>IT organization </li></ul></ul><ul><li>As IT moves beyond efficiency to business effectiveness </li></ul><ul><ul><li>BA becomes the central figure on the project team who is “bi-lingual” – i.e., speaks both business and technical languages </li></ul></ul><ul><li>Differs from traditional IS analysis in that it focuses almost exclusively on adding value to the business </li></ul>Enter The Professional Business Analyst
  17. 17. Typical Business Analyst <ul><li>40 years old </li></ul><ul><li>Well educated </li></ul><ul><li>Paid $78K per year </li></ul><ul><li>Hails from IT </li></ul><ul><li>More than 5 years experience performing BA functions </li></ul><ul><ul><li>36% > 10 years </li></ul></ul><ul><li>Analysis skills acquired on the job </li></ul><ul><li>Disturbingly, they report </li></ul><ul><ul><li>Most of their projects do not deliver all requirements </li></ul></ul>Source: The New Business Analyst : A Strategic Role in the Enterprise, November 2006 Evans Data Corporation Research Study
  18. 18. Ambiguity in the BA Role Source: The New Business Analyst : A Strategic Role in the Enterprise, November 2006 Evans Data Corporation Research Study Conclusion: there is a need for Business Analyst competency and career path definition 13.0% Other 10.1% Tester, Test Lead 13.5% Subject Matter Expert, Domain Expert 15.4% Developer, Engineer, Development Lead 18.7% Project Management 29.3% Business Analysis
  19. 19. Business Analyst Career Path PM/BA Principles BPR, Six Sigma Principles Business Writing Scribe Simple models Help Desk support Ability to perform simple tasks with assistance Associate Business &/or IT Domain Project Management BPR, Six Sigma Workshop Facilitation Requirements Modeling Elicit, Analyze, Specify, Validate, Manage Requirements Ability to perform simple-to-moderately complex tasks with minimal assistance Intermediate Business & IT Domains Project & Program Mgt. Systems Engineering, BPR, Six Sigma Requirements Engineering Elicit, Analyze, Specify, Validate, Manage Requirements Ability to perform complex tasks with minimal coaching Senior Business & IT Strategy Program and Portfolio Mgt. Systems Engineering, BPR, Six Sigma Enterprise Architecture Business Case Development Strategic Planning Enterprise Analysis Mentoring Ability to perform strategic tasks with minimal direction Strategic Competencies Responsibilities Proficiency Level
  20. 20. Staffing Surveys Reveal Increasing Demand for Senior BAs Who are Multi-Skilled <ul><li>Customer relationship management </li></ul><ul><li>Business domain knowledge </li></ul><ul><li>Time management and personal organization </li></ul><ul><li>Technical domain knowledge </li></ul><ul><li>Authenticity, ethics, and integrity </li></ul><ul><li>Business case development </li></ul><ul><li>Cost / benefit analysis </li></ul><ul><li>Rapid prototyping </li></ul><ul><li>Team management, leadership, mentoring, and facilitation </li></ul><ul><li>Business writing </li></ul><ul><li>Administrative, analytical, and reporting skills </li></ul><ul><li>Technical writing </li></ul><ul><li>Problem solving, negotiation, and decision-making </li></ul><ul><li>Business outcome thinking </li></ul><ul><li>Requirements risk assessment and management </li></ul><ul><li>Testing, verification, and validation </li></ul><ul><li>Organizational change management; management of power and politics </li></ul><ul><li>Communication of business concepts to technical audiences </li></ul><ul><li>Techniques to plan, document, analyze, trace and manage requirements </li></ul><ul><li>Communication of technical concepts to non-technical audiences </li></ul><ul><li>Capacity to articulate vision </li></ul><ul><li>Strategic and business planning </li></ul><ul><li>Ability to conceptualize and think creatively </li></ul><ul><li>Complex modeling techniques </li></ul><ul><li>Fundamentals of project management </li></ul><ul><li>Business process improvement and reengineering </li></ul><ul><li>Fundamentals of business analysis </li></ul><ul><li>Systems engineering concepts and principles </li></ul>Leadership Business Analytical Technical
  21. 21. Business Analyst Organizational Placement Usually placed in IT Junior Usually placed in IT Intermediate <ul><li>In IT (67%) </li></ul><ul><ul><li>The business may not take ownership of problems </li></ul></ul><ul><li>In BU (10.8%) </li></ul><ul><ul><li>Difficult for BAs to feel like a “community of practice” and hard to manage BA standards and improvements </li></ul></ul>Senior Part of an enterprise-wide PMO or center of excellence with a strategic focus Working on pre-project analysis, serving as BA for strategic initiatives, and managing projects for value Strategic Organizational Placement Level
  22. 22. BA Role - The Past Elicitation Analysis Elicitation Specification Validation and Documentation Requirements Phase
  23. 23. <ul><li>For the system architect, poor requirements results in </li></ul><ul><ul><li>A disconnect between what IT builds and what the business needs </li></ul></ul><ul><li>For the project manager, inadequate requirements lead to </li></ul><ul><ul><li>Poor estimates </li></ul></ul><ul><ul><li>Time and cost management becoming virtually impossible </li></ul></ul><ul><li>For the business </li></ul><ul><ul><li>Challenged/failed project </li></ul></ul><ul><ul><li>Business needs not met </li></ul></ul>Getting Requirements Right
  24. 24. BA Role - The Future Enterprise Analysis Strategic Planning Requirements Design Construction Test Deliver Operations and Maintenance Deactivate
  25. 25. What do Today’s BAs Really Do? <ul><li>Organizational change </li></ul><ul><li>Organizational readiness </li></ul><ul><li>Organizational change management </li></ul><ul><li>Business artifacts: business policies, procedures, rules, training, retooling, restructuring </li></ul><ul><li>Requirements management </li></ul><ul><li>Planning </li></ul><ul><li>Elicitation </li></ul><ul><li>Analysis </li></ul><ul><li>Specification </li></ul><ul><li>Validation </li></ul><ul><li>Change management </li></ul><ul><li>Communication </li></ul><ul><li>Enterprise analysis </li></ul><ul><li>Business architecture </li></ul><ul><li>Opportunity analysis </li></ul><ul><li>Problem analysis </li></ul><ul><li>Solution feasibility analysis </li></ul><ul><li>Business case development </li></ul><ul><li>Solution assessment and validation </li></ul><ul><li>Benefits measurement and management </li></ul>
  26. 26. The BA Drives Strategic Alignment Enter New Mkts Increase Quality Grow Market Share Reduce Costs Improve Shopper Experience Certify 1000 Reps Coaching Job-related e-learning Higher Hiring Stds Learning Management System TMM NAITF* In-store Learning Kiosks Content Acquisition Training Policy etc. DB Boxes Apps etc. Certificate Process
  27. 27. Strategic Business Analyst Role: Managing the Business Value <ul><li>During the project life cycle </li></ul><ul><ul><li>Once projects are funded, they must be managed throughout the project life cycle to ensure that the business case remains valid and continued investment in the project is still warranted </li></ul></ul><ul><li>After solution delivery </li></ul><ul><ul><li>Once the project delivers the new business solution, the Business Analyst ensures organizational measurements are in place: </li></ul></ul><ul><ul><li>Actual benefits that are achieved vs. </li></ul></ul><ul><ul><li>Benefits promised in the business case </li></ul></ul><ul><li>For solution enhancements </li></ul>
  28. 28. Business Solution Value Cost to Develop, Operate and Retire the Solution Business Value Deployment Value = Benefits – Costs to Develop, Operate, Retire Project Costs
  29. 29. <ul><li>The BA & PM partner to conduct requirements phase planning and to </li></ul><ul><li>Understand (or create if non-existent) </li></ul><ul><ul><li>Business vision, drivers, goals and objectives </li></ul></ul><ul><ul><li>Business needs, environment & constraints </li></ul></ul><ul><ul><li>Business case, project charter, and scope definition </li></ul></ul><ul><li>Assemble and educate the requirements team </li></ul><ul><li>Define the requirements artifacts to be produced (documents, graphs, models, matrices) </li></ul><ul><li>Develop the requirements management plan </li></ul><ul><ul><li>Use your PM to help plan requirements activities </li></ul></ul>Requirements Planning
  30. 30. <ul><li>Discovery </li></ul><ul><ul><li>Interview management and end users </li></ul></ul><ul><ul><li>Review current business process, supporting systems, studies </li></ul></ul><ul><ul><li>Document business problem and opportunity </li></ul></ul><ul><li>Current Vs. future business architecture </li></ul><ul><ul><li>Develop/refine current state models (“As Is”) </li></ul></ul><ul><ul><li>Develop/refine future state models (“To Be”) </li></ul></ul><ul><li>Scope statement, WBS and scoping models </li></ul><ul><ul><li>Start with information in the business case </li></ul></ul><ul><ul><li>Build to clearly defined and approved scope </li></ul></ul><ul><ul><li>Use Problem Domain (aka Conceptual Domain) models to describe the context in which the business solution will operate </li></ul></ul>Business Planning & Scope Definition
  31. 31. <ul><li>Conduct requirements gathering sessions with customers, users, and stakeholders </li></ul><ul><li>Requirements gathering techniques include </li></ul><ul><ul><li>Requirements workshops </li></ul></ul><ul><ul><li>Discovery sessions </li></ul></ul><ul><ul><li>Interviews </li></ul></ul><ul><ul><li>Surveys </li></ul></ul><ul><ul><li>Prototyping </li></ul></ul><ul><ul><li>Note taking and feedback loops to customers, users, and stakeholders </li></ul></ul><ul><li>Acquire/hone your facilitation skills! </li></ul>Requirements Elicitation and Discovery
  32. 32. Requirements Analysis Process 2. Decomposing requirements 4. Studying and assessing requirements feasibility 5. Prioritizing requirements 1. Modeling requirements 3. Confirming Scope
  33. 33. <ul><li>Structure requirements information into various categories </li></ul><ul><li>Evaluate requirements for selected qualities </li></ul><ul><li>Represent requirements in different forms </li></ul><ul><li>Derive detailed requirements from high-level requirements </li></ul><ul><li>Negotiate priorities </li></ul><ul><li>Determine function and performance characteristics </li></ul><ul><li>Define context of implementation </li></ul><ul><li>Identify stakeholder constraints, measures of effectiveness, and validation criteria </li></ul>Requirements Analysis – The Key Requirements are first stated in simple terms, then decomposed, restated and captured to:
  34. 34. What is Requirements Modeling? <ul><li>Describes requirement using specialized notation, languages, and symbols </li></ul><ul><li>Goal: </li></ul><ul><ul><li>Simplify reality and filter out “noise” </li></ul></ul><ul><ul><li>Aid understanding of complex systems and processes </li></ul></ul><ul><ul><li>Provide different views and perspectives on what is important to different audiences </li></ul></ul><ul><ul><li>Assure that all aspects of problem are considered </li></ul></ul><ul><ul><li>Translate more easily into solutions </li></ul></ul><ul><li>Because you have multiple models that you can apply, you need to know their strengths and weaknesses to be effective in their use. </li></ul><ul><li>Since each modeling technique has its pros and cons, to be effective you will want to have several requirements modeling techniques in your toolkit. </li></ul><ul><li> Source: Scott W. Ambler 2005 </li></ul>
  35. 35. Modeling Categories
  36. 36. What is Requirements Specification? <ul><li>Process of documenting a system’s requirements in a structured, shareable, and manageable form </li></ul><ul><li>Structures functional and supplemental requirements </li></ul><ul><li>Provides structured requirements repository with attributes specified </li></ul>Source: Karl E. Wiegers, Software Requirements Business Need Written Functional Requirements Graphical Functional Requirements Supplemental Requirements
  37. 37. The Importance of Requirements Specification <ul><li>The amount of information we must manage increases rapidly as we move lower down the pyramid </li></ul><ul><li>Prepares for requirements allocation </li></ul><ul><li>Provides foundation for requirements traceability (ability to follow a requirement forward and backward) </li></ul><ul><li>Accomplishes cross-referencing of project deliverables </li></ul>Modified from Dean Leffingwell
  38. 38. <ul><li>Identifier </li></ul><ul><ul><li>a unique reference </li></ul></ul><ul><li>Acceptance criteria </li></ul><ul><ul><li>nature of the test to demonstrate the requirement has been met </li></ul></ul><ul><li>Author </li></ul><ul><ul><li>who wrote the requirement </li></ul></ul><ul><li>Complexity </li></ul><ul><ul><li>how hard the requirements will be to implement </li></ul></ul><ul><li>Ownership </li></ul><ul><ul><li>the individual or group that needs the requirement </li></ul></ul><ul><li>Performance </li></ul><ul><ul><li>how the requirement must be met </li></ul></ul><ul><li>Priority </li></ul><ul><ul><li>the relative importance </li></ul></ul><ul><li>Source </li></ul><ul><ul><li>who requested the requirement </li></ul></ul><ul><li>Stability </li></ul><ul><ul><li>how mature the requirement is, to determine whether the requirement is firm enough to start work on </li></ul></ul><ul><li>Status </li></ul><ul><ul><li>indicating whether it is proposed, accepted, verified with the users, or implemented </li></ul></ul><ul><li>Urgency </li></ul><ul><ul><li>how soon the requirement is needed </li></ul></ul>Assign Requirement Attributes for Manageability
  39. 39. How Do I Recognize “Good” Requirements? <ul><li>“Good” Requirements </li></ul><ul><li>The requirements have been specified uniquely in well-written, unambiguous language </li></ul><ul><li>Absent duplicate or overlapping requirements </li></ul><ul><li>Stated in their entirety </li></ul><ul><li>Do not make assumptions about how the requirement will be implemented – solution free </li></ul><ul><li>Not outside the capability of current technology </li></ul><ul><li>Used to conduct further analysis </li></ul><ul><li>Reduced rework caused by defects in requirements </li></ul><ul><li>Invalid Requirements: </li></ul><ul><li>Incomplete in some way </li></ul><ul><li>Vague </li></ul><ul><li>Ambiguous </li></ul><ul><li>Inconsistent </li></ul><ul><li>Incorrect </li></ul><ul><li>Un-testable or not measurable </li></ul>
  40. 40. Requirement Guidelines and Pitfalls <ul><li>Guidelines: </li></ul><ul><li>Use natural non-technical language </li></ul><ul><li>Text Vs. diagrams: </li></ul><ul><ul><li>Use clearly written text Vs. diagrams for the precise definition of concepts </li></ul></ul><ul><ul><li>Use diagrams to express structure and relationships </li></ul></ul><ul><li>Pitfalls : </li></ul><ul><li>Incomplete understanding </li></ul><ul><ul><li>Failing to ask for clarification </li></ul></ul><ul><li>Incorrect interpretation </li></ul><ul><ul><li>Applying personal filters to the information that alter the intent </li></ul></ul><ul><li>Writing about implementation (the how ) instead of requirements (the what ) </li></ul><ul><ul><li>Implementation decisions should be deferred to as late a point in the requirements gathering process as possible </li></ul></ul><ul><li>Using undefined acronyms </li></ul><ul><li>Using incorrect sentence structure </li></ul>
  41. 41. Requirements Validation <ul><li>Benefits </li></ul><ul><ul><li>Defect reduction: avoid errors before they propagate to later development phases </li></ul></ul><ul><ul><li>Reduce project risk </li></ul></ul><ul><ul><li>Reduce ambiguity in requirements </li></ul></ul><ul><ul><li>Improve planning </li></ul></ul><ul><ul><li>Avoid insufficient involvement from development team </li></ul></ul><ul><ul><li>Address issues of minimal specifications </li></ul></ul>Requirements validation is the process of evaluating requirement documents, models, and attributes to determine whether they satisfy the business needs and are complete enough that the technical team can commence work on system design and development
  42. 42. Requirements Phase Exit <ul><li>Prepare for Phase Exit: </li></ul><ul><ul><li>Conduct requirement risk identification, analysis and risk response planning </li></ul></ul><ul><ul><li>Develop detailed plans for design and construction phases </li></ul></ul><ul><ul><li>Update business case </li></ul></ul><ul><ul><li>Conduct phase exit control gate reviews </li></ul></ul><ul><li>Prepare for Requirements Management: </li></ul><ul><ul><li>Baseline requirement specifications </li></ul></ul><ul><ul><li>Ensure requirement documentation is structured and easily accessible </li></ul></ul><ul><ul><li>Develop requirements change management plan, process, and tools </li></ul></ul><ul><ul><li>Communicate need for requirements change management process, change control board (CCB), roles and responsibilities </li></ul></ul><ul><ul><li>Begin to build the requirements traceability matrix and process </li></ul></ul>
  43. 43. <ul><li>Allocating requirements to different subsystems or sub-components of the system. </li></ul><ul><li>Tracing requirements throughout system design and development </li></ul><ul><li>Managing changes and enhancements to the system to add, delete, and modify requirements during all phases of the solution development life cycle </li></ul><ul><li>Continue validating and verifying requirements to: </li></ul><ul><ul><li>Ensure the system satisfies the customer </li></ul></ul><ul><ul><li>Determine whether the system satisfies specifications and conditions imposed upon it by the requirements </li></ul></ul>Requirements Management
  44. 44. Organizational Change Management <ul><li>Planning for the organizational change is often overlooked by IT-focused project teams, including: </li></ul><ul><ul><li>Business unit knowledge and skill assessment </li></ul></ul><ul><ul><li>Training/retooling/acquiring staff for skill gaps </li></ul></ul><ul><ul><li>Reorganization </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Managements’ role in the championing the change </li></ul></ul><ul><ul><li>Updated policies, procedures, business rules </li></ul></ul>
  45. 45. Requirements Best Practices <ul><li>Stakeholders actively participate </li></ul><ul><li>Confirm scope with customers and sponsors </li></ul><ul><li>Focus on how, not what </li></ul><ul><li>Prioritize needs, wants and desires </li></ul><ul><li>Deliver in increments </li></ul><ul><li>Speak business and user terminology </li></ul><ul><li>Ensure management support </li></ul><ul><li>Choose the right size modeling and documentation effort </li></ul>
  46. 46. <ul><li>Ranks of IT and the business </li></ul><ul><ul><li>As the IT development role is being outsourced, business savvy IT staff are transitioning into the role of BA </li></ul></ul><ul><li>Expertise </li></ul><ul><ul><li>Conventional business knowledge </li></ul></ul><ul><ul><li>Supplemented by IT domain knowledge </li></ul></ul><ul><li>As with any leadership role, competency comes from: </li></ul><ul><ul><li>Acquiring education and training </li></ul></ul><ul><ul><li>Seeking mentoring and coaching </li></ul></ul><ul><ul><li>Leveraging organizational support </li></ul></ul><ul><ul><li>Jumping in headfirst to learn the discipline </li></ul></ul>Where do Exceptional Business Analysts Come From?
  47. 47. <ul><li>Business outcome thinking </li></ul><ul><li>Ability to conceptualize and think creatively </li></ul><ul><li>Capacity to articulate vision </li></ul><ul><li>Interpersonal skills, ethics, and integrity </li></ul><ul><li>Negotiation and conflict management skills </li></ul><ul><li>Customer management skills </li></ul><ul><li>Analytical and communication skills </li></ul><ul><li>Broad (not deep) IT technical knowledge </li></ul>BA Development Program: It’s More About the Business than IT
  48. 48. <ul><li>It’s a difficult and risky business </li></ul><ul><ul><li>Requirements definition is difficult </li></ul></ul><ul><ul><li>Estimation of IT projects is often unreliable until requirements and the solution are well understood </li></ul></ul><ul><li>Requirements change because: </li></ul><ul><ul><li>Difficult to articulate – always unclear in the beginning </li></ul></ul><ul><ul><li>Iterative nature of requirements definition </li></ul></ul><ul><ul><li>Dynamic business environment </li></ul></ul><ul><li>Concepts to consider </li></ul><ul><ul><li>Firm basic requirements – not expected to change </li></ul></ul><ul><ul><li>Iteration – the best defense against ambiguity </li></ul></ul><ul><ul><li>Agile requirements – allows requirements to emerge </li></ul></ul><ul><ul><li>Scalability – barely sufficient is enough to move on </li></ul></ul>Final Words: Requirements Engineering Considerations
  49. 49. <ul><li>Lean methods alone will not ensure project success </li></ul><ul><li>Follow the Recipe For Project Success </li></ul><ul><ul><li>Ingredients: minimization, communications, standards </li></ul></ul><ul><ul><li>Mix with : f ull-time core team (business analyst, project manager, business visionary, lead architect/developer) coached by an involved project sponsor </li></ul></ul><ul><ul><li>Bake: no longer than six months, no more than six people, at no more than $750,000 </li></ul></ul>Recipe for Project Success Source: Standish Group International, Inc., Unfinished Voyages, A Follow-Up to The CHAOS Report (1999)
  50. 50. <ul><li>Kathleen B. (Kitty) Hass, PMP 303-663-8655 [email_address] </li></ul>For Further Information