Modeling As A Risk Management Strategy

Transcription

1 Modeling As A Risk Management Strategy Enterprise Data World 2010 San Francisco March 17 th, 2010 All rights reserved. This material is protected under U.S. and Canadian copyright. No part of this material may be redistributed, reproduced, copied, or stored by any mechanism, either electronic or manual, without the prior written consent of Roberts Logan Inc. Roberts Logan Inc. Unit Weldrick Road West Richmond Hill, ON L4C 3V2 Canada Phone: Enterprise Data World 2010 March Page 1 of 24

2 AGENDA What Risk? ROBERTS Risk Management Primer What is a Model? Why Model? What is a Data Model? Why Data Model? Risk Management Summary Enterprise Data World 2010 March Page 2 of 24

3 WHAT RISK? That process includes dozens of partners around the globe that build and pre-assemble big pieces of the plane. Boeing s s job is to manage this far-flung flung supply chain and to make sure the parts fit together flawlessly on the factory floor Fortune Magazine, May 2008 WHAT RISK? Ford Europe began to build and prove out vehicles virtually instead of with physical models. This digital pre- assembly cut 14 months out of a typical four-year car development program and enabled engineers to check out 16,000 design elements before fabrication Fortune Magazine, May 2008 Page 3 of 24

4 WHAT S S THE REAL RISK? Fortune Custom Publishing survey, May 2009: More than 66% of respondents believe continued investment in technology will pay important benefits. More than 50% say they realized productivity or cost savings within 12 months. Less than 50% of the respondents say their companies are effective in implementing technologies. Only 33% of the respondents think their companies are very good at developing new products and services that address changing business requirements or take advantage of new opportunities. WHAT S S THE REAL RISK? There are a few lessons that large companies just don t t seem to learn The first lesson is that the best way to build a large, complex system is to evolve it from a small system that works. No one bothered to get a small system up and running in the first place they went for the big bang But once the system gets to a certain point, there is an attitude that the project s too big too fail, that we have to make it work now. There is an unwillingness in upper management to believe that things are as bad as they are. Bruce Webster, Principal, Webster & Associates, ComputerWorld June 2005 Page 4 of 24

5 RISK MANAGEMENT PRIMER A structured approach to managing risk or uncertainty, including identify, analyze, plan, control, and communicate. Risk management techniques are avoidance (eliminate), reduction (mitigate), transference (outsource or insure), or retention (accept & budget). Benefits of modeling to Risk Management : Introduce more rigor in the early deliverables of a project, so they can be objectively evaluated. Reveal mistakes early in the development life cycle, when it s s cheaper, faster, & easier to fix. Scope the deliverables into bite-sized loosely coupled parts so you deliver the product in iterative phases. Use the discrete parts of a model as an objective basis for estimating effort and measuring progress. RISK MANAGEMENT because risk is usually an indicator of value we need to learn to run toward risk, not run away from it. (If a project has no risks at all, don t t do it!). But when you re running toward risk you also need to take certain reasonable precautions. These precautions make up the heart of the discipline called risk management. Tom DeMarco, EDA Centrum Forum 2004 Risk Management is Project Management for Adults Page 5 of 24

6 MODELING USAGE TODAY ScienceCartoonsPlus.com METHODOLOGY USAGE TODAY Page 6 of 24

7 WHAT IS A MODEL? A model is a communication mechanism that visually & rigorously describes a simplified abstraction of a product in sufficient clarity & detail so that the components of the product can be verified & validated before the product is delivered. VERIFICATION Page 7 of 24

8 VALIDATION WHAT IS A MODEL? A model can be built. A model that can t t be built is a picture. Page 8 of 24

9 WHY MODEL? We build models to communicate the desired structure and behavior of our system. We build models to visualize and control its architecture. We build models to better understand the system we are building, often exposing opportunities for simplification and reuse. We build models to manage risk. Grady Booch, Chief Scientist, Rational Corp. (IBM) WHY MODEL? Models are designed to help people envision how the parts fit together, reduce the development risk, and ensure that the people building the product and those requesting it have the same expectations Claudia Imhoff, Nicholas Galemmo, & Jonathan Geiger Mastering Data Warehouse Design Page 9 of 24

10 WHY MODEL? Analyze Design Build Deploy PHASE RISK-MANAGEMENT CRITERIA SIMPLIFY MODULARIZE PRIORITIZE CONFIRM GOODNESS OF FIT REVISE & REPEAT Page 10 of 24

11 SIMPLIFY & MODULARIZE SIMPLIFY & MODULARIZE PERSONNEL COACH coaches TEAMS ooo utilizes CONTRACTS PLAYER signs plays for COUPLING FACILITIES ooo OPTION includes CONTRACT COHESION Page 11 of 24

12 SIMPLIFY & MODULARIZE CLARITY OF WRONG While there is no guarantee that a model is right, when it s s wrong, it is glaringly, demonstrably, indefensibly wrong. This seems to me to be an enormous advantage of modeling. Tom DeMarco Structured Analysis & System Specification Page 12 of 24

13 WHY MODEL? KNOWLEDGE Analyze Design Build Deploy PHASE WHY MODEL? MISTAKE COUNT Analyze Design Build Deploy PHASE Page 13 of 24

14 WHY MODEL? EFFORT & DOLLARS TO FIX Analyze Design Build Deploy PHASE WHY MODEL? EFFORT & DOLLARS TO FIX By intensely studying customer preferences early the team hopes to limit design changes late in the design cycle. Analyze Design Build Deploy PHASE Page 14 of 24

15 WHAT IS A MODEL (DATA)? A rigorous method that: analyzes, classifies, and organizes data into simplified patterns that are highly cohesive, loosely coupled, and audience-verifiable; clearly communicates the patterns; and enables the iterative delivery of a database to support those patterns. A visual blueprint of data assumptions, written in a rigorous businessoriented language/syntax, that communicates data, data characteristics, and the naturally occurring relationships between the data A visual specification for an engineered approach to project management that communicates set(s) of agreed-upon work products in incremental levels of detail in the life cycle of a project A point-in-time application-agnostic representation that communicates the data rules at a level of abstraction that excludes the distraction of the details (for example, verbose narrative, why wanted, how populated, ) A multi-perspective abstraction that communicates the data requirements of an organization ( permanent organizational memory ), independent of: Technology; Environment; and Organizational alignment. SCOPE A PROJECT PERSONNEL COACH coaches coaches PLAYER signs plays for TEAMS ooo utilizes FACILITIES ooo CONTRACTS OPTION includes CONTRACT Focus Release 1 Structure Release 2 Scope Mis-communication?? Page 15 of 24

16 MANAGE RISK Provide an easy-to to-read visual method by which scope can be identified, so that a project may be broken up into smaller cohesive groupings for purposes of scope-in and scope-out out Provide a specification mechanism to enable a more rigorous method of project estimation, based on a discrete count of objects and an estimated duration per object Provide an early-warning mechanism to generate rigorous deliverables earlier in the life cycle, when very little is known Provide a method of assessing project progress based upon agreed-upon deliverable contents, so that progress-to to-date can be objectively and consistently measured, even though very little is known Manage risk by introducing measurable rigor as early as possible in the project life cycle MANAGE RISK IN 2010 Provide a visual easily understood communication mechanism for decomposing a project into smaller highly- cohesive loosely-coupled groupings for purposes of scoping Provide the basis for a project management process by which effort can be consistently estimated and progress can be objectively measured at defined milestones / checkpoints Provide a rigorous set of consistent deliverables that allows design & development to be distributed across separate subject-aligned teams, geographies, etc. Provide an objective framework for a measurable metrics- based approach to database design and development. Provide an architectural foundation for an Enterprise Data Warehouse, Data Quality / Profiling, Sarbanes-Oxley compliance, Basel II, & Master Data Management. Page 16 of 24

17 GOOD ENOUGH If we want to learn anything, we must not try to learn everything. Tom DeMarco Structured Analysis & System Specification GOOD ENOUGH If we want to deliver anything, we must not try to deliver everything. Bob Zoltok Page 17 of 24

18 GOOD ENOUGH A model is good enough when: It has been completed to the level of detail expected for the iteration; It has been reviewed and approved by the audience(s) appropriate to the iteration; and It is sufficiently complete to be used as input into the next iteration. WHY GOOD ENOUGH? Your resistance to change your model is directly proportional to the level of effort you have expended to produce the model. Page 18 of 24

19 RESISTANCE TO CHANGE RESISTANCE TO CHANGE Analyze Design Build Deploy LEVEL OF EFFORT WILLINGNESS TO CHANGE WILLINGNESS TO CHANGE Analyze Design Build Deploy LEVEL OF EFFORT Page 19 of 24

20 ABILITY TO CHANGE ABILITY TO CHANGE Analyze Design Build Deploy LEVEL OF EFFORT AFFECTED TOUCH POINTS AFFECTED TOUCH POINTS Analyze Design Build Deploy LEVEL OF EFFORT Page 20 of 24

21 EFFORT & DOLLARS TO CHANGE EFFORT & DOLLARS TO CHANGE Analyze Design Build Deploy LEVEL OF EFFORT MODEL-BASED RISK MANAGEMENT A random trial-and and-error walk with no rigorous targets and no verification criteria OR A planned define-and and-refine iterative model with pre-defined measurable targets and not-on-the-wrong-path criteria Page 21 of 24

22 MODEL-BASED RISK MANAGEMENT 1. Modeling will not decrease the number of mistakes; it will change the timing of when you discover the mistakes. 2. The goal of modeling is to reveal mistakes early in the development life cycle, when it s s cheaper, faster, & easier to fix. Get used to it and plan for it. 3. The advantages of modeling will be decreased if you front- load the project with lots of people and lots of touch points. 4. Modeling is the basis for scoping a project into bite-size pieces so you can deliver the end product iteratively in phases. If you choose to deliver the whole thing at once, you negate a major advantage of modeling. 5. One of modeling s s goals is to introduce some rigor into the early deliverables of a project. These deliverables will have no value if you don t t review, quality check, and approve these deliverables when they re delivered. 6. Modeling is the project manager s s best friend. Expect resistance. MODEL-BASED RISK MANAGEMENT Model-based risk management will not make you smarter Model-based risk management should make you smarter earlier in the life cycle. Page 22 of 24

23 MODEL-BASED RISK MANAGEMENT The primary feature of model-based risk management is the rigor and clarity it brings earlier in the development life cycle, so as to reveal your mistakes when the cost of fixing them is manageable. MODEL-BASED RISK MANAGEMENT The primary benefit of model-based risk management is the development of a framework that is modular, so that the underlying product may be delivered in phases over time. Page 23 of 24

24 OGAN Modeling As A Risk Management Strategy Roberts Logan Inc. robertslogan@netscape.ca Page 24 of 24