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
- 3. Business Analysis Definition Business analysis helps an organization to improve how it conducts its functions and activities in order to reduce overall costs, provide more efficient use of scarce resources, and better support customers. It introduces the notion of process orientation, of concentrating on and rethinking end-to-end activities that create value for customers, while removing unnecessary, non-value added work. The person who carries out this task is called a business analyst or BA . Wikipedia In other words documenting the Processes within the business 03/23/11
- 4. The Past – a Dismal Record
- 5. The Present – Still Troubling Nearly ⅔ of all projects fail or run into trouble.
- 6. Change is the norm Fierce competition is the driver Lean thinking is the latest call to action Success is the only option Strategy depends on projects The Future – Fierce Competition
- 7. Projects are essential to the growth and survival of today’s organizations Projects create value by responding to changing environment, competition, marketplace to Improve business processes Eliminate waste & drive inefficiencies out of operations Offer new products and services Flow higher value to customers Often business needs can only be satisfied by large change initiatives that have a significant IT component Result: a never-ending demand for new IT systems IT is viewed as a value provider IT is faced with an extraordinary combination of pressures How can we eliminate most of the challenged and failed projects? The Future - IT is at the Heart of Business Strategy
- 8. Executives have their eyes on the IT portfolio to ensure that they: Understand their capacity to deliver Invest in the right mix of projects Develop expert capabilities & optimize their resources Cancel high-risk, under performing projects Deliver flawlessly Flow value through the business to customers The BA role is now about value! Achieve Strategy through Projects
- 9. Can You Relate? How has the past been for you? How critical are the projects you are working on?
- 10. A bridge is built between the business and technical communities The business need is understood before solutions are developed The customer is involved in the project throughout the life cycle Breaking the Cycle of Challenged Projects
- 11. The New Project Leaders are Strategy Executors In the past, PMs were primarily implementers of solutions Narrow orientation focused on technical implementations Skills narrow focused on budget, schedule, specs Role undergoing major transformation due to new business realities Effective project management tantamount to effective business management Skills broadened, encompassing all aspects of business management Business Analyst role professionalizing Project leadership teams emerging
- 12. How Well Do We Execute Strategy? Studies indicate that less than 10% of strategies successfully formulated are effectively executed 85% of executives spend less than one hour per month on strategy 95% of the workforce don’t understand their organization’s strategy 60% of organizations do not link strategies to the budget 70% of organizations do not link strategies to incentives Source: David Norton, Project Balanced Scorecards – a Tool for Alignment, Teamwork and Results . ProjectWorld & The World Congress for Business Analysts Conference Proceedings, November 2005
- 13. Combining disciplines leads to success Business analyst Project manager Business visionary System architect/technical lead Each taking the lead depending on the project needs Determined to break the cycle of challenged projects The Project Performance Partnership
- 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
- 16. A senior position in the enterprise placed either in Business units IT organization As IT moves beyond efficiency to business effectiveness BA becomes the central figure on the project team who is “bi-lingual” – i.e., speaks both business and technical languages Differs from traditional IS analysis in that it focuses almost exclusively on adding value to the business Enter The Professional Business Analyst
- 17. Typical Business Analyst 40 years old Well educated Paid $78K per year Hails from IT More than 5 years experience performing BA functions 36% > 10 years Analysis skills acquired on the job Disturbingly, they report Most of their projects do not deliver all requirements Source: The New Business Analyst : A Strategic Role in the Enterprise, November 2006 Evans Data Corporation Research Study
- 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
- 19. Staffing Surveys Reveal Increasing Demand for Senior BAs Who are Multi-Skilled Technical Analytical Business Leadership Systems engineering concepts and principles Fundamentals of business analysis Business process improvement and reengineering Fundamentals of project management Complex modeling techniques Ability to conceptualize and think creatively Strategic and business planning Capacity to articulate vision Communication of technical concepts to non-technical audiences Techniques to plan, document, analyze, trace and manage requirements Communication of business concepts to technical audiences Organizational change management; management of power and politics Testing, verification, and validation Requirements risk assessment and management Business outcome thinking Problem solving, negotiation, and decision-making Technical writing Administrative, analytical, and reporting skills Business writing Team management, leadership, mentoring, and facilitation Rapid prototyping Cost / benefit analysis Business case development Authenticity, ethics, and integrity Technical domain knowledge Time management and personal organization Business domain knowledge Customer relationship management
- 20. Business Analyst Organizational Placement Level Organizational Placement Strategic Part of an enterprise-wide PMO or center of excellence with a strategic focus Working on pre-project analysis, serving as BA for strategic initiatives, and managing projects for value Senior In IT (67%) The business may not take ownership of problems In BU (10.8%) Difficult for BAs to feel like a “community of practice” and hard to manage BA standards and improvements Intermediate Usually placed in IT Junior Usually placed in IT
- 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
- 30. What do Today’s BAs Really Do? Enterprise analysis Business architecture Opportunity analysis Problem analysis Solution feasibility analysis Business case development Solution assessment and validation Benefits measurement and management Requirements management Planning Elicitation Analysis Specification Validation Change management Communication Organizational change Organizational readiness Organizational change management Business artifacts: business policies, procedures, rules, training, retooling, restructuring
- 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
- 32. Strategic Business Analyst Role: Managing the Business Value During the project life cycle Once projects are funded, they must be managed throughout the project life cycle to ensure that the business case remains valid and continued investment in the project is still warranted After solution delivery Once the project delivers the new business solution, the Business Analyst ensures organizational measurements are in place: Actual benefits that are achieved vs. Benefits promised in the business case For solution enhancements
- 33. Business Solution Value Cost to Develop, Operate and Retire the Solution Business Value Deployment Value = Benefits – Costs to Develop, Operate, Retire Project Costs
- 34. The BA & PM partner to conduct requirements phase planning and to Understand (or create if non-existent) Business vision, drivers, goals and objectives Business needs, environment & constraints Business case, project charter, and scope definition Assemble and educate the requirements team Define the requirements artifacts to be produced (documents, graphs, models, matrices) Develop the requirements management plan Use your PM to help plan requirements activities Requirements Planning
- 35. Discovery Interview management and end users Review current business process, supporting systems, studies Document business problem and opportunity Current Vs. future business architecture Develop/refine current state models (“As Is”) Develop/refine future state models (“To Be”) Scope statement, WBS and scoping models Start with information in the business case Build to clearly defined and approved scope Use Problem Domain (aka Conceptual Domain) models to describe the context in which the business solution will operate Business Planning & Scope Definition
- 36. Conduct requirements gathering sessions with customers, users, and stakeholders Requirements gathering techniques include Requirements workshops Discovery sessions Interviews Surveys Prototyping Note taking and feedback loops to customers, users, and stakeholders Acquire/hone your facilitation skills! Requirements Elicitation and Discovery
- 37. Requirements Analysis Process 2. Decomposing requirements 4. Studying and assessing requirements feasibility 5. Prioritizing requirements 1. Modeling requirements 3. Confirming Scope
- 38. Structure requirements information into various categories Evaluate requirements for selected qualities Represent requirements in different forms Derive detailed requirements from high-level requirements Negotiate priorities Determine function and performance characteristics Define context of implementation Identify stakeholder constraints, measures of effectiveness, and validation criteria Requirements Analysis – The Key Requirements are first stated in simple terms, then decomposed, restated and captured to:
- 39. What is Requirements Modeling? Describes requirement using specialized notation, languages, and symbols Goal: Simplify reality and filter out “noise” Aid understanding of complex systems and processes Provide different views and perspectives on what is important to different audiences Assure that all aspects of problem are considered Translate more easily into solutions Because you have multiple models that you can apply, you need to know their strengths and weaknesses to be effective in their use. Since each modeling technique has its pros and cons, to be effective you will want to have several requirements modeling techniques in your toolkit. Source: Scott W. Ambler 2005
- 41. What is Requirements Specification? Process of documenting a system’s requirements in a structured, shareable, and manageable form Structures functional and supplemental requirements Provides structured requirements repository with attributes specified Source: Karl E. Wiegers, Software Requirements Business Need Written Functional Requirements Graphical Functional Requirements Supplemental Requirements
- 42. The Importance of Requirements Specification The amount of information we must manage increases rapidly as we move lower down the pyramid Prepares for requirements allocation Provides foundation for requirements traceability (ability to follow a requirement forward and backward) Accomplishes cross-referencing of project deliverables Modified from Dean Leffingwell
- 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
- 53. Identify Issues Critical Thinking Methodology – Identify Issues Define problem as undesirable deviation from an expectation or standard Clarify Issues: How manifested/What is result? When does it occur? Frequency? Who is affected? Business Diagnostics/ Health Check Submit/Brainstorm Issues Cluster Issues Check Lists/ Business Measures/ Reporting Structured List of Potential Business Problems Structure in Critical Thinking Tool
- 54. Critical Thinking Methodology – Select Problem Clarify the Problem: How manifested/What is result? When does it occur? Frequency? Who is affected? Select Problem Business Problem Identified Assess/vote using Critical Thinking Tool Structured List of Potential Business Problems Consensus Analysis
- 55. Critical Thinking Methodology – Find Root Cause(s) Find Root Cause(s) Clarity (well-defined statement) Validity (is cause true/correct?) Causality (cause-effect link, single statements, no pre-defined solutions) Validated Root Causes Defined (‘5 Whys’) ‘ What is the cause of…’ Define immediate causes of preceding statements Identified Business Problem
- 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
Editor's Notes
- #5: 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.
- #6: 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.
- #12: 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
- #13: 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).
- #15: 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.
- #16: 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
- #29: 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.
- #30: 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?
- #31: 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
- #32: Verification and Validation Unit 1: Key Concepts
- #34: 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.
- #38: 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.
- #39: 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
- #40: 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).
- #41: 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).
- #42: 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.
- #43: 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.
- #53: 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)
- #54: 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.
- #55: 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.
- #56: 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.