Disclaimer: I was a technical reviewer for this book and I work with Jennifer Greene, if you feel that taints my opinion, please feel free to move along, move along, this isn't the review your looking for.
Applied Software Project Management is one of those rare books about technology that is actually worth your valuable time to read. You might be saying to yourself, I already have a software development process that I am very comfortable with, why should I bother reading this book? This isn't a software process book. It isn't about Extreme Programming (XP), Agile, CMM, Microsoft Solutions Framework, Rational Unified Process, etc. individually, but it is about all of these processes. The book takes the best ideas from all of them and tells you, the project manager, how you can apply them on individual projects, or even as a group if you want to get revolutionary in your organization, to improve how you build software. Also, the book is language, development environment, operating system, and named software process agnostic with one exception.
Subversion, the open source software source control system and natural succesor to the venerable CVS, is specifically mentioned. I started using Subversion for a personal project, and I now love it. If you are still using Visual SourceSafe, stop torturing yourself and make the move.
The ideas contained in
Applied Software Project Management have taken me personally years of practice managing software projects, and trial and error, to realize need to be in place for a sucessful project. I wish I had a book like this when I started managing software projects professionally. Professional software projects are a beast unlike college or hobby projects, primarily because the careers of many people are intertwined with the project you are on. Lots of money is at stake, peoples livelihood, so everyone can get jittery. Best to know how to manage the project to calm everyone down. :-)
Part One of the book takes a diagnose and fix approach to your software project, listing symptoms your projects may have had and what you can do to make them better. Topics include:
- Introduction
- Project Planning
- Estimation
- Schedules
- Reviews
- Requirements Gathering
- Design and Programming
- Testing
If you read nothing else, you will be a better project manager just from reading Chapter 1. There are two key principles talked about in that chapter I think require special attention.
Tell everyone the truth all the time
This is
Transparency. Tell your customers what is going on with the project, tell your project team what is going on with the project, everyone involved with the project should have complete access to the information about the project. The book also lists
Trust Your Team as a princple, and you really can't be transparent if you don't trust your team. So maybe your thinking to yourself my company likes or needs to operate in secret, how can I be transparent? The key to being transparent with the project team and your customer is how you define those terms. If you are in a public company that you are building software to sell, your ultimate customer is of course the buyers of the software. Ideally you want to be as transparent to that group as possible. Transparency build trusts because customers know what is going on. But projects can't always be fully trusted to customers for competative reasons. The "customer" or a project manager is also your manager and there managers up to your companies executives, and its with this group you really need to be transparent with. You might be thinking "If I show all the bad stuff that happens on a project, I might not get a promotion or even fired". For some managers, that might be true, they might only want good news, and they would be bad managers. Bad managers in any business are tough to deal with, I wish you luck.
All software engineers are created equal
I laugh when people misinterpret this. This principle does not mean developers are interchangable cogs (the book goes out of its way to make this obvious) and all members of the team do not have the same skill level. No, this principle is referencing Thomas Jefferson's "All men are creating equal" and in that case all men are equal under the law. In the software engineer case, it means that any member of the project team can contribute
ideas and they should be objectively analyzed. Maybe your development team lead, business analyst, or architect (hey that's me!) contribute a majority of ideas because of their experience. That's ok, but when your most junior developer proposes an idea, you better listen and be objective, because sometimes that idea will trump everyone elses idea and the project will be better for it. Use the best ideas, not just the ideas backed by titles.
Chapter 11 - Managing An Outsourced Project is a key chapter because most project managers have never run an outsourced project and with outsourcing being a hot topic, this chapter gives you a good overview of hows thing are different from a normal project and what you can expect. I need to call out a couple key point from the book based on my year of experience working with an offshore development team.
Maintain Control Of Design And Programming
I can't stress this point enough. You might be tempted to say that you have paid the vendor good money to handle the project, doesn't that mean everything, design, architecture, and development? It might, I can't say it won't, but I don't think its in a project managers best interest, and ultimately the companies, to give up that much control over the outcome of the software, and the book makes this point well. From my experience, the are three problems with relinquishing design control to the vendor. The time it takes for unclear requirements to get resolved because of time zone differences result in bad design decisions being made by the vendor to eliminate the downtime of waiting for a response from the onshore project management team. Next is a supply-demand inbalance pressing inexperienced developers into technical lead or architect positions without the breadth or depth of experience to make educated design decisions. I also believe that a lot of vendors, and this is the classic hired consulting company problem, have conflitory goals than your organizations, resulting in conflicting priorities which influence the design (e.g. if I write few unit tests I can code down faster, and I get bonused on faster delivery!).
Build a Relationship with your Team
Depending on the vendor you work with, how the titles junior software engineer, software engineer, senior software engineers, etc. actually correlate to the experience of the person doing the work on your outsourced team could be a mismatch between what can be delivered and what you expect. It is the responsibility of the project manager to know the development team, I would go so far as to conduct technical interviews, to gauge the kind of experience the vendors people have. One of the worse experiences in software development is assigning work to someone that says they can do the work, but really doesn't have the experience to get it done.
Conclusion
Applied Software Project Management is the kind of book that should be taught to people that want to be professional software engineers. Prospective software developers need to know that being able to write code and being able to run projects are completely different skills. If you want to understand the complete picture of software development, you need to know both. This is not a book about any specific company, technology, or process, it is about the best practices you can use when running software projects and that is its greatest strength. Andrew Stellman & Jennifer Greene have done an excellent job and the contents of this title will remain relevant for years to come. Highly Recommended!
