Business Analysis Case Study: Adding Business Value using Agile

Download Business Analysis Case Study: Adding Business Value using Agile

Post on 10-Feb-2017

216 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

<p>Business Analysis Case Study: Adding Business Value using Agile within Waterfall</p> <p>16th March - IIBA Event - BaselBusiness Analysis Case Study: Adding Business Value using Agile within Waterfall</p> <p>2IntroductionAbout meBrian Hill - CBAP</p> <p>Freelance contracting in projects (IT and Process) for 10+ years</p> <p>Committed to professional development</p> <p>Strong sense of ownership </p> <p>Focused on delivering value to the business and meeting stakeholder expectations</p> <p>2</p> <p>3IntroductionObjectivesTo demonstrate the value a Business Analyst can bring to Project delivery and to the Business, focusing on a case Study incorporating Agile within WaterfallExpected outcomeIncreased understanding of the Business Analyst role</p> <p>Demonstrated application of the BABOK framework</p> <p>Demonstrated Agile thinking and practices - even within a Waterfall project</p> <p>Clarity on how a Business Analyst can add Business Value</p> <p>3</p> <p>4Initial assessment on joining the projectBusiness NeedTo provide a major update to an in-house, User Service Self Service portalOrganisational Process Assets</p> <p>Enterprise Architecture</p> <p>Expert JudgementProject Management to align with Internal company specific project methodology (~ PMBOK)</p> <p>Mandated use of Requirement Management (RMS) and Document Management systems (DMS)</p> <p>Two development teams and two systems, geographically dispersed, mix of CSV/ Agile</p> <p>First release with a Business Analyst (BA) - therefore a challenge to demonstrate BA value </p> <p>Fixed project duration and go-live date, fixed budget scope fluid at start of projectThe challengeAs a business analyst, determining:Is my role to simply document requirements OR is my role TO be a leader and deliver real business valueAs a projectAvoid conflict and simply overpromise and under-deliver ORPractice Agility to deliver optimal value within complex set of constraints</p> <p>4</p> <p>5Checkpoint SynopsisInternal PM methodology mandates waterfall approach</p> <p>Waterfall approach requires scope/ time/ budget fixed</p> <p>CSV mandates fixed scope &amp; baselined documentation, </p> <p>Agile methods are light on documentation, requirements change, scope variable </p> <p>Pure Agile would spectacularly fail CSV and internal PM methodology complianceKey FindingsFull Development and Test Team Resources active for duration of the Project</p> <p>Business Value related to maximising value from these teams</p> <p>Business Stakeholders present an initial set of requirements which constitute scope</p> <p>Requirements incomplete, associated effort and prioritisation unknown</p> <p>Ability to meet stakeholder needs uncertain</p> <p>Project Plan including Phase duration not yet defined</p> <p>5</p> <p>Business Analysis Planning and Monitoring (BAPM) - BABOK v26</p> <p>Plan Business Analysis ApproachRapidly perform iterative analysis of the requirements and group by moduleEstablish priority and associated project resource effortsCompare to project resource capacity enabling scope settingStakeholder Analysis</p> <p>Plan BA Activities</p> <p>Plan BA Communications</p> <p>Plan Requirements Management Process</p> <p>Manage BA PerformanceAs a first step, identify stakeholders and start to determine all constraints (location/hours)</p> <p>Schedule daily workshops with the SME and Development Team Resources, Plan mandatory trainings (internal compliance for BA), gain system access and authorisation rights</p> <p>Schedule daily Stand-Up meetings, schedule weekly team meetings</p> <p>Use of RMS and DMS mandated for baseline/ signed off documents. Use of collaborative tools 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</p> <p>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</p> <p>7Business Analysis Planning and Monitoring (BAPM) tasks</p> <p>7</p> <p>8Checkpoint SynopsisScope creep from day 1: </p> <p>Need to educate stakeholders and manage expectations</p> <p>Conflicts between stakeholders and availability issues </p> <p>Caution/ inexperience toward BA role</p> <p>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</p> <p>Immediate PrioritiesWork 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</p> <p>Keep track on original requirements, and those that are snuck in</p> <p>Review ALL requirements, start prioritising and getting assessments from SME, dev team 1, dev team 2, testers: assessing effort and system interdependencies requiring change</p> <p>Developing my own system context and expertise while demonstrating the role, and value of the BA role, to the project stakeholders</p> <p>8</p> <p>9Elicitation</p> <p>9</p> <p>10ElicitationMore than just documenting requirementsA popular misconception is that Business Analysts simply document requirements.</p> <p>This section from BABOK clearly differentiates how documenting (requirementelicitation results is just one part of the Elicitation process, which is part of the larger Business AnalysisPrepare for Elicitation</p> <p> Conduct Elicitation Activity</p> <p>Document Elicitation Results</p> <p>Confirm Elicitation ResultsUsing 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</p> <p>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)</p> <p>Online collaboration tools were used to document the elicitation results, including targeted feedback and clarification in addition to a standalone open actions google sheet. This mitigated the risk of the Business Analyst and SME availability (timezones) hindering progress - and allowed for rapid iterations to finalise individual requirement definitions</p> <p>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</p> <p>10</p> <p>11Checkpoint SynopsisBAPM highlights that scope needs to be set asap</p> <p>ALL requirements need to be estimated and prioritised</p> <p>Defining in Waterfall approach will erode Business Value</p> <p>SolutionImplement daily calls and workshops with key stakeholders via hangouts</p> <p>Morning Stand-Up: 15 minutes focusing on key actions, blockers, and to build team identity. </p> <p>Utilise google documents to collaborate during definition</p> <p>During the workshop, requirements are reviewed for completeness and actions to be assessable</p> <p>Requirement prioritised (1-10 not high/ medium/low)</p> <p>First estimates from devs/ test of effort for design/ build phase provided</p> <p>Interdependencies identified</p> <p>11</p> <p>12Requirements Management and Communication</p> <p>12</p> <p>13Requirements Management and CommunicationThe Waterfall v Agile DilemmaIn 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 Soln ScopeAnd Requirements Manage Requirements Traceability</p> <p>Maintain Requirements for re-use</p> <p>Prepare Requirements Package</p> <p>Communicate RequirementsReview/ estimate/ prioritise used to help business make a scope setting decisionRequirements being elicited, validated and verified prior to baselining in RMS</p> <p>Within RMS, requirements will be traced to other (dependencies), User Requirements, Design Specifications and Test Cases</p> <p>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 made by referring to the overall baselined requirements (operational, not just release)</p> <p>Determine the best way to communicate a set of baselined requirements.Internal Project Methodology mandates published extract of the release plus new overall requirement baseline to exit Define Phase</p> <p>More formal for Sponsors, PM - SME, Dev, Test all actively engaged in elicitation/ validation/ verification process</p> <p>13</p> <p>14Checkpoint SynopsisTools working well and all teams engaged and aligned</p> <p>SMEs integrated and active</p> <p>PM working on PMM deliverables and aligned with BA approach</p> <p>Daily Stand-Ups working well robust dialogue, everyone aware of priorities</p> <p>Prioritisation and estimation taking place plus scope creep addressed</p> <p>Critical requirements verified and Design effort for these being reduced by development teams</p> <p>Immediate PrioritiesManage scope by performing capacity based planning</p> <p>Make any excess demand over budgeted capacity a business problem they choose the scope we can accept</p> <p>High level estimates and prioritisation of requirements after first iteration of reviews provides assessment that demand exceeds capacity substantially</p> <p>14</p> <p>Delivering Optimal Scope by being Agile within Waterfall15</p> <p>Optimised Build Phase duration is critical to maximising scope</p> <p>Define Phase agility reducing design phase duration and increasing build phase - maximising build scope</p> <p>Manage scope by performing capacity based planning</p> <p>Business Value from Build Scope maximised by the prioritisation and estimation technique</p> <p>Operating in pure waterfall would deliver a very small set of scope within time/budget</p> <p>16Exiting Define Phase Project phases, capacity, in-scope requirements signed off:Final requirements being validated and verified</p> <p>Design work progressing well on defined requirements - effort to Design reducing</p> <p>Dev Teams and Test teams demonstrate robust common understanding</p> <p>Less and less problems to resolve now - we are a well oiled machine</p> <p>Requirement documentation and traceability become focus</p> <p>Build sense of team, maintain momentum, and coordinate team efforts for the upcoming transition into Build PhaseSolutionPrepare Requirements Package and formally baseline Requirements</p> <p>Exit Define phase</p> <p>Schedule a face to face workshop at end of Design Phase</p> <p>16</p> <p>17Design Phase Face to face workshop: Meet and greet, Design document sign-offs, bombshells and a planning lesson:Conducted 3 day workshop, bringing most key stakeholders into a single room for first time</p> <p>Expedited design documentation sign off</p> <p>Agreed dev Team for non CSV will go Agile for Build Phase</p> <p>Agreed Second dev team to work waterfall in Build Phase</p> <p>Lead Architect from Dev Team A announced he is leaving the company imminently</p> <p>Agreed development sequence between the two teams in the build phaseDefault sequence proposed by teams not optimalOutputsA common approach for Build Phase moving forward</p> <p>Documentation sign off complete - into Build Phase</p> <p>Progress measured via Burndown Chart (remaining effort) &amp; sprint based working product</p> <p>17</p> <p>Build Phase Synopsis:Maintain daily stand-ups</p> <p>Working Product Showcased at end of each sprint</p> <p>Stakeholder confidence skyrocketed</p> <p>Track progress via Burndown chart - small deviations but tracked closely to plan</p> <p>Assisted Dev and Test teams with traceability</p> <p>Maintained requirements for re-use: Minor adjustments to non CSV system result in an edit to project requirements baseline</p> <p>Managed solution scope and stakeholder expectations: Raised change requests for future releases as needs identified which were not in scope</p> <p>Identified use of new functionality in discussion with SMEs </p> <p>Assisted OCM and Test preparations</p> <p>Exited the Phase on time - but very tight schedule</p> <p>18</p> <p>18</p> <p>Agile thinking - using a Burndown chart to measure Demand, Capacity and progress during build phase. 19</p> <p>Test Phase Synopsis:Extremely nerve wracking Test Phase - lack of defects: High quality or bad testing?</p> <p>Provided assistance to Test Team and SME in test preparations, incl peer reviews</p> <p>Test Phases executed with unprecedented lack of defects</p> <p>Final week of Test Phase used to wrap up project in a pressure free environment</p> <p>Stakeholders extremely pleased with delivered scope functionality and quality</p> <p>Project Deployed on time</p> <p>20</p> <p>20</p> <p>Wrap up and Review Section21</p> <p>BABOK technique review22</p> <p>Business Analysis Planning &amp; Monitoring</p> <p>Requirements Analysis</p> <p>Elicitation</p> <p> Enterprise Analysis</p> <p>Solution Assessment and Validation</p> <p>Requirements Management and Communication</p> <p>Underlying CompetenciesCommenced by assessing the Stakeholders, Roles, Deliverables, created Business Analysis Plan and Performance monitoring, daily calls/ virtual workshops scheduled</p> <p>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</p> <p>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</p> <p>Defined Business Need in first iteration of requirement review and prioritisation</p> <p>Conducted Org Readiness/ Defined Transition Requirements and triggered actions which led to increase value realisation/ business benefit via training/ comms/ catalogue configuration</p> <p>Used RMS for 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 for formal document sign-offs, daily stand-up and weekly team calls</p> <p>Used Prototyping, Mockups, Workshopping, Interviews, Systems Analysis, Document Analysis, Problem Solving, Negotiating, Influencing, Conflict Management and multitude of other competencies as Business Analyst in this very challenging project </p> <p>23Case study: Business Analysis review in BABOK v2 framework</p> <p>23</p> <p>Cherry Picking of the Agile methodologyLike browsing a buffet, we cherry picked applicable aspects of Agile methodologiesWhat we appliedWe estimated and then prioritised requirements from the vast initial list</p> <p>Business chose a capacity constrained bundle of scope in the project long sprint</p> <p>We let teams self organised, but we did need to review, challenge and modify the draft pla...</p>

Recommended

View more >