Book Review: Manage It! Your Guide to Modern, Pragmatic Project Management
After some fifteen years of managing a wide range of projects I joined Logica in 1989 to head up one of the company's largest projects. Before I even unpacked my briefcase I was sent on a three-day project management course during which I discovered that almost everything I had done in the past was not good practice. It was a salutary experience to sit there amongst less senior colleagues and get the answers wrong. The course paid off some ten years later when I started a major project in Washington two days before 9/11 and managed to deliver on time and on budget. Over the years I have built up quite a collection of project management books and was very interested to see how this new book would stand up against them.
Chapters and Subjects Covered
Before looking at the book in detail I should explain that this book is primarily about the management of software projects. Johanna Rothman [1] has a long and distinguished career in software engineering. Not many readers will actually be managing a software development project themselves right now, but my expectation is that their daily life is being influenced by one or more such projects as I write. In addition my guess would be that only about five per cent of this book is about techniques that are purely applicable to software development.
There are sixteen chapters that follow the life cycle of any project. The first five chapters cover project initiation, initial project scheduling and estimating the work that will be involved. It is when you get to Chapter Six that the author really starts to show her considerable expertise and her gift for communication. The chapter is entitled 'Recognising and Avoiding Schedule Games' and includes observations on various approaches to managing schedules, such as the 'Bring Me a Rock' game. This is when the sponsors tell you they want it faster but don't tell you when or why. I'm sure that is a familiar situation, and the author comes up with five possible solutions.
Chapters Seven to Ten are all about the people-aspects of projects, including creating a great project team, steering the project, maintaining project rhythm and managing meetings. The chapter on managing meetings is quite superb, and starts with a section entitled 'Cancel These Meetings', highlighting that any meeting that does not clearly have a defined and measurable impact on the progress of the project should be cancelled.
Chapters Eleven to Thirteen provide advice on the ongoing management of projects and monitoring progress. Chapter Thirteen specifically covers methods for integrating testing into software projects and is the only chapter that is only tangentially valuable to other categories of project. The final chapters cover the management of multiple projects and project completion.
Throughout the book there is a good selection of diagrams and charts and many of these are available on a Web site associated with the book. There are a few Web citations in the footnotes but this is basically the expertise of the author laid out in a highly organised way with good contents pages and a well-constructed index that facilitates dipping in to a specific set of pages for guidance on a problem. The writing style is heavily 'conversational' and when I read the book for the first time on a long train journey I felt that I was being talked to by the author. Paragraphs longer than 100 words are very rare.
Conclusion
If you are looking for a formal comparison of project methodologies then this is not the book for you. If you have been told (or in a moment of madness volunteered) to be a project manager then this book will be invaluable if you accept that from time to time you will need to recognise that the advice is specifically about software projects. However this could be an asset when you are the customer for a software project, for example the upgrade of your library management system or a new content management system. You can then use the book to check on the project management procedures being used by the contractor and highlight those that you sense are going to cause problems along the line.
The approach is very pragmatic and comes from an author who has clearly managed a very wide range of successful projects. Because of this pragmatic approach, reconciling the advice given with Prince2 [2] is going to be a challenge, but then all too often I find Prince2 has been adopted because it's the only methodology most managers have ever heard of!
Even after some thirty years in project management, I found much of value in this book and time after time found I was saying to myself "That's neat!". Give this book to any one in your team that you have appointed as a project manager but do read it first, as you will find yourself being asked some difficult questions within a very short time.
References
- Johanna Rothman http://www.jrothman.com/
- What is PRINCE2? - PRINCE2 Definition http://www.prince2.com/what-is-prince2.asp