Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
The IT
       Litigator’s
        Library
                Edward Yourdon
                      Ed Yourdon
               e...
Publication Details and Disclaimer




Published under the GNU Free Documentation License (GFDL)   2
Publication Details and Disclaimer
            This presentation is an open-content collaborative document. Anyone with an...
Introduction




Published under the GNU Free Documentation License (GFDL)   3
Introduction
✮ Large percentage of IT projects are over budget, behind
        schedule, buggy, unusable, inflexible, etc....
Introduction
✮ Large percentage of IT projects are over budget, behind
        schedule, buggy, unusable, inflexible, etc....
Introduction
✮ Large percentage of IT projects are over budget, behind
        schedule, buggy, unusable, inflexible, etc....
Introduction
✮ Large percentage of IT projects are over budget, behind
        schedule, buggy, unusable, inflexible, etc....
Introduction
✮ Large percentage of IT projects are over budget, behind
        schedule, buggy, unusable, inflexible, etc....
Introduction
✮ Large percentage of IT projects are over budget, behind
        schedule, buggy, unusable, inflexible, etc....
Introduction
✮ Large percentage of IT projects are over budget, behind
        schedule, buggy, unusable, inflexible, etc....
Introduction
✮ Large percentage of IT projects are over budget, behind
        schedule, buggy, unusable, inflexible, etc....
Introduction
✮ Large percentage of IT projects are over budget, behind
        schedule, buggy, unusable, inflexible, etc....
The Nature of IT Risks, #1
✮ Brooks, Fred. The Mythical Man-Month (20th anniversary edition,
        Addison-Wesley, 1995)...
The Nature of IT Risks
✮ Jones, Capers. Patterns of Software Systems Failure and Success
        (International Thomson Co...
Peopleware #1
✮ Austin, Robert D. Measuring and Managing Performance in
        Organizations (Dorset House, 1996)
       ...
Peopleware #2
✮ McCarthy, Jim. Dynamics of Software Development (Microsoft Press,
        1995).
        ✔ From the former...
Process #1
  ✮ Beck, Kent. eXtreme Programming eXplained: Embrace Change
        (Addison-Wesley, 2000)
         ✔ For man...
Process #2
  ✮ Leffingwell, Dean and Don Widrig. Managing Software Requirements:
       A Unified Approach (Addison-Wesley...
Process #3
  ✮ Robertson, Suzanne, and James Robertson. Mastering the
         Requirements Process (Dorset House, 1999).
...
Technology
  ✮ Dertouzos, Michael. What Will Be: how the new world of
        information will change our lives (HarperEdg...
Conclusion




Published under the GNU Free Documentation License (GFDL)   12
Conclusion
✮ IT failures are often blamed on technology issues, but
        that’s only a small part of the story




Publ...
Conclusion
✮ IT failures are often blamed on technology issues, but
        that’s only a small part of the story
✮       ...
Conclusion
✮ IT failures are often blamed on technology issues, but
        that’s only a small part of the story
✮       ...
Conclusion
✮ IT failures are often blamed on technology issues, but
        that’s only a small part of the story
✮       ...
Conclusion
✮ IT failures are often blamed on technology issues, but
        that’s only a small part of the story
✮       ...
Upcoming SlideShare
Loading in …5
×

IT Litigators Library

705 views

Published on

This is an Apple Keynote version of a presentation that I've given in several legal conferences -- a reading list for attorneys about IT projects, and all the things that can go wrong with them.

  • Be the first to comment

IT Litigators Library

  1. 1. The IT Litigator’s Library Edward Yourdon Ed Yourdon email: ed@yourdon.com Website: www.yourdon.com Blog: www.yourdonreport.com Twitter, LinkedIn, Facebook, Plaxo, Flickr: “yourdon”
  2. 2. Publication Details and Disclaimer Published under the GNU Free Documentation License (GFDL) 2
  3. 3. Publication Details and Disclaimer This presentation is an open-content collaborative document. Anyone with an Internet connection and World Wide Web browser may view and/or alter its content — for better or worse. Please be advised that nothing in this document has necessarily been reviewed by Ed Yourdon ("Ed"); the theories and business practices expressed by the document are not necessarily his. This isn't to say you won't find valuable and accurate information herein; however, Ed cannot summarily guarantee the validity of this document. The content of any given page may recently have been changed, dumbed-down, or other wise edited by someone whose opinion does not correspond to Ed’s original material (or any subsequent drafts). Neither Ed, nor any of the contributors, collaborators, nor anyone else connected with this document, can in any way whatsoever be held responsible for the appearance of any inaccurate information, or for your use of the information contained in or linked from this document. You are being granted a limited license to copy anything from this document; it does not create or imply any contractual or extra-contractual liability on the part of Ed, nor any of the contributors, collaborators, or viewers of this material. There is no agreement or understanding bet ween you and Ed regarding your use or modification of this information beyond the GNU Free Documentation License (GFDL); neither is Ed responsible should someone change, edit, modify, or remove any information that you may post on this document. Any of the trademarks, ser vice marks, collective marks, design rights, personality rights, or similar rights that are mentioned, used, or cited in this document are the property of their respective owners. Their use here does not imply that you may use them for any purpose other than for the same or similar informational use — as recognized under the GFDL licensing scheme. Unless other wise stated, Ed and this document are neither endorsed by nor affiliated with any of the holders of any such rights; as such, Ed cannot grant any rights to use any other wise protected materials. Your use of any such or similar incorporated property is at your own risk. Published under the GNU Free Documentation License (GFDL) 2
  4. 4. Introduction Published under the GNU Free Documentation License (GFDL) 3
  5. 5. Introduction ✮ Large percentage of IT projects are over budget, behind schedule, buggy, unusable, inflexible, etc. Published under the GNU Free Documentation License (GFDL) 3
  6. 6. Introduction ✮ Large percentage of IT projects are over budget, behind schedule, buggy, unusable, inflexible, etc. ✮ Hence many disappointments, cancelled projects, system failures, financial losses, injuries, regulatory penalties, loss of competitive advantage, etc. Published under the GNU Free Documentation License (GFDL) 3
  7. 7. Introduction ✮ Large percentage of IT projects are over budget, behind schedule, buggy, unusable, inflexible, etc. ✮ Hence many disappointments, cancelled projects, system failures, financial losses, injuries, regulatory penalties, loss of competitive advantage, etc. ✮ Some of which leads to litigation… Published under the GNU Free Documentation License (GFDL) 3
  8. 8. Introduction ✮ Large percentage of IT projects are over budget, behind schedule, buggy, unusable, inflexible, etc. ✮ Hence many disappointments, cancelled projects, system failures, financial losses, injuries, regulatory penalties, loss of competitive advantage, etc. ✮ Some of which leads to litigation… ✮ It would be helpful for attorneys to have a better understanding of why IT projects fail: Published under the GNU Free Documentation License (GFDL) 3
  9. 9. Introduction ✮ Large percentage of IT projects are over budget, behind schedule, buggy, unusable, inflexible, etc. ✮ Hence many disappointments, cancelled projects, system failures, financial losses, injuries, regulatory penalties, loss of competitive advantage, etc. ✮ Some of which leads to litigation… ✮ It would be helpful for attorneys to have a better understanding of why IT projects fail: ✔ The nature of IT risks Published under the GNU Free Documentation License (GFDL) 3
  10. 10. Introduction ✮ Large percentage of IT projects are over budget, behind schedule, buggy, unusable, inflexible, etc. ✮ Hence many disappointments, cancelled projects, system failures, financial losses, injuries, regulatory penalties, loss of competitive advantage, etc. ✮ Some of which leads to litigation… ✮ It would be helpful for attorneys to have a better understanding of why IT projects fail: ✔ The nature of IT risks ✔ Peopleware issues Published under the GNU Free Documentation License (GFDL) 3
  11. 11. Introduction ✮ Large percentage of IT projects are over budget, behind schedule, buggy, unusable, inflexible, etc. ✮ Hence many disappointments, cancelled projects, system failures, financial losses, injuries, regulatory penalties, loss of competitive advantage, etc. ✮ Some of which leads to litigation… ✮ It would be helpful for attorneys to have a better understanding of why IT projects fail: ✔ The nature of IT risks ✔ Peopleware issues ✔ Process and methodology issues Published under the GNU Free Documentation License (GFDL) 3
  12. 12. Introduction ✮ Large percentage of IT projects are over budget, behind schedule, buggy, unusable, inflexible, etc. ✮ Hence many disappointments, cancelled projects, system failures, financial losses, injuries, regulatory penalties, loss of competitive advantage, etc. ✮ Some of which leads to litigation… ✮ It would be helpful for attorneys to have a better understanding of why IT projects fail: ✔ The nature of IT risks ✔ Peopleware issues ✔ Process and methodology issues ✔ Technology issues Published under the GNU Free Documentation License (GFDL) 3
  13. 13. Introduction ✮ Large percentage of IT projects are over budget, behind schedule, buggy, unusable, inflexible, etc. ✮ Hence many disappointments, cancelled projects, system failures, financial losses, injuries, regulatory penalties, loss of competitive advantage, etc. ✮ Some of which leads to litigation… ✮ It would be helpful for attorneys to have a better understanding of why IT projects fail: ✔ The nature of IT risks ✔ Peopleware issues ✔ Process and methodology issues ✔ Technology issues ✮ To help accomplish this, a recommended reading list is provided. The book titles are all hyperlinks that will lead you to the appropriate page on the Amazon web site. Published under the GNU Free Documentation License (GFDL) 3
  14. 14. The Nature of IT Risks, #1 ✮ Brooks, Fred. The Mythical Man-Month (20th anniversary edition, Addison-Wesley, 1995) ✔ One of the earliest, and most famous, “bibles” about basic software engineering principles and what can go wrong on large, complex projects. Originally published in 1975, and then updated in 1975 ✮ DeMarco, Tom. The Deadline: A Novel About Project Management (Dorset House, 1997) ✔ Another summary of the many issues and risks associated with large complex — and highly political! — projects, written in the form of a novel. Appears to be light reading, but covers many deep, significant points. ✮ Dorner, Dietrich. The Logic of Failure: Recognizing and Avoiding Failure in Complex Systems (Addison-Wesley, 1996) ✔ To many veterans, managing a large, complex project is not about achieving success, but rather avoiding failure — or at least anticipating failure early enough to be able to avoid it, minimize it, and/or cope with it. ✮ Jones, Capers. Assessment and Control of Software Risks (Prentice Hall, 1994) ✔ Jones approaches the subject of IT risks in the manner that health officials catalog and describe diseases and contagions: symptoms, carriers, consequences, cures, etc. A very different, and quite intriguing, perspective on software risks. Published under the GNU Free Documentation License (GFDL) 4
  15. 15. The Nature of IT Risks ✮ Jones, Capers. Patterns of Software Systems Failure and Success (International Thomson Computer Press, 1996). ✔ More of a statistical summary of the various causes (individually, and in tandem with one another) of software failures ✮ Hall, Elaine. Managing Risk: Methods for Software Systems Development (Addison-Wesley, 1998) ✔ Risk management is not just about identifying risks, but also developing processes and strategies for escalating them (on the assumption that the project manager often lacks authority to deal with them personally), managing, and mitigating them ✮ Minasi, Mark. The Software Conspiracy (McGraw-Hill, 1999) ✔ Argues that many of the larger software-product vendors (especially the “shrink-wrap” companies) know exactly how mediocre their products are, but are more concerned about getting their (buggy) products into the marketplace quickly than assuring that their customers will receive well-tested, usable products ✮ Neumann, Peter. Computer-Related Risks (Addison-Wesley, 1995) ✔ Drawn from thousands of examples, and a couple of decades of coverage of computer-related problems and failures reported in the Communications of the ACM. Catalogs many different categories of failures, and reminds the reader of things like the law of unintended consequences, and other subtle causes of problems. Published under the GNU Free Documentation License (GFDL) 5
  16. 16. Peopleware #1 ✮ Austin, Robert D. Measuring and Managing Performance in Organizations (Dorset House, 1996) ✔ Vendor marketing brochures, and documents associated with litigation, often claim that IT project personnel are either talented, competent, or incompetent. But how do you measure the performance and skills of IT people? Austin, a professor at the Harvard Business School, has some provocative things to say on the subject. ✮ Curtis, Bill et al. People Capability Maturity Model (Addison-Wesley, 2001) ✔ The people who brought us the SEI-CMM have now got a model that describes the “maturity” of IT organizations, in terms of their human-resource practices — e.g., the sophistication and maturity of recruiting, hiring, motivation, training, compensation, and other practices. ✮ DeMarco, Tom, and Timothy Lister. Peopleware: Productive Projects and Teams (2nd edition, Dorset House, 1997) ✔ Considered by many to be the bible in terms of “best practices” for nurturing the individuals and teams who build IT systems. DeMarco and Lister once worked in my software consulting/ training company, and Peopleware is sometimes known as “a compendium of all the things Ed did wrong when managing his company.” ✮ Humphrey, Watts. Managing Technical People: Innovation, Teamwork, and the Software Process (Addison-Wesley, 1997) ✔ A more traditional, and classical, treatment of issues, strategies, and guidelines for managing technical people — from the “father” of the SEI-CMM at the Software Engineering Institute. Published under the GNU Free Documentation License (GFDL) 6
  17. 17. Peopleware #2 ✮ McCarthy, Jim. Dynamics of Software Development (Microsoft Press, 1995). ✔ From the former manager of Microsoft’s Visual C++ project team, a highly readable, no- nonsense discussion of both peopleware issues and other project management issues. Great aphorisms and suggestions like “Don’t flip the bozo bit” and “Never let a programmer disappear into a dark room.” ✮ Weinberg, Jerry. The Psychology of Computer Programming (silver anniversary edition, Dorset House, 1996) ✔ First published in 1971, and generally considered the first book acknowledging that software is written by people, and that the human/sociological/psychological issues need to be kept in mind, because software is not written by robots. Updated 25 years after its original publication, and still highly relevant. Technology has obviously changed enormously in the past 25 years, but (with rare exceptions) people are still people. ✮ Whitaker, Ken. Managing Software Maniacs (John Wiley & Sons, 1994) ✔ As the title implies, this book is about the difficult job that project managers usually have, when managing high-strung programmers working on a high-pressure project — a task sometimes described as “herding cats”. And if you believe Whitaker’s message, and follow his guidelines, then arguably there is no excuse for letting even the wildest, craziest project get out of control because the programmers are “unmanageable”. Published under the GNU Free Documentation License (GFDL) 7
  18. 18. Process #1 ✮ Beck, Kent. eXtreme Programming eXplained: Embrace Change (Addison-Wesley, 2000) ✔ For many small, internal, non-safety-critical IT projects, a methodology known as “extreme programming” has become quite popular. There are about half a dozen books discussing different aspects of it; this one, by Kent Beck, is the first and arguably the best. ✮ Boehm, Barry. Software Cost Estimation with COCOMO II (paperback edition, Prentice Hall, 2009) ✔ One of the “processes” that typically takes place at the beginning of a project (assuming that schedule, budget, and other project parameters were not simply imposed by fiat) is “estimating”. There are several mathematical models for doing this, of which COCOMO (an acronym for COnstructive COst MOdel is probably the best known. The author, Barry Boehm, is considered one of the pioneers and gurus in the field. ✮ Davis, Alan. 201 Principles of Software Development (McGraw-Hill, 1995) ✔ Alan Davis is a world authority on software requirements management, and has written several books on the subject. But this book is pretty much what the title implies: a bunch of short (one-page or less), simple, bite-sized principles about software development. ✮ Highsmith, James. Adaptive Software Development (Dorset House, 1999) ✔ In many of today’s IT projects, the classical task of defining requirements is considered fruitless, because (a) the users don’t know what they want, (b) they change their mind, and (c) the external world imposes its own chaotic changes throughout the course of the project. Thus, success is often not based on having a rigid, disciplined — but static and unchangeable — process, but rather by having a process that emphasizes agility and flexibility. Highsmith is one of the most articulate advocates of this new IT approach. Published under the GNU Free Documentation License (GFDL) 8
  19. 19. Process #2 ✮ Leffingwell, Dean and Don Widrig. Managing Software Requirements: A Unified Approach (Addison-Wesley, 1999) ✔ Leffingwell and Widrig point out that there are three separate issues associated with software requirements: (a) eliciting the requirements from users who often don’t know what they want, (b) documenting the requirements so that concurrence and communication are possible, and ( c) managing the requirements throughout the course of the project, when new requirements are added and old requirements are dropped, and the relative priority of remaining requirements goes up and down dynamically ✮ McConnell, Steve. Rapid Development: Taming Wild Software Schedules (Microsoft Press, 1996). ✔ The title speaks for itself. Much of the emphasis in this book, by the former editor of IEEE Software, and a recognized guru in the field, has to do with prototyping, iterative/spiral development methods, risk management, etc. ✮ Metzger, Philip and John Boddie. Managing a Programming Project (3rd edition, Prentice Hall, 1995) ✔ A more traditional project management book, which covers the “basics” of managing and controlling progress (or lack of same), schedules, budgets, estimates, etc etc. ✮ Paulk, Mark C., Charles V. Weber, Bill Curtis, Mary Beth Chrissis, and a cast of thousands. The Capability Maturity Model: Guidelines for Improving the Software Process (Addison-Wesley,1995) ✔ A full and complete treatment of the basic SEI-CMM, by the key people who worked on it at the Software Engineering Institute. This may eventually be superseded by SEI-CMM/I Published under the GNU Free Documentation License (GFDL) 9
  20. 20. Process #3 ✮ Robertson, Suzanne, and James Robertson. Mastering the Requirements Process (Dorset House, 1999). ✔ A second excellent book on software requirements; a third such book is the one written by Karl Wiegers. The Robs (as they were known when they worked for my company) introduce a simple approach called VOLARE for managing requirements ✮ Sullivan, Ed, and John Robbins. Under Pressure and On Time (Microsoft Press, 2001). ✔ A Microsoft perspective on managing projects that are under intense time pressure, but which still have to be finished on time. ✮ Yourdon, Edward. Death March (2nd edition, Prentice Hall, 2004) ✔ A death-march project, loosely speaking, is one that for which a COCOMO-generated schedule, budget, and project team has basically been cut in half; in most cases, it appears that the only way to succeed is for the team to work a “death-march” schedule of heavy overtime. For IT litigators, a key question is whether the death-march nature was (or should have been) recognized from the very beginning, or whether a properly-planned project has somehow degenerated into a death-march. Also, a key question is which of the “regular” process activities can be compromised, shortened, or ignored in a death-march. ✮ Yourdon, Edward. Managing High Intensity Internet Projects (Prentice-Hall, 2001) ✔ An updated version of the death-march project, dealing specifically with the super-intense dot-com, e-business, and Internet-oriented projects developed almost everywhere in the late 1990s and early 2000s. Published under the GNU Free Documentation License (GFDL) 10
  21. 21. Technology ✮ Dertouzos, Michael. What Will Be: how the new world of information will change our lives (HarperEdge, 1997) ✔ A futuristic look at computer technology by the late Director of MIT’s computer lab. ✮ Landauer, Thomas K. The Trouble With Computers: Usefulness, Usability, and Productivity (MIT Press, 1995). ✔ A highly skeptical assessment of the powers and possibilities of computer technology, especially useful to help offset the gushing optimism of books like Negroponte’s below. ✮ Negroponte, Nicholas. Being Digital (Alfred A. Knopf, 1995) ✔ Written by the former director of MIT’s Media Lab, at the beginning of the hype-period associated with the Web. Negroponte was also one of the founding columnists of Wired magazine ✮ Postman, Neil. Technopoly: The Surrender of Culture to Technology (Random House, 1993) ✔ Written by a British sociologist and management consultant, who has a very dour opinion of the impact of technology on much of what is considered “good” about our current organizational and social culture. Depressing, but recommended reading. ✮ Stoll, Clifford. Silicon Snake Oil: Second Thoughts on the Information Highway (Doubleday, 1995) ✔ Somewhat dated at this point, but still worth reading — by the author of The Cuckoo’s Egg, which described one of the first high-tech computer hacking cases. Stoll is a wild, crazy, but brilliant and captivating speaker; if you ever hear that he’s on the program of any conference you’re attending, be sure to wear a Kevlar vest, but don’t miss his talk! Published under the GNU Free Documentation License (GFDL) 11
  22. 22. Conclusion Published under the GNU Free Documentation License (GFDL) 12
  23. 23. Conclusion ✮ IT failures are often blamed on technology issues, but that’s only a small part of the story Published under the GNU Free Documentation License (GFDL) 12
  24. 24. Conclusion ✮ IT failures are often blamed on technology issues, but that’s only a small part of the story ✮ Key issue is whether potential risks were acknowledged and managed properly throughout the project. Published under the GNU Free Documentation License (GFDL) 12
  25. 25. Conclusion ✮ IT failures are often blamed on technology issues, but that’s only a small part of the story ✮ Key issue is whether potential risks were acknowledged and managed properly throughout the project. ✮ Example: look at the Appendix to the Rogers Commission Report on the Space Shuttle Challenger Accident, in which Nobel-prize winner Richard Feynman observed: Published under the GNU Free Documentation License (GFDL) 12
  26. 26. Conclusion ✮ IT failures are often blamed on technology issues, but that’s only a small part of the story ✮ Key issue is whether potential risks were acknowledged and managed properly throughout the project. ✮ Example: look at the Appendix to the Rogers Commission Report on the Space Shuttle Challenger Accident, in which Nobel-prize winner Richard Feynman observed: ✔ “It appears that there are enormous differences of opinion as to the probability of a failure with loss of vehicle and of human life. The estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures come from the working engineers, and the very low figures from management. What are the causes and consequences of this lack of agreement? Since 1 part in 100,000 would imply that one could put a Shuttle up each day for 300 years expecting to lose only one, we could properly ask ‘What is the cause of management's fantastic faith in the machinery?’” Published under the GNU Free Documentation License (GFDL) 12
  27. 27. Conclusion ✮ IT failures are often blamed on technology issues, but that’s only a small part of the story ✮ Key issue is whether potential risks were acknowledged and managed properly throughout the project. ✮ Example: look at the Appendix to the Rogers Commission Report on the Space Shuttle Challenger Accident, in which Nobel-prize winner Richard Feynman observed: ✔ “It appears that there are enormous differences of opinion as to the probability of a failure with loss of vehicle and of human life. The estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures come from the working engineers, and the very low figures from management. What are the causes and consequences of this lack of agreement? Since 1 part in 100,000 would imply that one could put a Shuttle up each day for 300 years expecting to lose only one, we could properly ask ‘What is the cause of management's fantastic faith in the machinery?’” ✮ Bottom line: the more you understand about why IT failures occur, the better you’ll be able to prosecute and/ or defend such cases. Published under the GNU Free Documentation License (GFDL) 12

×