Change Done Well

Change Done Well

Volume 9 of the Quality Software Series

by

Gerald M. Weinberg

CLICK HERE TO SKIP TO THE BEGINNING

SMASHWORDS EDITION

PUBLISHED BY:

Gerald M. Weinberg on Smashwords

Change Done Well

Copyright © 2011 by Gerald M. Weinberg

All rights reserved. Without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording, or otherwise) without the prior written permission of both the copyright owner and the above publisher of this book.

Smashwords Edition License Notes

This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person you share it with. If you're reading this book and did not purchase it, or it was not purchased for your use only, then you should return to Smashwords.com and purchase your own copy. Thank you for respecting the author's work.

Contents

Chapter 1. Starting Projects Correctly

Chapter 2. Sustaining Projects Correctly

Chapter 3. Terminating Projects Properly

Chapter 4. Building Faster By Building Smaller

Chapter 5. Protecting Information Assets

Chapter 6. Managing Design

Chapter 7. Introducing Technology

Epilogue

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

FURTHER READING

Chapter 1. Starting Projects Correctly

It was also becoming painfully evident that estimating the cost of technologically state-of-the-art projects was an inexact science. The experts, in spite of their mountains of numbers, seemingly used an approach descended from the technique widely used to weigh hogs in Texas. It is alleged that in this process, after catching the hog and tying it to one end of a teeter-totter arrangement, everyone searches for a stone which, when placed on the other end of the apparatus, exactly balances the weight of the hog. When such a stone is eventually found, everyone gathers around and tries to guess the weight of the stone. Such is the science of cost estimating. —N. R. Augustine

I've studied dozens of unsuccessful projects, trying to find the earliest point at which failure could have been predicted—and then that failure prevented by management action. Most of these projects were under pressure from the moment they started—actually even before the moment that their process models said they started. Indeed, the primary reason for the pressure was that there were no explicit models of what happens before a project officially starts. By the time a project manager was put in charge, external decisions had put so many constraints on the project that failure was highly probable.

1.1 Project Prerequisites

Preceding every project is a series of high-level negotiations that lead to the decisions that constrain the project. If these negotiations are not both informed and congruent, the project is doomed before it starts.

When a project is in the fuzzy early stages, before official initiation, the first question is, of course, what benefits the organization expects from the successful completion of the project. This is the What's it worth? calculation. Assuming that benefits have been projected correctly (which is frequently not the case, however), consider the next question, which is about risk.

1.1.1 Risk analysis

Infinite potential benefits will have zero value if the project isn't completed. When project benefits are large, however, it's difficult to make a congruent decision about risk. There are a number of relatively formal systems of risk analysis that can aid in making this decision, and any software engineering manager should be steeped in at least one. Nevertheless, keep risk analysis as simple as possible, because complex processes

• are easy to rig in favor of any decision you ardently desire

• are costly, and your sunk cost may make you reluctant to kill a project that needs euthanasia

Boehm gives a checklist of the top ten risk factors in software, and I have found that an early, brief, and rough consideration of these ten factors generally improves the chances for project success by at least a factor of two:

1. personnel shortfalls

2. unrealistic schedules and budgets

3. developing the wrong software functions

4. developing the wrong user interface

5. gold plating

6. continuing stream of requirements changes

7. shortfalls in externally furnished components

8. shortfalls in externally performed tasks

9. real-time performance shortfalls

10. straining computer science capabilities

At the earliest stages, it's relatively easy to determine if several of these are potential problems, and to take some action to diminish the risk. However, Boehm, like many other writers on risk analysis never really considers what is always the biggest risk of all: The management team isn't up to the job of performing a congruent risk analysis, let alone leading the project, as the following example illustrates.

1.1.2 Congruence and risk analysis

I had just helped a hardware company complete a successful rescue of Asteroid, a software project that had been labeled as hopeless. The company was now proposing that I help apply the same planning methods to Comet, a project that had been bogged down for many months. While I was considering this proposal, I got the following note from Lex, the Comet Project Manager:

Anyone using comparisons with Asteroid to show what plans can do to Comet is being deeply unjust. Asteroid secured some 10 people from the start. Clear customer demands and agreements were defined, and these protected their goals. Technical issues were visible from the start, and quite modest in complexity and demands, well limited, and isolated. Quite a comfortable setup! I congratulated those who were assigned, because success was assured in advance. But Comet as a project is ridiculous!

Poor Lex! Like so many software managers who are unfamiliar with the role of tactical planning, he couldn't see the real message in his own note. Of course Comet was ridiculous, since it was without planning that

• noted the risks

• made plans to reduce these risks to an acceptable level

Two years earlier, at the start of its planning process, Asteroid had been in exactly the same state. The planning process, not the plan, was what transformed a ridiculous fantasy into a real project, whose success was assured in advance. That's what tactical planning is all about.

Lex was operating from a placating position: He felt he had to conform to whatever fantasies upper management tossed in the hopper. He didn't see that the planning process was an opportunity to stop placating and uncover the real issues with the Comet fantasy. Not that I should have expected anything different from Lex, who had seen only one non-placating planning process, and that from the outside. Previously, planning in this company had meant hammering down anyone who raised issues of risk, until everyone was committed to the previously established plan. Where blame is so intense and universal, placating will always flourish.

1.1.3 Win/win negotiation

For a project to succeed, these early negotiations must produce a congruent agreement—one that balances the Self, Other, and Context. Without that balance, the project will tear itself apart like a crooked wheel spinning at high velocity.

Many software organizations become so enmeshed with their customers that they can't negotiate well. Some are prevented from negotiating by general management. A bigger problem is that they don't know they are negotiating, or they think negotiate is a dirty word. Consequently, they negotiate implicitly and don't even like to call what they do negotiating. If you don't negotiate explicitly, you won't negotiate well; you won't record your agreements; you won't honor your agreements; you won't know what your agreements are; and you often won't even be aware that you've even made agreements. How, then, can you measure the single most important measure of any development project: Did we fulfill our agreement?

One essential for making projects comparable is to be sure they start on the same basis, which implies that all negotiations must be done explicitly, done well, and the agreements recorded. Steven Covey lists the following five elements for a win/win agreement:

• Desired results (not methods) identify what is to be done, and when.

• Guidelines specify the parameters (principles, policies, etc.) within which results are to be accomplished.

• Resources identify the human, financial, technical, or organizational support available to help accomplish the results.

• Accountability sets up the standards of performance and the time of evaluation.

• Consequences specify—good and bad, natural and logical—what does and will happen as a result of the evaluation.

The following sections examine each of these points in some detail to see why this is a good checklist for project or sub-project prerequisites.

1.2 Desired Results

Consider two projects, A and B. They are as similar as two projects can be, each with requirements, resources, methods, tools, and schedule. Project A is completed on time, within budget. Project B runs 25% late and 30% over budget. What can we conclude about the way each project was managed?

We can, of course, make no conclusions at all unless we know how the two projects defined completed. If their definitions were the same, we reach one conclusion. But what if Project A dropped a few requirements to meet the schedule? Does that matter? Only if their original agreement was clear on what had to be done, but in the end they didn't do it.

Judah Mogilensky describes how lack of clear initial agreement on results becomes locked into the customer/developer culture:

The problem often lies in organizational fear of clarity. Documenting clear requirements would force the customer to accept responsibility for initiating changes if a system meeting the documented requirements does not meet the real needs.... Documenting clear requirements would force the developer to accept accountability for satisfying them, and could expose the developer to risk if the cost and schedule estimates turn out to be inaccurate.

Thus, even though they are operating from opposite motivations, customer and developer can covertly conspire together to keep the requirements management practices of the Capability Maturity Model from being carried out. Each side thinks they are operating to protect themselves, and strengthen their bargaining position, but in reality each side is setting themselves up for future disappointments and disputes.

The culture creates this problem of such covert collusion to violate good requirements processes—it becomes a culture of fear. As such, the problem cannot be solved without changes at the top management level, a conclusion supported by numerous studies of project failures.

1.2.1 Phrases to listen for

Here are some of the things you'll hear when fear creates a situation in which the interested parties will not negotiate cleanly on results:

• (Any of the phrases suggesting that fixed requirements don't matter, or that they are fixed when they are not).

• I hope they won't hold us to the wall on that one.

• Well, I didn't understand it exactly, but what could I do but agree.

• I had no choice.

• You will do this. It's nonnegotiable. (Listen carefully: this may be coming out of your mouth.)

• If you were any good at this, you could do it. (Again, who's talking?)

• Schedule/resources will be really tight, but we can negotiate relief from requirements later. (Why not now?)

1.2.2 Actions to take

DO NOT allow design or construction to proceed without verified requirements, unless you have a staged process. In that case, DO NOT let any stage begin without verified requirements for that stage. DO NOT be sucked in by assurances that prototyping is different. Prototyping is a staged process, and each stage needs to define its requirements, even though they are not requirements for the completed system.

As a final step in the negotiation process, DO hold a closing meeting with customers and developers to in effect sign their agreement. DO question all parties to the agreement to ascertain if there is true emotional sign-on. DO look for hesitations, reservations, or uncertainties, and DO NOT allow agreement to proceed unless and until these are cleared up.

DO establish policies that reward projects for truly satisfying customers, not beating them in some legalistic game.

DO establish policies that reward customers for cooperating in the effort to define what they want. The best reward is to show that you are listening to them, and not just rejecting their needs out of hand.

DO NOT browbeat, bribe, or manipulate your employees into agreements or commitments or signing up.

1.3 Guidelines

The power of guidelines is the way they can remind us not to do foolish things when under pressure. For instance, though we know that time, resources, and function are sometimes interchangeable, they are not linearly interchangeable. In the heat of a project, we are likely to be tempted to make such interchanges and cause great trouble.

There are so many possible guidelines that we could not cover them all here, so a few examples will have to suffice:

• Brooks's Law: Adding X per cent to the staff will not generally speed the schedule by X per cent.

• The Square Law of Computation: Adding X per cent to the schedule will not accommodate X per cent increase in functionality.

• Jones's Law: Those parts of the product that don't go through the entire development process will cause 90% of your problems.

Guidelines are a way to establish triggers while you are relatively sane, so they will keep you from doing foolish things when the project is driving you insane.

1.3.1 Phrases to listen for

• We just want to make one simple change.

• I'll give you two new people so that you can take on that added function.

• We'll take out one function and add one function, so nothing is changed.

• We can save time for testing by cutting out reviews.

• We can save time for coding by cutting out design. We'll design as we code.

• We can save time for design by cutting down on the elaborate requirements process.

1.3.2 Actions to take

DO NOT put time pressure on projects that are having reliability problems.

DO NOT add features to a project without renegotiating schedules.

DO NOT decree schedules. Schedules derived from plans should always be possible. Plans derived by working backward from schedules are often impossible, at least under the constraints given. If schedule is really a critical issue (rather than simply a way to show who's in charge), then plan in order to determine what you must spend to attain that schedule, and be prepared to spend a bundle or accept that some things simply cannot be done.

DO NOT play games on blackboards or spreadsheets that cannot be supported by measurable facts.

DO learn to take no for an answer, if backed with facts. DO send nay-sayers back for facts when they come empty-handed.

DO insist on change control from the beginning, and DO NOT yield to temptations to shortcut it.

DO insist on configuration management from the beginning, and DO NOT yield to temptations to shortcut it.

DO get outside views from disinterested parties for reality checking.

1.4 Resources

All resources are not created equal. Human, financial, technical, or organizational resources each have their own algebra, so you cannot assume that each participant at the beginning of a project knows what the resource commitments mean.

For instance,