Greetings all!
After a long holiday break Hogarth and I are finally back. Hogarth is still getting over a banana hang over so today we'll take a break from our normal format to offer up a book review.
I am a member of the Bay Area Agile Planning Leadership Network. Recently BayAPLN was asked to review a selection of books. I volunteered, hoping to learn about some new tools and pass on my review for others at the same time. Now, Hogarth and I do not take our commitments lightly. So when we agreed to review "Evaluating Project Decisions - Case Studies In Software Engineering" by Carol L Hoover, Mel Rosso-Llopart and Gil Taran, we were bound and determined to read the book and provide the best possible review.
Well you know what they say about good intentions? Over the course of a month, I attempted to complete the book. I actually ended up scheduling time on my calendar and even using self rewards for every section I finished reading. In the end I was only able to plow halfway through the book before I finally gave up.
So to start with the bottom line up front, I give this book a failing grade. The only place I would recommend someone read this book, is if they are taking a course that it is required reading and they do not know anything about project management what so ever. There were several things that culminated in my rating of this book. A number of these so grievous, to be enough to prevent me from ever recommending the book on their own. Together they compile up that I can't in good conscience recommend this book at all.
The highly academic bent of the book is not in and of itself a bad thing. There are many well written text books out there. The thing is, they are supposed to be Text books and are tied to a course that will fill in the missing information. "Evaluating" did not actually give you answers or final solutions to the case studies. Instead the case studies all ended with a Case Analysis section that asked a bunch of questions. This is fine for a text book that leads to a class lecture, but as a business book on project management it failed to deliver. I was left wanting to know the analysis, but instead was faced with a homework assignment.
The explanation portions of each chapter were likewise difficult for me to absorb. The authors provided what I found to be simplistic overviews of what I consider basic foundational project management. For a computer sciences bachelor student the overview is probably helpful, likely having minimal exposure to project management principles. For anyone with even a few years in the software industry, the text would have been a very dry review.
After the third chapter of project management for dummies, capped by case studies that didn't actually give suggested solutions I finally set the book aside. The flavor of the book and the errors I had run head long into had finally built up to make it impossible to complete the book.
Speaking of those errors, those are perhaps the single largest contributor to why I finally gave up. Faced with text that was dry and offered little new concepts was difficult enough. But when I was questioning every fact in the book, it just made it impossible to continue.
Errors ranged from obvious grammar errors, ones I could spot and I'm known for my own poor grammar to basic fact issues like you don't take a few days to "Jaunt on the San Francisco Bay". SF Bay is the kind of bay you go out for a few hours and then go home. It was however the Earthquake fiasco that so irreparably shook my faith in the authors ability to fact check that I began to question if they were not just making things up to fit their findings and premise.
For those who really want to know I've included my rant (I can't justifiably call it anything else) about the Earthquake fiasco below.
For the rest, I must again advise against the reading of this book unless assigned by your professor. And even then, I'd reconsider that class if the professor is using this as their source material.
For Hogarth and myself I bid you happy project management dreams,
Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
The Earthquake fiasco:
I made it only as far as page ten before I found myself deeply questioning the book. The authors created a case study called the "California Bridge Problem". So wrought with errors was this case study, that I immediately found myself questioning everything else I read. This wasn't some minor little error, this case study was so rife with errors the facts presented almost seemed to be 'adjusted' to fit the needs of the story. Anyone who spent even a twenty minutes with Google will note the massive errors. Having lived in California all my life I didn't even need twenty minutes to question everything this book had to say.
"It can't be that bad you say?"
Well let's see:
The Authors merged the 1989 Loma Prieta and 1994 Northridge earthquakes into a single event.They said it occurred in 1991 (This is the date of yet a third somehwhat famous quake called the Sierra Madre quake).
- The ascribed the quake as an 8.49. The Loma Prieta quake was a 7.0 and the Northridge a 6.7. The Richter scale is a logrithmic scale, so an 8.5 quake would be equal 5.5 gigtons of TNT a 7.0 only 32 gigtons. Just a little off in the power. There are only 7 recorded quakes of 8.1 or greater in known history. One of them is the one caused by the asteroid that killed the dinosaurs!
- The stated the quake lasted two minutes. Both quakes were around 20 seconds. Quakes of two minutes in length are incredibly rare and usually much stronger.
- They claimed the Bay Bridge collapsed because of inadequate concrete columns. No the bay Bridge is a metal structure. It was freeway overpasses that collapsed in both the 89 and 94 quake.
- Even the proposed new way of building bridges missed the mark. Encasing in steel sleeves was a suggested retrofit for existing highway bridges that could not be built to the new recommended spiral reinforcements.
Posts
