1. Gil Garduno UNM Tech Days 2016 June 9, 2016

2. Objectives Definition of business analysis and business analyst profession Exploring the knowledge areas of business analysis Definition of requirements and its types

3. In the Beginning There was chaos…

4. In the Beginning Projects were like a battlefield

5. A lot of work was being done…but it wasn’t always productive

6. A Little Later On…Organizations invested in Project Management Practices

7. What do you mean it doesn’t work Only 16.2% of projects will be completed on time and on budget About 40-56% of project conflicts can be traced to requirements errors Finding and fixing requirement errors consumes 70-85% of project rework costs The average project exceeds its planned time schedule by 120% About 52.7% of projects will cost 189% of their original estimate About 30% of projects are cancelled before completion

8. Conclusion Typical project Expends least effort on requirements analysis Which is where most errors originate And whose errors cost most to fix And that’s why so many projects end up here:

9. Enter Business Analysis to Complete the Picture

10. How Did This Happen? In 2003, the International Institute of Business Analysis (IIBA) was established as an independent non-profit professional association, serving the growing field of business analysis

11. Defining Business Analysis Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders Business Analysis is a research discipline of identifying business needs and determining solutions to business problems. Business Analysis is NOT technology in search of a problem; Needs, NOT solutions come first Business analysis often finds that problems may also be solved by: Business process reengineering Training Upgrading existing solutions

12. Defining Business Analysis: Another View Business analysis is the practice of enabling change in an organizational context by defining needs and recommending solutions that deliver value to stakeholders.

13. A Business Analyst A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems.

14. Putting the Business Analyst in Context

15. The Business Analysis Paradox Employing a business analysis approach is an up-front investment in time and money that saves time and money in the back-end Reduction in requirements churn Reduction in development rework Uncovering more cost-effective solutions

16. Why is Business Analysis So Important Projects fail because the outcome is not as desired by business. Business Analysis is the bridge between the outcome and the need.

17. Business Analysis Knowledge Areas

18. Enterprise Analysis Feasibility Studies High-Level Risk Assessments Business Cases

19. Requirements Planning and Management Objective - Guide the enactment of the requirements elicitation process - Establish an agreement among project stakeholders - Roles and Responsibilities - Deployment Schedule

20. Just What is a “Requirement?” (1) A condition or capability needed by a stakeholder to solve a problem or achieve an objective (2) A condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification or other formally imposed document (3) A documented representation of a condition or capability as in (1) or (2) above. Two Essential Questions We Must Ask Of All Requirements: Does it support the problem we’re trying to solve? Will it help us realize a productivity gain?

21. Requirements Elicitation THE core BA activity! Elicited, not “gathered!” To elicit is to: Draw forth or bring out Call forth or draw out Requirements elicitation is an active effort to extract information from stakeholders and subject matter experts Elicitation is not a step or task you do at a certain point. It is a set of techniques you apply, appropriately during the requirements phase

22. The Results of Poor Requirements Elicitation

23. Elicitation: Mining More Deeply Basic Requirement: The system must have a Search engine. Derived Requirements: Database is refreshed daily to index new content and update changes to existing content Search engine must return results for Web pages, PDF, Word, Excel and PowerPoint Search engine must allow searches within different domains (.edu,.doc,.gov) Search engine must return results based on relevancy and popularity Search engine must allow for Boolean operands (and, or, +, -) Search engine must return results within two seconds after Enter is pressed. Keywords are highlighted on results returned.

24. The UNM Journey Two Business Analysts (Elaine Rising and Gil Garduno) were hired in January, 2015 to institutionalize business process practices across UNM IT Using business analysis practices, they successfully completed projects thought to be much more complex, time-consuming and resource-intensive.

25. Business Analysis Practice Maturity Model BA Awareness Informal BA processes Developing understanding of business analysis Determining value of business analysis BA Framework Establishing business analysis Center of Excellence with clearly defined roles and responsibilities Developing, piloting and deploying standard requirements management practices Requirements elicitation, analysis, prioritization, change control, communication Business analysis methods, practices, tools and training Business Alignment Realization that business analysis is essential to ensure business alignment: project goals, objectives, business solutions Focus on customer satisfaction and business alignment across the enterprise Emphasis on measuring benefits and solution assessment and validation Business/Technology Innovation Advanced business analysis practices used to innovate and use technology as a competitive advantage Focus on innovation, breakthrough processes and technology changes Converting opportunities into innovative business solutions

26. Back-up Slides

27. Requirements Prioritization The highest single part of building a software system is deciding precisely what to build…no other part of the work cripples the resulting system if done wrong. No other part is more difficult to rectify later. ~ Frederick P. Brooks Not all requirements carry equal weight High/Critical – Critical requirement without which product is not acceptable to stakeholders Medium/Important – Necessary, but deferrable requirement which makes produce less usable but still functional Low/Desirable – A nice feature to have if there are resources, but the product functions well without it.

28. Business Analysis: Like Trying to Describe An Elephant While Blindfolded

29. Agenda What is Business Analysis The Business Analysis Paradox Incorporating Business Analysis The Requirements Churn Impact of Poor Requirements Requirements is all Well and Good but Where Does Change Come In

30. Requirements: Ambiguity at Work Other Examples of Unachievable Requirements The system should be compatible with future operating system releases The screen should be blue The system shall process all mouse clicks very fast so users don’t have to wait The user must have Adobe Acrobat installed The system shall validate and accept credit cards and cashier’s checks The system must be stable

31. What Constitutes “Good” Requirements Requirements must be clear and concise Easily read and understood by non-technical people Unambiguous and not subject to multiple interpretations Requirements must be verifiable Stated in such a way that it can be tested by inspection, analysis or demonstration Must be possible to evaluate whether solution met requirement Is verifiable by means that will not contaminate the product or compromise data integrity Requirements must address one thing The word “and” usually means two requirements in one Sometimes one of the two is a higher priority than the other As a single entity, each requirement must pass or fail as one piece

32. What Constitutes “Good” Requirements Requirements must be viable Can be met with existing technology Can be achieved within budget Can be accomplished within schedule Will be used by end-users

33. What is Business Analysis? Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders Business Analysis is a research discipline of identifying business needs and determining solutions to business problems. Business Analysis is NOT technology in search of a problem; Needs, NOT solutions come first Business analysis often finds that problems may also be solved by: Business process reengineering Training Upgrading existing solutions

34. Requirements Churn “60%–80% of project failures can be attributed directly to poor requirements gathering, analysis, and management.” - Gartner Group “Poorly defined requirements 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.” – Forrester Research “The cost to fix a defect after delivery is more than 100 times the cost to fix it in the requirements and design phase.” – Gartner Group “70percent of software defects are introduced in the requirements phase.” – National Institute of Standards and Technology (NIST)

35. Requirements Elicitation: The Key to Good Requirements To elicit is to: Draw forth or bring out Call forth or draw out Requirements elicitation is an active effort to extract information from stakeholders and subject matter experts Elicitation is not a step or task you do at a certain point. It is a set of techniques you apply, appropriately during the requirements phase of a project

36. Impact of Poor Requirements