CHANGE: Planned & Unplanned
CHANGE: Planned & Unplanned
$9.99
Minimum price
$9.99
Suggested price
CHANGE: Planned & Unplanned

Last updated on 2014-09-10

About the Book

Gerald M. Weinberg illustrates how to create a supportive environment for software engineering —an environment in which your organization can realize long-lasting gains in quality and productivity by learning how to manage change.

As the author argues, the history of software engineering is riddled with failed attempts to improve quality and productivity without first creating a supportive environment. Many managers spend their money on tools, methodologies, outsourcing, training, and application packages, but they rarely spend anything to improve or to remove the management that created those situations in the first place.

From systems thinking to project management to technology transfer to the interaction of culture and process, this volume analyzes transformation from a broad range of perspectives, providing a breadth of awareness essential for successful management of high-quality software development.

Topics include:

Meta-Planning: Information

Meta-Planning: Systems Thinking

Tactical Change Planning

Planning Like a Software Engineer

What Changes Have to Happen

Components of Stable Software Engineering

Process Principles

Culture and Process

Improving Process

Requirements Principles and Process

Changing the Requirements Process

The book also had five important appendices:

Appendix A: The Diagram of Effects

Appendix B: The Software Engineering Cultural Patterns

Appendix C. The Satir Interaction Model

Appendix D. Control Models

Appendix E. The Three Observer Positions

About the Author

Gerald M. Weinberg
Gerald M. Weinberg

I've always been interested in helping smart people be happy and productive. To that end, I've published books on human behavior, including Weinberg on Writing: The Fieldstone Method, The Psychology of Computer Programming, Perfect Software and Other Fallacies, and an Introduction to General Systems Thinking. I've also written books on leadership including Becoming a Technical Leader, The Secrets of Consulting (Foreword by Virginia Satir), More Secrets of Consulting, and the nine-volume Quality Software series.

I try to incorporate my knowledge of science, engineering, and human behavior into all of my writing and consulting work (with writers, hi-tech researchers, software engineers, and people whose life-situation could require the use of a service dog). I write novels about such people, including The Aremac Project, Aremac Power, Jigglers, First Stringers, Second Stringers, The Hands of God, Freshman Murders, Where There's a Will There's a Murder, Earth's Endless Effort, and Mistress of Molecules—all about how my brilliant protagonists produce quality work and learn to be happy. My books that are not yet on Leanpub may be found as eBooks at <http://www.smashwords.com/profile/view/JerryWeinberg>; on Amazon at http://www.amazon.com/-/e/B000AP8TZ8; and at Barnes and Noble bookstore: http://tinyurl.com/4eudqk5.

Early in my career, I was the architect for the Project Mercury's space tracking network and designer of the world's first multiprogrammed operating system. I won the Warnier Prize, the Stevens Award, and the first Software Testing Professionals' Luminary Award, all for my writing on software quality. I was also elected a charter member of the Computing Hall of Fame in San Diego and chosen for the University of Nebraska Hall of Fame.

But the "award" I'm most proud of is the book, The Gift of Time (Fiona Charles, ed.) written by my student and readers for my 75th birthday. Their stories make me feel that I've been at least partially successful at helping smart people be happy.

Bundles that include this book

How Software Is Built
Why Software Gets In Trouble
How To Observe Software Systems
Responding to Significant Software Events
Managing Yourself and Others
11 Books
$106.89
Suggested Price
$49.99
Bundle Price

Table of Contents

  • Change: Planned and Unplanned
    • Part I. Planning for the Future Organization
    • Chapter 1. Meta-Planning: Part I. Information
      • 1.1 Start by Meta-Planning
      • 1.2 Information Gathering
        • 1.2.1 Omission of information
        • 1.2.2 Unreliable sources
        • 1.2.3 Wrong level of detail
      • 1.3 Mechanics
      • 1.4 Helpful Hints and Suggestions
      • 1.5 Summary
      • 1.6 Practice
    • Chapter 2. Meta-Planning: Part II. Systems Thinking
      • 2.1 Problem solving
        • 2.1.1 The Big Game
        • 2.1.2 No systematic approach for decision making
      • 2.2 Growth and Size
        • 2.2.1 Growth produces bigness
        • 2.2.2 Complexity restricts development
        • 2.2.3 Size restricts freedom
        • 2.2.4 Tools influence thought
        • 2.2.5 Big isn’t the same as small
      • 2.3 Risk and Reward
        • 2.3.1 Always be first
        • 2.3.2 Always be second
        • 2.3.3 Don’t risk
        • 2.3.4 Don’t even talk about risk
      • 2.4 Trust
        • 2.4.1 You go first
        • 2.4.2 Management swooping
      • 2.5 Moving Off a Dead Stop
        • 2.5.1 Critical mass
        • 2.5.2 Chicken-and-egg syndrome
        • 2.5.3 Wrong cultural prescriptions
        • 2.5.4 Hooked by resisters
      • 2.6 Helpful Hints and Suggestions
      • 2.7 Summary
      • 2.8 Practice
    • Chapter 3. Tactical Change Planning
      • 3.1 What Is Tactical Change Planning?
      • 3.2 Open-Ended Change Planning
      • 3.3 Plans Are Made Backward
        • 3.3.1 Test: Is it clear?
        • 3.3.2 Test: Is it specific?
        • 3.3.3 Test: Is each component accountable and dependable?
      • 3.4 Choosing a New, Realistic Goal
      • 3.5 Congruence from Start to Finish
        • 3.5.1 Self: Where are you now?
        • 3.5.2 Others: Who will be affected?
        • 3.5.3 Context: What should be preserved?
      • 3.6 Selecting and Testing a Goal
        • 3.6.1 Use a positive format.
        • 3.6.2 Be sure it’s achievable
        • 3.6.3 Be sure it’s observable
        • 3.6.4 Make it specific
        • 3.6.5 Be sure the goal is not too tight
        • 3.6.6 Explore variations
        • 3.6.7 Eliminate solution statements
      • 3.7 What Stands in the Way of Achieving the Goal?
        • 3.7.1 Check for obstacles
        • 3.7.2 Look for stabilizing feedback loops
      • 3.8 Models for Planning in the Face of Unpredictability
        • 3.8.1 Check risks and resources using the PLASTIC model
        • 3.8.2 Check resources against the MOI Model
        • 3.8.3 Check human resources using emotional information
      • 3.9 The Feedback Plan
      • 3.10 Helpful Hints and Suggestions
      • 3.11 Summary
      • 3.12 Practice
    • Chapter 4. Planning Like a Software Engineer
      • 4.1 What Engineering Control Means
        • 4.1.1 Dynamic models, not magic formulas
        • 4.1.2 Trading off
        • 4.1.3 Juggling multiple variables
        • 4.1.4 Handling new levels of technology
      • 4.2 The Fundamental Graph of Engineering Management Action
      • 4.3 Levels of Control
        • 4.3.1 Multi-level stability
        • 4.3.2 Placing decisions at the right level
        • 4.3.3 Decisions at higher levels can control decisions at lower levels
        • 4.3.4 Decisions at low levels can control decisions at higher levels
        • 4.3.5 Amplification by position
      • 4.4 Helpful Hints and Suggestions
      • 4.4 Summary
      • 4.5 Practice
    • Chapter 5. Components of Stable Software Engineering
      • 5.1 Why Software Isn’t Different
      • 5.2 Why Software Costs So Much
        • 5.2.1 System size
        • 5.2.2 People factors
        • 5.2.3 Tool factors
        • 5.2.4 Poor management
      • 5.3 Where Improvement Can Be Found
      • 5.4 Why Software Projects Fail
      • 5.5 Information Failures
        • 5.5.1. Not knowing what product is wanted
        • 5.5.2. Not understanding the nature of the processes
        • 5.5.3 Having no visible evidence of progress
        • 5.5.4 Lacking sufficient stability for meaningful measurements
        • 5.5.5 Lacking or losing design integrity
      • 5.6 Evolving Solutions to Information Failures
        • 5.6.1. A requirements process to identify what product is wanted
        • 5.6.2 Process models to explain the nature of software development
        • 5.6.3 Processes that provide visible evidence on progress
        • 5.6.4 Systems to provide stability for meaningful measurements
        • 5.6.5 Tools and techniques to maintain design integrity
      • 5.7 Action Failures
      • 5.8 Helpful Hints and Suggestions
      • 5.9 Summary
      • 5.10 Practice
    • Chapter 6. Process Principles
      • 6.1 The Millionaire Test
      • 6.2 The Stability Principle
        • 6.2.1 Phrases to listen for
        • 6.2.2 Actions to take
      • 6.3 The Visibility Principle
        • 6.3.1 Phrases to listen for
        • 6.3.2 Actions to take
      • 6.4 The Measurability Principle
        • 6.4.1 Phrases to listen for
        • 6.4.2 Actions to take
      • 6.5 The Product Principle
        • 6.5.1 Phrases to listen for
        • 6.5.2 Actions to take
      • 6.6 Helpful Hints and Suggestions
      • 6.7 Summary
      • 6.8 Practice
    • Chapter 7. Culture and Process
      • 7.1 The Culture/Process Principle
      • 7.2 Examples of the Interaction of Culture and Process
        • 7.2.1 Don’t kill anyone and don’t go to jail
        • 7.2.2 Bring ‘em back alive
        • 7.2.3 Quick results
        • 7.2.4 Don’t make a wrong decision
        • 7.2.5 Number of customers
      • 7.3 Three Meanings of Process
        • 7.3.1 Supervisory level: Making the product
        • 7.3.2 Middle management level: Creating process models
        • 7.3.3 Top management level: Creating a culture
      • 7.4 What Creates the Culture?
      • 7.5 Helpful Hints and Suggestions
      • 7.6 Summary
      • 7.7 Practice
    • Chapter 8. Improving Process
      • 8.1 Three Levels of Process Improvement
      • 8.2 An Example of Process Improvement
        • 8.2.1 Document the actual process
        • 8.2.2 Discover the root cause of the problem
        • 8.2.3 Modify the process to reduce variation
        • 8.2.4 Test the process improvements
      • 8.3 Seeing the Invisible
      • 8.4 Preventing Future Occurrences
      • 8.5 Lessons
      • 8.6 Sure, But We’re Different
      • 8.7 But It Costs Too Much
      • 8.7 Helpful Hints and Suggestions
      • 8.8 Summary
      • 8.9 Practice
    • Chapter 9. Requirements Principles and Process
      • 9.1 The Assumption of Fixed Requirements
      • 9.2 The Zeroth Law
        • 9.2.1 Phrases to listen for
        • 9.2.2 Actions to take
      • 9.3 Process Models of Requirements
      • 9.4 The Twin Processes
      • 9.5 Upward Flow of Requirements
      • 9.6 Management’s Attitude Toward the Requirements Process
      • 9.7 Helpful Hints and Suggestions
      • 9.8 Summary
      • 9.9 Practice
    • Chapter 10. Changing the Requirements Process
      • 10.1 Measure the True Cost and Value of Requirements
        • 10.1.1 Faults caught early or not created at all
        • 10.1.2 Redundant work eliminated
        • 10.1.3 Better reception by customers
        • 10.1.4 Faster, more manageable, development
        • 10.1.5 Improved maintenance
      • 10.2 Gain Control of the Requirements Inputs
        • 10.2.1 Identify and plug all leaks
        • 10.2.2 Replace leaks with explicit negotiation
      • 10.3 Gain Control of Requirements Outputs
        • 10.3.1 Visibility
        • 10.3.2 Stability
        • 10.3.3 Controllability
      • 10.4 Gain Control of the Requirements Process Itself
        • 10.4.1 Resource support
        • 10.4.2 Process support
      • 10.5 Helpful Hints and Suggestions
      • 10.6 Summary
      • 10.7 Practice
    • Appendix A: The Diagram of Effects
    • Appendix B: The Software Engineering Cultural Patterns
      • Pattern 0. Oblivious Process
      • Pattern 1: Variable Process
      • Pattern 2: Routine Process
      • Pattern 3: Steering Process
      • Pattern 4: Anticipating Process
      • Pattern 5: Congruent Process
    • Appendix C. The Satir Interaction Model
      • Intake.
      • Meaning.
      • Significance.
      • Response.
    • Appendix D. Control Models
      • D.1. The Aggregate Control Model
      • D.2. Cybernetic Control Models
        • D.2.1 The system to be controlled (the focus of Patterns 0 and 1)
        • D.2.2 The controller (the focus of Pattern 2)
        • D.2.3 Feedback control (the focus of Pattern 3)
    • Appendix E. The Three Observer Positions
    • What Next?

Other books by this author

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors, publishers and universities use Leanpub to publish amazing in-progress and completed books and courses, just like this one. You can use Leanpub to write, publish and sell your book or course as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub