Applied Software Project Management Book Review

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

There are too many books on software project management or software engineering, which are dry, too complex and boring, but this book is not one of them. It 'was a joy to read because their writing style is clear without being simplistic, the authors describe things the right amount of detail. It seems that they understand their audience and set out to write in an extremely useful and practical. They have certainly achieved this.

The first part of the book covers tools and techniques that can be applied to projects. Project planning, estimating, scheduling, reviews, requirements, design and programming and testing each have a separate chapter. The second part is the use of project management in an effective and has chapters on understanding change, management and leadership, project management outsourcing and process improvement.

A clear thread throughout the book is a description of the typical problems software project teams face - inadequate requirements, change management, lack of quality assurance at every stage of a project, endless testing and bug-fixing cycles, tensions and misunderstandings between software engineers and business users. None of these problems are technical, but organizational and managerial. Stellman and Greene offer practical advice for solving these problems based on their experience on similar projects.

Stellman and Greene certainly seem to know much about the problems facing software development teams. Already the introduction describing the need to overcome the chronic problems and this theme is continued throughout the book. For every problem, there is always at least one solution. For example, describing a common scenario where managers do not trust the estimates of the technical team, somehow convinced that the technical team are deliberately over-estimated in order to give them a bit 'loose. The proposed solution is to involve these managers in the estimation process so they can see the current estimates in a transparent and systematic. They then go on to describe in detail how to perform a Wideband Delphi estimation session and provide examples of models and documents that can be used during these sessions. They also provide a valid script process for teams to follow.

Subsequent chapters cover the planning, programming, reviews, requirements, design and testing. While most of these chapters cover each topic in reasonable detail, the section on design lacks detail and does not provide any description on the type of deliverable design could be produced nor any detailed description of what these project deliverables may contain. This is in contrast to the requirements section that contains job scripts for requirements elicitation and analysis and a detailed description of use cases and software specification documents.

Another nice aspect of the book is the checklists that appear after facing a major topic of project management or software engineering. Checklists are important quality assurance techniques that the authors rightly point out should be used in all software projects as a way to catch errors early. For example, if a list of control applied to the specific needs software captures the fact that a critical requirement is missing or ambiguous, then the error can be corrected during the analysis phase. The authors explain that to catch and correct errors early, the cost is small compared to the cost of correcting the errors found later in a project. Their emphasis on quality assurance techniques to be applied throughout the project with examples of checklists for the application is therefore very practical and useful.

The authors might want to reconsider some of the examples they use. They describe the process of refactoring the code to make it more maintainable and use an example of Java code, which little by little refactoring several iterations. At the end of this process is called refactoring because it would apply in situations where code is spaghetti-like. This is fine, except that using an example of very little spaghetti-like code refactoring Java. In this way I seem to fall into a common trap programmers to code beautification where programmers spend time by iterative improvement program code that works well for writing the code for 'perfect', class or object. I've seen this happen on projects where there simply was not time in the program to allow this, and certainly did not bring any additional benefit to the business stakeholders. However this is a minor gripe.

I would have liked to see more pages dedicated to risk management. Time and again, no risk management is cited as a reason why projects fail. The authors do not describe the management of risk in a superficial way, but 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 design.

One thing that I thought the book lacked a detailed look at iterative methods. The implicit assumption is that the entire software project should follow the waterfall method. I would agree. There have been some important alternatives to the waterfall method, which were developed over the past 20 years in particular those based on iterative approaches. The fall of the main waterfall approach is the assumption that everything about the requirements is known, at the beginning of a project.

Iterative approaches on the other hand assume that requirements will change during the project or because users gain a better understanding of what they need, or because of changes in the business environment. Based on this assumption, iterative methods are designed to better manage this changing environment. With waterfall approaches, changes in requirements often require the project to revisit earlier stages with a corresponding increase in the cost and effort. The authors spend barely a page of the Rational Unified Process (RUP) and the authors should look more closely at how their practical tips and processes may be used on alternative iterative approaches to the waterfall approach.

Finally, I think that the book tried to be too broad, appealing to three different groups of people. First, one side is aimed at those who are involved in a software team (project managers, analysts, programmers and testers). The second part turns to consultants hired to improve practices in project management and project managers who need to manage software projects outsourcing. The book would have been better focused only on those who are involved in the software team.

The penultimate chapter deals with the management of an outsourcing project is dealt with in a superficial way as if the authors have found it necessary to talk about it, because outsourcing is a business priority these days. The final chapter deals with the improvement of processes is too short to deal effectively with a theme so great. Separate books that deal exclusively with these problems would be more appropriate.

Notwithstanding these points, this book is an excellent guide for those involved in software projects, both project managers and team members similar techniques. They will find a lot can be applied directly to their projects.

I would recommend this book to anyone working in a software development team because the book has so much practical advice to help people improve their ability to deliver quality software. Come to think of it, I would also recommend it to executives of companies that have a negative view of their software development teams. Perhaps then leaders could understand why commit the resources to process improvement is one of the best investments you can make ....