The Systems Thinking Tool Box

Similar documents
The Systems Engineering Tool Box

The Systems Engineering Tool Box

Requirements Engineering

The Systems Thinking Tool Box

Agile versus? Architecture

TickITplus Implementation Note

W8 Wednesday, November 3, :15 PM

Case Study: Aligning Customer Experience with Business Architecture

A Level Economics Guidance on answering multiple choice questions. Section A: Handling multiple choice questions in Economics

DEVELOP TEAMS AND INDIVIDUALS FACILITATOR MANUAL & ASSESSMENT BSBLED401A

Trisasi Lestari

Operations and Supply Chain Management Prof. G. Srinivasan Department of Management Studies Indian Institute of Technology, Madras

HIMSS ME-PI Community. Quick Tour. Sigma Score Calculation Worksheet INSTRUCTIONS

3C05: Software Quality. Unit 8: Software Quality. What is Quality?

Techniques for Improving Machinery Reliability

ISO whitepaper, January Inspiring Business Confidence.

Before You Start Modelling

Product Design and Development Dr. Inderdeep Singh Department of Mechanical and Industrial Engineering Indian Institute of Technology, Roorkee

erhaps you ve heard this quote by 18th century author Oliver Goldsmith: Our greatest glory is not in never failing, but in rising up every time we

Advice on Conducting Agile Project Kickoff. Meetings

Performance Measure 73: State/Territory Quality Assessment

Requirements Change Management Practices

What are requirements? Basics of Requirement Engineering. Definition of a Stakeholder. Stated Vs. Real Requirements. Stated Vs.

introduction by Stacey Barr

Part VI MANUFACTURING SUPPORT SYSTEMS

Copyright WorldAPP. All rights reserved US: +1(781) UK: +44(0) US TOLL FREE: +1(888) AU: +1(800)

to Successful Non-profit Cloud ERP System Selection

Helping Your Online Community Succeed

Developing a Monitoring and Evaluation Plan for Food Security and Agriculture Programmes

Engineering 2503 Winter 2007

Analysing client requirements

How to do a RACI Charting and Analysis a Practical Guide

Also we will try to recap what we studied in the last class. (Refer Slide Time: 00:35)

Risk appetite and internal audit

1) Introduction to Information Systems

10 Reasons to use XLCubed for Managed Self-Service Business Intelligence

7 Steps for Building an Effective CSR Program

Introduction to Agile Change Management

Staffing and Teamwork Tug of War Analogy

1. What is a key difference between an Affinity Diagram and other tools?

7A Skills Transformation Centre. Stand out from the crowd

Software Engineering Prof. Rajib Mall Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur.

CITB-ConstructionSkills BEHAVIOURAL COMPETENCY FRAMEWORK

AUDITING CONCEPTS. July 2008 Page 1 of 7

DEVELOPMENT PLANNING TOOLKIT

Conducting a RACI (Responsible, Accountable, Consulted and Informed) analysis

Module 5: Project Evaluation in

Professional Development: Leadership for Performance Improvement

How to Build a Solid Analytics Foundation

Business Studies - Management Notes. Business Studies Study Notes

Lecture 8 Agile Software Development

White Paper. Selecting Enterprise Software

GUIDANCE ON CHOOSING INDICATORS OF OUTCOMES

Introduction to Control Charts

Chapter 2. 2 Literature review

Using Quality Function Deployment in Singulation Process Analysis

13 Project Graphics Introduction

Workbook table of contents

Goldilocks: Finding the Right Fit in Monitoring & Evaluation

Through these, as well as through our other products and services, EFQM aim to "Share What Works".

Article from. CompAct. April 2017 Issue 55

Get Started with COBOTS EASY STEPS

LEAN PRODUCTION SYSTEM

Agile leadership for change initiatives

Management Drives. Introduction

How to get people using self-service for IT support

Chapter 3 Assembly Systems. Screen Titles

Contingency Planning

Lucy Walker Recruitment Case Study. How we support IP Group with their recruitment

Measuring Your ROI On Social Media

Software Engineering Lecture 5 Agile Software Development

How Business Analysis Can Improve Sales and Marketing Outcomes

QUADRANT-I. Module 3:Competency Based HRM

Comprehensive manual for the PPP scan

MICHIGAN TECHNOLOGICAL UNIVERSITY MICHIGAN TECHNOLOGICAL

HSE Design Reviews and Action Close-out

The Business Case for a Project and Portfolio Management Platform. Craig McQueen Agora Consulting Partners Inc.

The Communications Audit NEVER MORE RELEVANT, NEVER MORE VALUABLE:

Optimao. In control since Control Systems Obsolescence: Support Strategies and Key Considerations

Practice Notes IMPROVING THE IMPACT OF MICROFINANCE ON POVERTY: ACTION RESEARCH PROGRAMME

Full file at

Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1

15 TIPS ITSM FOR By Stuart Rance

The Egmont Group of Financial Intelligence Units. Egmont Strategic Analysis Course Session 9 Reporting. Participant Manual

Master Production Scheduling - Is it still relevant?

Avoiding Knowledge Management Pitfalls. Ten Common Mistakes and How to Avoid Them

PROJECT MANAGEMENT AND PROJECT TEAM STRUCTURE

Thinking about competence (this is you)

Challenges faced when taking strategic decisions. Results of 2010 Global Survey. Executive Summary

Global Journal of Engineering Science and Research Management

A strong tool for public transport planning the software in operation

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2

How to define your unique selling proposition

Successful Procurement: Art or Science?

Creating a Job Search Program In Your Church, Synagogue Or Community Organization

Organization Realignment

Organisational robustness. A new standard for top management

LCA in decision making

KPIs and Stakeholders

Leadership Behavioural Competencies Somerset County Council October 2011

Transcription:

List 1 Item A Item B Item C Item D Item E The Systems Thinking Tool Box Dr Stuart Burge.. bump, bump, bump, on the back of his head. It is, as far as he knows the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it. Winnie the Pooh - A. A. Milne Matrix Diagram (MD) What is it and what does it do? A Matrix Diagram (MD) is a tool that allows a team to identify the presence and strengths of relationships between two or more lists of items. It provides a compact way of representing many-to-many relationships of varying strengths. An example matrix diagram is shown in Figure 1. List 2 Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Figure 1: An Example Matrix Diagram Figure 1 shows, by the symbols, the presence of a relationship between the items in list 1 and the items in list 2. The different symbols indicate the strength of the relationship and an empty cell indicates no relationship. Page 1 of 13

The contents of the lists being related in a matrix diagram can be: Data Information Functions Concepts Actions People Materials Equipment Etc. However, the contents of the lists should have something in common so that they represent a set of something. Why do it? Relationships between things are often complex (many-to-many) and require us to think in more than one-dimension. The Matrix Diagram is a simple tool that allows relatively complex situations to be analysed in a simple straightforward way. They help us to expose interactions and dependencies between things that help us to understand complex causal relationships. Where and when to use it? A Matrix Diagram can be used where we wish to identify and assess the strength of relationships between to or more lists of items. It is particularly useful for examining the relationships between: a set of vague and un-measurable items with a set of precise and measurable items (such as relating customer requirements to technical requirements). two sets of items that are physically different (such as design solutions to a set of technical requirements). There are five basic types of Matrix Diagrams that allow for different numbers of lists to be to be explored. The Types are: L-type T-type Y-type X-type C-type QFD Type (Quality Function Deployment). Page 2 of 13

List 1 Item A Item B Item C Item D......... L-type Matrix Diagram The L-type is the basic Matrix Diagram that allows the relationships between two lists. It is shown schematically in Figure 2. List 2 Item 1 Item 2 Item 3 Item 4 Figure 2: The L-type Matrix Diagram Page 3 of 13

list 3 List 2 Item A Item B Item C Item D List 3 T-type Matrix Diagram The T-type is effectively two L-types joined by a single list. It allows one list to be related to two others and is shown in Figure 3. Item Item Item Item List 1 Item 1 Item 2 Item 3 Item 4 Figure 3: The T-type Matrix Diagram Y-type Matrix Diagram The Y-type Matrix is combination of three L-type matrices as shown in Figure 4. d c b a 1 2 3 4 Figure 4: The Y-type Matrix Diagram Page 4 of 13

List D List B X-type Matrix Diagram The X-type Matrix is combination of four L-type matrices as shown in Figure 5.. B 3 B 2 B 1 List A A 3 A 2 A 1 C 1 C 2 C 3 List C D 1 D 2 D 3 C-type Matrix Diagram Figure 5: The X-type Matrix Diagram The C-type Matrix Diagram is a represented as a cube whose sides are three lists as shown in Figure 6. This diagram allows for three dimensional relationships. However, this can be difficult to visualise even with the cubic arrangement and it is often easier to interpret by using the inside of the cube as shown in Figure 7. B b 4 b 3 b 2 b 1 a 1 a 2 C a 3 a 4 A c 1 c 4 c 3 c 2 Figure 6: External C-type Matrix Diagram Page 5 of 13

C c 4 c 3 c 2 c 1 b 3 b 2 b 1 a 1 a 2 a 3 a 4 b 4 B A Figure 7: Internal C-type Matrix Diagram Quality Function Deployment (QFD) Type Matrix Diagram One derivative of the Matrix Diagram that has become widespread is the Quality Function Deployment Chart. This in its simplest form is simply an L-type Matrix Diagram with an ancillary list that has a many-to-one relationship with one of the main lists. It is used to investigate the relationships between sets of requirements that are developed during new system (product) introduction. While several organizations use QFD as the foundation for their New Product Introduction Process (NPIP), many only use its first iteration to examine the relationships between customer requirements and technical requirements. QFD in all its varieties is describe as a separate tool, but as an example, Page 6 of 13

shows a QFD phase 1 chart. Page 7 of 13

Items related Items related Items related Items related LIST 1 Item A Item B Item C Item D......... White-Black +full colour +/- 1% 5kg miminum 5kg minimum all currently available 15l/min cold 10-28C 10l/min+/- 1l equivalebt to 1600rpm spin Reflectance of 500 removal of cleaning to... Moisture content of no damage to clothing All standard Cycle as All Cycle info All Cycle info Refer to CS 123 Stabdard BS fittings Style Customer Requirements Intelligent Washing Machine Long Cost Ease of Use Good Wash Detect Load Make Up Measure H20 Hardness Load Dirty Items Unload Clean Items Load Cleaning Agents Fill Water Drain Water Heat Water Wash Rinse Dry Contents Select Cycle Control Cycle Receive user inpu Display user messages Suuport Interface to Services IWM Functions and Features Wash Sensing Load Machine Manage Water Clean Items Manage User I/O Intelligent Washing Machine Good Dry Performance Good Wash Perf ormance Automation & Intelligence Easy to use Controls Access Ergonomics Purchase Running F G H F H H G F H G H G G F H F H G H F H H G F G G F F F F F G F G G G G G G G H G H F F F G G H G G F G F Reliable Easy to Maintain Attractive H G G G F H G G G G G G H G G G G H H How Much Figure 8: Example QFD Phase 1 Chart This chart is an L-type matrix modified as shown in Figure 9. LIST 2 Item 1 Item 2 Item 3 Item 4 LIST 3 many-to-one related with List 2 Figure 9: The Basic Structure of the QFD Type Matrix Diagram Page 8 of 13

In the first phase of QFD, List 1 comprises customer requirements which are often expressed in vague and ambiguous terms. List 2 comprises the set measurable technical requirements for the system under development. The matrix is therefore used to show the relationships between the customer and technical requirements. Blank or sparse rows or columns will highlight potential deficiencies in either set of requirements. List 3 is used to set target levels for the measurable technical requirements in list 2. Who does it? Constructing a Matrix Diagram is best performed by a team to draw upon the experience and expertise in that team. It is important to emphasise that the quality of the outcome is dependent upon the team and hence team selection is critical. What is important is expertise in both lists. As an example, consider the phase 1 QFD briefly described above. List 1 comprises the customer requirements gathered in many organizations by the Marketing Function. List 2 comprises the technical requirements of the system under development generated by Systems Engineers. It is obvious that both groups need to be present to generate a good chart. Time size is also an important consideration and the recommendation is for 5 to 8 members. Below 5 and there is perhaps not enough critical mass to represent all the stakeholders adequately. Above 8 creates management issues which often leads to bureaucracy and consequent slowing of progress. There is great benefit in terms of quality of output and time efficiency if the Matrix Diagram sessions are facilitated by a Matrix Diagram craftsman. This is particularly important for virgin teams. How to do it? The process for constructing a Matrix Diagram is given in Figure 10. Step 1: 1: Define purpose of of Matrix Diagram Step 2: Identify the matrix Lists Step 3: Assemble the best team that can inter-relate the lists Step 4: Select the matrix type Step 5: Choose and define the relationship symbols Step 6: Identify, discuss and capture the matrix relationships Step 7: Draw conclusions Figure 10: The Process for Constructing a Matrix Diagram Page 9 of 13

STEP 1: Define purpose of Matrix Diagram Clarity is important here. Not we should use this tool to explore situations but rather if that is the case we should say so clearly. STEP 2: Identify the matrix lists This should follow automatically from the purpose. What is often problematic here is whether the lists: exist are sufficiently complete are representative and unbiased. If they do not exist then effort may have to be expended to generate them and it is a question of whether this is done by the same team that will determine the relationships. As a general rule, it is recommended that the list originators take part in the determination of relationships simply because they understand their respective lists. On the other hand it is import to recognise the potential for bias. A classic example of this is asking a bunch of Engineers to help generate a set of customer requirements by pretending to be customers. The outcome is very plausible but probably not representative of the true customers needs and leading to the wrong conclusions being drawn. It is important here to realise that the lists should contain items that have something in common so that they represent a set of something. This again is easier to say than do. In some situations it is easy. For example if you were investigating train lateness against train operator and type of service it would be hard to get the contents of the lists mixed up. But, what about lists of customer requirements and technical requirements? Some customer requirements are technical requirements so in which list do they reside? 1 STEP 3: Assemble the best team that can inter-relate the lists This step is obvious linked with step 2 and can in fact happen before the completion of step 2. Whatever the formation of the team it must contain the expertise and experience to be able to inter-relate the lists. STEP 4: Select the matrix type If the earlier steps have been completed this should be straightforward, although for any particular situation you may wish to construct more than one type of Matrix Diagram. 1 This particular issue is discussed and resolved in the QFD tool description. Page 10 of 13

STEP 5: Choose and define the relationship symbols The relationship symbols accomplish two tasks: indicate the presence of a relationship indicate the strength of a relationship In some instances only the presence of a relationship is sought, in which case any symbol will do. However, in most case both presence and strength is sought and two common ways exist for capturing this: Symbolic method Strong relationship Medium relationship Weak relationship No relationship Numeric Method 9 Strong relationship 3 Medium relationship 1 Weak relationship 0 No relationship The two are equivalent and can be interchanged but the numeric method can lead to unnecessary and potentially dangerous tinkering. In general, people are much more willing to accept the strong, medium and weak symbology and not question its efficacy. However, when faced with the numeric method people often wish to change the relative values (i.e. medium = 4.5) or attempt to introduce inter-range values (i.e. use the complete scale from 1 to 9). While in principle this is not a problem, in practice it leads to endless debate, constant recalibration and criticism of the tool (the classic case of a poor workman blaming his tools). My experience is to start with the symbols and if a numeric scale is required translate to this after using the symbols. There is a third option that attempts to capture whether the relationships are positive or negative. This uses: 9 Strong positive relationship 3 Medium positive relationship 1 Weak positive relationship 0 No relationship -1 Weak negative relationship -3 Medium negative relationship -9 Strong negative relationship While this can be useful, it is difficult to apply when a relationship can be either positive or negative. In my experience of this scheme the disadvantages outweigh the advantages. The best approach is to indicate that there is a relationship on the Matrix Diagram and make notes about the type and form of the relationship. Page 11 of 13

STEP 6: Identify, discuss and capture the matrix relationships This step is the core of the tool. It is best to be disciplined and systematic in how the cells of the matrix are examined for potential relationships. Whether to proceed rowwise or column-wise depends largely on the situation under considering. As a general rule row-wise is often the most appropriate since we tend to place the most important list vertically on the left (for the L, YC and QFD type matrices this is the dominant position). Each relationship should be considered in turn and the presence and strength debated until the team reaches a consensus. Since the symbols are measures of the relative strength it can be useful to start by quickly scanning a row (or column) to identify the strongest relationship which can be assigned with the appropriate symbol. This performs a type of calibration against which the other symbols and agreed. You may also find that having completed a row (or column) that you may need to go back and change some of your symbols. Deciding on symbols will (and should) provoke discussion and it is important to record some of this. While I would not necessarily recommend making notes for every symbol entered on a Matrix Diagram, it is certainly worthwhile recording those discussions where there was lengthy or frank debate (i.e. an argument). This is extremely valuable if you ever have to return to a diagram at a later date, or for other people who will use the diagram but were not present during its construction. STEP 7: Draw Conclusions There should be a purpose for undertaking a Matrix Diagram and once it is complete it should reviewed against that purpose to draw out conclusions. It is worthwhile capturing these on the diagram for future reference and to inform others. What Goes Wrong: The limitations of Matrix Diagrams Ambiguous, invalidated, and incomplete lists. It is important to think through what is in each list and what constitutes membership of a particular list. Attempting to precisely quantity the strength of a relationship. Matrix Diagrams are useful tools in exploring a large number of items quickly to reduce the scope of a situation down to the vital few. As such the broad strong, medium and weak relationships are ideal. Attempting to be precise can be damaging to the team and the value of the tool. Wrong expertise and insufficient experience in teams. Like a great many Systems Engineering tools, the Matrix Diagram tool is really only a vehicle to help extract the knowledge and experience from the team. The wrong team can still follow the process and arrive at a result but that resultant Matrix Diagram will be of little use. Page 12 of 13

Success Criteria The following list represents a set of criteria that have been found to be useful when using Matrix Diagrams. Team size between five and eight. Team constitution has expertise and experience in the lists being related. Use an experience independent facilitator. Plan for one half-days effort. Irrespective of the situation a Matrix Diagram will take about ½ day to construct. Define clearly what we are trying to do. Find some mechanism for validating the lists. Use the symbols and convert the numbers later. Record reason final symbol decision in contentious situations. Page 13 of 13