BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting

1. BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting Apr 7, 2011 (Originally Jan 27) 00-2011 BA Team Roles: A BA is not a BA is not a BA…

2. BA – What is Business Analysis anyway? "the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.” -International Institute of Business Analysis (IIBA)

3. A BA is not a BA is not a BA… The BA Team has been faced with a broad set of expectations (consistent actually with IIBA’s definition), expanding the job requirements beyond a traditional “Business Analysis” role as defined in other companies. This is largely a result of ongoing lessons-learned on previous projects and a goal of continuous improvement as a service-provision organization. We want to repeat those approaches that differentiate EIM, and add value to our clients. However, it is critical to realize that such a broad spectrum of expectations is met with not a single job role but multiple roles. Core Competency Skills Areas for which a BA team may need to provide support: (Most of us have strength in 1 particular area) • Traditional Business Analysis Skills • Technical or Systems Analysis Skills • Interface Design/Web Design/Usability Architecture Skills • Consultative, Product Ownership/Leadership Skills

4. BA Practice “We all fit somewhere, and no-one fits everywhere…” GUI Designer Systems Analyst Traditional Requirements Analyst Product Owner/Solution Designer

5. Traditional BA: Requirements Analyst A traditional Business Analyst focuses on asking discerning questions, and thoroughly documenting specifications, business processes, and detailed requirements. This is a critical, foundational element for any and all projects. (I’ve included items here that also could be associated to a Business Process Engineer as well) • Collect and Document Functional Requirements Specifications and a sub-set of Non-Functional Requirements (per previous training: may be formatted as User Stories with Acceptance Criteria as opposed to traditional syntax, but the content is the same with the benefit of added context.) • Generate Use Cases where applicable, Requirements Traceability Matrices, and acceptance criteria • Generate Process-Centric Flow Diagrams such as BPMN or UML diagrams, rough mocks, or other visual enhancements • Organize and Run SME input sessions to collect requirements • Enter/Organize requirements in RTC or similar system • Possibly generate user documentation, training materials, or help test against use cases Traditional Business Analysis Skills Technical or Systems Analysis Skills Interface Design/Web Design/Usability Architecture Skills Consultative, Product Ownership/Leadership Skills

6. Technical BA: Systems Analyst A Technical or Systems Analyst focuses on defining and documenting the technical specifications and implementation details that will ultimately support what the user needs, from a system-side rather than user-side perspective. (Currently at EIM, these hires have fallen under Architecture, not BA) Traditional Business Analysis Skills Technical or Systems Analysis Skills Interface Design/Web Design/Usability Architecture Skills Consultative, Product Ownership/Leadership Skills • Collect and Document technical/system level requirements (implies BA with technical experience) • Collect and document Interface Control Details/Web Service Details in conjunction with architecture (includes additional items such as data mapping, manifest definitions, data dictionary management) • Possibly collect and document details for a sub-set of technical non-functional requirements specifications for things such as solution monitoring, reliability, security, integrity, etc. • Generate a technical version of a Solution Design (the technical response to the SDD at EIM)

7. GUI Designer: Interface Design and Graphics An Interface Designer or Usability Architect focuses on the user experience, owning the process of transforming functional requirements and high-level system design into an interface that makes sense and presents professionally. Traditional Business Analysis Skills Technical or Systems Analysis Skills Interface Design/Web Design/Usability Architecture Skills Consultative, Product Ownership/Leadership Skills • Generate Site-Maps and GUI Organizational Charts, or works with Product Owner/Other BA to jointly accomplish this • Generate GUI Specifications and mocks that support the SDD • Organize user feedback sessions to review / gather iterative feedback on GUI mocks • Manage iterative GUI design cycles • Incorporate branding, color schemes, style guides and 508 compliance considerations Note: We now have a team of 2 who do this! Roman Chanclor and Amanda Collodel, reducing the burden on other BA types 

8. Product Owner / Solution Designer A Product Owner or Product Owner Proxy is a consultative role, requiring an analyst to feel comfortable with an increased amount of responsibility for the overall solution, ensuring that the client, the user, the market, the business goals, budgets, ROI, etc. are all considered in a solution design, and in the implementation rollout. This is a thought-leadership role that carries significant accountability for what’s built. Traditional Business Analysis Skills Technical or Systems Analysis Skills Interface Design/Web Design/Usability Architecture Skills Consultative, Product Ownership/Leadership Skills • Act as Product Owner (Customer Proxy), and have the ability to lead the efforts to define of the solution • Prioritize requirements into meaningful groupings to ensure that each release provides value (road-mapping a product to manage delivery of value) • Generate Solution Description Document/Diagram, vet out technical viability with the tech lead, and help guide UI team to get the right GUI elements • Handle client interactions and assist the PM in scope discussions in highly professional manner • Display assertiveness and discernment in keeping development on course (re: requirements interpretation) to meet the needs of the client in the most efficient manner

9. Training & Documentation And as a brief aside, we should address a couple other areas that were listed as a bullet under the traditional Business Analyst job description. Although BAs often are asked to support documentation and training needs (and we can all do these at a basic level of competency in a pinch), these are areas that truly are unique disciplines, and could be supported by people with specific skill-sets, thus improving the quality of deliverables... Training Technical Writing • Generating Training Plans • Writing Curriculum • Delivering Classroom Sessions • Generating Online Courses • Generating Training Manuals/Materials • User Manuals • Quick Reference Guides • Help Files • Editing of all Deliverables Note: We now have 1 technical writer, KimberGlorioso, and have hired a Training-Centric BA (Andrea Ayala) who starts April 25!

10. Summary In order to “Recommend solutionsthat enable the organization to achieve its goals” per the IIBA, there are many puzzle pieces that must be defined and come together. At EIM, we want to present solutions, beginning to end, with as much integrity, clarity, completeness, and efficiency as our customer’s deserve, in a manner that differentiates us from the competition. Each of us brings our own piece(s) to the puzzle. So, as a BA practice: • We begin with an up-front, high-level solution description, and visual depiction of the proposed solution, which draws nice boundaries against which requirements can be decomposed and scope managed from day 1 (Traditional Analyst, Product Owner SDD & GUI Designer) • We will continue to provide solid requirements gathering/definition for all projects, and in most cases (if not all) there will still be a set of traditional deliverables such as an SRS, traceability matrix, use cases to support testing, etc. (“traditional” BA/Requirements Analyst) • We stay with the project and help support a smarter “priorized” tackling of our requirements to deliver value incrementally instead of only at the end (Product Owner) • We have a goal of providing an up-front technical response to the SDD and clarity in technical specifications (Technical Analysis) • We will continue to also provide professional documentation and training where applicable (Trainers or Training BAs, Tech Writers, and Graphics)