It is not often that a software project management book comes along that is practical, easy to read and stacked full of ready to use process scripts. Andrew Stellman and Jennifer Greene have done just that with the recent book Applied Software Project Management.

Too many books on project management software or software engineering that are dry, too complex and boring, but this book is not one of them. It was a joy to read because his writing style is clear without being simplistic and the authors describe things in much detail. Seems to understand your audience and set out to write a useful and practical. They have achieved this.

In the first part of the book refers to the tools and techniques that can be applied in projects. Project planning, estimating, scheduling, exams, requirements, design and programming and testing have their own chapter. Second part is on the use of effective project management and has chapters on understanding change, management and leadership, project management outsourcing and process improvement.

A clear message throughout the book is a description of the typical problems facing the software project teams? Inadequate requirements, change management, lack of quality assurance at every stage of a project, a plethora of testing and fixing errors cycles, tensions and misunderstandings between the software engineers and business users. None of these problems are technical in nature, they are the organization and management. Stellman and Greene offer practical advice to solve these problems based on its experience in similar projects.

Stellman and Greene certainly seems to know much about the problems faced by teams of software. Already in the introduction describes the need to overcome the chronic problems and this theme is continued throughout the book. For each problem, there is always at least one proposed solution. For example, they describe a common scenario that senior managers do not trust the estimates of the technical team, somehow believing that the technical team are deliberately over-estimate in order to give themselves some downtime. His proposed solution is to involve these managers in the estimation process so you can see that the estimates are done in a transparent and systematic. Then turning to describe in detail how to run a wide Delphi estimation session and provide examples of templates and documents that can be used during such sessions. They also provide a valuable process script for teams to follow.

Chapters cover planning, programming, testing, requirements, design and testing. Although most of these chapters cover each topic in reasonable detail, the design section is lacking in detail and provides no description about what type of design results can be produced and no detailed description of what these results could contain design. This is in contrast with the requirements of the chapter that contains scripts for the process of collection and analysis of needs, as well as a detailed description of use cases and software requirements specification documents.

Another aspect of the book is the verification that appear after addressing a major engineering project management software or subjects. Checklists are important techniques for quality assurance that the authors point out that are used throughout software projects as a way to catch errors early. For example, if a checklist is applied to the software requirements specification captures the fact that a prerequisite is missing or ambiguous, then the error can be corrected during the analysis phase. The authors explain that by catching and fixing errors early on, the cost is small compared to the cost of errors fixing later in a project. His emphasis on the techniques of quality assurance are applied throughout the project with examples of checklists to be applied, therefore, is very useful.

The authors may want to revisit some of the examples they use. Describe the process of refactoring the code to make it more maintainable and use an example of Java code that gradually over several iterations to refactor. At the end of this process of refactoring to say why it would apply in situations where the code is like spaghetti. This is fine, except they use a little example of spaghetti-like Java code refactoring. In this way I think they fall into a trap programmers code beautification where programmers spend time on the list iteratively improve the code works well to write the perfect? Code, the class or object. I’ve seen this happen on projects that simply was not time in the schedule to allow this, and since then, no additional benefit to business stakeholders. However, this is a minor flu.

I would have liked to have seen more pages dedicated to risk management. Again and again, risk management is not cited as a reason why projects fail. The authors describe risk management in a superficial way, however, the book would benefit from a better description of how and why risk management should be done throughout the project, not only in the early stages of planning projects.

One thing that I thought that the book lacks a detailed look at iterative methods. The implicit assumption is that all software project should follow the method waterfall. I disagree. There have been some important alternatives to the method of the cascade have been developed over the past 20 years including those based on iterative approaches. The main fall of the waterfall is its assumption that everything that is known about the requirements at the beginning of a project.

Iterative approaches, on the other hand assume that requirements change during the project, either because users get a better understanding of what they need, or because of changes in the business environment. Based on this assumption, iterative methods are designed to improve the management of this changing environment. With waterfall approaches, changes in requirements often require the project to revisit the early stages, with corresponding increases in cost and effort. The authors spend barely a page in the Rational Unified Process (RUP) and the authors should consider more carefully how their tips and processes can be used in alternative approaches to the iterative waterfall approach.

Finally, I think the book tried to be too broad, citing three different groups of people. First, a party is aimed at those involved in a software team (project managers, analysts, programmers and testers). Second part is for the consultants hired to improve the practices of project management and project managers who need software to manage outsourcing projects. The book would have been better if it had focused exclusively on those involved in the software.

The penultimate chapter on the management of an outsourcing project is discussed in a superficial manner as if the authors consider it necessary to mention that due to the outsourcing business is a priority these days. The final chapter deals with the improvement of the process is too short to deal effectively with this great theme. Separate books dealing exclusively with these issues would have been more appropriate.

Despite these points, this book is an excellent guide for those involved in software projects, both project managers and technical team members alike. They will find much that can be applied directly to their own projects.

I would recommend this book to anyone who works in a software development team, because the book has much practical advice to help people improve their ability to deliver quality software. Come to think, I also recommend to senior management of the companies that have a negative view of their own software development teams. Perhaps then the senior managers can understand why committing resources to process improvement is one of the best investments you can make.