Management by Objectives Outcome driven results managment Author: Ian Andrew Martin Last updated: 11/12/2014 Document History Version Review Date Description of Amendment 0.1 23/03/1997 First draft completed – edited by Laurence Hulse PhD 0.2 28/03/1997 Modifications to RAPIER model section 0.3 15/04/1997 Modifications to MBO section. 0.4 16/06/1997 Update and refresh with revisions from Lawrence Hulse PhD 0.5 21/10/1997 Second draft completed – edited by Lawrence Hulse PhD and I Andrew Martin 0.6 03/03/1998 Modification to rapier model section 0.7 01/06/1998 Rework of the MBO approach to make it clearer for readers 0.8 27/11/1998 Minor re-write to remove excess jargon 0.9 15/05/1999 Modification to workflow 1.0 01/02/2000 First published 1.1 18/10/2004 Additional information added to the Appendices o provides more background for the method. 1.2 07/08/2008 Modified internal links within the document for better access to resources 1.3 12/09/2009 Additional appendix data – Appendix E. 1.4 29/05/2012 Updated sections specifically for Rivers IT to make the document more relevant to Rivers IT Support Staff. 1.5 11/12/2014 Added a copyright section to the document, prepared for publication. Current Document Version: 1.5 Copyright © 1995 - 2014 – Ian Andrew Martin Last updated: 11 December 2014 Publish date: 11 December 2014 Current Version: 1.5 Management by Objectives Table of contents Overview of this document 3 Management by objectives 3 R.A.P.I.E.R. Issue analysis model 3 Short form 3 Long form 4 Research 4 Analysis 4 Planning 5 Implementation 5 Evaluation 5 Recommendations 5 Example R.A.P.I.E.R. resolution 6 Background 6 Issue 6 Aim 6 Objective 6 Research 6 Analysis 6 Planning 6 Implementation 7 Evaluation 7 Recommendations 7 Appendices 8 Appendix A 9 Appendix A 9 Management by Objectives (MBO) 9 Features and Advantages 9 Domains and levels 9 Practice 9 Limitations 10 Arguments Against 10 Appendix B 11 Deming philosophy synopsis 11 Appendix C 12 The Deming System of Profound Knowledge 12 Key principles 13 Appendix D 15 Seven Deadly Diseases 15 Appendix E 16 Plan-Do-Check-Act (PDCA) 16 Meaning 16 About the PDCA model 16 [2] Outcome driven results managment Overview of this document Ian Andrew Martin developed the R.A.P.I.E.R. model in 1998-1999. Ian Andrew Martin expresses his right under the Boerne Convention to be recognised as the originator and creator of the work. R.A.P.I.E.R. model was developed by Ian Andrew Martin, in association with Dr Lawrence Hulse PhD. This document, and the R.A.P.I.E.R. model, may be used by Rivers Australia in its current format in perpetuity by permission of the author and creator Ian Andrew Martin. Management by objectives The essence of MBO is participative goal setting, choosing courses of actions and decision-making. An important part of the MBO is the measurement and the comparison of the employee’s actual performance with the standards set. Ideally, when employees themselves have been involved with the goal setting and choosing the course of action to be followed by them, they are more likely to fulfil their responsibilities. The R.A.P.I.E.R. Issue analysis and resolution model provides for defined outcomes of defined issues. Based on Peter Drucker’s Management by Objectives (MBO)1 approach the R.A.P.I.E.R. model is a method of defining issues, determining their root cause, and resolving them to the satisfaction of management and employees. This helps adherents of the R.A.P.I.E.R. model answerable to the underlying running of the business by assisting them in the resolution of issues that impediment the role they play in the organisation. Thus, someone versed in the R.A.P.I.E.R. model is more likely to resolve root causes to roadblocks rather than find workarounds, ultimately lowering costs to the business. R.A.P.I.E.R. Issue analysis model The R.A.P.I.E.R. Issue analysis model provides a method to resolve issues Short form The MBO section is broken down into three steps. These three steps help you focus on the issue, how you will resolve it and the resources you will need to provide that resolution. The three steps are: 1) The Issue, 2) The Aim, and 3) The Objective. The objective has four sub-steps that provide costing information and a QA approach to guide you through the remainder of the resolution model. These sub- steps are: 1) The Time you expect it will take to reach the resolution, 2) The Costs associated with achieving the resolution, 1 The term "management by objectives" was first popularized by Peter Drucker in his 1954 book 'The Practice of Management'. [3] Management by Objectives 3) The Outcome, which is the resolution you’ll achieve and deliver to the organisation (the deliverable), and 4) The Measurement, which is the change the resolution will make to the organisation. That is you will reduce the number of occurrences, will you save the company "x" hours of time, $X,000 dollars, increase uptime or reliability, etc. In the “Example R.A.P.I.E.R. resolution” shown on page 6 I will work through an issue that occurred in the IT support area and how it was resolved using the model described here. Long form The results of the MBO section drive the R.A.P.I.E.R. model’s inputs. Thus, the issue defined and the outcomes proposed are put to the test to determine if your original resolution can be achieved within the time, costs, outcome, and measurements stated. Research The heart of the R.A.P.I.E.R. model is the research section. It provides a logical analysis of the factors that caused, or are causing an issue to occur. You should determine at the least: 1) Who did what 2) When it occurred and in what order the issue unfolded 3) Where the incident occurred, either a system, a program or a location 4) Why the operator or system performed the action 5) How the actions affected the business, process, operator or system. Areas to include in your research should include, but may not be limited to: a) people, b) hardware, c) software, d) external or internal events, etc. e) what each of the participants did, or failed to do: f) actions performed, or not performed, g) processes followed, or deviated from h) hardware used and how it was used, i) software used and how it was used, etc. j) the order the events occurred in to allow a timeline to be generated to assist mistiming in processes or procedures to become evident, allow for bug detection, and so on. Analysis The analysis section aims to put together the output of the research in a coherent form to answer the basic question of “what went, or what is going wrong?” The resolution road map should provide answers to at least the following questions: 1) Where did the issue occur? 2) Why did the issue occur? 3) What were the contributing factors? [4] Outcome driven results managment Planning The planning section aims to provide a straightforward plan to resolve the issue, assign the appropriate resources, and test the resolution hypothesis put forward in the analysis section. What steps need to be put in place to ensure the issue does not happen again? Implementation This is what you plan to do to put the resolution to the issue in place. Write out: 1) Who (people or other resources) you need, 2) What they will be doing, 3) When they’ll need to do it by 4) Where the work needs to be done, if some work is to be done remote from the IT Support office for example, 5) How each item is to be completed, with references to current model documentation where appropriate, and references to new or beta documentation as determined through the Analysis and Planning sections. Evaluation The evaluation is a two part exercise: 1) Objective Section: How close were we to achieving the four parts of the objective? a) Time: Did we over/underestimate how long things would take? b) Cost: Did it cost more/less than we expected? c) Quantity: d) Quality: 2) Implementation: an evaluation of the implementation plan. 3) How did it work out? Did it resolve the issues? 4) What did not work as expected? 5) Are there internal or external road blocks to the implementation that you did not expect? 6) Were there any unexpected issues that arose, interdependencies with other products, software, processes that were not known before? Recommendations This section is concerned with quality assurance (QA). In this section the aim is to: 1) Report on what we did right this time, what the person completing the work thinks we could do better next time. 2) Review each of the sections and determine what we could have done to: a) make the resolution quicker, b) make our processes better, c) improve our documentation, etc. 3) Provide a roadmap going forward for retesting, further study of the issues and other QA options to improve our efficiency and lower the cost per support incident. [5] Management by Objectives Example R.A.P.I.E.R. resolution Background During a power outage, caused by faulty equipment, it was observed that a critical server failed, even though it was plugged into a UPS.