Building Business Analysis Capabilities A Planning Toolkit from Enfocus Solutions Inc. http:// EnfocusSolutions.com

1. Building Business Analysis CapabilitiesA Planning Toolkitfrom Enfocus Solutions Inc.http://EnfocusSolutions.com

2. Building Business Analysis Capabilities Table of Contents The Value of Business Analysis 2 Why Business Analysis is Important 3 Defining the Role of the Business Analyst 14 Current State of Business Analysis Maturity 17 Stakeholder Engagement 21 Benefits Realization Management 31 Enterprise Portfolio Management 37 Maturing your Business Analysis Capability 44 Business Analysis Performance Metrics 73

3. Maximize Value through Business Analysis

4. Why Business Analysis is Important

5. Project Success Rates Source: Standish Chaos Report, 2009

6. Project Success Rates Source: Standish Group Chaos Reports

7. It Gets Worse!!! • Solutionwas ultimatelynotusedandwithdrawn because of lack of user adoption • Solution didnotdeliveronbusinesscase • Solution did not deliverexpected businessbenefits • Solution had poorusability, poor performance, orhigherrorratesrequiring rework The following projects would have been considered successful if they had delivered all planned scope on-time and on budgetusing the CHAOS criteria, but …

8. Waste: 45% of Functionality is never used Source: Standish Group Report at XP Conference 2002 by Jim Johnson

9. Where are the Benefits? • “78% of Information Systems projects failed to realize even 50% of the originally identified benefits.” Source: Management Today • “Only 40% of CFOs find that their IT investments are producing the returns they expected. ” Source: Gartner, How to Optimize IT Investment Decisions • “30-40% of systems to support business change deliver no benefit whatsoever.” Source: OGC, Successful Delivery Toolkit

10. Most Projects Deliver Little or No Business Value The Culprit Poor business analysis is at the root of most project failures. • Poor requirements • Poor communications between business and development teams. • Business cases are mostly used to secure funding and are not used to manage project outcomes. • Low business analysis maturity levels for most organizations • There is serious lack of tools to support business analysis.

11. Top 3 Reasons for Challenged Projects Source: Standish Chaos Report, 2011 Lack of User Input Incomplete Requirements Changing Requirements All of these are symptoms of Poor Business Analysis

12. The Cost of Poor Business Analysis • Companies with poor business analysis capability will have three times as many project failures as successes. • 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group’s projects were “runaways” which had any 2 of the following: • Taking over 180% of target time to deliver. • Consuming in excess of 160% of estimated budget. • Delivering under 70% of the target required functionality. • Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects. • Over 41% of the IT development budget for software, staff, and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization. • The vast majority of projects surveyed did not utilize sufficient business analysis skills to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed. Source: Business Analysis Benchmark, IAG Consulting

13. Most IT Projects Deliver Little or No Business Value The Problem Too many failed or challenged projects. Significant functionality is developed but never used. Projects seldom deliver benefits identified in the business case.

14. What are the Benefits of Good Requirements? Significantly lower costs through less rework Higher project success rates Delivery of more value to the business through effective requirements prioritization Faster time to market through earlier detection of defects Better alignment between IT and the business Higher user satisfaction More efficient testing Avoidance of costly workarounds resulting from missed requirements

15. Defining the Role of the Business Analyst

16. Business Analysis is Much More than Requirements • Requirements • Requirements Elicitation • Requirements Development • Requirements Management • Enterprise Analysis • Problem Analysis • Business Case • Organization and Process Change • Business Process Modeling • Business Process Improvement • Stakeholder Analysis and Communications • Organizational Readiness • Organizational Change Management • Manage Delivery of Value • Solution Assessment and Validation • Business Benefits Realization • Enterprise Portfolio Management

17. Business outcome oriented Business process improvement skills Organizational change skills Broad (not deep) IT technical knowledge Customer management skills Ability to conceptualize and think creatively Can articulate a vision Interpersonal skills, ethics, and integrity Negotiation and conflict management skills Analytical and communication skills Business Analyst Role: More About the Business than IT

18. Current State of Business Analysis Maturity

19. Requirements Maturity On average, performance virtually doubled as organizations progressed from using an ad-hoc approach for requirements definition and management to having institutionalized and consistent competency in business analysis. Source: IAG Consulting Business Analysis Benchmark 2009 Improved on time performance of technology projects increased by 161%. Reduced time overruns on projects by 87%. Improved average on budget performance for technology projects by just over 95%. Reduced budget overruns by just under 75%. Improved the per cent of projects that deliver 100% of the functionality needed by the business by just over 75%. Reduced average functionality missed by approximately 78%.

20. Current State of Business Analysis Maturity Business analysis maturity is low for most organizations. Effective requirements management does not necessarily equate to business analysis maturity. The profession of business analysis is relatively new: • IIBA was formed in 2004. • IIBA chapters were not created until 2008. • Less than 2,500 Certified BAs (2,230 CBAP, 184 CCBAs). IIBA’s competency model is geared towards individuals,not organizations. There is no recognized standard for measuring Business Analysis maturity: • Kitty Hass and Associates. • CompassBA/PM™ CMM. • IAG Requirements Management Maturity Model. • CMMI Requirements Development and Requirements Management. • Enterprise Agility’s BAMM. • Enfocus Business Analysis Maturity Model.

21. How is Your Business Analysis Maturity? If you answer “Yes” to any item – Your BA Maturity is not where it needs to be. Customers are not satisfied with product quality or IT services. Business and IT stakeholders frequently have different interpretations of requirements. Five types of requirements as specified in the IIBA BABOK are not defined and used consistently for all projects. • Business Requirements • Stakeholder Requirements • Functional Requirements • Nonfunctional Requirements • Transition Requirements Business cases are seldom prepared or when prepared, only used for funding purposes. After requirements elicitation, stakeholders are not involved again on the project until acceptance testing. Solution alternatives do not consider stakeholder, business process, and IT service impact. Requirements elicitation is haphazard. Key stakeholders are often not included in requirements elicitation. Important requirements are frequently missed. Frequent and often unnecessary requirements changes delay projects. ROI or some other measure of financial benefits is not estimated and measured on projects.

22. Stakeholder Engagement

23. How can better Collaboration betweenthe Solution Team and Stakeholders Help? Lack of user input is the #1 cause of project failures. Joint ownership of requirements results in lower costs and higher quality solutions. Organization change goes more smoothly when users and other stakeholders are involved through the entire lifecycle. Effective business analysis is the key for better collaboration between stakeholders and developers.

24. Joint Responsibility for RequirementsMakes a Big Difference Source IAG Business Analysis Benchmark, 2008

25. Engage your Stakeholders!!! • Learn background and purpose of project • Document and express needs • Document business rules • Gather relevant background materials • Review and validate requirements • Participate in requirement prioritization • Review design documents • Participate in software and prototype demonstrations • Participate in retrospectives and capturing lessons learned • Provide additional information for unclear requirements • Build test scenarios and test cases for user acceptance testing • Perform user acceptance tests • Approve changes to requirement specifications • Define transition requirements • Help prepare the organization for change

26. What is Solution Scope?

27. Why is Solution Scope important? Carefully defined solution scope is key to prevent scope creep, deliver value, and serve as a basis for gathering user needs and developing requirement specifications. Solution scope consists of high-level Features of the proposed solution. Features should be prioritized based on business value. Features are used to capture stakeholder needs and organize requirements. Using features significantly reduces solution scope creep. Using features is highly-beneficial for both Agile and Waterfall development, as well as implementation of Commercial Packages. Managing Features = Managing Business Value

28. Two Types of Value for the User Gain Creators Pain Relievers Value is helping the user get a job done faster, more conveniently, and less expensively than before.

29. Identify and Understand Your Users • Identify all your various types of users • Prepare a persona for each user type • The personas should contain: • Responsibilities • Systems and Services Used • Profile • Expectations • Review the persona with real users to ensure that it adequately represents their view.

30. Understand User’s Activities and Problems • Users frequently cannot describe their needs. However, they almost always describe what they do and what problems they frequently encounter. • When customers do understand their needs, they often cannot communicate these needs clearly to developers. • Users should develop scenarios that describe the work they do. • Problem Scenarios – Describe problems encountered in performing their work • Activity Scenarios – Describe how users perform their daily work • Interaction Scenarios – Describe how users interact with the system • Business Analysts read the scenarios to determine how the solution will add value to the user’s job. • Pain Relievers • Gain Creators • Business Analysts develop functional requirements to address the needs outlined in the scenarios and validate the requirements with users and developers.

31. What are the Key Reasons Expected Business Benefits are not Achieved? • The business problem was poorly defined giving rise to a flawed business case. • The business case was poorly developed and established an incorrect or unrealistic expectation. • Requirements for the solution were inaccurate, incomplete, or were poorly defined. • Delivery of the solution was poorly executed. • The technical solution was fundamentally flawed. • The delivered solution was not effectively adopted by the business. • The business changed significantly between inception and project completion.

32. Benefits Realization Management

33. Value Index Business Benefits Received ----------------------------------- Solution Cost

34. Benefits Realization Management • Benefits realization starts with defining a realistic business case. • Benefits do not just happen. • Benefits realization has its own lifecycle. • Benefits rarely happen according to plan. • Benefits realization is a continuous process of envisioning results, implementing, checking intermediate results, and dynamically adjusting the path leading from investments to business results. • Benefits realization is a process that can and must be managed, just like any other business process.

35. Benefits Realization Management

36. Benefits Realization Management • Validate and Re-Validate the Business Case • Create Benefit Realization Accountability • Create a Benefit Realization Management Plan • Measure and Evaluate Benefits Realization at Key Points • Identify Problems and Document Solutions • Continually Optimize Processes, Organization, and Technology to Achieve Benefits • Create a Benefits Dashboard

37. Business Analysis Involves Facilitating Business Change 7 Core Aspects 12 Additional Aspects Source: ePMbook

38. Enterprise Portfolio Management

39. Portfolio Management Portfolio Management is a corporate, strategic level process for coordinating successful delivery across an organization's entire set of programs and projects. • To obtain the highest return from your available resources given an acceptable level of risk. • To ensure balance – in terms of investment types and organizational strategies. • To ensure funding allocations reflect business priorities. • To reallocate funds when performance deteriorates and/or priorities change. • To manage dependencies, constraints and minimize double counting of benefits. • To manage Portfolio-level risk and uncertainty. • To provide transparent reporting on performance from strategic intent to benefits realization.

40. Portfolio Management is More Than Just Projects Process Portfolio Process BPM IT Service Portfolio Technology ITSM ProjectPortfolio Strategy PPM Stakeholder Portfolio People Org. Change • Project Portfolio Management (PPM) is often not understood or embraced and is often managed quite haphazardly. • PPM is often has different tools and processes and organizations to manage projects, processes, applications, and IT services. • Enterprise portfolio management involves addressing strategy, people, process, and technology.

41. Portfolio ManagementManaging for Value • Evaluate • Value • Alignment • Fit • Innovation Value Are the benefits worth the effort and risk? • Optimize • Re-Scope • Re-Classify • Re-Assign (resources) • Re-Design (merge) • Remove (cancel) • Reschedule Do the projects contribute to the strategic goals of the company? Alignment Do we have the resources and skills to complete the project? Fit • Monitor • KPIs • Solution Delivery • Benefits Realization • Stakeholder Satisfaction Are we willing to invest something new and will we gain a competitive advantage? Innovation

42. Gartner’s View of Portfolio Management • Enterprise Portfolio Management Offices are beginning to emerge. The key driver is the need to merge technology and business projects under the same organization. • Organizations must consider moving beyond traditional IT portfolio management to align with mission critical business objectives. • Since 2008, there has been a high rate of PMO startup activity with an implementation failure rate of more than 50%. • By 2014, more than 30% of organizations will experience a proliferation of software tools installed to support Project and Portfolio Management processes and projects. • “Don’t start a PMO unless it focuses on demonstrable results and business value vs. process and administrative burden.” Source: Gartner Group – Project Manager 2014 Effective portfolio management requires managing strategy, people, processes, and technology and focuses on delivering business value, not creating an additional process or administrative burden.

43. Key Takeaways for Portfolio Management • PMOs will emerge to EPMOs merging IT and business portfolio silos including: • IT Service Portfolio Management • Traditional PMOs • BA Centers of Excellence • Portfolio management will focus more on delivering value and less on standardization of processes and administration • By 2014, companies will invest 30% less time and money in traditional IT project management than in 2011. (Source: Gartner Group) • Business analysis skills will play a major role in realizing the potential benefits of an EPMO.

44. Business Value Lifecycle Portfolio Management Project Delivery Benefits Realization “Doing the Right Projects” “Doing Projects Right” “Harvesting the Benefits” • Solution Scoping • Business Case • Prioritization • Approval • Closing projects that are no longer important • Requirements • Design • Build • Test • Deploy • Measure • Evaluate • Optimize Portfolio Governance Project Management Business Analysis Enterprise Portfolio Management

45. Building yourBusiness Analysis Capability

46. Business Analysis Capability Maturity Levels 5 4 3 2 1 5.0 Innovating Focus on innovations used to gain competitive advantage 4.0 Managed Enterprise portfolio managed for business value 3.0 Aligned Valuable solutions are delivered and aligned with the business 2.0 Defined Business requirements defined and managed 1.0 Initial Process unpredictable, poorly controlled and reactive

47. Enfocus Business Analysis Maturity Model™ 3. Aligned 4. Managed 5. Innovating 1. Initial 2. Defined Stage: Survival Projects Business Alignment Enterprise Portfolio Business Model Innovation Focus: Awareness of the importance of business analysis Business requirements defined and managed Solutions aligned with the business Enterprise portfolio managed for business value Innovations used to gain competitive advantage Goal: Description: Business analysis methods are not well established and defined. Deep fragmentation exists across the organization - one area does it one way while another unit is following a different process for getting the same thing done. Things get done through individual effort as opposed to a standardized process. • All five types of requirements are defined and managed in a consistent way. • Business requirements • Stakeholder requirements • Functional requirements • Nonfunctional requirements • Transition requirements More advanced business analysis techniques are used to address business and organizational change. All projects are now aligned with business goals and objectives. Given standard performance baselines, business analysts can now measure, benchmark and evaluate performance across the enterprise. Enterprise portfolio management practices are used to manage business benefits across the enterprise. Business analysts work with business units to link enterprise goals and strategies to programs. Business analysts work as internal consultants with business units to evaluate innovations to gain a competitive advantage. Capabilities: • Elicitation • Solution scope • Requirements development • Requirements management • PM Partnership • Stakeholder engagement & communications • Business analysis planning and management • Solution analysis • Business case development • Business rules • Business process improvement • Organizational change • IT service strategy and design • Project portfolio management • Process portfolio management • Service portfolio management • Business Model /CapabilitiesAnalysis • Competitive market analysis • Enterprise portfolio management • Innovation management Enterprise Portfolio Management Office EPMO manages enterprise innovation Community of Practice Center of Excellence

48. Enfocus Business Analysis Maturity Model™Business Analysis Capabilities 2. 3. 4. 5.

49. Understanding the levels Understanding the Levels 1 2 3 4 5 Success depends on individual heroics People Processes “Fire fighting”is a way of life Measurement Relationships between disciplines are uncoordinated, perhaps even adversarial Technology

50. Understanding the Levels 1 2 3 4 5 People Success depends on individuals Commitments are understoodand managed People are trained Processes Measurement Technology