Applied Software Project Management Book Review
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 recent book Applied Software Project
Management.
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.
A clear thread throughout the book is a description of the
typical problems 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. 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.
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.
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. 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.
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.
One thing I thought the book lacked was a detailed look at
iterative 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.
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.
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.
