For Business AnalystsErlet Shaqewww.erletshaqe.com

Business Analyst TrainingMy agendaTo explain the role of the business analyst, To discuss the methodology described in the BABOKTo discuss practical tips and techniques for doing the job well To review sample requirements specifications to get an appreciation of what goes into themTo provide a list of further resources analysts can call upon for helpYour agenda

The Business Analyst Context > Role > SkillsContextProjects and SDLCWhy projects go wrong Project team roles

8.15-9.45

What BAs doRequirements ManagementBusiness ProcessesHuman change managementProject Portfolio Planning

10.00-11.00Practical skillsTechnical skillsAnalysis exerciseQuestions and discussion

11.15-12.15breakbreak

ReleaseTestCloseBuildDesignRequirementsPMI Project Management ProcessWaterfall DevelopmentProjects and the SDLCInitiate

ReleaseTestCloseBuildDesignRequirementsProduct ScopePMI Project Management ProcessWaterfall DevelopmentProjects and the SDLCInitiateReleaseTestBuildDesignRequirements

Product ScopeProjects and the SDLCReleaseTestInitiateCloseBuildDesignRequirementsPMI Project Management ProcessWaterfall DevelopmentSCRUMPRINCE2SIX SigmaAgileRADRationalEtc.Etc.

Product ScopeProjects and the SDLCReleaseTestInitiateCloseBuildDesignRequirementsPMI Project Management ProcessWaterfall DevelopmentSCRUMPRINCE2SIX SigmaAgileRADRationalEtc.Etc.

ReleaseTestInitiateCloseBuildDesignRequirementsProduct ScopePMI Project Management ProcessWaterfall DevelopmentSCRUMPRINCE2SIX SigmaAgileRADRationalEtc.Etc.Projects and the SDLC

ReleaseTestInitiateCloseBuildDesignRequirementsProduct ScopePMI Project Management ProcessWaterfall DevelopmentSCRUMPRINCE2SIX SigmaAgileRADRationalEtc.Etc.PlanDoCheckActBusiness Analysisand the BABOK

ReleaseTestInitiateCloseBuildDesignRequirementsProduct ScopePMI Project Management ProcessWaterfall DevelopmentSCRUMPRINCE2SIX SigmaAgileRADRationalEtc.Etc.Projects and the SDLC

Poor strategic alignmentLong time to deliveryPoor risk managementProject FailuresThere are many reasons why projects fail.PoorplanningLack of sponsor involvementIneffective communicationLack of handover(people change management)Team skills(esp. interpersonal skills)Poor requirements management is consistently in the top 3 reasons, regardless of the sourceLack of formal pm processes Poorly defined objectives/scopePoor or wrong requirements

The cost of bad requirementsThe following are a few key findings and data from the study:

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 groups projects were runaways which had any 2 of: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 skill 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.

The cost of bad requirementsThe following are a few key findings and data from the study:

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 groups projects were runaways which had any 2 of: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 skill 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.

The cost of bad requirementsThe following are a few key findings and data from the study:

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 groups projects were runaways which had any 2 of: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 skill 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.Requirements Professionals????

Project Failures

Requirements FailuresThe volume and complexity of stakeholders

Stakeholder expectations & involvement

Who is managing the requirements - skills of the requirements teamProcess Not deliverables

Requirements FailuresAvoid requirements failure by doing these things;FeedbackHave developers feed back their interpretation of requirements to the stakeholders and clients. Do it early and often. Use workshops, wireframes, prototypes, or documents, but do it.

Bring people togetherBring the subject matter experts and requirements owners into the same room as the developers. Get them talking to each other. If you can't be in the same room, arrange regular meetings. Don't rely on written communication.

The right Requirements teamMake sure your BAs are trained and highly skilled at requirements management (ie not just elicitation, but the whole shebang.) Practical tips

Project Team Roles

Project Team RolesSponsorProject ManagerBusiness AnalystChange ManagerQualitySolutions TeamLiaison RolesProcess AnalystsTrainersTestersSolutions ArchitectsSMEsSystems AnalystsTechnical WritersUsersDesignersDevelopers

SponsorProject ManagerChange ManagerQualityLiaison RolesProcess AnalystsTrainersTestersSolutions ArchitectsSMEsSystems AnalystsTechnical WritersUsersDesignersDevelopersBusiness Analyst

The IIBA and BABOKCertificationMelbourne eventsBABOK Chapter overview linklinklinkLink 1 Link 2

break

WHAT DOES A BA DO?Requirements ManagementBusiness ProcessesPeople Change ManagementProject Portfolio Planning

Requirements Management

MATURITY LEVELS (SEI/IEEE)Chaos Written requirementsOrganizedStructuredIntegrated

BABOK Knowledge areasDefining the role, resources etcBA BOK and contentsPlanningElicitationModelling and AnalysisCommunicationValidationVerificationEnterprise analysisStrategy and Structure Business Process Analysis Financial analysis and business casesConsulting skillsProject ManagementLevel 3?

BABOK Knowledge areasDefining the role, resources etcBA BOK and contentsPlanningElicitationModelling and AnalysisCommunicationValidationVerificationEnterprise analysisStrategy and structure Business process analysis Financial analysis and business casesConsulting skillsProject management

Basic SkillsRequirements ManagementPlanningElicitationCommunicationVerificationValidation

Requirements integrity

Requirements integrity

Beautiful Requirements?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????Level 5?

WHAT DOES A BA DO?Understand the stakeholdersBreak work down to activity levelWho does what, when and why?Get lots of feedback (validation)Manage expectations throughout the processshouldRequirements management

Basic Skills

Requirements Management

PlanningElicitationCommunicationVerificationValidation

Requirements PlanningPlan before you actLack of Completeness is the greatest source of requirements problemsIncorrect Requirements is also an issueKnow the stakeholders, know their businessBreak your work down to detailed tasks

Planschange

Requirements ElicitationDesk researchInterviews Workshops

ModelsFlow charts (Swim Lanes)Use Cases (with stories) Context DiagramsState Transition

Remember

Activity Level

Method H

Requirements CommunicationKnow who needs to knowHave enough time to communicate effectivelyCommunicate through the whole lifecycleNo surprises, Bad news early

Plan your communication

Requirements VerificationDocument Reviews3 day review cycles dont always work wellTell people in advance

Reviews and Inspections are one of the most effective methods of Requirements QA

Walkthrough workshops have strengths and weaknessesS: Group SynergiesW: Time and effort

Peer Review, Manager Review, Tester Review

Look forcompleteness and accuracy(in that order)

Requirements ValidationTestingV-Model and Agile both highlight test driven development, beginning with requirements. Waterfall also relies heavily on testing (% of time/effort)

UATBA role in planning, participating, assessing impact of bugs, troubleshooting, workarounds, stakeholders expectations

Business AcceptanceContract perspective, Responsibilities of both project and business, Overlapping period

Validation is done by people.

Take them on the journey.

Designer/ProgrammerScope/ High level requirementsWorkshops and InterviewsIdentify ConstraintsRevise Scope/Bus CaseIdentify StakeholdersDocument Business RequirementsApprove Business RequirementsSolution DesignAssess DesignRequirements ManagementChange ManagementBA activitiesRTMUATReady for ServiceChange Mgt PlanComms PlanTrainingBusiness personIT BABus BASystems AnalystBusiness AnalystStakeholdersIT managers, Infrastructure and network SMEsStakeholdersBusiness Managers and SMEsPM

Business Processes

3 ThingsUse casesSwim lanesContext diagrams

Use CasesCaseuserTyner Blain: Use Cases

Swim lanesActor 1Actor 2Actor 3Actor 4Verb/nounBinary decisionsActivity levelparticipantsBoundariesHand-overBegin and end in same lane

Context diagramsInformation flowExternalInternalDrilling downContext Boundary

and UMLDiagram from Wikipedia

and UMLDiagram from WikipediaUML is forsolution design

People Change Management

Changing peopleLewin: Unfreeze > Freeze

Maister: The Fat Smoker

Prosci:ADKARAwareDesireKnowledgeAbilityReinforce

Changing peopleAwareDesireKnowledgeAbilityReinforceStakeholder 1ADKARStakeholder 2ADKARStakeholder 3ADKARStakeholder 4ADKARStakeholder 5ADKAR

Project Portfolio Planning

Project Portfolio Management

Enterprise Analysis

Defining the opportunitySolution StrategiesBusiness CasesBenefits management

Enterprise Architecture

Information Management Application PlanningBusiness Process

break

workshopBreak into groupsReview examplesPresent feedback

workshopWhat makes good requirements?Quality of documentationCompletenessAccuracyClarityThe difference between requirements and designManagement through the process

Reviewing Requirements

ResourcesIIBANew, but growing in influence. BOKSBA BOKPM BOKOthersModern AnalystArticles, Forums, etcEd YourdonJESATynerBlain Structured analysisBetterProjects

Modern AnalystArticlesForumsTemplatesOther resources

Ed YourdonWebsiteBlogStructured Analysis Wiki

Free download of his JESA ` book

And much more

Tyner BlainSoftware developmentRequirements managementProduct managementSeeStructured analysis and Use Cases

Scott Sehlhorst, Austin Texas

**********************************************************