IBD BI MC Business Analysis Tools And Tasks


Published on

IBD Business Intelligence Masterclass Presentation

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Objective: Give overview & establish Critical Thinking Approach as good business practice. Three comments, by way of introduction: The approach does not preclude gut feel and experience Vertical vs lateral thinking We will refer to real examples of problem solving from all spheres of human endeavour, including business. In explaining the methodology and describing the functionality of the Critical Thinking Tool, we will use generic examples.
  • Review terminology – Problem A problem is an undesirable deviation from an expectation or standard. E.g. experiencing a 5% defect rate when the target is 0%; crops are lower than expected; an accident occurs. A desirable deviation would be an outcome that is better than expected/the standard. This is in line with Kepner-Tregoe’s def. of ‘trouble’ in their ‘Analytic Trouble Shooting’ approach. Our process also provides for designing a solution to meet a new need or end state. For example, ERP systems not only help to resolve/eliminate existing process or information management problems, but also create opportunities. E.g. planning, reducing inventory levels, etc. Space exploration opened up new requirements for safety procedures, training requirements, materials with certain properties, etc. (Let team discuss their views of what problems are, with examples.) Problem Solving The scope of problem solving depends on what a problem is. It can refer to fixing what is wrong, making an improvement; designing for a new purpose. See the next slide. Creative Thinking Creative thinking usually refers to a way of thinking that results in unique or ‘out of the box’ solutions. O’Dell says creative problem solving involves the creation of novelty and value. Not all solutions need to be ‘creative’. Some solutions may be obvious or simply follow a logical linear thinking process. Our solutions to the problems we face must however be designed to permanently eliminate the problem. (Refer to de Bono lateral thinking story – Landlord and the Daughter.) Where in race would you like to end? Write ½ of 8 in as many different ways as possible. Systems Thinking Systems thinking refers to a ‘big picture’ perspective of organisations. This implies an understanding of the inter-relatedness of the organisation’s components through its structures and events linked through cause and effect. Therefore, actions taken in one area will have consequences in another. As we shall see, a systems perspective is important to resolving the true causes of problems. (See also Nadler & Hibino – ‘Breakthrough Thinking’) Critical Thinking In general we can describe critical thinking as the thinking process used to evaluate our assumptions. It implies a questioning/critical attitude to the issues we face, the assumptions we make and solutions we come up with. (Critical thinking is required when we make decisions, solve problems or question our assumptions when embarking on new initiatives.) Internationally, companies have reported the benefits of running training programmes in creative problem solving (benefits such as cost savings and time efficiency.) Successful improvement/change/transformation projects normally involve problem solving of some sort.
  • Problem A problem is an undesirable deviation from an expectation or standard. This is in line with Kepner-Tregoe’s definition of ‘trouble’ in their ‘Analytic Trouble Shooting’ approach. Problems have also been defined as having a goal, but not knowing how to achieve it (see Nickols, and also Newell & Simon). This definition broadens the scope of problem solving from - fixing what is wrong, to include - improving an existing system, or designing for a particular purpose. Types of problems Repair - Fix what is wrong (rust resistant stainless steel - Harry Brearly, 1913; punctuation for ease of reading - medieval scribes) - Cause and Effect (e.g. Ishikawa fishbone diagram, TOC) - The Kepner-Tregoe Analytic Trouble Shooting refers to this type of problem Improve - Ongoing improvement; reengineering (e.g. Aqualung - Cousteau & Gagnon, 1943; wind generator for clean power - Palmer Putnam, 1940) - (See also Nadler & Hibino – ‘Breakthrough Thinking’) Design - Meet a new purpose (electric light bulb - J Swan & T Edison,1878; others – ATMs, Internet) - No system/process exists to meet the purpose; existing system does not meet new purpose - Design for an end state/ideal solution (See also Nadler & Hibino – ‘Breakthrough Thinking’). Both Hill and Nickols distinguish three appoaches similar to those described here. O’Dell includes fixing what is wrong as well as ‘creating something to fit a need’ in his definition of problem solving. (See also ‘Appreciative Enquiry’ – building on what is working well.)
  • 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.
  • The inverse of the root causes is the starting point for defining alternative solutions. The question that must be answered at this point is what would be required for the inverse of the root cause(s). The question may be asked in terms of what must be changed (or designed), in what way it must be changed and with what mechanisms it must be changed. The requirements of clarity, validity and causality are still relevant. A famous example of an alternative solution to a problem is the conviction of Al Capone (the prohibition era ganster) for income tax evasion. In 1927 Capone’s wealth was about R27m. He owned breweries, warehouses, trucking companies, night clubs, race tracks and casinos, and was moving into unions and film production. Capone was very generous: he paid strangers’ hospital bills and set up soup kitchens during the depression. Capone is reckoned to have been responsible for up to 400 deaths by delegation and 20 to 60 personal killings. He had 50% of Chicago’s police force and 700 gangsters on his immediate payroll. He had unknown numbers of journalists and politicians on his payroll. No one would testify, and it was impossible to get him on his gangster activities. They got him for tax evasion – no testimony was required; you only had to prove that no tax forms had been submitted. Al Capone was sent to jail for 11 years for not submitting tax forms for 3 years. Discuss the root causes of the problem of getting Al Capone behind bars.
  • The objective here is to evaluate alternatives by assessing the consequences of each solution in turn. This is done by using the Critical Thinking Tool. Clarity, validity and causality must be adhered to. The importance of this step is illustrated by famous examples (even instances where the consequences of solutions may have been assessed, but the results were miscalculated): Coca-Cola changed its recipe to avert the growing threat of Pepsi in the US – this caused significant market resistance; today Pepsi outsells Coke in the US. (The Pepsi-Coke competition is so fierce that at one time Coke’s mission statement was simply Get Pepsi .) Pepsi has also made a similar mistake – they brought out a new Pepsi which flopped. 3M’s production chemists said it could not produce post-it notes (which had been developed by accident), Finance said it would not make money, and Marketing said it could not sell – the post-it note has subsequently become the single biggest product that 3M ever made. In 1948 Remington Rand bought the UNIVAC corporation, who had invented the electronic computer. Remington Rand spent most of their efforts integrating UNIVAC into their large organisation, not realising that they had in their hands the making of an entire new industry. This allowed IBM (starting from nothing in 1950) to thoroughly capture the computer market. In the early eighties, IBM was listed in Peters and Waterman’s In Search of Excellence. By the mid-1980s, IBM had made a similar mistake when MicroSoft entered the market for PC operating systems. In 1830 Edwin Budding invented a napping machine (to finish cloth) – unions and labour prevented its introduction. So he changed his invention into a lawnmower. Sometimes we realise the implications after the fact: John Glenn once said that the most frightening thing about space travel is when you sit on the launch pad and look around you and realise that everything went to the cheapest bidder. Some of the implications to consider involve resistance to change: When the first typewriters went on sale in 1874, some doctors said that using one could make you go mad. In the 1860s a certain Dr. Semmelweis (in Vienna) came up with the novel idea of washing your hands before treating patients. This unpopular idea was implemented and had an almost immediate effect in reducing the death rate amongst pregnant women. When Semmelweis’s contract expired it was not renewed. With his departure the hand washing regulation was discarded. The death toll soared. (Review the difficulties in implementing cross-functional teams, or similar examples requiring change management.)
  • The action steps required to implement the selected solution(s) must be defined and monitored. (The Keepgoing tool may not be required for this.) Implementing a solution may be a simple step or a complex project facing stiff resistance and requiring significant change management. An interesting example of resistance to a solution is the discovery of penicillin by Alexander Fleming in 1928. Penicillin provided a solution for a critical need, but was not used until the Second World War. (In 1940 America entered the war and sponsored its development.) The main reason for this delay was the resistance to injecting people with what is essentially a fungus. The process for implementing a solution may be project specific and is beyond the scope of this discussion.
  • This is a different entry point to identifying and analysing an existing problem. The end state/solved state is defined. This entry point to the process is used when designing for a particular purpose. Refer to American Space pen compared to Russian pencil. Review the purpose of the Al Capone case. Describe Power Profile, its initial objectives and Value Engineering/Value Analysis project.
  • The
  • The inverse of the root causes is the starting point for defining alternative solutions. The question that must be answered at this point is what would be required for the inverse of the root cause(s). The question may be asked in terms of what must be changed (or designed), in what way it must be changed and with what mechanisms it must be changed. The requirements of clarity, validity and causality are still relevant. A famous example of an alternative solution to a problem is the conviction of Al Capone (the prohibition era ganster) for income tax evasion. In 1927 Capone’s wealth was about R27m. He owned breweries, warehouses, trucking companies, night clubs, race tracks and casinos, and was moving into unions and film production. Capone was very generous: he paid strangers’ hospital bills and set up soup kitchens during the depression. Capone is reckoned to have been responsible for up to 400 deaths by delegation and 20 to 60 personal killings. He had 50% of Chicago’s police force and 700 gangsters on his immediate payroll. He had unknown numbers of journalists and politicians on his payroll. No one would testify, and it was impossible to get him on his gangster activities. They got him for tax evasion – no testimony was required; you only had to prove that no tax forms had been submitted. Al Capone was sent to jail for 11 years for not submitting tax forms for 3 years. Discuss the root causes of the problem of getting Al Capone behind bars.
  • This is a training guide for training users in the application of the Critical Thinking Tool and problem solving approach.
  • IBD BI MC Business Analysis Tools And Tasks

    2. 2. WELCOME Who are the Business Analyst and How do they tap into Organization's Potential PRODUCTS PRODUCERS SOLUTION Business Analyst BUSINESS OWNER Liaison among stakeholders to - Elicit, Analyze, Communicate, Validate Requirements To provide recommendation on changes to business processes, policies and information systems. Certified Business Development Analysts. Passionate Business Analyst Performs through-People, Systems, Management and Processes Critical Thinking Is the Investigator, Mediator or Peace Maker, Lobbyist, Trainer, Subject Matter Expert, Leader, Reporter or Communicator ,Consensus Builder, Clairvoyant , Listener, Bridge Builder, Documentor, Reporter, Planner and Methodologist . “ What is a Business Analyst and Role of the Business Analyst “ Business Analyst by BA for BA <ul><li>Set of tasks, knowledge, and techniques used to: </li></ul><ul><li>-Identify business needs </li></ul><ul><li>-Determine solutions to business problems </li></ul>
    3. 3. Scope of Work <ul><li>Enterprises Analysis </li></ul><ul><li>Requirement Planning & Management </li></ul><ul><li>Requirement Elicitation </li></ul><ul><li>Requirement Analysis & Documentation </li></ul><ul><li>Requirement Communication </li></ul><ul><li>Solution Assessment & Validation </li></ul><ul><li>Definition of a requirement: </li></ul><ul><li>- A condition or Capability:. </li></ul><ul><li>- Needed by a stakeholder to solve a problem or achieve an objective. </li></ul><ul><li>- That MUST be met or possessed by a system or system component to satisfy a contact, standard, specification, or other formally imposed documents. </li></ul><ul><li>- That is documented. </li></ul>
    4. 4. Business Analyst Work Division Strategy <ul><li>The Business Analyst work division strategy is a systematic plan of action intended to </li></ul><ul><li>accomplish a specific goal. What are the different methods to divide the activities within </li></ul><ul><li>the group? There are 5 Business Analysts and 72 requirement activities, how will the work </li></ul><ul><li>be divided? What information/knowledge needs to be transferred between the Business </li></ul><ul><li>Analysts to successfully deliver compatible requirements? The strategy is applicable for a </li></ul><ul><li>Business Analyst team where there is more than one member. If there is only one Business </li></ul><ul><li>Analyst assigned to the project, then all requirement activities are assigned to that </li></ul><ul><li>Business Analyst. Within the Business Analyst team, the strategy is to define the work </li></ul><ul><li>division and co-ordinate the information and knowledge transfer among the team </li></ul><ul><li>members. </li></ul>
    5. 6. TASK WORK DIVISION AMONGST A BUSINESS ANALYST TEAM Purpose Dividing the work among the Business Analysts in a team removes obstacles of confusion and uncertainty that can be placed among the Business Analysts and their goals. It defines responsibilities and sets expectations. It clarifies both where the team wants to be and how to get there. Description The team or the lead will decide and implement the most suitable method to achieve their specific goal(s). The task of deciding which Business Analyst in the team is assigned to the requirement activity. . Predecessors The Requirements Activities or Requirements Work Plan Process and Elements The Business Analyst and/or Lead and/or the team review the activities and the duration of the work effort. The Business Analyst and/or Lead and/or the team decide on which strategy or strategies to apply and document the rationale. Based on the decided work division strategy or strategies, the activity is assigned to a Business Analyst, either by another Business Analyst or by team consensus. The task is completed when all the requirement activities are assigned to the Business Analysts. Stakeholders The Stakeholders are the Business Analyst and the Stakeholders associated with the requirement activity. Deliverables The resources (Business Analysts) assigned in the Requirements Work Plan.
    6. 7. Requirement Types <ul><li>Business Requirements </li></ul><ul><li>User Requirements </li></ul><ul><li>Functional Requirements </li></ul><ul><li>Quality of Service Requirements </li></ul><ul><li>Assumptions and Constraints </li></ul><ul><li>Implementation Requirements </li></ul><ul><li>Statement of goals, objectives or needs of the enterprise(reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure its success). </li></ul><ul><li>Describe needs that a given stake holder has and how that stake holder will interact with a solution. </li></ul><ul><li>Describe behaviour and information that the solution will manage. A specific system action or response. </li></ul><ul><li>Describe environmental conditions under which the solution must remain effective or quality that the systems must have. </li></ul><ul><li>Identify aspects of the problem domain that are not functional requirements of a Solution and will limit or impact the design of the solution. </li></ul><ul><li>Describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete. </li></ul>
    7. 8. Requirements Traceability
    8. 9. Analysis tools & techniques Slide of 18 <ul><li>Tools or techniques to analyse processes include: </li></ul><ul><li>Workflow tracing </li></ul><ul><li>Activity based costing (ABC) analysis </li></ul><ul><li>Cycle-time analysis </li></ul><ul><li>Problem analysis </li></ul><ul><ul><li>Structured brainstorming </li></ul></ul><ul><ul><li>Ishikawa (cause-effect) analysis </li></ul></ul>
    9. 10. Workflow tracing Slide of 18 <ul><li>Indicates information and materials flow </li></ul><ul><li>Show time dependencies between activities </li></ul><ul><li>Shows who performs each activity </li></ul><ul><li>Similar to data flow diagrams </li></ul><ul><ul><li>information or material flow implies time dependencies </li></ul></ul><ul><li>Illustrates sequential/ concurrent nature of processes </li></ul><ul><li>Highlights departmental hand-offs and boundaries of responsibility </li></ul>
    10. 11. Workflow tracing Slide of 18 <ul><li>“ Walk through the process - with someone who knows it!! </li></ul><ul><li>Tag a document or work item and follow it through the process - note times, decisions, problems etc . </li></ul><ul><li>Avoid skewing results </li></ul><ul><ul><li>the items you are following should not get preferential treatment </li></ul></ul>This is very time consuming: use only when other methods don’t provide enough information
    11. 12. Activity-based Costing <ul><li>First build the process model by activity </li></ul><ul><li>Use the model to build an activity dictionary </li></ul><ul><li>In workshop(s) assign “rough cut” costs to activities </li></ul><ul><li>Use supervisors to assign costs </li></ul>Slide of 18 N N N N N
    12. 13. Cycle time analysis <ul><li>Total cycle time for a process = first activity + to the last activity </li></ul><ul><li>Time is assigned to all activities including store and hold </li></ul><ul><li>Operators collect time for every level </li></ul><ul><li>Preparation of activity sheet needs careful planning </li></ul>Slide of 18
    13. 14. Cycle time analysis Slide of 18 Customers Sales Clerks Sales Managers Financial Managers Financial staff Warehouse Call to place an order Accept order terms Negotiate order changes Input order details Confirm availability and accept terms Approve order Call customer to change order Approve order Inventory report Process credit card information Order sent to warehouse Average elapsed time for order:3 hours Full time equivalent employees: 42 First time approvals (no errors) 85% Order promises kept 92%
    14. 15. Types of Problems Desired (Expectation/ Standard) Current Deviation End State Design Repair Improve
    15. 16. Problem analysis <ul><li>Objectives: </li></ul><ul><li>to identify “root causes” of the weaknesses identified in current processes </li></ul><ul><li>to identify opportunities for improvement </li></ul><ul><li>Techniques for problem analysis include: </li></ul><ul><li>structured “brainstorming” </li></ul><ul><li>Ishikawa (cause and effect) </li></ul>Slide of 18
    16. 17. Structured Brainstorming <ul><li>Rules for brainstorming: </li></ul><ul><li>Focus on the topic </li></ul><ul><li>Any idea is allowed </li></ul><ul><li>Build on previous ideas </li></ul><ul><li>No criticism of any idea - there are no bad ideas </li></ul><ul><li>Leader keeps ideas flowing </li></ul><ul><li>Capture every idea </li></ul>Slide of 18
    17. 18. Tool Name Utilization Affinity Diagram Used to Organize abstract thinking about a problem. Relations Diagram Used for determining causalities among parts of a problem. Systematic Diagram Planning tool. Matrix Diagram (many types) Used to organize knowledge in a matrix format; sometimes includes intercell relationships. Matrix Data Analysis Method Principal components technique is performed on matrix data. Process Decision Program Chart (PDPC) Determining which processes to use by evaluating events and prospective outcomes. Arrow Diagram Used to do 'what-iffing' on flow of process.
    18. 20. Using the Affinity Diagram as a Team It is relatively simple to try out using affinity diagrams yourself using the post-it note method mentioned above. Use the steps shown below. Gather a team; make sure the right people are on the team - that is that the team has common goals and interests. Discuss and select a specific problem area. For example, lack of productivity. Have each member jot down as many contributing factors to the selected problem as possible on a post-it note. Post the note on a board and begin as a team to logically group the notes. Name the logically selected groups. Have a period of quiet reflection and permitting any team member to move any note to any other desired group. Discuss the changes. Iterate these last two steps until a steady state is reached. Next, analyze the different groupings and decide which things to focus on in the remaining tools.
    19. 22. Relations Diagrams Relations diagrams specify the relationships among things. More specifically, these diagrams are used to map and analyze problems where causes of the problem have complex interrelationships. In contrast to the Ishikawa diagram in which all causes of a problem are assumed to be hierarchically decomposable, the relations diagram promotes discovery of relationship among causes. In plain terms, this means that a single thing might influence two or more other things, a situation that cannot be easily shown in a fishbone diagram. Consider the figure below in which multiple relationships among causes of a specific problem are shown. When teams work in a group to create relation diagrams, the 'card' or 'post-it note' technique can be used in which causes are specified by team members and arranged on a table or board and arrows drawn between cards or notes as needed to show the relationships.
    20. 24. The figure below shows how relations diagrams and Ishikawa diagrams are related. Ishikawa diagrams are arranged hierarchically, that is, there is a main node, subnodes, and subnodes of the subnodes, and so forth. The arrangement in which no branches are permitted to crossover is called a strict hierarchy; those cases in which crossover is permitted is termed a tangled hierarchy. The relations diagram is most like a tangled hierarchy. Crossover is permitted, in fact, encouraged. The relations diagram and the Ishikawa diagram are identical if the structure of either graph does not permit crossovers between the hierarchically organized structures. The top diagram shows a simple Ishikawa diagram with 6 causes shown (Cn). Shown below the Ishikawa diagram is the identical relations diagram with one additional link, shown to the left. Note that the primary difference between the two diagrams is simply the arrangement of the drawing - and the ability to have additional interconnectivity between causes. In truth, there is no reason that such interconnectivity cannot be shown on the fishbone.
    21. 26. Systematic Diagram Systematic diagrams help teams or individuals think systematically about how to achieve a goal. Affinity diagrams assist in identifying a problem, relations diagrams help to figure out what is related to a problem, and systematic diagrams organize the aspects of the solution of the problem. The Figure shows a general form of a systematic diagram, in this case a structure for assisting in breaking a goal down into subgoals. Subgoals in this case can become sets of methods and plans which assist in achieving the subsequent goal. Another way to use the systematic diagram is to decompose components or physical processes into their subparts. This type of hierarchy is sometimes known as a whole-part hierarchy, in reference to breaking the whole into it's constituent parts. The term systematic diagram is also referred to, by some, as the tree diagram due to the way that the diagram appears. Once the systematic diagram is organized and completed, the tip nodes (those to the right in the figure) represent the specific methods and actions that are to be taken. In this configuration, one can use a matrix diagram to prioritize and organize the work to be done. When a matrix diagram is used in this fashion it is sometimes termed a prioritization matrix.
    22. 27. Matrix-Related Tools Matrix diagrams permit organization of knowledge so that relationships between factors, causes, objectives, (or any thing that one wants to show) can be shown. Matrices, of course, provide rows and columns with intersecting cells that can be filled with information that describes the relation between the items located in the rows and columns. Several basic forms of matrix- related tools have been developed including, an L-type matrix, a T-type matrix, Y-type matrices, and X-type matrices. The L-type matrix is just a two dimensional table that places contrasting elements in the rows and columns of the matrix. The L term is used to describe the upside-down shape of the labels of the row and columns. The T-type matrix forms the labels in the form of a T adding an additional matrix above the top of the matrix. X and Y-type matrices are simply composed of multiple L and T matrices. As shown in the diagram below, the L is discernable in the column and row labeled Cn and Rn; for the T the additional set of Cns gives the appearance of a T.
    23. 28. The next figure shows another matrix style display technique with a 'rooftop' on the top of the matrix. This addition makes the diagram into what is sometimes called the &quot;House of Quality.&quot; The additional diagram provides the capability of making additional relationships between factors that are listed in the columns. The typical means for showing relationship in a matrix diagram is to place a symbol in a cell in the matrix, for example: - strong relationship - relationship - possible relationship Naturally, it is plausible to use any type of symbol that has meaning to the user. Different types of symbols are used by different authors and software manufacturers of matrix toolsets. One popular methodology based on matrix-style representations is known as Quality Function Deployment (QFD). QFD designates the columns as hows and the rows as whats, that is, how to accomplish something and what to accomplish. The whats are customer requirements or objectives; the hows are the different things that can be done to achieve the objectives. The roof of the hows show any interrelationship among the hows. In one software package by Qualisoft (1991), the whats are segmented into different types of requirements and the hows into different categories of things to be accomplished. To use this system, the user places in cells various symbols indicating the relationships between the whats and hows. Weights indicating the relative importance of the whats permit assessment of which of the columns (hows) provide the most benefit.
    24. 30. Process Decision Program Chart (PDPC) Process decision program charts are charts that help the user select the best processes to be used to accomplish a desired task. While the method has many variations, the most simple explanation of the method is that one shows the possible tasks in a process and the task sequences of all the relevant alternatives. For example, this figure shows starting at some beginning point and proceeding toward a goal. Each circle (node) is a separate task. In this figure, four different pathways are possible from start to goal. The fundamental idea is that the goal can be reached in various ways; however, only one of the sequence of tasks will be optimal. The PDPC assists in visualizing the alternatives when planning a sequence of tasks in a process. Two major alternatives for analyzing PDPCs are used - forward planning and backward planning. The first type is illustrated in the figure to the right and the latter in figure below. The method in forward planning is to begin at the start node and work toward the goal node, attempting to select the best path as one moves forward. In contrast, backward planning starts at the end node and moves toward the start.
    25. 32. Arrow Diagrams Arrow diagrams display information about the operation of a process by using arrows and nodes. Arrow diagrams can be thought of as a way to understand the operation of a process using time, cost, or other metrics. As a simple example, consider the figure below which displays a simplified process of creating a new product. In this very simple diagram, two paths are shown, the top path for creating the hardware component of the product and the bottom path, the software component. Each link (i.e., arrow) has a numerical label on it which designates the time required to proceed from one node to the next. In this example, the values used for the arrows are in weeks. Hence, the time required for completing the initial software for this product is much longer than the time required for the hardware. The arrow diagram, as in all the other tools, simply permits an explicit visualization of the bottleneck problem that will occur in this process!
    26. 33. Gantt charts have been used for many years to permit visualization and scheduling of parallel activities. The figure below shows a typical Gantt chart. Tasks are listed on the right side of the diagram. The times during which the tasks are scheduled are shown by the extent of the arrow in the diagram. The abscissa in this example might be weeks or months. In contrast, the arrow diagram attaches the name of each task to a node and shows the times between the tasks. Parallelism is easily seen and, moreover, disconnects in time are easily observed so that delays can be identified and plans can be altered to achieve the minimum time from start to completion of the process. Note that the same type of analysis could be accomplished using cost or any other metric that is appropriate to the process.
    27. 35. PEST analysis <ul><li>Political factors </li></ul><ul><li>Economic factors </li></ul><ul><li>Socio-cultural factors </li></ul><ul><li>Technological factors </li></ul><ul><li>Political/legal </li></ul><ul><li>Monopolies legislation </li></ul><ul><li>Environmental protection laws </li></ul><ul><li>Taxation policy </li></ul><ul><li>Employment laws </li></ul><ul><li>Government policy </li></ul><ul><li>Legislation </li></ul><ul><li>Others? </li></ul>
    28. 36. Economic Factors <ul><li>Inflation </li></ul><ul><li>Employment </li></ul><ul><li>Disposable income </li></ul><ul><li>Business cycles </li></ul><ul><li>Energy availability and cost </li></ul><ul><li>Others? </li></ul><ul><li>Socio Cultural factors </li></ul><ul><li>Demographics </li></ul><ul><li>Distribution of income </li></ul><ul><li>Social mobility </li></ul><ul><li>Lifestyle changes </li></ul><ul><li>Consumerism </li></ul><ul><li>Levels of education </li></ul><ul><li>Others? </li></ul>
    29. 37. Technological <ul><li>New discoveries and innovations </li></ul><ul><li>Speed of technology transfer </li></ul><ul><li>Rates of obsolescence </li></ul><ul><li>Internet </li></ul><ul><li>Information technology </li></ul><ul><li>Others? </li></ul>
    30. 38. Source: Adapted from M. E. Porter, Competitive Strategy, Free Press, 1980, p. 4. Threat of substitutes Potential entrants Threat of entrants Suppliers Bargaining power Substitutes Buyers Bargaining power COMPETITIVE RIVALRY Five forces analysis
    31. 39. Five Forces Analysis: Key Questions and Implications <ul><li>What are the key forces at work in the competitive environment? </li></ul><ul><li>Are there underlying forces driving competitive forces? </li></ul><ul><li>Will competitive forces change? </li></ul><ul><li>What are the strengths and weaknesses of competitors in relation to the competitive forces? </li></ul><ul><li>Can competitive strategy influence competitive forces (eg by building barriers to entry or reducing competitive rivalry)? </li></ul><ul><li>S.W.O.T. ANALYSIS </li></ul><ul><li>INTERNAL AUDIT – Factors over which firm has control </li></ul><ul><li>Strengths </li></ul><ul><li>Weaknesses </li></ul><ul><li>EXTERNAL AUDIT – Opportunities </li></ul><ul><li>Threats </li></ul>
    32. 40. Product Analysis <ul><li>Composed of both characteristics and features as well as benefits </li></ul><ul><li>Understanding the customers’ requirements may present opportunities for developing or augmenting the product. </li></ul><ul><li>Ongoing analysis of markets & products can assist the firm to improve the fit between their products and the needs of their customers. </li></ul><ul><li>Portfolio Analysis </li></ul><ul><li>The range of products offered by a company. </li></ul><ul><li>Product item </li></ul><ul><li>Product line </li></ul><ul><li>Product mix </li></ul><ul><li>Boston Group Matrix </li></ul><ul><li>Star, Question Mark, Cash cow, Dog </li></ul>
    33. 41. The BCG Matrix <ul><ul><ul><li>A concept developed by the Boston Consulting Group that evaluates SBUs with respect to the dimension of business growth rate and market share. </li></ul></ul></ul>
    34. 42. <ul><li>Four Alternative Positions: </li></ul><ul><ul><li>Question Marks </li></ul></ul><ul><ul><ul><li>The business unit has low market share compared to competitors, however it is doing business in high-growth market. </li></ul></ul></ul><ul><ul><li>Stars </li></ul></ul><ul><ul><ul><li>The business has high market share compared to competitors and it is doing business in high-growth market. </li></ul></ul></ul><ul><ul><li>Cash Cows </li></ul></ul><ul><ul><ul><li>The market is not very attractive – low market growth rate, however the business has high market share compared to competitors. </li></ul></ul></ul><ul><ul><li>Dogs </li></ul></ul><ul><ul><ul><li>This business has low market share and operates in low-growth market. </li></ul></ul></ul>
    35. 43. Competitor Analysis <ul><li>Competitor analysis table </li></ul><ul><li>Benchmarking </li></ul><ul><li>Complementary business </li></ul><ul><li>Business lifecycle </li></ul><ul><li>Market Analysis </li></ul><ul><li>Considers trends in the marketplace. </li></ul><ul><li>People with a need or desire for the product. </li></ul><ul><li>People with purchasing power. </li></ul><ul><li>People willing to purchase the product </li></ul><ul><li>Market place </li></ul><ul><li>MARKET SHARE </li></ul><ul><li>MARKET GROWTH </li></ul>
    36. 44. Evaluation of Strenths and Weaknesses <ul><li>The Organisation </li></ul><ul><li>The Marketing System </li></ul><ul><li>The Products </li></ul><ul><li>The Existing Market </li></ul><ul><li>The Suppliers </li></ul><ul><li>The Marketing Intermediaries </li></ul>
    37. 45. Use Cases Case user Tyner Blain: Use Cases
    38. 46. 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
    39. 47. Context diagrams Information flow External Internal Drilling down Context Boundary
    40. 48. … and UML Diagram from Wikipedia
    41. 49.
    42. 50.
    43. 51.
    44. 52.
    45. 53.
    46. 54.
    47. 55.
    48. 56.
    49. 57. Prioritising requirements <ul><li>Once you have classified data into categories, you have completed the first stage of analysis. We are interested in business requirements; therefore, the output from the first stage of analysis should be a list of business requirements (or functional requirements). The next stage is to rank the importance of each requirement. </li></ul>
    50. 58. Consider a website, for example. Are each of the requirements below equal in importance? The website system must <ul><li>conduct transactions over the Internet </li></ul><ul><li>display products on screen </li></ul><ul><li>provide an animation of the production process </li></ul><ul><li>display a privacy policy </li></ul><ul><li>link Internet sales to the inventory system </li></ul><ul><li>display a returns policy </li></ul><ul><li>enable a &quot;contact us&quot; facility </li></ul><ul><li>enable customers to check delivery and production status </li></ul><ul><li>provide &quot;about us&quot; information </li></ul><ul><li>display customer satisfaction testimonies </li></ul><ul><li>provide a user's guide for products </li></ul><ul><li>capture customer details online </li></ul><ul><li>have password protection for a &quot;members only&quot; section </li></ul><ul><li>display correct pricing - especially for customers with discounts </li></ul><ul><li>describe products </li></ul><ul><li>accept multiple payment methods. </li></ul>
    51. 59. <ul><li>You may have noticed that some requirements are dependent on others. For example, as soon as you capture customer details of any kind, you must have a privacy policy - this is a requirement under set law (with a few exceptions). </li></ul>
    52. 60. Ranking Requirements <ul><li>Given the dependencies within the requirements list, you should order the list for importance. </li></ul><ul><li>But your ranking is just that - your ranking! You also need to establish the organisation's ranking of importance. </li></ul><ul><li>present the key stakeholders with a list of requirements and ask them to rank the list by importance. </li></ul>
    53. 61. Ranking Requirements <ul><li>A little caution needs to be taken when collating and analysing the results of the ranked list. You need to consider who responded to the request and their importance within the organisation. For example, if the distribution list included five from sales and marketing yet only one from finance, the results may skew toward sales. </li></ul>
    54. 62. Ranking Requirements <ul><li>As another example, the business owner may want their response to be weighted three times the strength of their management team. The examples above could be extreme, but it is prudent to discuss the distribution list and respondents' relative weighting with the project sponsor. </li></ul>
    55. 63. Ranking Requirements <ul><li>The absolute ranking is important, but relative ranking is also important. To use the example above, where there are 16 items listed, it should not be inferred that the item on the top of the list is 16 times more important than the item on the bottom of the list. Perhaps the item on the bottom of the list is only 50% less important. For this reason, a relative importance should be allocated to the requirement. A scale of 5-10 is frequently used when allocating the relevant importance of a business requirement. The reason for a relative scale becomes apparent in the next section: &quot;Capability Analysis&quot;. </li></ul>
    56. 64. The table below provides an example of relative and absolute rating, where the higher the number the more important the requirement is. Business Requirement (Functional Requirement) Importance Rating Absolute (1-16) Relative (5-10) The system must display products on screen. 16 10 Requirements 15 - 2 n The system must enable customers to check delivery and production status. 1 5
    57. 65. Considering available resources <ul><li>Once you have ranked and rated the requirements by importance , you have completed the second analysis stage . By now you should have a list of business requirements (functional requirements), and you should know how important they are to the organisation. </li></ul>
    58. 66. Question: <ul><li>Should we implement all of them? </li></ul><ul><li>Answer: </li></ul><ul><li>&quot;All things are possible given enough time and money.&quot; </li></ul><ul><li>The answer to these questions requires the application of the third stage of analysis: Capability Analysis. </li></ul>
    59. 67. Capability analysis In order to estimate the ease of realisation, you need to know the following: <ul><li>your capability </li></ul><ul><li>the capability of your client </li></ul><ul><li>the capability of your organisation </li></ul><ul><li>the capability of any other organisations that you may incorporate into the project </li></ul><ul><li>the capability of the tools that will be used to develop the solution for the client. </li></ul>
    60. 68. Capability analysis <ul><li>Often a specialist or project manager who has experience in the field will rate the ease of realisation for a given business requirement. </li></ul><ul><li>A simple method of applying capability to business requirements is to simply rate the ease of realisation between 5 and 10, where 10 is the easiest and 5 is the hardest. Once you have the ease of implementation, multiply it by the relative importance of the requirement. </li></ul>
    61. 69. An example of applying capability to business requirements Business Requirement (Functional Requirement)   Importance Rating Ease of Realisation Final Rating Absolute 1-16 Relative 5-10 Relative 5-10 The system must display products on screen   16 10 8 80 Requirements 15 - 2   n n n x n The system must enable customers to check delivery and production status 1 5 5.5 27.5
    62. 70. Software to assist identification of capability <ul><li>There are various methods and software that can be used to assist in the identification of capability; you may want to search the Internet for sources. When the solution is to be developed by a consulting firm, the capability resides with the consultant. </li></ul>
    63. 71. Summarising business requirements <ul><li>By now, you should have a list of requirements that has been ordered by importance and ease of realisation. The final stage is to estimate how many of the requirements can be implemented given the available time and money. </li></ul>
    64. 72. Summarising business requirements <ul><li>Again, there are various techniques to establish the boundaries, but put simply, you need to draw a line through the requirements list and identify what you can achieve and what you cannot achieve. </li></ul><ul><li>The requirements that you can achieve become mandatory functional requirements and retain the verb &quot;MUST&quot;. The requirements that you cannot achieve become optional or desirable functional requirements and the verb &quot;must&quot; changes to &quot;MAY&quot;. </li></ul><ul><li>For example: </li></ul><ul><li>The system must display products on screen. </li></ul><ul><li>The system may enable customers to check delivery and production status. </li></ul>
    65. 73. Summary <ul><li>The issue that faces you now is: how easy is it to implement (or realise) each of the requirements? In other words, how many of the requirements can you implement in a given time frame and within a given budget? </li></ul>
    66. 74. Critical Thinking Methodology – Find Root Cause(s) Find Root Cause(s) <ul><li>Clarity (well-defined statement) </li></ul><ul><li>Validity (is cause true/correct?) </li></ul><ul><li>Causality (cause-effect link, single statements, no pre-defined solutions) </li></ul>Validated Root Causes Defined (‘5 Whys’) ‘ What is the cause of…’  Define immediate causes of preceding statements Identified Business Problem
    67. 75. Critical Thinking Methodology – Develop Alternatives Develop Alternative Solutions <ul><li>Clarity (well-defined statement) </li></ul><ul><li>Validity (is requirement correct?) </li></ul><ul><li>Causality (cause-effect link, single statements, no pre-defined solutions) </li></ul>Potential Solutions Identified ‘ What is required for…’  Define pre-requisites to achieve inverse of root cause or to eliminate root cause  Define pre-requisites to achieve purpose Validated Root Causes <ul><li>What must be changed/designed </li></ul><ul><li>In what way must they be changed/designed </li></ul><ul><li>With what aids/mechanisms must they be changed/designed </li></ul>
    68. 76. Assess Implications Critical Thinking Methodology – Assess Implications <ul><li>Clarity (well-defined statement) </li></ul><ul><li>Validity (is consequence correct?) </li></ul><ul><li>Causality (cause-effect link, single statements, no pre-defined solutions) </li></ul>Selected Solution(s) ‘ What is the implication of…’  Determine positive and negative consequences Potential Solutions
    69. 77. Compile Action Plan Critical Thinking Methodology – Compile Action Plan Action Plan & Measures ‘ What is required for…’  Determine action steps for implementation Selected Solution(s) Deadline Responsibility Confirmation Action Post-Value Pre-Value KPIs
    70. 78. Critical Thinking Methodology Develop Alternative Solutions Assess Implications Compile Action Plan Find Root Cause(s) Select Problem Identify Issues Define Purpose
    71. 79. Critical Thinking Methodology – Define Purpose Define Purpose Solved State/ New State Defined New Requirement ‘ What is the purpose of…’  Determine structure of purposes
    72. 80. Critical Thinking Methodology Develop Alternative Solutions Assess Implications Compile Action Plan Find Root Cause(s) Select Problem Identify Issues Define Purpose State Position/ Claim Assess Reasons/ Objections
    73. 81. Critical Thinking Methodology – State Position/Claim State Position/ Claim Position/Claim defined <ul><li>Position taken in response to issue/problem </li></ul><ul><li>Claim made </li></ul><ul><li>Clarity (well-defined statement) </li></ul><ul><li>Validity (is claim/premise true?) </li></ul><ul><li>Causality (Strength of inference, single statements) </li></ul>
    74. 82. Critical Thinking Methodology – Assess Reasons/Objections Assess Reasons/ Objections <ul><li>Clarity (well-defined statement) </li></ul><ul><li>Validity (is claim/premise true?) </li></ul><ul><li>Causality (Strength of inference, single statements) </li></ul>Assumptions and Premises articulated ‘ Because…but…’  Define reasons (support) and objections (oppose)  Evaluate validity and strength Position/Claim defined
    75. 83. Software Tools Develop Alternative Solutions Assess Implications Compile Action Plan Find Root Cause(s) Select Problem Identify Issues Define Purpose State Position/ Claim Assess Reasons/ Objections
    76. 84. <ul><li>Key Requirements: </li></ul><ul><li>The ability to identify and solve problems </li></ul><ul><li>An understanding of cause-effect relationships </li></ul><ul><li>A balanced view of the perspectives of different people with diverse experience </li></ul><ul><li>Active participation across the organisation in the problem solving/decision making process </li></ul>Summary <ul><li>Critical Thinking in Action: </li></ul><ul><li>Focus on finding the true causes of problems and thereby avoid dealing with symptoms </li></ul><ul><li>Gain a deeper understanding of how related issues influence each other </li></ul><ul><li>Actively participate in the problem solving process </li></ul><ul><li>Generate open-minded, creative ideas </li></ul><ul><li>Benefits: </li></ul><ul><li>The development of critical thinking skills </li></ul><ul><li>Interactive group participation </li></ul><ul><li>Anonymous contributions in the brain storming process </li></ul><ul><li>Input from across organisational levels and functions in solving problems and debating issues in the business </li></ul>More than ever, an education that emphasises general problem solving skills will be important. Bill Gates
    77. 85. Paul Ikele MBA FBDI Registrar/ Chief Executive The Institute of Business Development [email_address] THANK YOU