Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Ibd Business Analysis & Reporting
Ähnlich wie Ibd Business Analysis & Reporting (20)
Ibd Business Analysis & Reporting
- 1. THE INSTITUTE OF BUSINESS DEVELOPMENT EXECUTIVE CONVERSION COURSE LECTURE SERIES Business Analysis and Reporting Paul Ikele, M.Sc, MBA, FBDI, FBTM
- 2. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 4. The Past – a Dismal Record
- 5. The Present – Still Troubling Nearly ⅔ of all projects fail or run into trouble.
- 14. Traditional Project Team Business Team & End-users IT Architecture Team Test Team Project Manager Business Sponsor Business Analyst Team Leads Test Manager Architect Business Visionary Development Team
- 15. Core Project Team Concept Business Team & End-users IT Architecture Team Test Team Project Manager Business Sponsor Business Analyst Team Leads Test Manager Architect Business Visionary Development Team SMEs
- 18. Business Analyst Career Path Level Proficiency Responsibilities Competencies Strategic Ability to perform strategic tasks with minimal direction Strategic Planning Enterprise Analysis Mentoring Business & IT Strategy Program and Portfolio Mgt. Systems Engineering, BPR, Six Sigma Enterprise Architecture Business Case Development Senior Ability to perform complex tasks with minimal coaching Elicit, Analyze, Specify, Validate, Manage Requirements Business & IT Domains Project & Program Mgt. Systems Engineering, BPR, Six Sigma Requirements Engineering Intermediate Ability to perform simple-to-moderately complex tasks with minimal assistance Elicit, Analyze, Specify, Validate, Manage Requirements Business &/or IT Domain Project Management BPR, Six Sigma Workshop Facilitation Requirements Modeling Associate Ability to perform simple tasks with assistance Scribe Simple models Help Desk support PM/BA Principles BPR, Six Sigma Principles Business Writing
- 21. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 22. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 23. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 24. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 25. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 26. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 27. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 28. BA Role - The Past Elicitation Analysis Elicitation Specification Validation and Documentation Requirements Phase
- 29. BA Role - The Future Enterprise Analysis Strategic Planning Requirements Design Construction Test Deliver Operations and Maintenance Deactivate
- 31. The BA Drives Strategic Alignment Enter New Mkts Increase Quality Grow Market Share Reduce Costs Improve Shopper Experience Certify 1000 Reps Coaching Job-related e-learning Higher Hiring Stds Learning Management System TMM NAITF* In-store Learning Kiosks Content Acquisition Training Policy etc. DB Boxes Apps etc. Certificate Process
- 33. Business Solution Value Cost to Develop, Operate and Retire the Solution Business Value Deployment Value = Benefits – Costs to Develop, Operate, Retire Project Costs
- 37. Requirements Analysis Process 2. Decomposing requirements 4. Studying and assessing requirements feasibility 5. Prioritizing requirements 1. Modeling requirements 3. Confirming Scope
- 43. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 44. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 45. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 46. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 47. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 48. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 49. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 50. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 51. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 52. Critical Thinking Methodology Develop Alternative Solutions Assess Implications Compile Action Plan Find Root Cause(s) Select Problem Identify Issues
- 56. Use Cases Case user Tyner Blain: Use Cases
- 57. Swim lanes Actor 1 Actor 2 Actor 3 Actor 4 Verb/noun Binary decisions Activity level participants Boundaries Hand-over Begin and end in same lane
- 58. Context diagrams Information flow External Internal Drilling down Context Boundary
- 59. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 60. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 61. THE INSTITUTE OF BUSINESS DEEVELOPMENT
- 62. THE INSTITUTE OF BUSINESS DEEVELOPMENT
Hinweis der Redaktion
- Verification and Validation Unit 1: Key Concepts The Standish Group’s 2004 Third Quarter Research Report, culminating a decade of that organization’s IT project surveys, shows a reversal of gains that had been evident in recent years: Five percent fewer projects were deemed successful than in 2003; the IT project failure rate increased by 3%, while challenged projects increased by 2%. Source: The Standish Group International, Inc., 2004 Third Quarter Research Report, <http://www.standishgroup.com/sample_research/PDFpages/q3-spotlight.pdf> (20 May 2005), Resolution of Projects.
- Verification and Validation Unit 1: Key Concepts The Standish Group’s 2004 Third Quarter Research Report, culminating a decade of that organization’s IT project surveys, shows a reversal of gains that had been evident in recent years: Five percent fewer projects were deemed successful than in 2003; the IT project failure rate increased by 3%, while challenged projects increased by 2%. Source: The Standish Group International, Inc., 2004 Third Quarter Research Report, <http://www.standishgroup.com/sample_research/PDFpages/q3-spotlight.pdf> (20 May 2005), Resolution of Projects.
- Verification and Validation Unit 1: Key Concepts The New Project Leader: From implementers to business decision-makers It is not enough for executive teams to just select the right mix of projects to achieve their strategic imperatives. Executive teams must also establish organizational capabilities to deliver. Executives must ensure that project teams are capable of contributing to the success of their organization. For project success, several elements are essential: Effective and targeted project management processes, tools, and techniques Appropriate executive decision making at key control gates High-performing teams Exceptional project leadership As programs and projects are launched to realize critical strategic goals, the project manager of strategic initiatives should be looked upon as the executive officer of a small enterprise. Just as a business leader must be multi-skilled and strategically focused, a project leader must possess a broad range of knowledge and skills including competence in: Technical areas of the project, Project management, People management, Team building, General management (e.g., marketing, finance), Organizational behavior, Political maneuvering, Change management, Strategic alignment, Conflict management, Negotiating, Communications
- Verification and Validation Unit 1: Key Concepts Strategic planning focuses the executive team on the organization’s reason for being. The formal strategic planning document usually defines the vision, mission, guiding principles, values, and objectives of the organization. To drive from vision to strategy, executive teams build strategic plans consisting of initiatives or programs. The strategic focus of the organization serves as the foundation to select and prioritize programs and projects - and to manage changes to the portfolio of projects as the competitive landscape changes, or the business case no longer justifies the project. Note : While it is noted here that the executive team performs strategic planning, it is not only their responsibility. Strategic planning needs to occur at all levels in the organization (e.g., the organization level, the department level, the project level, and even at an individual level). Thus, everyone is responsible to some degree for strategic planning . Note : A project portfolio is a collection of projects co-managed under the same management umbrella. The project portfolio may be at the organizational, departmental, program, or project manager level. We will use this term synonymously with the term program (a group of related projects managed in a coordinated way).
- Verification and Validation Unit 1: Key Concepts The two key roles that this workshop will focus upon include: Project manager – The person assigned by the performing organization to achieve the project objectives. Business analyst – The person responsible for identifying the business needs of their clients and stakeholders to help determine solutions to business problems. As IT’s role moves beyond efficiency to business effectiveness, the business analyst becomes the central figure on the project team who is “bi-lingual” – i.e., speaks both business and technical languages.
- Verification and Validation Unit 1: Key Concepts The two key roles that this workshop will focus upon include: Project manager – The person assigned by the performing organization to achieve the project objectives. Business analyst – The person responsible for identifying the business needs of their clients and stakeholders to help determine solutions to business problems. As IT’s role moves beyond efficiency to business effectiveness, the business analyst becomes the central figure on the project team who is “bi-lingual” – i.e., speaks both business and technical languages. A
- Verification and Validation Unit 1: Key Concepts Refer to the Supplemental Materials section, 1-1 for a more comprehensive depiction of the Business Solutions Life Cycle.
- Verification and Validation Unit 1: Key Concepts Refer to Supplemental Materials : The Business Analyst: The Pivotal IT Role of the Future and the Business Solution Life Cycle graphic. Discussion: What happens during each phase? What deliverables are produced during each phase? What phases is the business analyst involved in? What happens during the requirements phase?
- Verification and Validation Unit 1: Key Concepts The BA manages business benefits by: Preparing project business case to invest in the most valuable projects Ensuring that the business case remains viable and continued investment in the project is still warranted during the project Measuring business benefits based on new solution - Actual benefits that are achieved vs. benefits promised in the business case
- Verification and Validation Unit 1: Key Concepts
- Verification and Validation Unit 1: Key Concepts Capacity = Maximum # of Successful Projects. Gained Benefits = Ability to Deliver Successful Projects When Managing to Capacity With the unmanaged portfolio, eventually you will be taking on more and more projects, reducing quality, and all of your projects will fail or implode. You will be putting out fires and not performing the work on the projects that are important to the organization.
- Verification and Validation Unit 1: Key Concepts Models are logical or functional representations of a system, and therefore are representations of business or functional requirements. They are usually graphical in nature, and represent the system from the perspective of whatever is moving through it. Decomposing requirements to restate and clarify them. Confirming project scope through interaction with key project stakeholders and users to ensure that the project will satisfy the need for which it was funded. The goal is to reduce requirement risks through early validation prototyping techniques. Assessing requirements feasibility by analyzing requirement risks and constraints, and modifying requirements to mitigate identified risks. The goal is to reduce requirement risks through early validation prototyping techniques. Prioritizing requirements to reflect the fact that not all requirements are of equal value to the business. Then, perhaps, lower priority needs can be addressed in a later system release.
- Verification and Validation Unit 1: Key Concepts Purpose of Requirements Analysis: Documentation of requirements for development Confirmation that scope is feasible Validation that project meets user needs Prioritization of requirements Reduction of project risks Progressive clarification of requirements
- Verification and Validation Unit 1: Key Concepts A model is a representation of the solution or a solution component. A model is used to depict a process, investigate risk, or to evaluate an attribute, such as business reengineering models (process), technical feasibility models (risk), and physical fit models (attributes). Models may be physical or computer-based. Software models are constructed to prove or demonstrate technical feasibility. Reference: Hal Mooz, Kevin Forsberg, and Howard Cotterman, Communicating Project Management: The Integrated Vocabulary Of Project Management And Systems Engineering (Hoboken, NJ: Wiley, 2003).
- Verification and Validation Unit 1: Key Concepts In making the argument that modeling actually occurs in a more iterative manner rather than in tidy, linear phases, Ambler presents eight Agile modeling categories. Refer to Supplemental Materials: Phases Examined: Why Requirements, Analysis, and Design No Longer Make Sense. Reference: Scott W. Ambler, “Phases Examined: Why Requirements, Analysis, and Design No Longer Make Sense,” “Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation,” Ambysoft, Inc., <http://www.agilemodeling.com/essays/phasesExamined.htm> (accessed June 7, 2005).
- Verification and Validation Unit 1: Key Concepts Requirement specifications are elaborated from and linked to the structured requirements, providing a repository of requirements with a completed attribute set. Through this process of progressive elaboration, the requirements team often detects areas that are not defined in sufficient detail, which unless addressed can lead to uncontrolled change to system requirements. Requirements are specified in either an enterprise requirements tracking system or the business requirements document (BRD). Note: This is not the software specification which is a deliverable of the design phase. Reference: Karl E. Wiegers, Software Requirements (Redmond, WA: Microsoft Press, 2003), 489.
- Verification and Validation Unit 1: Key Concepts After the elicitation and analysis phases, the BA will begin providing additional specificity to define system behavior. This increases the amount of information to be tracked by the project team. Reference: Dean Leffingwell and Don Widrig, Managing Software Requirements: A Use Case Approach (Boston: Addison-Wesley, 2003), 144.
- Most writers emphasise the use of a structured process in solving problems. O’Dell says that there are periods of divergent thinking (generating alternatives) and convergent thinking (selecting from these alternatives) throughout the process. He stresses the importance of distinguishing divergent and convergent phases so that judgement is suspended and ideas can flow during the divergent phases. The steps in the process depicted above, could be described as follows: Identify Issues: Divergent Select Problem: Convergent Find Root Cause(s): Divergent Develop Alternative Solutions: Convergent on the previous step/Divergent for the following step Assess Implications: Convergent Compile Action Plan: Convergent The diagram depicts a process for problem solving that compares with various problem solving approaches, e.g. Kepner-Tregoe’s ‘Analytic Trouble Shooting’ approach is powerful for the rigour of the approach, focusing both on ‘what is’ and ‘what is not’ the problem; it is however not as powerful at idea generation, but focuses rather on defining and correcting the cause of a problem. The Theory of Constraints incorporates cause-effect analysis that is displayed in ‘Current Reality Tree’, ‘Evaporating Cloud’ and ‘Future Reality Tree’ diagrams. Hubert Hill’s ‘Combined Approach’ to problem solving incorporates three different types of problem solving, i.e. design, control and research. Elements of Nickols’ writing on problem solving refers to problem solving ‘bases’ that can be selected and combined into different configurations depending on type of problem to be solved. The ‘4-diamond model’ described by O’Dell, overlaid with phases of divergent and convergent thinking. (Refer to American space pen vs Russian pencil)
- Issues may be identified from existing reporting/measures, from a specific diagnostic/ health check analysis, or from a brainstorming session. A list of issues can be structured/grouped together using the Critical Thinking Tool. The structure is then evaluated using the voting mechanism in the Tool, and restructuring the diagram. The objective of this step is to determine a structured list of potential problems.
- The next step is for users to select the problem for analysis by using the voting mechanism in the Critical Thinking Tool. (The appropriate issue may also be selected through discussion, consensus or decision making. Further analysis may also be necessary, e.g. Pareto Analysis.) It may also be necessary to prioritise/select the problem by first analysing the implications of every problem to assess the relative importance/impact of each problem in turn. The Critical Thinking Tool is also useful for doing this.
- Once a problem has been selected/identified, the root causes can be defined. This approach is appropriate where a problem is a ‘deviation from a standard or expectation’, i.e. a process/system/item is not meeting previous requirements or new requirements have been set. (The process for designing to a particular end state is dealt with later.) The objective of this step is defining and validating the root causes of the problem. During this process it is important to adhere to the requirements of clarity, validity and causality: Clarity refers to the use of well-defined statements that other participants can understand; a simple rule to adhere to is to use full statements Validity implies testing whether the statement is true or correct, and voting accordingly Causality means that the cause-effect relationship must be sound (logical and true), that single statements must be used to support simple causality, and that pre-defined solutions are to be avoided in favour of following the logical chain of cause and effect. Root cause analysis is at the heart of problem solving. Finding a root cause often leads to the solution immediately, without further analysis. Health care provides many interesting examples of the need for root cause analysis. Primary health care has often been accused of treating symptoms rather than causes. Effective health care generally requires the assessment of symptoms (what’s wrong; how does deviation from the expectation/standard present itself), and then determining the root causes. In recent years there has been a lot of focus on the impact of stress/lack of exercise/insufficient diet/genetic make-up/etc. on our health. In 1999 Dr. Gui Xien was invited by a colleague to diagnose a mysterious disease in the remote peasant villages of China’s Henan province. It turned out to be the first diagnosis of AIDS in what was to become known as China’s AIDS villages. How had this disease come to infect to such an extent poor rice farmers who scrape by and rarely leave their remote villages? The cause was traced back to a government sponsored blood donation programme in the 1980s to replenish dwindling blood bank supplies (which had also supplemented farmers’ meagre incomes.) The needles used (sometimes by middlemen) were not always sterile. After initial resistance from the provincial officials, Gui sent his report to the central government. They treated it seriously and enforced government involvement. In such cases, understanding the cause is important to manage the outbreak and to prevent recurrence. Fighting malaria is difficult for 2 reasons – the biological complexity of the parasite, and the reluctance of drug companies to put money into (mostly) poor victims. Understanding this must be partly the reason for the Gates Foundation involvement in sponsoring vaccine trials. A Chinese virologist, Dr. Guan Yi, is credited with preventing a second SARS outbreak by tracing the virus back to civet cats being sold in wild animal markets. (They were culled.) More recently, stem cell research is leading to a shift in thinking about how we treat cancer – until now the focus has been on treating malignant tumors, but the latest thinking is that new cancer treatments should target the root cause of tumors, i.e. cancerous stem cells, rather than focusing on the resulting cancerous growth.