Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Destaque
Destaque (13)
Semelhante a 01 scope of the ba role
Semelhante a 01 scope of the ba role (20)
Último
Último (20)
01 scope of the ba role
- 1. Bite sized training sessions: Scope of the Business Analyst Role
- 2. Objectives • Review the scope of the BA role • Make a case for the importance of the BA role • Discuss whether a BA really is a BA… • Think about the “analyst” part the BA title
- 3. Putting the Business Analyst in context Owner/sponsor “I want it all I want it now I want it for free” Solutions developers “Given all the other projects we are already doing for you, the best we can do is a bit, in 6 months and it will of course cost a bit” Subject Matter Experts/Users “We must have this - and soon! - or our business will fail” BUSINESS ANALYST Programme/Project Manager “The sponsor will get it all, now and for free”
- 4. Sponsor: We’re going to the moon! Project Manager: ok, we have to plan…first off, SME’s, what do you need? SME: We’ll need a spaceship and spacesuits! Business Analysts: Do we need anything else? Business Analysts: to answer your question I need to know… Why are we going to the moon? (Problem analysis) How will we know it was a worthwhile trip? (Objectives analysis) Therefore - what will we need to ensure it is worthwhile? (Requirements analysis) Developer: So we need to develop solutions for the following requirements…
- 6. An example of rocket science...? Mars Climate Orbiter went in to orbit at 57km above Mars instead of 150km. It was completely 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
- 7. What do you think are the other main causes of project failure? Discussion
- 8. The Standish Group “Chaos Report” (1994) The landmark study of project failure covering 365 executive managers and 8,380 applications in all major industry segments including: banking, retail and wholesale. Some of the contents of this slide were taken from www.it-cortex.com Why Projects Fail
- 9. More chaos stats, stats and … Source: http://blogs.msdn.com/b/dannawi/archive/2009/05/15/2009- standish-chaos-report-we-are-successful-in-the-failure.aspx
- 10. How can BAs mitigate the main risks for project failure? Discussion
- 11. Reqts Design Program Test Accept Live 0 20 40 60 80 100 1 3 5 14 33 100 Relative cost of correcting error Barry Boehm Cost of analysis errors The cost of correcting analysis errors rises almost exponentially the longer they remain undetected.
- 12. • 40-56% of bugs can be traced to requirement errors • Finding and fixing requirement errors consumes 70-85% of project rework costs • The average project exceeds its planned time 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. How much poor analysis £costs
- 13. What do you think a business analyst does? Should PMs do what BAs do and vice- versa? Discussion
- 14. Scope of the Business Analyst role (I) There is a chain of reasoning that leads from the statement of a problem to the implementation of solutions… …it is documented in products… Drivers Objectives Scope Business & Functional &NF Requirements Processes & Data Models BA products BA product application Tech Specs Code & Databases UAT specs Extracted data Business Procedures Loaded Data Business Training TOR
- 15. POST-IMPLEMENTATION Business Analysts feed back to the Owner how well their measure of success has been achieved Owners defines measures of success and $targets …Business Analysts confirm & document Strategists determine the strategy to hit the targets …Business Analysts help research, create strategy, challenge & document Sponsors establish a Programme that delivers the strategy …Business Analysts document Programme TOR and help build the Business Case Programme Managers Institute Projects that implement the programme …Business Analysts document the Project TOR Project Stakeholders …Business Analysts specify requirements for Projects (in the Business Model) Design Analysts design solution that satisfies the requirements …Business Analysts write functional specifications, protect requirements & document compromises Project managers Implement solution …Business Analysts help with -Process and data migration -Cutover planning -Rollout Solution Builders & Business test solution …Business Analysts ensure tested against requirements Solution Builders build solution …Business Analysts protect requirements & document compromises Users Accept solution …Business Analysts help with -$MEASURING $BENEFITS $REALISATION Scope of the Business Analyst role (II) There is a chain of reasoning that leads from the statement of a problem to the implementation of solutions… …involving up to 10 groups of people… $Mone y!
- 16. Definition of terms for “Business Analysis” Business: why “Business”? …should it be Change Requirements??? Analysis: “the process of breaking a concept down into more simple parts, so that its logical structure is displayed” (OED) a : examination of a complex, its elements, and their relations b : a statement of such an analysis (Merriam Webster)
- 17. Inductive VS Deductive Analysis • Induction: – a method of reasoning from a part to a whole, from particulars to generals, or from the individual to the universal. – Example: whenever I let go of a hammer, it falls to the ground. Therefore, every time I let go of a hammer it will fall to the ground. • Deduction: – a rigorous proof, or derivation, of one statement (the conclusion) from one or more statements (the premises)— i.e., a chain of statements, each of which is either a premise or a consequence of a statement occurring earlier in the proof. – Example: All fairies are pink. Tinkerbelle is a fairy. Therefore, Tinkerbelle is pink. • Which is better? That’s elementary, Watson.
- 18. …and there’s more the BA needs to be thinking about… • Argumentation theory – how to discover the truth. • Philosophy – what is “truth” in a business context and how to do we prove it? • Rhetoric – persuasion and/or enquiry? • Opinions – they matter but are only one tool – not the only tool! • Communication theories – how to best communicate what to who? …BAs are the analytical engine of a project…no-one else is accountable for doing it…we better do it well!
- 19. You are not alone… • www.smart-BA.com » Articles » Sample analysis documentation • www.ModernAnalyst.com » Excellent BA community » Articles » Forums » Sample analysis documentation • www.RequirementsNetwork.com » Another excellent BA community » Articles » Forums • www.TheIIBA.org » BA professional organisation » BA professional qualifications (CBAP) • www.BCS.org » BA professional qualifications (ISEB Diploma)
- 20. Questions?
Notas do Editor
- Review the scope of the BA role An examination of what the scope needs to be in order for a BA to be able to do analysis of requirements. Assuming that there are such things as business requirements for change and that these need analysis in order to be defined, then there is certain information required which necessitates a BA either being involved in or having intimate knowledge of certain stages of a project. Make a case for the importance of the BA role What value do BAs add? Can this be specified? Can it be quantified? The issue is that most of the benefits that BAs deliver are invisible as they are concerned with the avoidance of foul-ups. Discuss whether a BA really is a BA… A deconstruction of the title “Business Analyst” – do they really do what they say on the tin? Differentiate between Inductive and Deductive analysis Analysis is not just talking, chatting or even asking questions. It is as precise and formal process as possible in order to maximise chances of discovering the right information to deliver maximum benefits in the minimum time. As BAs we should be aware of some of the basics and inductive logic and deductive logic are basics.
- The point of this slide is to mostly self explanatory except for the arrows – they show key interactions. Some of these do not involve the BA yet they materially affect the work that BAs do, and as such we need to be aware that they are going on.
- Worked (mickey-mouse) example, hopefully self explanatory. The point to stress is that it is not until we get to the BA section that there are questions on the specifics of what is being proposed, why and what istherefore necessary. Give the developers that information and tell them they don’t have to worry about justifying whether it is really needed or not (the analysis of that has been done!) and they are ‘freed up’ to think creatively about best solutions.
- 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
- The fact that “Most project failures are due to incomplete/inaccurate requirements “ is substantiated on a subsequent slide. Possible question for debate (referring back to the scope of the BA role)…is the specification of calculation units the realm of the BA or technical analyst/systems designer? Answer: it depends on whether the business have specific requirements in this area – and those requirements are justified given the objectives of the piece of work.
- The Chaos Report is the first survey made by the Standish Group. This report is the landmark study of IT project failure. It is cited by everybody writing a paper or making a presentation were a reference is made of IT project failure. It includes large, medium, and small companies across major industry segments : banking, securities, manufacturing, retail, wholesale, heath care, insurance, services, and local, state, and federal organizations. The total sample size was 365 respondents representing 8,380 applications. It is also hotly contested and disputed (as brief Google search will verify) – so do not accept this data as utterly without question true.
- The trends in the Chaos dataset are not encouraging…
- Incomplete/inaccurate requirements Business Analysts own requirements. They may not always be the people who generate them, but if the signed-off requirements are not fit for purpose (that purpose being the development of all aspects of solutions, computerised or not) then it is the Business Analyst who should be held responsible. A good Business Analyst then should remove the risk of inaccurate requirements, and should significantly mitigate the risk of incomplete requirements. They cannot remove this risk as they will be dependant to an extent on the quality of the other people who are supplying requirements. Lack of user involvement To mitigate the risk of lack of user involvement, we need to know which users need to be involved, why and how. A Business Analyst should be analysing and documenting the context and scope of the solution. Context. BAs need to define user groups that need to be engaged by the project in the course of defining the context in which the solution will operate. They need to know the user and customer groups who interact with the solution. The BA also needs to define who is to be engaged by the project and how in order to do the analysis the analyst needs to do. Scope. The BA must analyse the organisation units which are the user groups that are going to be changed by the solution (what they do, how they do it, how they are structured and so on). These users need to be engaged to gather requirements. The Business Analyst has the responsibility for ensuring that these context and scope definitions are full, complete and accurate. This analysis should mitigate the risk of lack of user involvement. What the analysis does NOT do is analyse who the solution needs to be ‘sold to’ and how to ‘sell it’. Thus the Business Analyst can mitigate the risk of lack of user involvement but not remove it. Unrealistic expectations Unrealistic expectations can be caused by many reasons and the majority of them will not be directly attributable to the Business Analyst so they can not mitigate the risk. The area that Business Analysts can and must mitigate risk is the area of unrealistic expectations for the project deliverables. Logically, this can be traced back to the objectives for the project. Unless objectives are specific, measurable, achievable, directly relevant to what the project will deliver and fundamentally important to the business owners of the project, then they can be interpreted in any number of ways leading directly to unrealistic expectations about what the project will deliver. For example, consider these two objectives: a. become a centre of excellence for customer service b. increase sales by 10% Objective ‘a’ immediately raises the question of how the business will know it has become a centre of customer service. What measure will it use as a scale of customer service and what value on that scale means that the business has achieved being a centre of customer service? Define that and there is no doubt about what the project is setting out to achieve. The Business Analyst owns responsibility for ensuring that the objectives are fit for purpose (that purpose being the development of requirements that – when implemented – will result in the objectives being achieved). Note that the Business Analyst does not have to do the work of defining the objectives (in the real world they are often done by Project Managers), they must simply make sure they are fit for purpose. If they are not, then the project runs the significant risk of failure due to unrealistic expectations caused by a poor definition of what the project will achieve. Similar arguments can be made for functionality that is expected (BA defines functional requirements), scaleability and other non-functional requirements that the BA should be defining. Lack of executive support Surely the Business Analyst is not responsible for senior exec buy-in? Consider this: you are a Business Analyst working on a project and for some reason the people who can make the go/no-go decisions are always too busy to attend steering group meetings and so on. The question is why? There can be a multitude of reasons which are outside of the control of the Business Analyst and – indeed – the project. However, one reason that is in control of the project (and may be in control of the Business Analyst themselves) is that the senior execs are not interested because they do not care about the deliverables of the project. Suppose now you are a senior exec and you have 2 projects for which you hold ultimate authority. One project will deliver a solution that takes you some way to meeting your sales targets that you are responsible to the company board for achieving. The other project delivers a cultural change programme centred around the slogan of “becoming a centre of excellence for customer service”. Which would you focus on? By the way, both of these projects were projects in the real world – guess which one got completed and which failed due to lack of decisions by the senior execs? Business Analysts can make sure that the objectives are directly relevant to what the project will deliver and fundamentally important to the business owners of the project. If they are not then the Business Analyst should raise the risk that the project will fail due to lack of senior exec support. Changing requirements Requirements can change because the business environment changes, the business users come to understand what they are asking for is not what they need or because of misunderstandings about what the requirement really is. It is this last reason that the Business Analyst can mitigate against. By building up a rigorous chain of inductive logic starting with the precise definition of what the project seeks to address (in terms of problems and/or opportunities) and following through to the full set of process and data requirements for the change, the Business Analyst can deliver a justified set of change of requirements that will not change because of misunderstandings. This ‘chain of reasoning’ is the covered in more detail in a subsequent training session. Lack of planning The Business Analyst is not a Project Manager (or vice-versa) – they are very different skills sets and (typically) the type of person who makes a good Business Analyst does not make a good Project Manager (and vice-versa). Planning is owned by the Project Manager. In the real world, most projects are planned by setting an implementation date and then the plan is constructed back from that date to try and fit everything in. This implementation date constraint is often outside of the control of the project team. What the Business Analyst can and must do is define what they need to do, who and what they need to do it with and how much effort will be involved. At least that part of the plan will then have some rational justification. Business Analysts must also analyse the risks of cutting back on the analysis – and in the real world the risk is (typically) project full or partial failure due to 1. Incomplete/inaccurate requirements 2. Lack of user involvement 3. Unrealistic expectations 4. Lack of executive support 5. Changing requirements 6. Lack of planning
- Cost of correcting analysis errors rises almost exponentially through a project lifecycle because the longer an analysis error is left The more places it is being used so… The more work has to be un-done The more work has to be re-done
- These are products. Although they are dependant on each other as the arrows show, they do not have to be developed sequentially. Typically, they will be developed concurrently with significant overlap. Certainly the process models can not be declared complete until at least the functional requirements are complete (because functional requirements result in at least 1 process model). The skill is in recognising that a change to (say) functional requirements means a potential change to process models, and that a change to process models needs to be verified against functional requirements. This ‘bouncing up and down’ the chain of products is typical in an iterative process of analysis.
- Scope of the BA diagram narrative. ‘Owners’ are those people who can enable a project to proceed or cancel it. They will include budget holders but almost certainly there will be other owners who may or may not be officially recognised as such but who can – if they desire – stop the project. For example, an IT Director might be one owner of a Business project involving a new system if there are IT standards which must be adhered to before a system can go live. These owners need to agree what the change project will accomplish and analysis is needed to define these objectives in terms of what the measures of success will be and – for each measure – the target value that equates to success. ‘Strategists’ will define an approach for achieving the objectives. Analysis is needed to ensure that the strategy is justifiable to the owners. Note that it is very common for an Owner to also be a Strategist! But not all Owners will be Strategists. ‘Sponsors’ will back a programme of change. A programme is defined as a collection of projects. Taken together these projects will deliver the strategy that has been agreed will achieve the objectives. Note that it is very common for an Owner to also be a Sponsor! But not all Owners will be Sponsors. Analysis will be needed to define the Terms of Reference (TOR) for the Programme: the Objectives, Scope and High Level Requirements as a bare minimum. ‘Programme Managers’ will initiate the projects that make up the programme. The same note for Programmes apply to Projects: it is very common for an Owner to also be a Programme Manager! But not all Owners will be Programme Managers. Analysis will be needed to define the Terms of Reference (TOR) for the Programme: the Objectives, Scope and High Level Requirements as a bare minimum. ‘Project stakeholders’ will generate and sign-off requirements for the project. Analysis is required to define the process, data and non-functional requirements. ‘Design analysts’ will take the products of analysis and propose the best solution to meet the requirements (‘best’ being defined as satisfies most requirements). Any compromises required will be mediated by the Business Analyst with all who need to accept the compromise. Note that Design Analysts can be IT analysts for IT components, HR analysts for people and organisation units, and others for other components. ‘Solution Builders’ take the design specifications and construct solutions. Note that these solutions are not constrained to IT components but must all work together to provide the whole solution. ‘Solution builders and Business’ test the solution. The requirements analysis should be used to construct the test plans – especially the user acceptance testing. Note that the Business Analyst should q/a that the UAT does test that the requirements have been met. ‘Project Manager’ will co-ordinate the whole project and implementing the solution, and the Business Analyst (being a subject matter expert on project Objectives, Scope, and Requirements) should be able to contribute significantly to the design of all implementation activity, all the while ensuring that requirements are being met. In an ideal world, ‘post implementation’ how well the objectives have been met will be fed back to the Owners.
- Summary: One definition that can be used: a Business Analyst is someone who analyses change requirements and produces a justifiable set of analysis deliverables that are used to design and implement the solution. Justification:Did you know that there is no standard, definitive and agreed definition of what a Business Analyst is? That means not only does the profession have no recognised industry standards or an agreed definition, there is also no binding definition of a set of qualifications or standards that all Business Analysts must adhere to. And that means that Business Analysts: can be all things to all people can define their own role should define their own role so that they have an answer for anyone who tries to dump unassigned tasks in to the remit of a Business Analyst in (for example) your organisation – i.e. you! “Business Analyst” – let’s deconstruct (analyse!) the term. 1. “Business” – no, we are not going to define “business”, but we are going to challenge why Business Analysts are called Business Analysts. Apart from working in businesses, don’t Business Analysts also do their work in local and central government, charities, non-governmental organisations, and so on? The term “Business” in “Business Analyst” may have come about in the 1980s when Systems Analysts (who pre-date Business Analysts) declared that they were starting to get engaged in activities not related to Systems Analysis. If they were not analysing systems, what were they analysing? Their answer was “Business”. However, a more descriptive answer would be "they analyse requirements for change". Based on that the role would be more accurately described as “Change Requirements Analyst” but as the name “Business Analyst” has stuck we will continue with that title. 2. “Analyst” – someone who analyses. “Analysis” then is the important definition. Here's how three sources define "analysis" Internet: an investigation of the component parts of a whole and their relations in making up the whole Oxford English Dictionary: a detailed examination of the elements or structure of something. the separation of something into its constituent elements — ORIGIN Greek analysis, from analuein ‘unloose.’ Merriam-Webster dictionary: separation of a whole into its component parts a: the identification or separation of ingredients of a substanceb: a statement of the constituents of a mixture a: proof of a mathematical proposition by assuming the result and deducing a valid statement by a series of reversible steps b(1): a branch of mathematics concerned mainly with limits, continuity, and infinite series (2): calculus 1b a: an examination of a complex, its elements, and their relations b: a statement of such an analysis a: a method in philosophy of resolving complex expressions into simpler or more basic ones b: clarification of an expression by an elucidation of its use in discourse the use of function words instead of inflectional forms as a characteristic device of a language So analysis is all about breaking a problem down to its component parts to expose the logical inter-relationships between them. The ‘problem’ being analysed is the change requirements for a project. We ‘break the problem down’ so we can prove that all the components are actually required. We analyse change requirements (break them down to their component parts) and prove that each and every requirement is necessary in order to deliver the project. And once armed with all these provable facts about the project, new requirements can be derived from the existing facts. This is where the business analyst really creates value for the project as they discover new requirements that no-one had ever thought of, or realised must exist, based on the current project definition. Summary: Business Analyst = someone who analyses change requirements and produces a provable set of analysis deliverables that are used to design and implement the solution. …and here are a few things Business Analysts are not (although none of these roles can function well without an effective Business Analyst producing high quality analysis deliverables!): Project Managers Systems Analysts Designers Coders Testers Implementers
- Although deductive analysis is always preferably but as analysts we need to recognise that the vast majority of the time we can only analyse inductively, hence the value in checking and verification of our analysis – inductive analysis is not as rigorous or reliable as deductive so it needs checking.
- We have barely scratched the surface of the shrink-wrap on the subject of business analysis. In order to do some kind of analysis that gives a conclusion we can justify (at least!) or prove (rare but best!) then we need to be thinking about… …argumentation theory: how the two sides of an argument are formed, how they can be resolved, the tools, techniques and challenges in conducting an argument (not the stand up row sort, but the logical, presenting cases sort). …philosophy: what is this truth that we claim to have analysed for a project? What reality does it have? Are there limitations to it that can inform our analysis? …rhetoric: is a convincing argument a matter of style, of substance, or both? Does the fact that rhetoric affects opinions matter? …opinion: in the logical world of analysis what part could opinions play? Well, have a chat with you subject matter experts and you may find that they are summarising an awful lot of experience and knowledge in to opinions (not for nothing are there such things as medical opinions). Having recognised that, be aware that an opinion expressed by an expert on something they are not expert in may not be worth as much (good doctors are not necessarily good car mechanics!) …communication theories: BAs have a wide group of disparate roles to communicate with…what methods, styles and techniques work best for which groups? These subjects have fundamental impacts on projects that profoundly affect the ability of the BA to be successful in helping projects avoid the pitfalls that mean most end up failing.