Presentation is loading. Please wait.

Presentation is loading. Please wait.

. MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 1 1 Improving Business Analysis and Requirements Engineering. Presented by: Morris Oslin, Trissential, LLC.

Similar presentations


Presentation on theme: ". MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 1 1 Improving Business Analysis and Requirements Engineering. Presented by: Morris Oslin, Trissential, LLC."— Presentation transcript:

1 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 1 1 Improving Business Analysis and Requirements Engineering. Presented by: Morris Oslin, Trissential, LLC May, 8, 2008

2 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 2 Objectives Identify what exactly business analysis is in terms of its relationship to requirements What makes good software requirements What drives good requirements Roles and Processes in the Business Analysis Maturity model –Realize the need for separation of duties of roles –Describe the pitfalls of combining the roles –Provide suggestions for avoidance Skills and Tools in the Business Analyst Maturity model Case Study of Business Analysis/Requirements Basic Improvement Roadmap

3 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 3 Business Analysis- Definitions According to : Business analysis helps an organization to improve how it conducts its functions and activities in order to reduce overall costs, provide more efficient use of resources, and better support customers. It introduces the notion of process orientation, of concentrating on and rethinking end-to-end activities that create value for customers, while removing unnecessary, non-value added work. The person who carries out this task is called a business analyst or BA.orientationvalue addedbusiness analyst Those Business Analysts who work solely on developing software systems may be called IT Business Analysts or Technical Business Analysts.Significant Cultural Drivers affecting the software project: According to Trissential good requirements are f ocused on creating software products by being: Traceable to the business- map to an explicit business architecture. Consumable by the technical staff- used entirely and the only source

4 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 4 Business Analysis and Requirements- Current State Google Business Analysis Requirements you get: A lot of different training (people) A lot of different processes A lot of tools Which is best? Most are excellent choices Which people training, process and tools are best for my organization so we can produce requirements that are traceable and consumable? It Depends!

5 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 5 Business Analysis in the Organizational Model Effective Strategy & Planning Mind share Business, IT, Cultural Drivers Exceptional Execution Implemented Mindshare Requirements Ownership Business Excellence Benefit Validation ©2006 Trissential. All Rights Reserved. Business Analyst Software Product Development Business Processes and Static Model Business Analyst Leadership Efficient Management Accepted Business Requirements Approach

6 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 6 Business Analysis in Governance Model & Processes – E1 Bus & IT Executives Technology Architecture Business Architecture Program Architecture Facilitate Governance Decisions Determine Strategy Decompose Strategy Why, Why, Why Whats the Pain/Gain Create the Business Case and ROI Model the business as Static and In-motion (process) Technology Form & Fit Identification Categorization Evaluation Selection Prioritization Portfolio Balancing Authorization Review & Reporting Strategic Change

7 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 7 Business Analysis in the Project Management Model –E2 Business Requirements User and Stakeholder Identification and Profiling Requirements Approach (based on Bus. Reqs., User Profiling, and SDLC used on project) Business Analysis Leadership

8 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 8 Business Analysis in Product Development Model- E3 Business and System Analysis Quality Assurance and Testing Requirements Engineering Change Mgmt Application Architecture (as needed) Business Analyst Software Product Development

9 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 9 Business Analysis – Requirements Continuum The Drivers of Good Requirements Where does an organization think they are on the Requirements continuum? Where is the organization really at on the Requirements continuum? Where does the organization want to be on the Requirements continuum? Extreme Agile: Solution based story Agile Lite/Iterative: Story with business case Formal RUP: Use Case driven Defense Department (IEEE SRS and Spiral approach) Waterfall- Requirement Lists orientated RUP Lite: Use Case driven FluidRigid

10 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 10 Business Analysis – Requirements Continuum What are the business drivers that affect the Requirements? (E1) Operational Scalability Product speed to market Cut Operational Costs Increase Product Profit Margins Increase Customer Satisfaction Increase Product Market Share Regulatory Compliance Keep the lights on Explicit versus implicit business knowledge

11 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 11 Business Analysis – Requirements Continuum What are the project and cultural drivers that affect the Requirements? (E2) Physical Location of Project Team(s) Project Governance: Scorecard and Project Reporting Executive Sponsorship Business Engagement Residual Knowledge of the Business Architecture Culture Maturity (ex: Requirements capability) New or Existing Business

12 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 12 Business Analysis – Requirements Continuum What are the technology drivers that affect the Requirements?(E3) Resource Skill Sets System Complexity: Standalone vs. Integrated Resource Demand Development Tools: Example Agile and XML work well Development Costs Technology Support Costs Outsourcing Residual Knowledge of the Technology Architecture New or existing Technology

13 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 13 Business Analysis – Requirements Continuum So what should the Requirements Continuum be set at for my organization? The Requirement approach must be chosen on the Situational Needs of the project to produce good requirements. The Business Drivers, Technology Drivers, and Cultural/Project Drivers all work together to move the Requirements location on the continuum based on priority. The three Drivers fit right into the Essential Business Model. The Requirements Engineering Process, Tools, and People (Analysts and Technical staff) must fit the chosen Requirements approach.

14 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 14 Business Analysis - Roles & Responsibilities Business Analysis Quality Assurance Requirements Engineering Change Mgmt Software Development Software Product Development Business Architecture Business Analysis Leadership

15 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 15 Business Analysis - Role Comparison Project Plan Development (Requirements Phase) Project Plan Execution (Requirements Phase) Project Time Management (Requirements Phase) Apply Business Architecture: Scope Planning, Scope Definition Document Business Requirements Drive Requirements Review/Approval Drive Resolution of Requirements Issues Scope Change Overall Project Plan Development Overall Project Scope Management Overall Project Time Management Project Cost Management Project Quality Management Project Risk Management Project Procurement Management Project Communications Management Project Human Resource Management Requirements Process Expert Facilitate Requirements Gathering Lead Requirements Analysis Develop Supplementary Documentation Partner with IT to Define Functional & Non- Functional Requirements Compose Business Rules for Rule Execution Manage Business Rules PM (E2)BA (E3) Business Architect (E1) Business Domain Expert (E1) Create Business Policies Create Business Rules Provide and approve Business Architecture Provide and approve Business Requirements Provide and approve User Requirements Approve Functional Requirements Understand Non Functional Requirements Identify Business Policies Identify Business Rules from Policies Develop Business Requirements Manage the recorded Business Architecture Business Architect (E1)

16 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 16 Role Delineation Develop Scope Identify & Engage stakeholders & SMEs Team BA Begin Project Develop Scope Develop Phase Schedule & Budget PM Ideation Team BA Verify Requirements Ensure Product Delivery Analyze Project Results Close Project PM Wrap Up Team BA Identify Business Issues Manage Requirements changes Ensure Budget & Schedule Tolerances Manage WBS, Issues, Project Changes PM Development Team BA Elicit How, What, Why from SMEs Develop Detailed Requirements Create Schedule & Cost Baseline Gain Approval for Scope Statement PM Discovery

17 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 17 Industry Insights Where does the BA role live? –Historically IT –Shifting towards business –Jurys still out Where is the BA role going? –Recognition –Training/Certification What are the future trends? –IIBA as household name –Degreed programs –Indispensable role

18 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 18 BA Processes Source: IIBA BABOK®

19 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 19 Business Analysis- Maturity Levels 5 Optimizing 4 Comprehensive 3 Consistent 3 Consistent 2 In-consistent 2 In-consistent 1 Ad Hoc 1 Ad Hoc Business Architecture models managed well. Focus Is On Continuous Improvement of BA Process/ Tools with Training. Strategic Competitive Advantage gained from reuse of Business Architecture from projects. Business Analyst Role Separation practiced. Senior Management and IT support Business Architecture and uses it themselves. Senior BAs engaged in early Program and Project Management. Consistent use of Documented Business Analysis Processes as selected by project. Requirements traceable to the business. Business Architecture Published on Project basis but not managed for reuse. Process Role Business Analysis approach to projects is based on business, IT, and cultural drivers with some difficulty in deciding. Inconsistent use of documented Business Analysis processes on projects. Business Analysis tools reused across projects. Business Analysis approach is one size fits all. Each project has its own Business Analysis tools. OJT Business Analyst training. Business Analyst Role Separation is recognized with Business Architecture done for all projects with consistent IT & business support Business Analyst Role Separation recognized but not as difference maker Business Architecture initiated occasionally with some business and IT support Business Analysis Approach selection is routine Development staff regularly consumes Business Analysis Artifacts. Development Staff may not always consume Business Analysis Artifacts Artifacts Business Analyst Role Separation not recognized Entrepreneurial/Heroic BA efforts

20 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 20 Business Analyst- Skills Comparison PM (E2)BA (E3)Business Architect (E1) Big Picture Thinker Directs the project team Helps people get things done Conscience of time and $$ Removes issues/barriers Possesses management skills Big Picture Thinker Possesses management skills Communicates well with Business Executives Manage Business Analysis Process Manage Requirements Artifacts Communicates well with SMEs Manages interpersonal relationships well Interprets Business Architecture Details Correctly Communicates well Understands SDLC Manages interpersonal relationships well Negotiates Applies Business Architecture

21 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 21 Business Analyst - Maturity Levels 5 Bus. Architect 4 Structure 2 Guidance Provided 2 Guidance Provided 1 IT waiter/waitress 1 IT waiter/waitress Management Practice Advanced VISIO, WBI Modeler, Enterprise Architect, playbooks as modeling tools. Integrated Requirement management with modeling tools. Pictorial business model first (As is, to be). Static and process pictorial models of the business. Produce textual view of requirements last. ToolsSkills Business Modeling Standardized (UML, IDEV, in VISIO or basic modeling tools). Multiple formats: Use Cases, Stories, SRS. Requirements management tools. Problem first then solution approach. Business or System processes in a business model. Processes and Scenarios identified in the business model. Textual and Pictorial view of requirements. Solution first approach-start with screens. Some business knowledge needed for effective interview. Difficult to know when analysis is done. Textual list of requirements with some process links. Solution first approach-technology priority. Good personal interviewing skills required. Extensive business knowledge for effective interview. Difficult to know when analysis is done. Textual list of requirements, 3 Categorization 3 Categorization Capture Business Requirements, User Requirements, Functional and Non-functional requirements in single standard format Requirements published with tools: Rational products, TFS, Web… Go ask who, what, when, where, why this way….. Suggested Questions and formats Requirements shared in network file system No suggested questions Plan interview, conduct interview, recap interview Requirements stored for personal use

22 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 22 Business Analysis Case Study Case Study: Midsize Service Company Significant Business Drivers affecting the software project: Quick time to market Changing economic conditions affected project funding Subject matter experts and stakeholders in remote locations Significant Cultural Drivers affecting the software project: Departments affected by the software were not mature, nor expected to be mature, in their own processes. This forced IT to own major business processes. Project Management Office was immature and typically produced product owners. IT had traditionally produced software products then shown the business when it was done. IT managed much of the business model especially in operations. Significant IT Drivers affecting the software project: IT was not well versed in the new technologies = coders that dont do design Developers, BAs, and PM were contracted resources Accountability of Developers to PM was limited

23 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 23 Business Analysis Maturity Level- Midsize service company 5 Optimizing 4 Comprehensive 3 Consistent 3 Consistent 2 In-consistent 2 In-consistent 1 Ad Hoc 1 Ad Hoc Process Role Business Analysis approach is one size fits all. Each project has its own Business Analysis tools. OJT Business Analyst training. Development Staff may not consume Business Analysis Artifacts Artifacts Business Analyst Role Separation not recognized Entrepreneurial/Heroic BA efforts

24 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 24 Role Comparison- Midsize service company Project Plan Development (Requirements Phase) Project Plan Execution (Requirements Phase) Project Time Management (Requirements Phase) Apply Business Architecture: Scope Planning, Scope Definition Document Business Requirements Drive Requirements Review/Approval Drive Resolution of Requirements Issues Scope Change Overall Project Plan Development Overall Project Scope Management Overall Project Time Management Project Cost Management Project Quality Management Project Risk Management Project Procurement Management Project Communications Management Project Human Resource Management Requirements Process Expert Facilitate Requirements Gathering Lead Requirements Analysis Develop Supplementary Documentation Partner with IT to Define Functional & Non- Functional Requirements Compose Business Rules for Rule Execution Manage Business Rules PM (E2)BA (E3) Business Architect (E1) Business Domain Expert (E1) Create Business Policies Create Business Rules Provide and approve Business Architecture Provide and approve Business Requirements Provide and approve User Requirements Approve Functional Requirements Understand Non Functional Requirements Identify Business Policies Identify Business Rules from Policies Develop Business Requirements Manage the recorded Business Architecture Business Architect (E1)

25 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS Bus. Architect 4 Structure 2 Guidance Provided 2 Guidance Provided 1 IT waiter/waitress 1 IT waiter/waitress Management Practice ToolsSkills Solution first approach-start with screens. Some business knowledge needed for effective interview. Difficult to know when analysis is done. Textual list of requirements with some process links. Solution first approach-technology priority. Good personal interviewing skills required. Extensive business knowledge for effective interview. Difficult to know when analysis is done. Textual list of requirements, 3 Categorization 3 Categorization Go ask who, what, when, where, why this way….. Suggested Questions and formats Requirements shared in network file system No suggested questions Plan interview, conduct interview, recap interview Requirements stored for personal use Business Analyst Maturity Levels- midsize service company

26 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 26 Skills Comparison- Midsize service company PM (E2)BA (E3)Business Architect (E1) Big Picture Thinker Directs the project team Helps people get things done Conscience of time and $$ Removes issues/barriers Possesses management skills Big Picture Thinker Possesses management skills Communicates well with Business Executives Manage Business Analysis Process Manage Requirements Artifacts Communicates well with SMEs Manages interpersonal relationships well Interprets Business Architecture Details Correctly Communicates well Understands SDLC Manages interpersonal relationships well Negotiates Applies Business Architecture

27 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 27 Business Analysis Processes & Tools Business Architecture to support Project, Program and Portfolio Management Business Analyst Knowledge, Application (Usage) Execution of Business Analysis output in software development Business Analysis Maturity Level Assessment Business Analyst Maturity Level Assessment Business Analysis Improvement Roadmap So what should I do to improve at business analysis? Typical Business Analysis Assessment Context

28 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 28 Business Analysis Assessment Scope Project Management Office Project Program Portfolio People- BA roles ProcessTools Analysis Development le Testing E1 E2 E3 Essential Model Domain X X X X X X X X X X X X X X X X X X Business and System Analysis – the organizational glue of software development

29 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 29 Basic Improvement Roadmap- People Recognize and Value Business Analyst role separation to gain project efficiencies 1.BA function is not a stepping stone to PM nor Business Architect roles 2.Projects need all three roles for success 3.Each position requires different abilities 4.Dont wait for role delineation; be a catalyst for change 5.IF in the multiple role, create safeguards to reduce project risk 6.Business Analysis, Business Architecture, and Project Management are Essential!

30 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 30 Basic Improvement Roadmap- Process Business Model updates Objectives Requirements traceable to Business and consumable by technical developers Bug fixes Business Model Strategy Communication Products Business Architecture Requirements Development Process based on SDLC chosen for project Project Management Execution Business Analysis Process PM Focus Build/Test DesignInstallRequirements Product Lifecycle Business Analyst Focus Formalize the set of sustainable Requirement Development processes, by SDLC, based on business, IT and Cultural drivers. Train BAs and PMs on the multiple processes chosen. Avoid producing Requirement Artifacts that are not used by Developers by monitoring on a project level basis.

31 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 31 Basic Improvement Roadmap –Tools Business Architecture –Identify the tools that match the level of reusable business architecture that can be used to describe the business based on business, IT, and cultural drivers. These drivers should also be identified and prioritized for greatest impact. Requirements Development –Identify the common set of requirement development tools that match the level of detail required on a project by project basis. –All tools should enable requirements that are traceable to the business and consumable by the IT staff.

32 . MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 32 Questions & Discussion Morris Oslin


Download ppt ". MORE THAN CONSULTANTS. WERE ESSENTIALISTS. 1 1 Improving Business Analysis and Requirements Engineering. Presented by: Morris Oslin, Trissential, LLC."

Similar presentations


Ads by Google