Thornton May
SUCCESSFUL REENGINEERING, Daniel P. Petrozzo and John C. Stepper, Van Nostrand Reinhold, ISBN 0-442-01722-7, $24.95
Most BYTE readers will not get value from or enjoy Successful Reengineering by Daniel P. Petrozzo and John C. Stepper. The book, for all its faults, is grounded on a very accurate premise--most reengineering projects fail. The authors are correct in their belief that BYTE readers need a real-world guide to making such projects work. Unfortunately, this book is not that guide.
Much like the reengineering projects these two aging guru-wannabes protest to be expert in, the book starts with lofty promises, wanders around in a surprisingly unstructured manner (a problem of poor editing), takes too long, delivers too little, and in the
end disappoints. Three major points of disappointment appear consistently throughout the book: (1) There's no new empirical evidence, (2) It's grounded in managerial ``old think,'' and (3) It's dated technologically.
Reengineering is arguably the hottest thing on the managerial agenda of the Business Week 600 these days. In 1991, fully 45 percent of the top 600 companies in the U.S. had launched some type of reengineering initiative. By last September, the participation rate had increased to 63 percent. With these types of numbers, you would think the authors would be able to serve up a steamy plate of live case studies--what works and what doesn't. One would expect pearls of wisdom and telling anecdotes from Petrozzo's consulting experience. One yearns for live lessons from Stepper's days laboring in the trenches of Morgan Stanley. No such luck--not one personalized ``I was there, I watched it happen, and this is what I learned'' piece of information.
One might forgive the lack of granular rea
lism if, in its place, one found conceptual brilliance, an eloquent articulation of reengineering projects, and how they actually operate. No such luck here, either. The authors chose as their organizing framework the amazingly uncompelling I. discover; II. hunt and gather; III. innovate and build; IV. reorganize, retrain, retool.
What a yawn. Even the names are tiresome. In presenting their framework for Successful Reengineering, there is no empirical benchmarking data. We are never told how long each reengineering phase should take, how much it should cost, and what roles the various team members might play. The authors ad nauseam acknowledge some imagined debt they owe to Michael Hammer and James Champy. They confront you incessantly with phrases like ``similar to Hammer and Champy,'' ``not unlike Hammer and Champy,'' and ``as Hammer and Champy correctly pointed out.'' If we wanted to read Hammer and Champy's book, Reengineering the Corporation, we would have. In short, there is nothing new here.
The authors make no reference to collaborative work management software or groupware. One of the most exciting developments in reengineering is the business application of video-game technology to simulation or simulation modeling tools. The book reeks of technical talk, with cameo appearances from hot topics like intelligent agents and virtual reality. However, there is limited discussion regarding the cause and effect between distributed computing and reengineering.
What emerges is a well-intentioned though poorly executed view by outsiders into the fascinating world of reengineering. It's lacking a Hemingwayesque grounding in the realities, what the technical team leader experiences when the prototype works and when it fails.
Thornton May (
tmay@ctp.com
) is vice president, research and education, at Cambridge Technology Partners in Cambridge, Massachusetts. You can reach him on BIX c/o ``editors.''
Not-So-Successful Reengineering
