Introduction
It’s 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 book Applied Software Project Management.
It’s an easy read
There are too many books about software project management or software engineering which are dry, overly complex and boring, but this book is not one of them. It was a joy to read because their style of writing is clear without being simplistic and the authors describe things in just the right amount of detail. It seems they understand their audience and set out to write in an extremely helpful and practical way. They have certainly achieved this.
Part one of the book covers tools and techniques that can be applied on projects. Project planning, estimation, scheduling, reviews, requirements, design and programming and testing each have their own chapter. Part two is about using project management effectively and has chapters on understanding change, management and leadership, managing an outsourcing project and process improvement.
Practical advice to problems
A clear thread throughout the book is a description of the typical problems which software project teams face – inadequate requirements, managing changes, lack of quality assurance at each stage in a project, endless testing and bug-fixing cycles, tensions and misunderstandings between the software engineers and business users. None of these problems are technical in nature, but are organisational and managerial. Stellman & Greene offer practical advice to solve these problems based upon their experience on similar projects.
Stellman & Greene certainly appear to know a lot about problems that face software teams. As early as the introduction they describe the need to overcome chronic problems and this theme is continued throughout the book.
In fact, the most common problems faced by project teams are often not directly covered on your typical project management courses. So, reading this book will equip teams with some of the knowledge needed to improve their software development processes.
For each problem, there is always at least one proposed solution. For example, they describe a common scenario whereby senior managers do not trust the estimates of the technical team, somehow believing that the technical team are deliberately over-estimating in order to give themselves some slack time. Their proposed solution is to involve these managers in the estimation process so they can see the estimates being made in a transparent and systematic fashion. They then go on to describe in detail how to run a Wideband 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.
Subsequent chapters cover planning, scheduling, reviews, requirements, design and testing. Whilst most of these chapters cover each topic in reasonable detail, the section on design is lacking in detail and provides no description about what kind of design deliverables might be produced nor any detailed description of what these design deliverables might contain. This is in contrast to the requirements chapter which contains process scripts for requirements elicitation and analysis as well as a detailed description of use cases and software requirements specifications documents.
Checklists
Another nice aspect to the book is the checklists that appear after dealing with one of the main project management or software engineering topics. Checklists are important quality assurance techniques that the authors rightly point out should be used throughout software projects as a way of catching errors early.
For example, if a checklist applied to the software requirements specifications catches the fact that a critical requirement is missing or ambiguous, then the error can be corrected during the analysis stage. The authors explain that by catching and fixing errors early, the cost is small compared with the cost of fixing errors found later in a project. Their emphasis on quality assurance techniques being applied throughout the project with examples of checklists to apply is therefore very practical and useful.
Examples
The authors might want to reconsider some of the examples they use. They describe the process of refactoring code in order to make it more maintainable and use an example of some Java code which they gradually refactor over several iterations. At the end of this process they say why refactoring would be applicable in situations where code is spaghetti-like.
All this is fine, except they use an example of very un-spaghetti-like Java code to refactor. By doing this it looks to me that they fall into a common programmers trap of code beautification where programmers spend time from the schedule iteratively improving code that works just fine in order to write the ‘perfect’ code, class or object. I’ve seen this happen on projects where there simply wasn’t the time in the schedule to allow this, and it certainly didn’t bring any additional business benefits to the stakeholders. However this is a minor gripe.
What’s missing
I would have liked to have seen more pages devoted to risk management. Time and again, not managing risks is cited as a reason why projects fail. The authors do describe risk management in a cursory way, yet the book would benefit from a better description of how and why risk management should be done throughout the project, not just in the early stages of project planning.
Lacking iterative methods
One thing I thought the book lacked was a detailed look at agile methods. The implicit assumption throughout is that the software project should follow the waterfall method. I would disagree. There have been some important alternatives to the waterfall method which have been developed over the last 20 years most notably those based upon iterative approaches. The main downfall with the waterfall approach is it’s assumption that everything about requirements is known at the beginning of a project.
Iterative approaches on the other hand assume that requirements will change during the project either because users gain a better understanding of what they need, or because of changes to the business environment. Based upon 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 costs and effort. The authors spend barely a page on the Rational Unified Process (RUP) and the authors should look more closely into how their practical advice and processes might be used on alternative iterative approaches to the waterfall approach.
Aims too wide
Finally, I think the book tried to be too broad by appealing to three different groups of people. Firstly, part one is aimed at those involved in a software team (project managers, analysts, programmers and testers). Part two is aimed at consultants hired to improve project management practices and project managers who need to manage software outsourcing projects. The book would have been better had it focused solely on those involved in the software team.
The penultimate chapter dealing with managing an outsourcing project is dealt with in a cursory way almost as if the authors felt they needed to mention it because outsourcing is such a business priority these days. The final chapter dealing with process improvement is also too short to deal effectively with such a large topic. Separate books dealing solely with these issues would have been more appropriate.
Conclusion
Not withstanding these points, this book is an excellent guide for those people involved in software projects, both project managers and technical team members alike. They will find much they can apply directly on their own projects.
I would recommend this book to anyone who works on a software development team because the book has so much practical advice to help people improve their capability to deliver quality software. Come to think of it, I would also recommend it to senior managers of companies who have a negative view of their own software development teams. Perhaps then senior managers might understand why committing resources to process improvement is one of the best investments they can make.
