Hide Notes 

Slide 1: Business Analysis… …it ain’t rocket science! Guy Beauchamp Stand 96 ©Business Analyst Solutions 2007
Slide 2: The Top 6 Reasons Projects Fail The Standish Group “Chaos Report” (1994) • 365 executive managers • 8,380 applications • all major industry segments including: banking, retail and wholesale. Some of the contents of this slide were taken from www.it-cortex.com ©Business Analyst Solutions 2007
Slide 3: An example of rocket science...? Mars Climate Orbiter went in to orbit at 57km above Mars instead of 150km. It was destroyed. Cause: some navigation calculations performed in Imperial units (pound-seconds) and some in metric units (newton-seconds). Most project failures are due to incomplete/inaccurate requirements ©Business Analyst Solutions 2007
Slide 4: The hard sell Salesforce not engaged during development and rollout of a Contact Management tool. ©Business Analyst Solutions 2007 When they wouldn’t use it they were told it was a sackable offence not to. When they still didn’t use it - Contact Management tool reversed out - a new Contact Management project initiated (by a new Sales Director!) …without a rep from the salesforce! 2nd biggest reason for project failure: lack of user involvement
Slide 5: The “Can-Do” attitude and the Canute experience ©Business Analyst Solutions 2007 3 month ‘time boxed’ ‘quick-win’ ‘8020’ project for simpler order entry… …delivered 18 months late and abandoned a few weeks into trial 3rd most likely reason for project failure: unrealistic expectations
Slide 6: A Legend in Its Own Lifetime £Multi-million brand re-launch…sponsored by the Logistics Director. Sales & Marketing Director in blissful ignorance until financial year end… “This Programme has been such a success we will take the lessons learned from it to the [new relaunch] Programme” (sponsored by Sales & Marketing Director) 4th biggest reason for project failure: lack of senior exec support ©Business Analyst Solutions 2007
Slide 7: When I say “Yes” I mean… ©Business Analyst Solutions 2007 A report was required to produce cumulative total for “Yes” and “No” responses over a period of time to the following question…“Are Service Levels being met?” Halfway through UAT the question to be asked in future was changed to…“Are queuing times longer than normal?” Impact? 5th most likely reason for project failure: changing requirements
Slide 8: “I love deadlines – I love the ‘whooshing’ noise they make as they pass.” Douglas Adams 6th biggest reason of project failure: lack of planning ©Business Analyst Solutions 2007 Major outsourcer: “The Project Management strategy is that all Projects will deliver within 20 days. Analysis will run concurrently with design and development.”
Slide 9: Business Analysis Proverbs • Delivery is not the best time to analyse requirements ©Business Analyst Solutions 2007 Urban Wisdom • A factor present in every successful project and absent in every unsuccessful project is sufficient attention to requirements. Suzanne & James Robertson Requirements-Led Project Management
Slide 10: What is “sufficient attention to requirements”? (I) Average actual effort spent on each stage of the development cycle* 70 ©Business Analyst Solutions 2007 60 50 40 30 20 10 0 Requirements Analysis Design Code/test *based on a study by Staffordshire University
Slide 11: What is “sufficient attention to requirements”? (II) Average Proportion of Errors Built in During Development* 90 70 60 50 40 30 20 10 0 ©Business Analyst Solutions 2007 80 Requirements Analysis Design *based on a study by James Martin Code/test
Slide 12: What is “sufficient attention to requirements”? (III) Relative Cost of Correcting Requirements Errors* 100 ©Business Analyst Solutions 2007 80 60 40 20 0 100 1 Reqts 3 5 14 33 Design Program Test Accept Live *sourced from Barry Boehm
Slide 13: How Much Poor Analysis can £Cost* • Half of all bugs can be traced to requirement errors • fixing these errors consumes 75% of project rework costs ©Business Analyst Solutions 2007 CONTRIBUTING TO: • The average project exceeds its planned schedule by 120% • 52.7% of projects will cost 189% of their original estimate • Only 16.2% of projects will be completed on time & on budget • 30% of projects are cancelled before completion *Source: Calculating your return on investment from more effective requirements management IBM article Dec 2003
Slide 14: Summary ©Business Analyst Solutions 2007 The typical project… …expends least effort on analysis… …which is where most errors originate… …and whose errors cost most to fix!
Slide 15: 10 sets of stakeholders… …who follow a chain of reasoning that leads from problem definition to implemented solutions …and maintaining the integrity and coherence of the chain is the work of the Business Analyst. Owners defines measures of success and £targets …Business Analysts confirm & document £Mone y! Enough problems – what’s needed is… Strategists Sponsors establish a Programme that delivers the strategy …Business Analysts document Programme TOR and build the Business Case determine the strategy to hit the targets …Business Analysts do market research, create strategy, challenge & document ©Business Analyst Solutions 2007 Programme Managers Institute Projects that implement the programme …Business Analysts document the Project TOR Business analysts specify requirements for Projects in the Business Model Systems Analysts IT build solution …Business Analysts protect requirements & document compromises design solution that satisfies the requirements …Business Analysts protect requirements & document compromises IT and the Business test solution …Business Analysts ensure tested against requirements Project managers Implement solution …Business Analysts help with -Process and data migration -Cutover planning -Rollout Users Accept solution …Business Analysts help with -£MEASURING £BENEFITS £REALISATION POST-IMPLEMENTATION Business Analysts feed back to the Owner how well their measure of success has been achieved
Slide 16: How Business Analysts maintain the integrity and coherence of the chain of reasoning – Problem analysis creates the – Vision which will be realised by delivery of the – Goals whose measures of successful implementation are – Objectives that will be realised by – Requirements which are built in to – Solutions designs which are – Tested against requirements and – Delivered to the scope of the project ©Business Analyst Solutions 2007
Slide 17: In conclusion Business Analysis – ©Business Analyst Solutions 2007 • it ain’t rocket science • it is science (not a [dark] art) • science has the scientific method • Business Analysis has many structured methods All structured methods must be fundamentally the same as they must all • analyse problems • analyse the scope of the solution • analyse functional and non-functional requirements • manage requirements in to design & delivery.
Slide 18: …and finally… the secrets of doing Business Analysis 1. 2. 3. 4. 5. Agree the analysis method you will use Get some trained Business Analysts Plan how, when and who to do the analysis Do the analysis Use the analysis products to develop and implement the solutions 6. Er – that’s it. ©Business Analyst Solutions 2007
Slide 19: Business Analysis… …it ain’t rocket science! Guy Beauchamp Stand 96 ©Business Analyst Solutions 2007