I've been reading Applied Software Project Management for the past few months and the headline is that this is an excellent book. But first some background. Why is a technical architect reading a book about project management?

My answer is simple - there's no distinct line between the responsibilities of a technical architect versus those of a project manager. Sure, there are some unique responsibilities that fall very squarely on one side of the divide or the other, but success is all about the project manager and the technical architect working together to a common goal. Both roles are about leadership and I've found that they tend to work better together if they are thinking in the same way and have a good undertanding of each other. From my perspective, I read this book to better understand some of the project management techniques that I [have|haven't] seen in use and to better understand how I can help make a software project "better".

Looking at the table of contents shows you what a wide range of topics this book covers. It includes topics you'd expect to see (project planning, estimation, quality assurance, etc) and some that you might not (the benefits of refactoring, test-driven development and using Subversion). In addition to covering a wide range of very useful techniques to a good theoretical and practical depth (e.g. the Wideband Delphi estimation section was excellent), the authors also tackle lots of the other issues that you tend to encounter on any software project. Projects are all about people and there's great advice about how to deal with those tricky situations, such as what to do when your boss tries to cut the estimates. I really like the way that this book tackles the more human aspects of the role and it has a great section about how leadership is about responsibility, authority and accountability. Much of this is equally relevant to the role of a technical architect.

My only niggles with the book are (a) it's pretty much solid text for 300 pages and (b) towards the start of the book some of the techniques feel more applicable to waterfall style lifecycles, although the latter chapters seem to embrace iterative development more. These are minor though.

In summary, this book is 300 pages of solid advice and, at the end of every section, leaves you thinking what you'd read was just common sense. This is a very powerful feeling that I found motivated me to want to put some of it into practice. Of course, if it was all common sense then we'd all have perfect projects. But we don't. If you want to learn more about project management techniques and you want to help make your projects better, this book comes very highly recommended.

Responses[1]

Posted by Simon Brown on 22 May 2006 15:40:34 BST #