Rating: 
Summary: excellent resource
Review: Despite the fact that this book is over 5 years old -- its still an excellent resource. I used this book in my Software Project Management course for my Master's Degree and can definiltly see myself using it in the future at work.The book clearly explains the many risks and strategies involved in Rapid Development. The author uses anecdotes and examples effectively to illustrate his points. Many of the ideas build on top of each other to reinforce good methodologies for a project manager to follow -- but the book can also be read randomly (a chapter here, a chapter there). This is a great resource from a developer's perspective too -- it gives you the ammunition to debate with an untrained, unknowledgable, misinformed or mislead project manager who's asking WAY too much and doesn't even realize it. I think anyone involved in the software engineering process will be able to take away a lot of knowledge from this book.
Rating:
Summary: Project Management Reference for ALL Software Professionals
Review: Anyone who has ever been on a software project is initially confused by all the chaos involved. When Ford can churn out good quality and inexpensive automobiles and McDonald's can serve millions of satisfied people around the world, and we can put man on the moon, why do the most reputable companies struggle to deliver even the simplest of software projects? After being on two new model launches at Ford that went smoothly, I moved into IT at the beginning of the economic boom in the mid-nineties and asked the same question. Why is the IT world so inept at managing software projects? My boss at the time quickly whipped out this book and asked me to read it cover to cover before asking any more questions or wasting any more time trying to figure this out. I did as I was told and found the answers I was looking for. I also found answers to questions I hadn't asked yet but I would have eventually. I instantly purchased a copy of this book for my long term personal book collection. The book contains a thorough discussion of various software development practices and their effectiveness using case studies very extensively. These case studies stick in your mind really well and drive home the point that the author is trying to make. The book also talks about the most classic mistakes on any software development project and then details several strategies to avoid them altogether on your own project. I still refer to this book whenever I feel nervous on a software project that something's not right. You don't need to be technical to understand the book and the book is written for anyone on a software project - from the project manager to the developer to the tester. I can't believe the pricing on the book. I am always comparing the value I get from any book I purchase and this is one of the most reasonably priced books for the 600 + pages of wisdom it provides. Share this book with your colleagues and friends, they will definitely thank you for it. Get a copy and start taming those wild software schedules!
Rating:
Summary: A must read for every software professional
Review: I'm a big fan of eXtreme Programming (XP) so I was particularly interested in reading this book to see if I could pick up some ideas and concepts different from that of XP. I was quite suprised to see many of the concepts and best practices McConnell presents in this book are very consistent with XP's practices. I also like how McConnell gives lots of references for his claims. He gives plenty of convincing data and supporting arguments to show what many of us already know yet many managers refuse to believe. Things like mandatory overtime can make productivity go down, the importance of moral, why managers can't control all the variables of a SW project (cost, schedule, & product). Overall this book is a great read and I really believe if everyone followed this book's best practices, especially 40 hour work week and honest scheduling, the entire SW industry would be much better than it is today.
Rating:
Summary: Practical Guide With Real Life Examples
Review: Steve McConnell's books have always displayed a remarkable degree of practicality and readability. This book is no different. The author says at the outset the Purpose of the book is to answer issues about trade-offs. The author says that software can be optimized for any of several goals: lowest defect rate, lowest cost, or shortest development, etc... Software Engineering is then about achieving tradeoffs, and this is what this book is primarily about.
Because the book is so big, it has been broken into sections that can be read selectively and quickly. A short book would have oversimplified things to the point of uselessness. Organization of the book:
Parts 1, 2 deal with the Strategy and Philosophy of rapid development, while part 3 covers Rapid develoment best practices In chapter 3 the author talks about 'Classic Mistakes'. He calls them 'classic' and 'seductive' because they are so easy to make that they have been repeated in countless projects. The classic mistakes number 36 (though Steve M points out that a complete list could probably go on for pages and pages):
Undermined motivation, Weak personnel, uncontrolled problem employees, Heroics , Adding people to a late project , Noisy crowded offices , Friction between developers and customers , Unrealistic expectations , Lack of effective project sponsorship , Lack of stakeholder buy-in , Lack of user input , Politics placed over substance , Wishful thinking , Overly optimistic schedules , Insufficient risk management , Contractor failure , Insufficient planning , Abandonment of planning under pressure , Inadequate design , Planning to catch up later , Code-like-hell programming , Requirements gold-plating , Feature creep , Developer gold-plating , Push-me, pull-me negotiation , Research oriented development , Silver bullet syndrome , Overestimated savings from new tools or methods , Switching tools in the middle of a project , Lack of automated source-code control , Shortchanged quality assurance , Omitting necessary tasks from estimates , Shortchanged front end upstream activities.
He categorizes these classic mistakes into four sets : People related, technology related, product related, and process related. Part 2 covers rapid development issues in greater detail.
Core issues like Estimation, Scheduling, Lifecycle Planning, etc.. are covered. 'Soft' issues like Motivation, Teamwork, Customer Oriented Developmentare also covered. Part 3 is a compendium of best practices. There is a summary table of the each best practice, and the efficacies, major risks, major interactions and trade-offs listed. Some candidate best practices not included are getting top people
, Source Code Control, Requirements Analysis.. These are listed as fundamental to a software project. The Best Practices listed are
JAD, Spiral Lifecycle Model, Theory W Management, Throwaway Prototyping, Staged Delivery, Voluntary Overtime, Miniature Milestones, Outsourcing, Reuse, User-Interface Prototyping, Change Board, Daily Build and Smoke Test, Tools Group.
As an example, Steve McConnel covers 'Inspections' stating the
chances of its long term success are excellent, it reduces schedule risk, its improvement in progress visibility is only fair, has no major risks, it can be combined with virtually any other rapid development best practice The book has a very engaging style of writing...
Some quotes...
- Projects can look like a tortoise on valium to the customers, but as a rapid-development death march to the developers.
- The team ranks so low in the company that it has to pay to get its own team t-shirts.
- Rapid development isn't always efficient.
- Run every software project as an experiment ('Hawthorne Effect').
- If Las Vegas sounds too tame for you, software might be just the right gamble.
- The most common (and incorrect) definition of estimate is: 'An estimate that has the most optimistic prediction that has a non-zero probability of coming true' - Tom DeMarco All in all, a fully deserved five stars!
Rating:
Summary: Excellent Introduction to Project Management
Review: I recently read this book as part of my graduate MIS program at the University of Virginia. I thought the book was a great introduction to the world of software development. Having limited experience in the IT world, this book did an outstanding job of giving me insight into the tricky business of project management. I highly recommend this book to anyone who wants to learn a lot about classic mistakes that software developers and managers commonly make. Luckily, Mr. McConnell also lists many best practices that project managers can use in order to maximize their chances for success on software development projects.
Rating:
Summary: IT Management Must
Review: I found this book to be enlightening on so many issues. I bought it thinking that it was touting a new methodolgy that would save the world from failing IT projects and found that it was a general summary of many things that will increase the efficiency and effectiveness of your IT team. It is very insightful and an overall good read.
Rating:
Summary: Outstanding Software Development process book
Review: Unrealistic schedules are the bane of the software world's existance. In a world of "the quick and the dead" and "first mover advantage" achieving the unachievable seems to be a way of life in the industry. Steve McConnell takes a level headed approach at this crucial problem. Steve looks at 3 dimensions of the problem - people, process and technology. In the spirit of haste, lots of mistakes are made. Steve then covers many of the techniques available, and identifies their impact to schedule, risk, and other factors. This isn't just a "how I learned how to do it" - it's backed up by hard research on what works, and what doesn't. Invaluable information for anyone serious about improving their ability to survive in such a hypercharged environment. Ultimately, there is no silver bullet to this problem. Telling your project manager to read this book won't solve world peace. But carefully applying the tools and techniques listed will do you a world of good.
Rating:
Summary: If you only buy one project managment book - buy this one!
Review: If there is any one book that all developers and would-be project managagers should have - it's this one. Steve McConnell's writing style alone makes this an enjoyable read. Filled with tons of empirical data that is germane for any software project, this book is a tremendous resource. Having developed software professionally for over ten years now, I still find this book my favorite. Even though it was published in 1996, all of the material contained therein is still very pertinent to today's N-tier software development projects.
Rating: 
Summary: Marginal Instructor
Review: I recently took an online algebra tutorial and I was amazed at how well organized, clearly and simply presented, and how thoroughly I understood and retained the subject of alegbra for the very first time in my life. Whoever put that course together gets a solid A+ from me. Most teachers and instructors, including books and courses, I've had over the years would get an F-Minus from me, including the high school algebra teacher; The vast majority of these dismal failures should be doing something else, seriously. That goes for two gifted guys Grady Booch (Object Oriented Analysis and Design) and jeffrey Witten (Systems Analysis and Design), two books I own; both who make lousy instructors. Both books are dismal failures; more junk for the bon-fire. I wasn't able to understand one thing they said and I retained almost nothing. Grady's approach is bogged down with one page after another of solid rambling rhetoric. Whitten fails primarily with the chart approach; the same vague, modified chart page after page. The approach just didn't work for either. Steve knows his subject of Project Development very well; the planning and development that must preceed any project. But I give him only a marginal grade of C for the organization, presentation, and approach of the three books I own: Project Survival Guide, Rapid Devlopment, and Code Complete. I was only able to grasp some of what he was saying, and I have had a decade of experience as a senior programmer-analyst with advanced training. The books are a little too unorganized to cement the subject. He does convey one very strong message very well: you had better prepare and plan properly before spending time and expense on system project development. I know firsthand the consequences of not heeding his advice. One company I worked for on the development staff spent many millions of dollars, years of time, and dozens of staff personnel, before outside field personnel complained that the system was way too slow. I will have to re-read Steve's books. I give him a B+ for content and a C for instruction.
Rating:
Summary: Showed this to my former boss and he stole it from me...
Review: This is the second time I buy this book, but even if I cannot tell you this might be the bible of project management, is very close to being that. Very well written, easy to read with lots of advice to consider and follow. Almost everything you need to face sucessfully any software project is covered. I have many other software management books and papers, and after reading them all I keep checking on this one as reference. From my point of view, this book is a must and a strong first buy for those who not only head a programmers group, but also for programmers itself. A few years ago, and with that book recently bought, our programmer group stopped our manager (a non programmer) to take some "common" sense adjustments to a very cumbersome, badly designed and also delayed proyect (as most of his last important projects were): Wanted to add more people to the delayed project, force us to work round the clock to finish on time, abstract final users from validating our progress, and remove any more testing, leaving it to the end of the project. After many hours discussing with him and reading him complete chapters of this book (and some other books), we decided to stop our work, took a day free to clear our minds, keep our team unchanged, sat with our users to reschedule delivery times and keep working from 9 to 6. We didn't complete the work on time, but past projects were misscalculated by 50%, ours ended late by just 20%. Now, on my new job where projects were (and are) delayed usually more than triple of time with a lots of non-payed extra hours ended on time or with little delays (company culture is very difficult here), within our budget and rarely needing extra time. Other teams on my company keep working forever on a always delayed work refusing to believe there is a better way to work here, to be at the end, looking to work somewhere else or leaving entire projects unfinished or needing a severe rewrite. Our team uses this book (without approval from our systems director) and also two other titles that compliment the way we work (very well): Code Complete and Peopleware. I do strongly recommend to get those books also.
| 
