Business Analysis Case Study Adding Business Value using

Business Analysis Case Study: Adding Business Value using Agile within Waterfall 16 th March - IIBA Event - Basel

Introduction About me Brian Hill - CBAP “Freelance” contracting in projects (IT and Process) for 10+ years Committed to professional development Strong sense of ownership Focused on delivering value to the business and meeting stakeholder expectations 2

Introduction Objectives To demonstrate the value a Business Analyst can bring to Project delivery and to the Business, focusing on a case Study incorporating “Agile within Waterfall” Expected outcome Increased understanding of the Business Analyst role Demonstrated application of the BABOK framework Demonstrated Agile thinking and practices - even within a Waterfall project Clarity on how a Business Analyst can add Business Value 3

Initial assessment on joining the project Business Need To provide a major update to an in-house, User Service Self Service portal Organisational Process Assets Project Management to align with Internal company specific project methodology (~ PMBOK) Enterprise Architecture Mandated use of Requirement Management (RMS) and Document Management systems (DMS) Two development teams and two systems, geographically dispersed, mix of CSV/ Agile First release with a Business Analyst (BA) - therefore a challenge to demonstrate BA value Expert Judgement The challenge Fixed project duration and go-live date, fixed budget – scope “fluid” at start of project ● ● As a business analyst, determining: ○ Is my role to simply document requirements OR ○ is my role TO be a leader and deliver real business value As a project ○ Avoid conflict and simply overpromise and under-deliver OR ○ Practice Agility to deliver optimal value within complex set of constraints 4

Checkpoint Synopsis Internal PM methodology mandates waterfall approach Waterfall approach requires scope/ time/ budget fixed CSV mandates fixed scope & baselined documentation, Agile methods are light on documentation, requirements change, scope variable Pure Agile would spectacularly fail CSV and internal PM methodology compliance Key Findings Full Development and Test Team Resources active for duration of the Project Business Value related to maximising value from these teams Business Stakeholders present an initial set of “requirements” which constitute scope Requirements incomplete, associated effort and prioritisation unknown Ability to meet stakeholder needs uncertain Project Plan including Phase duration not yet defined 5

Business Analysis Planning and Monitoring (BAPM) - BABOK v 2 6

Business Analysis Planning and Monitoring (BAPM) tasks Plan Business Analysis Approach Rapidly perform iterative analysis of the requirements and group by module Establish priority and associated project resource efforts Compare to project resource capacity enabling scope setting Stakeholder Analysis As a first step, identify stakeholders and start to determine all constraints (location/hours) Plan BA Activities Schedule daily workshops with the SME and Development Team Resources, Plan mandatory trainings (internal compliance for BA), gain system access and authorisation rights Plan BA Communications Schedule daily Stand-Up meetings, schedule weekly team meetings Use of RMS and DMS mandated for baseline/ signed off documents. Use of collaborative tools Plan Requirements Management Process such as Google Docs, Google Sheets for the elicitation aspect of requirement definition. Common set of criteria agreed to assess, categorise and group the requirements Manage BA Performance Creation of a tracking sheet that measures the planned activity for BA (and others) on requirements assessment - this also enabled ability to track original requirements plus uncontrolled scope creep 7

Checkpoint Synopsis Scope creep from day 1: Need to educate stakeholders and manage expectations Conflicts between stakeholders and availability issues Caution/ inexperience toward BA role SME in Americas time-zone, one development team in Poland billing from day 1 on fixed budget with no work to execute, scope not set Immediate Priorities Work with PM to start planning – achievable scope and associated effort not yet known, but capacity and phases within waterfall mandated methodology will shape our approach Keep track on original requirements, and those that are snuck in Review ALL requirements, start prioritising and getting assessments from SME, dev team 1, dev team 2, testers: assessing effort and system interdependencies requiring change Developing my own system context and expertise while demonstrating the role, and value of the BA role, to the project stakeholders 8

Elicitation 9

Elicitation More than just documenting requirements A popular misconception is that Business Analysts simply document requirements. This section from BABOK clearly differentiates how documenting (requirement”elicitation results is just one part of the Elicitation process, which is part of the larger Business Analysis Prepare for Elicitation Using stakeholder analysis, Organisational Process Assets (tools for virtual meetings, online document collaboration tools), I set up intensive schedule of requirement elicitation sessions - a mix of document analysis, interviews, daily workshops with SME/ Usability Expert and other key stakeholders - with a set agenda for each session planned and circulated in advance Conduct Elicitation Activity Each session handled differently, but working under time pressures the decision to use collaboration tools proved valuable, as updates were flowing in real time and overnight between sessions (especially usability expert developing mockups and inserting to elicitation documents) Online collaboration tools were used to document the elicitation results, including targeted Document Elicitation feedback and clarification in addition to a standalone open actions google sheet. This mitigated Results the risk of the Business Analyst and SME availability (timezones) hindering progress - and allowed for rapid iterations to finalise individual requirement definitions Confirm Elicitation Results Due to the documentation technique and daily stand-ups, requirement elicitation could be rapidly confirmed, communicated to all stakeholders, and the baselined requirement stored in the RMS as record of truth, triggering individual requirement Design pre-work in parallel to the ongoing elicitation of other requirements 10

Checkpoint Synopsis BAPM highlights that scope needs to be set asap ALL requirements need to be estimated and prioritised Defining in Waterfall approach will erode Business Value Solution Implement daily calls and workshops with key stakeholders via hangouts Morning Stand-Up: 15 minutes focusing on key actions, blockers, and to build team identity. Utilise google documents to collaborate during definition During the workshop, requirements are reviewed for completeness and actions to be assessable Requirement prioritised (1 -10 not high/ medium/low) First estimates from devs/ test of effort for design/ build phase provided Interdependencies identified 11

Requirements Management and Communication 12

Requirements Management and Communication The Waterfall v Agile Dilemma In Waterfall, Scope and Requirements must be Baselined by end of Definition. In Agile, fixing scope and requirements is not very agile. In Validated environments, requirements live forever, projects do not. Manage Sol’n Scope And Requirements Review/ estimate/ prioritise used to help business make a scope setting decision Requirements being elicited, validated and verified prior to “baselining” in RMS Manage Requirements Within RMS, requirements will be traced to other (dependencies), User Requirements, Design Specifications and Test Cases Traceability Maintain Requirements live forever, therefore essential to manage traceability and link to change requests and previous versions of the requirements. Defects or enhancements decision can be for re-use made by referring to the overall baselined requirements (operational, not just release) Prepare Requirements Determine the best way to communicate a set of baselined requirements. Internal Project Methodology mandates published extract of the release plus new overall Package requirement baseline to exit Define Phase Communicate Requirements More formal for Sponsors, PM - SME, Dev, Test all actively engaged in elicitation/ validation/ verification process 13

Checkpoint Synopsis Tools working well and all teams engaged and aligned SME’s integrated and active PM working on PMM deliverables and aligned with BA approach Daily Stand-Ups working well – robust dialogue, everyone aware of priorities Prioritisation and estimation taking place – plus scope creep addressed Critical requirements verified and Design effort for these being reduced by development teams Immediate Priorities Manage scope by performing capacity based planning Make any excess demand over budgeted capacity a business problem – they choose the scope we can accept High level estimates and prioritisation of requirements after first iteration of reviews provides assessment that “demand” exceeds capacity substantially 14

Delivering Optimal Scope by being “Agile” within Waterfall Optimised Build Phase duration is critical to maximising scope Define Phase agility reducing design phase duration and increasing build phase - maximising build scope Manage scope by performing capacity based planning Business Value from Build Scope maximised by the prioritisation and estimation technique Operating in pure waterfall would deliver a very small set of scope within time/budget 15

Exiting Define Phase Project phases, capacity, in-scope requirements signed off: Final requirements being validated and verified Design work progressing well on defined requirements - effort to Design reducing Dev Teams and Test teams demonstrate robust common understanding Less and less problems to resolve now - we are a well oiled machine Requirement documentation and traceability become focus Build sense of team, maintain momentum, and coordinate team efforts for the upcoming transition into Build Phase Solution Prepare “Requirements Package” and formally baseline Requirements Exit Define phase Schedule a face to face workshop at end of Design Phase 16

Design Phase Face to face workshop: Conducted 3 day workshop, bringing most key stakeholders into a single room for first time Meet and greet, Design Expedited design documentation sign off document sign-offs, bombshells and a Agreed dev Team for non CSV will go Agile for Build Phase planning lesson: Agreed Second dev team to work waterfall in Build Phase Lead Architect from Dev Team A announced he is leaving the company imminently Agreed development sequence between the two teams in the build phase ● Default sequence proposed by teams not optimal Outputs A common approach for Build Phase moving forward Documentation sign off complete - into Build Phase Progress measured via Burndown Chart (remaining effort) & “sprint based” working product 17

Build Phase Synopsis: Maintain daily stand-ups Working Product Showcased at end of each sprint Stakeholder confidence skyrocketed Track progress via Burndown chart - small deviations but tracked closely to plan Assisted Dev and Test teams with traceability Maintained requirements for re-use: Minor adjustments to non CSV system result in an edit to project requirements baseline Managed solution scope and stakeholder expectations: ● Raised change requests for future releases as needs identified which were not in scope Identified use of new functionality in discussion with SME’s Assisted OCM and Test preparations Exited the Phase on time - but very tight schedule 18

Agile thinking - using a Burndown chart to measure Demand, Capacity and progress during build phase. 19

Test Phase Synopsis: Extremely nerve wracking Test Phase - lack of defects: High quality or bad testing? Provided assistance to Test Team and SME in test preparations, incl peer reviews Test Phases executed with unprecedented lack of defects Final week of Test Phase used to wrap up project in a pressure free environment Stakeholders extremely pleased with delivered scope functionality and quality Project Deployed on time 20

Wrap up and Review Section 21

BABOK technique review 22

Case study: Business Analysis review in BABOK v 2 framework Business Analysis Planning & Monitoring Commenced by assessing the Stakeholders, Roles, Deliverables, created Business Analysis Plan and Performance monitoring, daily calls/ virtual workshops scheduled Requirements Analysis Performed requirements analysis on initial prioritisation, extending into elicitation in subsequent iterations - working to define/ verify and validate the requirements and allow dev/ test teams to estimate the aggregate resource demand associated with all requirements Elicitation Scheduled/prepared for requirement elicitation sessions, conducted elicitation sessions using Google Hangouts for remote interviews/ workshops, documented in G-docs and confirmed by peer review before qualifying for design activities by development teams Enterprise Analysis Defined Business Need in first iteration of requirement review and prioritisation Solution Assessment and Validation Conducted Org Readiness/ Defined Transition Requirements and triggered actions which led to increase value realisation/ business benefit via training/ comms/ catalogue configuration Requirements Management and Communication Used RMS formal scope and requirement packaging/ traceability/ testing/ release allocation, G-Documents to communicate/ collaborate on requirements in definition/elicitation process, G-Sheets for scope setting/ project burndown, DMS formal document sign-offs, daily stand-up and weekly team calls Underlying Competencies Used Prototyping, Mockups, Workshopping, Interviews, Systems Analysis, Document Analysis, Problem Solving, Negotiating, Influencing, Conflict Management and multitude of 23 other competencies as Business Analyst in this very challenging project

The Agile bits we cherry picked Cherry Picking of the Agile methodology Like browsing a buffet, we cherry picked applicable aspects of Agile methodologies What we applied We estimated and then prioritised requirements from the vast initial list Business chose a capacity constrained bundle of scope in the “project long sprint” We let teams self organised, but we did need to review, challenge and modify the draft plans We used the burndown concept in conjunction to track progress once scope defined We had “virtual standups” to ensure “face to face” conversations and team motivation We showed business stakeholders working product during the build phase Demonstrated real progress and built stakeholder satisfaction We kept the team motivated and engaged - sense of team from daily standup and weekly TC Most important: We communicated, did peer reviews, and avoided silo’s: Despite time and location issues 24

Agile Manifesto The parts we could not use Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. The best architectures, requirements, and designs emerge from self-organizing teams. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The parts we could use Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Simplicity--the art of maximizing the amount of work not done--is essential. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts 25 its behavior accordingly.

Waterfall Principles Waterfall mandated Waterfall delivery was mandated due to CSV and internal Project Management methodology. Waterfall Phases and deliverables to exit the Phase Project Initiation: Project Charter, Roles and Responsibilities (PM Deliverables) Define Phase: Baselined User Requirement Specifications (URS). Baselined Functional Specifications, Baselined Scope *** All essentially BA Deliverables Design Phase: Draft Design Specifications, Draft Test Plan (Dev and Test Deliverables) Build Phase: Baselined Design Specifications, Unit Test (complete), Test Plan (signed off), Traceability Matrix (baselined) Test Phase: Test Report , Deployment Plan Project Value Proposition Following Waterfall method was a constraint we had to operate within, which without Agility would have potentially involved high expectations while delivering very little business value Identifying this constraint early, and being Agile (in thinking and approach) allowed the project to deliver maximum scope and value while navigating the Waterfall gateways. The Project Manager deserves immense credit for managing the documentation and gateways that allowed the project to be Agile within Waterfall, yet fully compliant and to first 26 manage business expectations, and then exceed these expectations

Adding Value through Business Analysis activities Set the vision and planned activities to maximise build phase Influenced Sponsors to focus on their highest priority requirements/ quick wins Resolved conflicts between stakeholders Managed and influenced business and project team stakeholder expectation Overcame time/ distance issues Collaborated with Operational staff to increase organisational readiness Business Analysis Value Proposition Maximised build phase - each week saved represented 10% of eventual scope! Deliver those scope items that offer maximum Business benefit SME interactions discovered unexpected, but significant business benefits 27

Business Analyst as Project Team enabler Business Analyst uniquely placed to lead via Pivotal Role by setting the vision others must follow Project Manager support of approach made the implementation of Business Analyst approach possible Tools and techniques used required buy-in and acceptance from project team “Designing” during define phase required Development team agility Thinking Agile only works if team adopts agile thinking Peer review concept required teams to break down silo mentality Business Analysis role BA set out the approach and fine-tuned it with feedback in bringing the team The approach delivered quick wins and benefits together As the Project progressed, team kept doing what worked and optimised via feedback 28

Summary Initial Challenge As a project, chose to: ● Practice Agility As a Business Analyst, chose to: ● Be a leader and set the vision Project outcome As a team, we delivered “a text book” project, despite overwhelming challenges We delivered full agreed scope, maximum benefit, on time, and with exceptional quality A happy and engaged set of sponsors, business stakeholders and project team members Personal outcomes A lot of satisfaction and enhanced profile within the client company Many of the tools and techniques utilised have been a template for future engagements especially around virtual teams Demonstrated the value of a Business Analyst to the organisation - stakeholders better informed for hiring and collaborating with BA’s in the future 29

Final Notes Documenting Requirements is a small part of the Business Analyst’s role - and does not reflect the value add activities a BA can bring to the Project and Organisation It is simply one of the many tasks that a Business Analyst may perform. Our role is to deliver Business Value What distinguishes BA’s as a critical project resource is that we are a : ● Pivotal role bridging ○ Operations and Project Team ○ Business and Technical Stakeholders ● Pivotal role in ensuring ○ Business Need is defined designed, built and deployed ○ Business Value is optimised through scope management Delivering Value to the Business offers career benefits for the individual BA, and BA’s collectively 30