Download Presenation

330 views
295 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
330
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • A warm welcome to the conference and to the first presentation of the day. Name….. I have worked in IT for 20 years and as a BA for over 10 years. I currently work for BAS as a BA and trainer. I am going to present Why some projects fail how we can have a more scientific approach to analysis And How BA Solutions can help
  • You can see from these stats that over half of projects cost nearly twice their original estimate. And only just over 15 % of projects will be complete on time and on budget. The exact numbers are debatable, the principles are not. Why are we still getting it wrong after 40 odd years of managing projects.?
  • These are the causes of those problems. INCOMPLETE REQS Some are missing, incomplete, ambiguous and not at the right level. Mars orbiter – SHOULD be 150km orbit – was 54km. Cause – imperial vs metric units. LACK OF USER INVOLVEMEN T The BA has not correctly analysed the impact on all users and sought representation from them UNREALISTIC EXPECTATIONS BA has not defined measurable benefits - Everybody assumes they know what will be achieved and none are right. LACK OF EXEC SUPPORT Poorly defined objectives will mean that senior execs don’t care about them and so will not engage – especially if it doesn’t have any impact on their bonus. CHANGING REQS Requirements often change because the analysis has not been done properly. LACK OF PLANNING Resources – time and people are not released at the right time -
  • The BA can mitigate theses problems The BA is the single most ciritical role and is the PMs strongest ally PM progresses but BA does the work. Could have fantastic delivery of project, but could be rubbish. INCOMPLETE REQS Reduce this problem to 0 by ensuring the BA understands the scope, the objectives, and end to end process. AND manage the reqs from beg to end of the project, not just at the beginning, but keep an eye all the way through. LACK OF USER INVOLVEMENT Reduce this by correctly identifying the stakeholders and engaging them and asking them the right questions. BA not always given access to people UNREALISTIC EXPECATIONS BA can reduce this by defined benefits, and by checking feasibility - feasibility of cost, design and technology with the relevant people And it's not the BA’S job to promise to delivery everything. LACK OF EXEC SUPPORT: Ensure a sponsor is engaged from the start , AND sets their objectives which the BA can help to define. CHANGING REQS Businesses change all the time so some change is good and inevitable, BUT Use the right techniques and ask the right questions of the right people and change will be kept to a minimum. Bas say, “the users have changed their minds again”, but its the BA’s job to help the users to understand their own requirements, b ut taking them through their e2e processes and by ensuring their data is understood. When they do change, control and manage the change. LACK OF PLANNING Time is required to capture the reqs and for full User Acceptance Testing and for structured walkthroughs. For quality control. The BA needs to liaise with the PM over this.
  • TALK THROUGH Bas have to challenge and test everything. Nothing must be ambiguous, so….. WHAT DO WE MEAN BY SUFFICIENT?
  • This is based on a study by Staffordshire University – figures are based on amount of actual effort rather than what is actually needed to get it right. Our experience is that requirements take about twice as long as the design and about the same amount of time/effort as Coding (not testing). What it should be: 30% reqs 15% design 40% code 15% test
  • You can see from the shape of this graph that most errors originate during analysis.
  • Now look at the shape of this graph. It’s going in the other direction. The relative cost of correcting reqs is 1 in 100 in comparison to correcting after go live. The numbers don’t matter too much – the fact the costs of correction rise exponentially does.
  • Half of errors are requirement errors costing ¾ o project rework costs – leading to… Late projects costing nearly double their budget – no wonder 30% just get canned. Contributing to…. Back to original slide figures
  • Don’t read this. It’s Human nature to want to get started, just get on with it, but preparation is all – like deocrating a room. Spend time prearing properly and the design and build will be quicker and better quallity
  • You’ve heard of the elephant graveyard? What about the white elephants’ graveyard? The way to get there is not to do the analysis of requirements!
  • In science, the first discipline is to : observe . Gather facts (In fact, evidence of trying to organise knowledge can be traced back to prehistoric times in the form of records carved in bone or stone, and by paintings on cave walls.) Ask Questions and then a hypothesis, Then tested or experiment. analysed and evaluate the results Why is there not a similar structure for Business Analysis? Why are there so many approaches for accomplishing the same job: the job of analysing equirements for change? Well, let’s have a look.
  • Let’s analyse the term “Business Analysis”. Why Business? It’s really Mangement Consultants who analyse business. The Bas that work within projects, particularly It projects inside all types of organisations are analysing change requirements, Analysis Anaysis is breaking things down, but it is also about thinking not JUST thinking. It is thinking in a particular way. For analysis of change requirements it means breaking down the requirements to their component parts to PROVE that all requirements deliver SMART project objectives.
  • Some methods and structured documentation and templates that are available to analysts often constrain them, prevent them from thinking, they feel obliged to tick boxes and complete templates with minimal thinking. What is the primary concern is the objectives. The requirements must meet the objectives Just like withi Prince2 or any project management methodology, you still need to think to be a project manager. Business Analyst Solutions can provide examples of documentation to help – come on our training day.
  • There is a chain of reasoning that leads from the sufficient definition of the problem to the sufficient definition of the requirements for the solution. Break any one link in the chain and the rest of the chain is unsupported: un-provable. REQUIREMENTS – wrong until PROVED right…so HOW do you PROVE that?
  • Scope is very important as I am sure any projcet manager here will confirm Does this look familiar? There are different types of scope – this is using POLDAT. P for processes etc.
  • EXAMPLE: Driver: Business Analysis function not performing optimally Objective: Reduce errors attributable to requirements analysis by 50% Requirement: Be able to analyse change requirements Business rule: all change requirements be peer group reviewed in structured walkthroughs NOTE: only 1 example of each component – in reality there will be many in each component, with the numbers increasing as you go down the chain.
  • IF : the BA uses the Chain of Reasoning to specify provable requirements for changes to processes and/or data and/or non-functional components THEN : it does not matter what method and approach using techniques, language and emphasis is employed so long as it covers every link in the chain
  • Made the case that BA is not a difficult thing to do in principle It is difficult in practice because it demands provable ANALYSIS which means TIME AND THINKING – on projects these are often both in short supply So long as the analysis is provable in your method/approach it doesn’t matter what method/approach you use Beware the jargon – my current fav is Jidoka – add the human element to processes (from Lean) When I am working as a BA my mantra is trust no-one, believe nothing, prove everything – and that should apply to how you do Business Analysis as well
  • Design the BA fucnction - Some Bas have to organise themselves Why not attend one our Training Taster Days at our offices in central London – see me at the stand 138 afterwards if you are interested!
  • Our objective is that you can do the job
  • Download Presenation

    1. 1. The Business Analysis Framework Wendy Waker Stand 138
    2. 2. Why do we still have these sort of problems with Change Projects…. <ul><li>The average project exceeds its planned schedule by 120% </li></ul><ul><li>52.7% of projects will cost 189% of their original estimate </li></ul><ul><li>Only 16.2% of projects will be completed on time & on budget </li></ul><ul><li>30% of projects are cancelled before completion </li></ul>*Source: Calculating your return on investment from more effective requirements management IBM article Dec 2003
    3. 3. <ul><li>The Standish Group “Chaos Report” (1994) </li></ul><ul><li>365 executive managers </li></ul><ul><li>8,380 applications </li></ul><ul><li>all major industry segments including: banking, retail and wholesale. </li></ul>Reasons for problems with change projects… Some of the contents of this slide were taken from www.it-cortex.com
    4. 4. Business Analysis mitigates the top 6 reasons for project failure <ul><li>Incomplete requirements </li></ul><ul><ul><li>Measure of success for Business Analysts! Target: Zero. </li></ul></ul><ul><li>Lack of user involvement </li></ul><ul><ul><li>BAs scope a project including who is impacted and therefore who needs to be engaged </li></ul></ul><ul><li>Unrealistic expectations </li></ul><ul><ul><li>Poorly defined? Open to misinterpretation? Blame the BA! </li></ul></ul><ul><li>Lack of senior exec support </li></ul><ul><ul><li>If the project objectives don’t matter to the exec, they won’t support </li></ul></ul><ul><ul><li>BA must ensure the exec define SMART measures and targets </li></ul></ul><ul><ul><li>SMART – the ‘T’ is To-Die-For! </li></ul></ul><ul><li>Changing requirements </li></ul><ul><ul><li>Measure of success for Business Analysts! Target: minimise. </li></ul></ul><ul><li>Lack of planning </li></ul><ul><ul><li>At least the analysis should be planned properly! </li></ul></ul><ul><li>Business Analysis – the analytics engine of your projects </li></ul>
    5. 5. Business Analysis Proverbs <ul><li>Delivery is not the best time to analyse requirements </li></ul><ul><li>Urban Wisdom </li></ul><ul><li>A factor present in every successful project and absent in every unsuccessful project is sufficient attention to requirements. </li></ul><ul><ul><ul><ul><ul><li>Suzanne & James Robertson </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Requirements-Led Project Management </li></ul></ul></ul></ul></ul>
    6. 6. Requirements Analysis Design Code/test 0 10 20 30 40 50 60 70 Average actual effort spent on each stage of the development cycle* *based on a study by Staffordshire University What is “sufficient attention to requirements”? (I)
    7. 7. Requirements Analysis Design Code/test 0 10 20 30 40 50 60 70 80 90 Average Proportion of Errors Built in During Development* *based on a study by James Martin What is “sufficient attention to requirements”? (II)
    8. 8. Relative Cost of Correcting Requirements Errors* *sourced from Barry Boehm What is “sufficient attention to requirements”? (III)
    9. 9. How Much Poor Analysis can £ Cost* <ul><li>Half of all bugs can be traced to requirement errors </li></ul><ul><li>fixing these errors consumes 75% of project rework costs </li></ul><ul><li>Maybe that’s why: </li></ul><ul><li>The average project exceeds its planned schedule by 120% </li></ul><ul><li>52.7% of projects will cost 189% of their original estimate </li></ul><ul><li>Only 16.2% of projects will be completed on time & on budget </li></ul><ul><li>30% of projects are cancelled before completion </li></ul>*Source: Calculating your return on investment from more effective requirements management IBM article Dec 2003
    10. 10. <ul><li>The typical project… </li></ul><ul><li>… expends least effort on change requirements analysis… </li></ul><ul><li>… which is where most errors originate… </li></ul><ul><li>… and whose errors cost most to fix! </li></ul>
    11. 11. So – projects are all doomed?
    12. 12. The tool for discovering new knowledge is the Scientific Method <ul><li>Construction of ‘theories’ </li></ul><ul><ul><li>Observation and experimentation of isolated facts and results </li></ul></ul><ul><ul><li>Creating generalised hypotheses </li></ul></ul><ul><ul><li>Testing hypotheses through observation and experimentation </li></ul></ul><ul><li>Methods and approach vary by discipline </li></ul><ul><ul><li>Physics Vs Psychology </li></ul></ul><ul><li>The top level process remains the same </li></ul>The tool for defining change requirements is...? There are many methods and approaches all for defining change requirements
    13. 13. Definition of terms for “Business Analysis” <ul><li>Business : why “Business”? </li></ul><ul><li>… should it be Change Requirements??? </li></ul>Analysis: “the process of breaking a concept down into more simple parts, so that its logical structure is displayed” (OED)
    14. 14. So how do you do analysis? <ul><li>You can pay your money and take your pick of the various methods & approaches </li></ul><ul><li>Our Training Taster Day gives examples of documentation for </li></ul><ul><ul><li>Problems/opportunity analysis </li></ul></ul><ul><ul><li>Objectives analysis </li></ul></ul><ul><ul><li>Requirements Analysis </li></ul></ul><ul><li>… but how is not the issue, proving that the analytical products deliver project objectives is </li></ul>
    15. 15. Chain Of Reasoning: <ul><ul><li>Change Requirements must be assumed to be wrong until they are proved to be right </li></ul></ul>Stakeholders Drivers Objectives Objectives Objectives Objectives Objectives Drivers Drivers Drivers Change Requirements Change Requirements Change Requirements Change Requirements Change Requirements
    16. 16. Scope of analysis of change requirements <ul><li>Change requirements can be for </li></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Organisation units </li></ul></ul><ul><ul><li>Locations </li></ul></ul><ul><ul><li>Data </li></ul></ul><ul><ul><li>Applications </li></ul></ul><ul><ul><li>Technologies </li></ul></ul><ul><ul><li>Non-functionals </li></ul></ul><ul><ul><li>… oh – and the valid intersections!!! </li></ul></ul>
    17. 17. All the Links in the Chain Of Reasoning The problems / opportunities that the business face The measures and targets that will enable us to declare the change project has been successful Driver Project Objective Project Requirement Business Rule Addressed as measured by Delivered by Enforces Definitions of what changes are required that will affect the measures of success (objectives) sufficiently for the project to be declared successful What rules must be implemented by the changes specified in the requirements Change requirements
    18. 18. How to forge links in the Chain Of Reasoning Problem / opportunity analysis SMART objectives Driver Project Objective Project Requirement Business Rule Addressed as measured by Delivered by Enforces Specific – there is a precise definition of the objective Measurable – there are units that the objective will be measured in Achievable – the measures can be achieved ‘in the real world’ Relevant –this project will actually affect this objective To-die-for – the project has failed if it does not achieve the objective Business… Functional… Non-functional… … high level … mid level Process model Process specification Non-functional specifications Data model Attribute specification … low level Change requirements
    19. 19. If… <ul><li>If you can map all your analysis to </li></ul><ul><li>components in the Chain of Reasoning </li></ul><ul><li>If there are no gaps AND no breaks in the chain </li></ul><ul><li>If those who can kill your project agree with your </li></ul><ul><li>analysis </li></ul><ul><li>Then your analysis is correct and what’s more you are a Business Analyst my (per)son. </li></ul><ul><li>Sorry Rudyard! </li></ul>
    20. 20. The secrets of doing Business Analysis <ul><li>Agree the analysis method and approach (if any!) you will use </li></ul><ul><li>Get some trained Business Analysts </li></ul><ul><li>Plan how, when and who to do the analysis </li></ul><ul><li>Do the analysis </li></ul><ul><li>Use the analysis products to develop and implement the solutions </li></ul><ul><li>Er – that’s it. </li></ul>
    21. 22. So – Business Analysis is needed… … what next? There are a number of steps to take to establish an operational Business Analysis function: Mentor and Support the B.A. Function Design the B.A. Function Recruit the B.A. Function Train the B.A. Function Equip the B.A. Function
    22. 23. How can BA Solutions help? Mentor and Support BA Function Design B.A. Function Recruit B.A. Function Train B.A. Function Equip B.A. Function <ul><li>Recruitment of permanent and contract analysts </li></ul><ul><ul><li>Source candidates internally and externally </li></ul></ul><ul><ul><li>Qualify CVs </li></ul></ul><ul><ul><li>Interview – conduct them or just assist with them </li></ul></ul><ul><ul><li>Assessment centres </li></ul></ul><ul><ul><li>Manage contracted analysts placed by B A S </li></ul></ul><ul><li>Training courses for analysts </li></ul><ul><ul><li>Training needs analysis </li></ul></ul><ul><ul><li>Fundamentals of Business Analysis </li></ul></ul><ul><ul><li>Process Modeling </li></ul></ul><ul><ul><li>Data Modeling </li></ul></ul><ul><ul><li>ISEB accreditation </li></ul></ul><ul><ul><li>Introduction to Testing </li></ul></ul><ul><ul><li>BPMN </li></ul></ul><ul><ul><li>Essential soft Skills for Business Analysts including Workshop Facilitation & Conflict resolution </li></ul></ul><ul><ul><li>Taster Day training – an intensive 1 day introduction to Business Analysis </li></ul></ul><ul><ul><li>Refresher day training based around your projects </li></ul></ul><ul><li>CASE tool recommendation - independent </li></ul><ul><ul><li>Assessment of requirements </li></ul></ul><ul><ul><li>Recommendations and benefits assessment </li></ul></ul><ul><li>Mentor and Support for analysts </li></ul><ul><ul><li>Phone and email post training </li></ul></ul><ul><ul><li>Refresher training </li></ul></ul><ul><ul><li>Facilitated workshops </li></ul></ul><ul><ul><li>Mentoring </li></ul></ul><ul><ul><li>Q/A reviews of analysis deliverables </li></ul></ul><ul><li>Design of the Business Analysis function </li></ul><ul><ul><li>Terms of reference </li></ul></ul><ul><ul><li>Business Analyst Profile </li></ul></ul>… and we can bespoke solutions for individual clients … try before you buy: BA Solutions Training Taster Day!
    23. 24. Who Are Business Analyst Solutions? <ul><li>BA Solutions are highly experienced Business Analysts </li></ul><ul><li>We have extensive practical experience in a wide range of industry sectors including retail, banking, utilities, software houses </li></ul><ul><li>We have worked in IT departments and within Businesses at every level from Majority Shareholder/Owner to Managing Director to shop floor workers </li></ul><ul><li>… and what is the Business Analyst Solutions vision? </li></ul><ul><li>To support the whole Business Analyst ‘life cycle’ and provide whatever services clients need in order to set up and run an effective Business Analyst function. </li></ul>
    24. 25. Why choose Business Analyst Solutions? <ul><li>Training material development and training delivery is all done by highly experienced and active Business Analysts </li></ul><ul><li>We are a niche supplier for all things related to Business Analysis and provide support end-to-end, not just training </li></ul><ul><li>We have a track record of high customer satisfaction (92% average) and references are available </li></ul><ul><li>We have worked in all major industry segments </li></ul><ul><li>We are adaptive to client requirements bespoking solutions as required </li></ul><ul><li>We know the value of doing effective Business Analysis </li></ul><ul><li>We care! We care about Business Analysis and do whatever we can do to get it being done effectively. </li></ul>
    25. 26. <ul><li>Come and see us on Stand 138 </li></ul><ul><li>If you would like to discuss anything further: </li></ul><ul><li>mail: [email_address] </li></ul><ul><li>phone: 07793 231428 </li></ul><ul><li>web: www.BusinessAnalystSolutions.com </li></ul>

    ×