Basics of Business Analysis.pdf (tham khao)
- 1. Basics of Business Analysis A two day course presented by Haydn Thomas and Lauren Healey CSU Project Service Centre April 2008
- 2. Course Objectives COURSE OBJECTIVES Understand the importance of business analysis to CSU Familiarise with business analysis principles Develop business analysis skills Obtain a framework for business analysis
- 3. Day 1 B/ Business Analysis and the CSU Context 1/ Understanding the Business Need & Strategic Direction 2/ Planning & Coordinating the Requirements development process 3/ Collecting Requirements 4/ Formulating Requirements 5/ Ensuring Shared Understanding of Requirements D/ Review & Improve C/ Project or Improvement Control A/ Introduction – Business Analysis & You
- 4. Business Analysis V Not required to have expertise in any area Lateral thinking – involving the bigger picture Apply structured processes Business Expertise Subject matter expertise in specific business areas Operational focus rather than big picture thinking
- 6. Exercise
- 7. 1. Business Analysis and the CSU context
- 8. Continuous Improvement at CSU Examples of individual views Maintenance & Basic Operation Continuous Improvement (everyday work & / or projects) Innovation Operational Staff Maintenance & Basic Operation Continuous Improvement (everyday work & / or projects) Innovation Senior Management
- 9. Continuous Improvement at CSU Example of an enterprise view Innovation Continuous Improvement (formal projects & informal projects) Operational Staff Senior Management CSU Position Level Effort / Time Enterprise View Maintenance & Basic Operation
- 10. Continuous Improvement at CSU We all have to get from „AS IS‟ > „TO BE‟ somehow... TO BE AS IS
- 11. Continuous Improvement at CSU ...and we all need to think about the same things...what, who, why, etc... ...but which path will maximise the quality of the „TO BE‟ situation...? WHO WHAT WHY WHERE HOW WHEN AS IS TO BE
- 12. Continuous Improvement at CSU The CSU Project Service Centre Project Lifecycle / Project Management Framework is an example of a project path to improvement
- 13. Project Phases & Effort
- 14. P PLAN I IMPLEMENT R REVIEW I IMPROVE W H E R E W H E N W H Y HOW W H A T WHO Continuous Improvement at CSU The Plan Implement Review Improve (PIRI) Cycle is based on a continuous improvement approach to AS IS > TO BE
- 15. Business Analysis & Continuous Improvement Business analysis is a mindset that focuses on... BUSINESS ANALYSIS WHO WHAT WHY WHERE HOW WHEN
- 16. A Business Analysis Framework ...and involves a set of activities designed to achieve a quality outcome. WHO WHAT WHY WHERE HOW WHEN Plan the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation Formulate how requirements will be implemented Formulate requirements Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 17. So - in short… Business analysis is the conduit between the requested outputs of a project / improvement and the solution created to address the identified need. WHO WHAT WHY WHERE HOW WHEN AS IS TO BE BUSINESS ANALYSIS
- 18. The PSC Needs Hierarchy depicts the relationship between the business needs which business analysis addresses
- 19. So – whether a project framework or continuous improvement cycle is used to achieve „TO BE‟, it is important that business analysis is undertaken to maximise the quality of the „TO BE‟ situation. OR PIRI CONTINUOUS IMPROVEMENT CYCLE PSC PROJECT LIFECYCLE FRAMEWORK
- 21. WHY AS IS TO BE
- 22. HOW WHO WHAT WHY WHERE HOW WHEN Plan the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation Formulate how requirements will be implemented Formulate requirements Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 23. B/ Project or Improvement Control The Control Kit provides a means of managing the project / improvement It also provides team members with a one-stop shop for information CONTROL KIT TEAM MEMBERS DOCUMENT CONTROL & LOCATION ISSUES & RISKS REGISTERS MEETING MINUTES SCOPE CHANGE CONTROL ACTION LISTS A RISK is something that MAY happen An ISSUE is something that HAS happened AND NEEDS TO BE ADDRESSED
- 24. 1/ Understanding the business need and strategic direction WHO WHAT WHY WHERE HOW WHEN Plan the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation Formulate how requirements will be implemented Formulate requirements DEFINITION Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 25. The Needs Hierarchy | Business Need Definition
- 26. WHO | Stakeholders Stakeholder Maps are a simple method to identify who needs to be involved in a project or improvement It is a living diagram which should be revisited throughout the life of the project or improvement http://www.csu.edu.au/staff/yo urcsu/who_stakeholders.html MORE INFO yourCSU
- 27. Exercise Service Providers / Enablers | Provides resources and support mechanisms to enable the product delivery Partners | Partners include those that are jointly engaged in the delivery of the product BUSINESS ANALYSIS TRAINING Governance | the systems and processes in place for ensuring proper accountability and openness in the conduct of the University‟s business. Customers | Recipient of a product output (service, product, information)
- 28. 2/ Plan the Requirements Development Process WHO WHAT WHY WHERE HOW WHEN Plan the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation Formulate how requirements will be implemented Formulate requirements DEFINITION Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 29. Steps in the Interview Process
- 30. Requirements are the basis on which potential solutions are assessed SO – If requirement specifications are inaccurate or incomplete there is little chance the solution will be what the business needed WHY Why is it so important to plan the requirements development process?
- 31. HOW Based on the information contained in the „definition‟, plan how you will gather the information you will need to specify the requirements that a solution must satisfy.
- 32. WHAT | Interview or Workshop? Interview when: • requirements are detailed • requirements cover many areas of knowledge that have specific individuals who are the experts • differing opinions are likely or are sought Workshop when: • requirements are high level • requirements are focused on one area of business in which the participants have knowledge • consensus is being sought • All stakeholders are available Remember – be aware of your objectives
- 33. Workshop Preparation WORKSHOP PREPARATION ENSURE STAKEHOLDER REPRESENTATION DETERMINE EXPECTED OUTCOMES RESEARCH BACKGROUND INFORMATION SET AN AGENDA SET OBJECTIVES SET ANY PRE-READING APPROPRIATE LOCATION / VENUE
- 34. 3/ Gather Information WHO WHAT WHY WHERE HOW WHEN Plan and coordinate the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation FUNCTIONAL REQUIREMENTS Formulate how requirements will be implemented REQUIREMENTS Formulate requirements DEFINITION Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 35. Steps in the Interview Process
- 36. Exercise
- 37. Interview Techniques INTERVIEW TECHNIQUES IDENTIFYING SIGNIFICANCE THE 5 WHYS CLOSED QUESTIONING PARAPHRASING OPEN QUESTIONING PROBE QUESTIONING THE MAGIC QUALIFIER THE 6 INTERROGATIVES
- 38. Open Questioning To initiate discussion on a broad subject and to encourage a comprehensive explanation use clear, direct phrasing that asks a single question ask how, what or when So what do you enjoy about the role? Are there any other issues I should be aware of?
- 39. Closed questioning Use a closed-ended question to elicit a specific reply such as yes/no, a simple piece of information or a selection from multiple choices. Is the new form better or worse than the old form? Is it Mary or Jane who enter the application details?
- 40. Probe questioning Probe questioning involves asking for more detailed information to clarify a vague state phrase such as „quite high‟ or „often late‟. Probe questioning needs to be balanced with open and closed questioning to avoid the interview seeming like an interrogation. How frequently does that happen? How did that change impact your division?
- 41. Paraphrasing is a technique used to confirm or clarify something the interviewee has said or implied. Executed properly it can also build rapport by showing you in alignment with their thoughts and feelings. Paraphrasing
- 42. The 6 Interrogators “I keep six honest serving men (They taught me all I knew); their names are What and Why and When and How and Where and Who.” ...Rudyard Kipling. WHO WHAT WHY WHERE HOW WHEN
- 43. The 5 Whys Moving from symptom through to root cause The goal of applying “The 5 Whys” method is to get to the cause / effect relationships underlying a particular problem SYMPTOM 1/ WHY? ROOT CAUSE 2/ WHY? 3/ WHY? 4/ WHY? 5/ WHY?
- 44. The Magic Qualifier Specifically… To elicit better quality information add this word to the question. Specifically how do you approve the application? We then approve the application...
- 45. Identifying Significance To determine overall significance: Ask what is important to you in ABC? To determine relative significance: Ask which is more important to you – X, Y or Z?
- 46. Be aware of... ...to ensure information is captured accurately and completely YOUR INTERVIEWEE LISTENING COMMUNICATION BARRIERS FILTERING BE AWARE OF
- 47. Be aware of your interviewee & adjust your style ASSUMING KNOWLEDGE TOO FAMILIAR WITH THE JOB A NON-TALKER EXAGGERATING NERVOUS HOSTILE PROTECTING OTHERS PRO- ESTABLISHMENT
- 48. Filtering occurs when the receiver of a message alters its interpretation by applying certain influences or biases. The consequence of filtering is misunderstanding which can lead to an unexpected response. Be aware that just because a message has been sent does not mean it has been received and interpreted as expected. Has the document been completed? Yes the document has been completed Has the document been approved? Yes the document has been written Be aware of filtering
- 49. Exercise
- 50. Common Areas Which Cause Filtering COMMON CAUSES OF FILTERING SITUATIONAL FACTORS ETHICS WORKPLACE CULTURE KNOWLEDGE- BASE ASSUMPTIONS SEMANTICS EMOTIONAL FACTORS ORGANISATIONAL STATUS
- 51. Be aware of communication barriers i.e. obstacles that restrict effective communication COMMON CAUSES OF COMMUNICATION BARRIERS PREJUDICES EMOTIONAL SENSITIVITY ABSENCE OF APPROPRIATE CHANNELS MANAGEMENT BY MEMO HIDDEN AGENDAS INFORMATION WITHHOLDING BACKGROUND NOISE / CLUTTER GEOGRAPHICAL SEPARATION
- 52. Exercise
- 53. The goal of active listening is to improve mutual understanding. Use non-verbal cues such as head nods to show you are listening. Do not internally prepare the next question while the interviewee is speaking Listen for emotions and attitudes as well as facts Do not interrupt unless you sense avoidance or the interviewee has drifted Request clarification, paraphrase and ask follow on questions Be aware of listening True listening involves mutual understanding
- 54. Steps in the Interview Process
- 55. Interviews are exceptionally rich sources of information. However, no two interviewees are alike: some tend to ramble, others are suspicious and curt, some will need only the slightest encouragement to speak their minds, while others will have to be guided along. The interviewer’s job is to conduct the interview to gather the information required, which takes skill, practice and structure. Once you have concluded your interviews, they must be summarised to yield the ‘big picture’. Your questions should therefore allow for valid comparison and summarisation of your interviewee’s viewpoints. Interview Execution
- 56. Interview Review Write up notes as soon as possible after the interview KEY FINDINGS ACTIONS GAPS IN INFORMATION EMERGING THEMES INTERVIEW NOTES DECISIONS
- 57. Workshop Execution Have a „Parking Lot‟ Publish outputs for review & comment Make it participative Have a Glossary of Terms SOME TIPS FOR HOLDING A WORKSHOP Understand the next steps
- 58. 4/ Formulate Requirements WHO WHAT WHY WHERE HOW WHEN Plan the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation Formulate how requirements will be implemented REQUIREMENTS Formulate requirements DEFINITION Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 59. The Needs Hierarchy | Requirements
- 60. Requirement Criteria If requirements do not fulfil these criteria further information must be sought SPECIFIC / UNIQUE MEASURABLE REQUIREMENT CLASSIFIABLE Clearly states what is required To confirm when it has been met Mandatory, important or nice to have
- 61. What should be included in a requirement? ID # Project Requirement Title Description Areas Impacted Level of Importance Mandatory, Important or Nice to have Verification Objective 1. Card deactivation Be able to deactivate lost/stolen security cards. Security Mandatory Deactivate a test card and then test that a transaction cannot be completed with the card. 3.Security 2. ... ... ... ... ... ...
- 62. 5/ Ensure Shared Understanding of Requirements WHO WHAT WHY WHERE HOW WHEN Plan the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation Formulate how requirements will be implemented REQUIREMENTS Formulate requirements DEFINITION Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 63. Process for Agreeing Requirements & Sign Off TEAM OWNER REQUIREMENTS REVIEW ATTEMPT TO REACH CONSENSUS SIGN OFF REQUIREMENTS SIGNED OFF CONSENSUS ESCALATE DECISION/S REFLECTED IN REQUIREMENTS REQUIREMENTS AMENDED MAKE DECISION/S RE REQUIREMENT/S REQUIREMENTS REVIEW RECOMMENDATION/S ARTICULATED ACCEPT UPDATED REQUIREMENTS YES NO NO YES SIGN OFF NO YES
- 64. Reaching Consensus 1/ IDENTIFY AREAS OF AGREEMENT & CLEARLY STATE DIFFERENCES State positions and perspectives as neutrally as possible Document a summary of concerns 2/ FULLY EXPLORE DIFFERENCES Explore each perspective and clarify Involve everyone in the discussion – avoid one-on-one debates Identify common ground and attempt to develop a compromise 3/ REACH CLOSURE AND ARTICULATE THE DECISION Ensure all team members have expressed their perspective Detect when the team is approaching consensus Ask each member if they agree and will they support the decision Document the decision
- 65. Review & Improve – Wrap Up Day 1 Review Objectives Feedback What‟s in store for Day 2?
- 66. Day 1 B/ Business Analysis and the CSU Context 1/ Understanding the Business Need & Strategic Direction 2/ Planning & Coordinating the Requirements development process 3/ Collecting Requirements 4/ Formulating Requirements 5/ Ensuring Shared Understanding of Requirements D/ Review & Improve C/ Project or Improvement Control A/ Introduction – Business Analysis & You
- 67. Course Objectives COURSE OBJECTIVES Understand the importance of business analysis to CSU Familiarise with business analysis principles Develop business analysis skills Obtain a framework for business analysis
- 68. Day 2 B/ Review & Improve 6/ Formulating How the Requirements will be Implemented 7/ Ensuring Operational Acceptance of Implementation A/ Business Analysis Tools & Techniques
- 69. Course Objectives COURSE OBJECTIVES Understand the importance of business analysis to CSU Familiarise with business analysis principles Develop business analysis skills Obtain a framework for business analysis
- 70. 6/ Formulate how requirements will be implemented FUNCTIONAL REQUIREMENTS WHO WHAT WHY WHERE HOW WHEN Plan the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation Formulate how requirements will be implemented REQUIREMENTS Formulate requirements DEFINITION Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 71. Defining the solution There is always more than one solution that can potentially meet the requirements Hence it is important to assess the alternatives to determine the best solution
- 72. The Solution Process Build your own Predefined solution Investigation of others Request for Information (RFI) Request for Proposal (RFP) A solution process could involve one or many of the following:
- 73. Problem Solving Techniques Can be used for: identifying and developing a solution recommendation based on the business requirements resolving issues addressing risks general problem solving
- 74. Solution Identification 1/ IDENTIFY POSSIBLE SOLUTIONS Generate multiple possible solutions, e.g. brainstorm Do not filter out potential solutions Then: consider/refine each idea to see how it could meet requirements 2/ ASSESS THE POTENTIAL SOLUTIONS Shortlist the feasible potential solutions Determine the criteria to be used to assess the solutions incl. impact on other areas of the business and level of risk Apply weightings to the criteria Rate each solution against the weighted criteria
- 75. The Do and Don’t of Problem Solving Don’t: Make assumptions Jump to conclusions Promote one solution without evaluation Allow a group with one specific area of expertise to propose solutions Attempt to solve the problem in isolation Do: Clearly state the problem Identify several solutions Assess potential solutions based on real or agreed requirements Ensure that business users accept the proposed solution Consider the big picture and the context
- 77. The Needs Hierarchy | Functional Requirements
- 78. Functional Requirements Translating requirements into specifications for the solution PROCESS FUNCTIONS BEHAVIOURS
- 79. Who should develop functional requirements? The team plus input from stakeholders and process owners Who uses functional requirement information? WHO All stakeholders with a responsibility for building, developing, delivering and/or maintaining the solution including external vendors
- 80. A Typical Functional Requirement Functional Requirement 1 Requirement Cross Reference: cross-references / describes which requirement/s this functional requirement addresses Business Rule Cross Reference: cross-references / describes which business rule/s constrain this functional requirement Name Name of the functional requirement Detail Definition Definition of the functional requirement Preconditions List conditions that must exist or be established before the functional requirement can occur Inputs List inputs required for this functional requirement Outputs List outputs required for this functional requirement Formulas List formulas and calculations required Triggers/Interfaces List internal/external triggers and interfaces and their data requirements Volume/Frequency Describe anticipated volume for all interfaces, e.g. approx. number of users, critical time periods Printing Requirements List printing requirements (if any) by volume, type, time and period Main Scenario – Tasks / Sub Functions List step by step the necessary main tasks and sub-functions Extensions List the necessary sub-functions outside of the main scenario, i.e. if ABC occurs, XYZ must occur Test Verification How the functional requirements will be verified
- 81. 7/ Ensuring operational acceptance of implementation FUNCTIONAL REQUIREMENTS WHO WHAT WHY WHERE HOW WHEN Plan the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation Formulate how requirements will be implemented REQUIREMENTS Formulate requirements DEFINITION Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 82. Business Analysis | Testing Activities Business analysis can assist in: Determining how the solution will be tested by its users to attain their acceptance of it, e.g. take early screen design concepts back to users for feedback Developing complete and detailed user acceptance tests (UATs) which reflect the Functional Requirements Helping users to understand the needs of UAT and their responsibilities in the UAT process Ensuring user acceptance testing is completed satisfactorily prior to implementation including resolving UAT issues
- 83. Testing | WHY, WHEN & WHAT WHY test? To ensure that a project delivers what is expected and has been agreed Is a means of identifying defects introduced during the development lifecycle WHEN does testing happen? From the beginning of the construction phase to the end of testing (refer to PSC Project Lifecycle) WHAT are some types of testing? Unit Systems Regression Integration User Acceptance Destructive
- 84. Business Analysis | Training Activities Business analysis assists in training activities by: Producing the training strategy to determine how the users of the solution will be trained Facilitating training preparation & delivery (but not necessarily providing the actual training) Ensuring training is provided Measure training effectiveness Training should be provided to users of the solution as necessary to facilitate the implementation of the change.
- 85. Business Analysis | Implementation Business analysis can assist in developing: Implementation strategy Implementation schedule Post Implementation Review (PIR) Business analysis can assist in implementation to ensure that the solution is handed over to the operational area/s successfully and disruption to the existing business during implementation is minimised.
- 86. Business Analysis Tools & Techniques WHO WHAT WHY WHERE HOW WHEN Plan the requirements development process Gather information Ensure shared understanding of requirements Ensure operational acceptance of implementation Formulate how requirements will be implemented Formulate requirements Understand the business need and strategic direction BUSINESS ANALYSIS FRAMEWORK
- 87. Context Modelling Context diagrams are used during the business need „definition‟ stage to provide a high-level visual model of the project / improvement It serves as a view of the business solution to be built, and identifies the entities that will interface with the solution They assist in understanding / agreeing the scope under review
- 90. Business Systems Context Diagram Asset Register BANNER HR (Alesco) Other University Systems Asset Management System GIS (Grounds information ) BEIMS (Bldg maintenance) Bldg Functionality & Condition Assessment Room Mgmt (Res & Catering) Space Mgmt Portfolio KPI’s Ad Hoc reports Benchmark reports Legend Provides some source data for fixed asset objects. Output Two way interaction Timetabling CAD (Bldg information ) Scope Project Idea/Goal: Identify a suitable Asset Register software solution . Appendix C Asset Management Project - Business View The Asset Register: * its relationship within an Asset Management System ; and * how it will Interact with other CSU Applications . Service Desk Comms Directory Bldg Mgmt System Other University Cost Centre Asset Registers Assetpro (Finance)
- 91. Exercise
- 92. Business process modelling (BPM) is a means of representing the steps, participants and decision logic in a business process. The goal of BPM is to articulate a business process to assist understanding and to potentially: Business Processes Improve business processes Re-engineer the business Automate an existing business process
- 93. Business Operation Modelling | WHAT Business operation models are a business analysis technique for breaking down a high level operation and dividing entities into smaller and smaller related parts – or „functional components‟ A business operation model shows a hierarchical organisation of the business processes that comprise the business operation A business operation model is distinct from a process flow diagram which shows the sequence of events of a business process
- 95. A large or complex operation is more easily understood when broken down into smaller processes. It therefore facilitates understanding of the business operation and hence is a useful tool in conducting analysis and design. Business Operation Model | WHY
- 96. Business operation modelling is used in determining and defining the functional requirements of a solution It can be used to break up a large or complex business process into smaller components prior to developing process flow diagrams It can also be used during the planning, analysis and design phases to assist in understanding business operations Business Operation Model | WHEN
- 97. Business Operation Modelling | HOW 1/ Identify the boundaries – which business operation is to be broken down 3/ For the operation identify the high level processes which comprise it 4/ Continue to break each process down to lower levels until sufficient meaningful level of detail is achieved 2/ Consult with business experts – the people managing / working with the operation 6/ Draft the business operation model 7/ Review with the experts to ensure completeness 8/ Refine and finalise 5/ Determine the purpose of each function and record for subsequent process flow models
- 98. Process mapping is a technique of diagrammatical modelling. The diagram represents a series of processes and how they are related. Process mapping provides a visual representation of who does what and in what order. Process Mapping | WHAT
- 99. WHY | Process mapping helps to clarify the steps involved in a particular process. WHEN | Use process mapping to: understand the current process clarify responsibilities identify process inefficiencies design new procedures assist in training Process Mapping | WHY & WHEN
- 100. Process Mapping | HOW 3/ Identify the participants – the roles involved in the process 4/ Identify the steps – what is done in which sequence by who 5/ Identify the decision points and the alternate paths 6/ Draft the process flow 7/ Review with the experts to ensure completeness 8/ Refine and finalise 1/ Identify the boundaries – the process beginning and end 2/ Consult with business experts – the people managing/working with the project
- 101. Terminator/Initiator Marks the start and end of a process Process Describes the action Decision Point Always has yes and no streams Related Process Does not detail the process but refers to it Process Mapping | HOW Which shapes to use
- 102. Swim Lane Diagrams | WHAT & WHY WHAT | Each swim lane represents the area of involvement of each participant who has a role in the process being mapped. WHY | Swim lane diagrams assist in identifying all participants involved in the process. „Participants‟ may be an individual, a team, a division/section or an organisation.
- 103. Starting at top left with the start symbol Draw each step along the swim lane and use arrows to represent the sequence Each step should start with a verb A number may be assigned to each step Swim Lane Diagrams | HOW
- 104. Swim Lane Diagrams | HOW When a step is performed by a different participant switch lanes If the next step depends on a decision show this as in the example above, labelling the alternatives and showing the steps that follow
- 105. Swim Lane Diagram Completed example
- 106. Wrap Up Exercise
- 107. Review objectives What will you take away? Feedback Further information sources www.csu.edu.au/division/psc/ www.csu.edu.au/staff/yourcsu/ www.theiiba.org Review & Improve – Wrap Up Day 2
- 108. Day 1 B/ Business Analysis and the CSU Context 1/ Understanding the Business Need & Strategic Direction 2/ Planning & Coordinating the Requirements development process 3/ Collecting Requirements 4/ Formulating Requirements 5/ Ensuring Shared Understanding of Requirements D/ Review & Improve C/ Project or Improvement Control A/ Introduction – Business Analysis & You
- 109. Day 2 B/ Review & Improve 6/ Formulating How the Requirements will be Implemented 7/ Ensuring Operational Acceptance of Implementation A/ Business Analysis Tools & Techniques
- 110. Course Objectives COURSE OBJECTIVES Understand the importance of business analysis to CSU Familiarise with business analysis principles Develop business analysis skills Obtain a framework for business analysis
- 111. Review objectives What will you take away? Feedback Further information sources www.csu.edu.au/division/psc/ www.csu.edu.au/staff/yourcsu/ www.theiiba.org Review & Improve – Wrap Up Day 2