The Unfulfilled Project: An Interview with Jerry Weinberg

Gerald M. Weinberg (known as Jerry) has been a leader in the system development field for more than half a century. Winner of the Warnier Prize and the Stevens Award for his writing on software quality, he is also a charter member of the Computing Hall of Fame in San Diego.

MORE ON DIFFICULT PROJECTS

How to Spot a Failing Project

Five Lessons from AT&T Wireless’s Project Failure

The Sensitive New Age Manager

Sign up for our Leadership newsletter!

Weinberg has written several books on leadership, including Becoming a Technical Leader, The Secrets of Consulting, More Secrets of Consulting and the four-volume Quality Software Management series. His books on human behavior are classics, including Weinberg on Writing: The Fieldstone Method, The Psychology of Computer Programming and An Introduction to General Systems Thinking. He incorporates his knowledge of science, engineering and human behavior into all of his software consulting work as well as his writing.

He also writes what he calls “nerd novels,” such as The Aremac Project, about what it takes for brilliant people to produce quality work.

CIO.com sat down with him (virtually, in e-mail) to ask Weinberg about his presentation at the next Amplifying Your Effectiveness conference, called “Moving Projects Forward”—and his thoughts on what makes IT projects succeed or fail.

CIO.com: Let’s start out with an anecdote: a project gone wrong, terribly terribly wrong.

Projects go wrong for many reasons, but most of the failures can be traced to missed communications. Someone has a problem and someone else could solve the problem, but they never get together. The larger and more hierarchical the project, the more likely this kind of bobbled connection.

Here’s an example. ZetaBang Systems (a fictitious name) had 1,200 employees and one product, an integrated hardware/software system sold to large manufacturing companies. The development of the newest model was seriously behind schedule, which resulted in a new CEO being brought in to accelerate the project. The CEO’s consultants discovered that software development was so slow because their data storage bank was 99% full. Access speeds were glacial. Workers were unable to put new data into storage unless they found something else the could be archived and replaced. Managers spent most of their time fighting to steal some other manager’s storage.

The solution was simple, and the new CEO immediately ordered a vast new storage array on an accelerated basis. But a month after the array arrived, progress was still sluggish. The CEO convened a problem-solving clinic, inviting representatives from every part of the company he thought had a stake in the problem. The clinic quickly discovered that things were still slow because the new storage array still hadn’t been brought on line.

The CEO took two of his best problem-solvers to the computing center where they discovered that the array was not on line because they lacked one cable. The trio marched down to the tiny shop that custom-made cables for the entire company. They confronted Cable Guy, who explained that the cables were made on a strictly first-come-first-served basis, and they would have to wait their turn—another month, at least.

The CEO then said, “I authorize you to put this one cable at the head of the line.”

Cable guy replied, “And who are you?”

CIO.com: Why do so many projects die unfulfilled?

Many projects die unfulfilled because they get stuck on little problems that become huge problems when they’re not addressed in a timely manner. The reasons they’re not addressed are many, but the problem is not the problem. The problem is the way the organization copes with problems.

CIO.com: What’s the Clinic Method you’re advocating? And how can a manager apply it in her own job?

The problem-solving clinic is a regular meeting among the best problem-solvers in the organization, not based on rank or department. Anybody can bring a problem to the clinic, where it is defined, rated, and delegated—and solved on the spot in many instances. The job of the clinic is to see that no problem goes unnoticed or otherwise neglected. The handling of the ZetaBang delays is typical of many clinic-solved problems, where follow-through is the key ingredient.

Any manager can create and foster a clinic approach, and there are many variations in style. You can copy what others have done, or you can develop your own approach—as long as the meetings are regular, frequent, populated by the best problem-solvers, and all issues are followed through to resolution.

CIO.com: Presumably, some projects should die. It gets underway and then the participants realize that the right action is to kill it. Sometimes, though, a project is murdered… or it should be, and isn’t. What advice do you have for managers to help them know when to wield the axe… and when to realize that the project is do-able but not being handled correctly?

The essential ingredient for dealing with all these problems is a system of technical and management reviews. The technical reviews determine whether the project is being done right, while the management reviews determine if it’s the right project. The reviewers must be people whose judgment is trusted by upper management, and management must believe their judgments—no matter how painful they might turn out to be.

Both types of review must take place for every project, at pre-scheduled times and/or milestones, and must not be postponed because a project says it “isn’t ready.” They’re not a way of punishing projects that management thinks might be in trouble, but are performed for every project on the same basis—which helps prevent hidden problems from growing out of control.