Implementation MGS 3100. spreadsheet modeling alone is insufficient for truly affecting decision making in organizations because:spreadsheet modeling.

Slides:



Advertisements
Similar presentations
Information Technologies Page 1 Information Technologies Page 1 Information Technologies Page 1 Information Technologies Page 1Information Technologies.
Advertisements

Program Management Office (PMO) Design
Chapter 1: Introduction
Strategies and Structures for Research and Policy Networks: Presented to the Canadian Primary Health Care Research Network, 2012 Heather Creech, Director,
Systems Analysis and Design 8 th Edition Chapter 3 Managing Systems Projects.
Chapter 9 IMPLEMENTATION AND EVALUATION Decision Support Systems For Business Intelligence.
Systems Analysis and Design 8th Edition
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
DECISION MODELING WITH MICROSOFT EXCEL Chapter 11 Copyright 2001 Prentice HallIMPLEMENTATION.
1 IS371 WEEK 8 Last and Final Assignment Application Development Alternatives to Application Development Instructor Online Evaluations.
Validating and Improving Test-Case Effectiveness Author: Yuri Chernak Presenter: Lam, Man Tat.
Assessment of Systems Effort Factors Functionality Impact Factors Functionality Interface Usability What it does Collection Value to task Effectiveness.
HFSD Methods Nov HFSD Methods Objectives –To consider types of systems –To characterise methods for HF input into SD –To identify HF contributions.
Iterative development and The Unified process
Chapter 3: The Project Management Process Groups
CHAPTER 9: LEARNING OUTCOMES
Stephen S. Yau CSE , Fall Security Strategies.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
Waniwatining Astuti, M.T.I
Chapter 2 A Strategy for the Appraisal of Public Sector Investments.
Change Request Management
Capability Maturity Model
Who Watches the Watchers Tyler Hamilton Marissa Kaprow Jeff Reifeiss.
Initiating and Planning Systems Development projects
Integrated Capability Maturity Model (CMMI)
CHAPTER 3: The Marketing Research Process and Proposals
N By: Md Rezaul Huda Reza n
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
University of Utah SoCCS Lecture 61 Architecture – An Introduction CS Lecture 6 Nathan Dykman.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Improving Implementation Research Methods for Behavioral and Social Science Working Meeting Measuring Enactment of Innovations and the Factors that Affect.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Clarity Educational Community How Companies Are Using CA PPM for Application Portfolio Management Presented by: Mark Feher | Date.
IIA_Tampa_ Beth Breier, City of Tallahassee1 IT Auditing in the Small Audit Shop Beth Breier, CPA, CISA City of Tallahassee
Project Administration Chapter-4. Project Administration Project Administration is the process which involves different kinds of activities of managing.
ROLE OF INFORMATION IN MANAGING EDUCATION Ensuring appropriate and relevant information is available when needed.
SQI © T.P. Rout and Griffith University, 1996 A Unified Reference Model for the Processes of Software and System Life Cycles Terry Rout Software Quality.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 3 Identification and Selection of Development Projects.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
Getting There from Here: Creating an Evidence- Based Culture Within Special Education Ronnie Detrich Randy Keyworth Jack States.
Requirements Engineering Overview Senior Design Don Evans.
Lecture 14 Maintaining the System and Managing Software Change SFDV Principles of Information Systems.
Software Requirements and Design Khalid Ishaq
Chapter 13: Software Quality Project Management Afnan Albahli.
Chapter 8: Participant-Oriented Evaluation Approaches
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
PPTTEST 12/26/ :41 1 IT Ron Williams Information Technology Management Project Management.
Requirements Engineering Process
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.
Slide 1 Security Engineering. Slide 2 Objectives l To introduce issues that must be considered in the specification and design of secure software l To.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
INTRODUCTION TO COGNITIVE SCIENCE NURSING INFORMATICS CHAPTER 3 1.
Chapter Two Copyright © 2006 McGraw-Hill/Irwin The Marketing Research Process.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
Final Review Systems Analysis and Design in a Changing World, 4th Edition 1 Final Review u Chapters 1-6, 8-10, 13, 14, 15 u Multiple choice, short answer,
Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu.
Writing the Requirements
DECISION MODELING WITH MICROSOFT EXCEL Chapter 11 Copyright 2001 Prentice Hall Publishers and Ardith E. BakerIMPLEMENTATION.
TK2023 Object-Oriented Software Engineering
Change Request Management
8 Managing Risk (Premium).
Security Engineering.
Software Requirements
© Julie Hodges and Roger Gill
The Object-Oriented Thought Process Chapter 05
Capability Maturity Model
Capability Maturity Model
Presentation transcript:

Implementation MGS 3100

spreadsheet modeling alone is insufficient for truly affecting decision making in organizations because:spreadsheet modeling alone is insufficient for truly affecting decision making in organizations because: Inadequate modeling is just one of the reasons why decision-makers do not make good decisions.Inadequate modeling is just one of the reasons why decision-makers do not make good decisions. This chapter will cover critical oversights that users new to the concepts of modeling make in attempting to move forward to apply those ideas in actual decision-making situations.This chapter will cover critical oversights that users new to the concepts of modeling make in attempting to move forward to apply those ideas in actual decision-making situations.INTRODUCTION

WHAT, AFTER ALL, IS A MODEL? Remember the definition from the first chapter: A model is an abstraction of a business situation suitable for spreadsheet analysis to support decision making and provide managerial insights. Consider the following evolution of a model:

A Prototype Model CompleteDebugged Runable by Its Author Validated with Test Data Believed to Deliver Value An Institutionalized Model Sustained by the Organization Integrated into Organization's Decision Processes Coordinated in Function with Other Models and Systems Useable by Other Managers Maintainable and Extensible by Others Need Data Supplied and Maintained by Others Effort: 10X-100X Effort: 1X A Modeling Application Usable by a Client Manager Well Documented Hardened to Reject Unusual Data Inputs Extensible by Author or Client Manager Validated with Real-World Data Known to Deliver Value Effort: 10X An Institutionalized Modeling Application Effort: 100X – 1000X

This framework is a variation of one originally proposed by C. West Churchman, et. al. Modeler,ProjectManager,DecisionMaker,Client Curse of Player Separation ClientModeler Project Manager DecisionMaker The Separation of Players Curse

The Curse of Scope Creep Narrow Modeling Project Single Model Single Objective Focused Activity Few Players Few Stakeholders Low Effort Low Cost Low Development Risk Informal Coordination & Project Management Low Project Visibility Scale Diseconomies in Information Systems for Model Scale Diseconomies in Model & Database Maintenance Low Potential Organization- wide Impact Curse of Scope Creep Wide Modeling Project Multiple (Replicated) Models Multiple Objectives Diffused Activity Many Players Many Stakeholders High Effort High Cost High Development Risk Formal Coordination & Project Management High Project Visibility Scale economies in Information Systems for Model Scale Economies in model & Database Maintenance High Potential Organizational-wide Impact

Other Sources of Implementation Failure Easily addressed issues in modeling failure are model logic, model inadequacy, etc. However, political issues that arise from the use of a model are far more prevalent as a source of failure in modeling. When a model fails, it is all too common to blame the model when in fact, the inadequacies of the development and implementation of the model were at fault.

Other Sources of Implementation Failure con’t Loss of continuity either during the development of a model itself or later during implementation caused by departure of key players, or the loss of “organizational memory” Developing a modeling application before assessing issues of the data availability An infrastructure must be present (or be created) that guarantees that the data and systems will be maintained Shortcomings at one level of an organization as being caused by failures or inadequacies at a higher, often more abstract, level of the organization.