Software Project Survival Guide by Steve McConnell

Software Project Survival Guide Reviews

• 
  Tom Schulte

  I really enjoyed this, possibly the most concise and short of McConnell's software design and project management tomes. I found I labeled for reference many spots in this work: Customer's Bill of Rights, Survival Test Score (cf., Raleigh Model), a good overview of required elements of a software process around requirements. Among the points I found interesting was the research into the ineffeciency of open work bays vis-avis the need for continued focus by developers.
  
  I also liked the broad view of vision documents and post mortems as this should be a broadly defined and controlled process, too. In there are such realistic caveats as "plan should not assume the team will work overtime" and support for scientific estimation processes and coding standards although I think he has left reality with "The best coding standards are .. less than 25 pages".
• 
  Mingyang Li

  This is the first book I have read on the topic of project management. Before starting the book, I was expecting the book to be as difficult as that CFA Level II Curriculum textbook I stumped upon a couple of months ago. Half way into it, however, the book turned out to be an easy-read.
  
  The book put a heavy focus on preparational work, such as formalizing a development plan, setting up version control for documents, creating an anonymous reporting channel to upper management, getting upper management support ahead of time, and so on.
  
  Although most of the listed tasks seem ordinary to me (and I guess this is a good sign that our project is going to survive!), there are a few things I learned for the first time. For example, at the beginning of the book, the author discussed how much time budget you should put into exploratory work before seeking upper management's approval. The middle part of the book described how each stage of development should be carried out, which could fit into the iterations of versions (V1, V2, ...) that I have experienced. Other tips, such as "don't build the whole software upon the prototype", "don't modify requirements easily", are valuable words as well. These are the things that I did not realize -- nor practiced -- while being a data scientist. In this sense, I'm glad that I read this book at the beginning of my career as a software developer in an enterprise setting.
• 
  David

  Even after more than 20 years of being published this book gives you practical tips to avoid failing on your current (if just started) or next software project.
  
  Many of the recommendations need to be adjusted to your needs of course. Guidelines should be followed and modified depending on the size of the project, the size and expertise of the team and the time to complete the project, among many others.
  
  If you have some experience with software projects (which will make a lot of sense since you are interested in this book), you can probably skip reading the whole book and just read the checklists at the end of each chapter. Then- if you want to know more -go to the corresponding chapter. The checklists are also available at their website
  http://www.construx.com/ResourceLandi...
• 
  Mikhail Filatov

  Reading this book is like finding a time machine and coming back to the time of M1-M3 milestones and major release once in 4 years. Waterfall, a lot of designs and reviews and just one small chapter about coding called "construction".
  The problem with this approach is that software itself is hidden within a pile of documents. All of these documents are supposed to improve quality, but in reality...no and you want to sign an Agile manifesto :)
• 
  Sean

  Although this book is out of date, most of the ideas in it are still highly applicable today. It does have a bit of a waterfall slant, as this was written before the agile movement and back when software was delivered on physical discs. Still, all development teams would benefit greatly if their project managers read this book.
• 
  Josh Allred

  You have to dig for it but there are some tidbits in here that will help you ship your project out the door.
• 
  Alex Alapatt

  This books was well ahead of the curve and many topics are still relevant almost 25 years later.
• 
  Denise Brinkmeyer

  I can't remember who recommended this book to me. I was the manager of a software development team at the time. With a degree in communication and studies in persuasion under my belt, I thought I had come home the moment I saw Maslow's hierarchy. Working as a computer consultant who had to balance customer satisfaction against a profitable deliverable, McConnell had me at Chapter 6, Hitting a Moving Target. The book gave me the confidence to set standards for my team and to push back when a customer was being unreasonable. The book is well organized and the caption in the very first image tells you that you've met someone who truly understands your situation.
• 
  Keith

  It appears that I will be the technical lead on a new software project---a project that will be substantially larger than the typical research projects I've worked on. So I'm planning to revisit some of my books on managing software projects, including this title. I just hope I don't need to re-read
  Death March!
• 
  Craig Cecil

  Most of us have been involved with software projects that we would just as soon forget--or at least run away from screaming. If you want to learn how software projects should be run, or how to run one correctly yourself, then Steve McConnell presents a straightforward, common-sense approach that can be applied to all types of projects. The companion web site provides a complete collection of templates to support all aspects of managing a software project.
  
• 
  Michael Ryan

  Steve McConnell is always worth reading.
  
  This book has some good stuff in it.
  
  All I would say is that, just because it says, "Constantly manage stakeholder expectations," for example, does not mean that it is easy to do, or that anyone who reads this book can actually do it. Still, to read the sentence is probably better than not reading it.
• 
  Aggiebradley

  I thought this was an excellent book back when I originally read it, years ago. There is some great advice. But I attempted to re-read this book recently and it felt dated in the age of Agile development and Scrum.
  
  I wonder if it could be updated to provide more recent content while keeping the basic information together?
• 
  Scott

  I became a project lead somewhat quickly and unexpectedly and this was one of the first books I picked up to get a handle of what I could be expected of me. It proved to be a good thing to read and has served me well since.
• 
  Amr Abuellil

  u will find the link to the author website were he has much more books for you .
  
  in this link
  http://your-wayout.blogspot.com/2012/...
  
  this is my blog ... u will find more topics about other books too ..
  
  
• 
  Adam

  I consider this required reading for anyone in a position to manage or participate in a software project of any size.
• 
  Josh Readmore

  The programmers and customers bill of rights at the beginning of the book is just golden.
• 
  Danien

  Lots of checklists that are theoretically sound and good for large teams and projects but the overhead is way too high for smaller projects.
• 
  Russ Painter

  It's been a while since I read this. It was a great book about the entire process and how to avoid the death march.
• 
  k.wing

  Skimmed this one. The information could've possibly summarized in a short article, but good step-by-step for a software team.
• 
  Christophe Addinquy

  
  Ma note de lecture complète en français ici
• 
  Jorge DeFlon

  Un libro de consejos sobre como volver a tener control sobre un proyecto