There are more stories of failed software projects than of failed insert_another_field projects. But why is that so? Of course, software management is young, contrary to the other fields, but there are a set of management practices that should help project managers in their jobs. Why are they failing? Is it because they are not applied? Because the field is really too young? Or something else?

Content and opinions

The first part is dedicated to the reasons why a software project can fail. It starts with 12 reasons of why software is different than other fields. This implies some assumptions that can differ from the usual project management. The last chapter is a simulation of what a failing software project is. All in all, the main message passes, but I think it is too harsh. The underlying idea is that software is different than all the other fields, but in fact, it may be all the same (at least on the points that were underlined): building a bridge is something we know how to do through usual management, but it can still run late/too expensive/… Besides, the example is overdone. It cumulates all the typical mistakes that we know now how to avoid.

The second part gives the pieces of advice to fix what the first part uncovered. Three agile processes are explained, then tools to budget with one of these processes. the last is the example of the first part reloaded with agile methods. I agree that agile methods are an answer to the software management project, but each time software management is really opposed to usual management. There are issues that are still really different in software projects: defining the needs of the users. When you build a bridge or when you build a house, you know what you want. You know the number of ways, or the number of doors/windows/rooms, … In software projects, you don’t know how many doors you need. Another issue is that people think that software is easy to do, so it’s easy to add something else (mainly because it is mandatory… or not).

Conclusion

If the book is really easy to read, there are some shortcuts that did bother me: the two examples are caricatures of reality (not even a real example where things went well or really bad, they are a story), and software management is also exagerated compared to project management. Perhaps the real conclusion is this one: exageration. Software project management is too difficult to be explained by a caricature: it may lead to the opposite effect.