--Originally published at That Class Blog
Well. What I’ve learned from this book, in fact, it’s stated from the start (I don’t remember at which point exactly, but I think it was in the beginning chapters); It’s that there isn’t a thing that causes problems and delays, there isn’t a specific thing that the book, the teacher or anybody else can tell you and warn you about at the moment when you become a software manager, or project owner, or developer.
Things just happen. A lot of them. At the start it’s just something simple, maybe something that no one thought that it could evolve to something else. Then another thing appears, now you notice but you don’t react immediately, and then another, and another, while the progress keeps getting slower and slower. And then the morale gets lower, and the performance too, and the client gets mad.
It’s a sad and stressful path. And there really isn’t something that you could know it will happen in every project. But you can try to prevent, everything, and make plans for every scenario if it comes to be, even if at the end the project goes very well.
And this is what the rest of the book is about. What is to really manage a software project and everything you can do when assuming such position. Either as a manager for the architects or a manager for the implementers, or general manager.
A basic concept for a good project to try to get to the end is communication. There is no chapter in the book where this capacity isn’t mentioned. It’s very important. At first level, there needs to be a very good communication between the architects and the implementers’ representatives. This is essential because the implementer will try to keep the architect from the skies and 
