Review By: Ronald R. Goodwin, PMP
03/23/2009This book on project management and software quality is fascinating. Even the foreword, written by Ed Yourdon, is interesting to the point of rereading several times. I find his (Yourdan's) statement "Becoming a bona fide project manager is not a quick or easy task ..." interesting as I heard a manager recently say that "...any developer can be a project manager, it ain't [sic] that hard, but I ain't [sic] never heard of a project manager knowing how to write code…" Yeah, sure. My feeling, as I gently stated to that manager was, "...try it, bozo!"

But let me get to this book properly. First, the book is not really a book. It is more like an encyclopedia of how to develop quality software using project management principles. With more than 1600 pages of information all organized into easily searched chapters, this book should be around for a long, long time. While a prospective candidate studying for his PMP might not want to read this book, or would place it lower in their reading list than, say, Berkun's The Art of Project Management (Theory in Practice), or Kerzner's Project Management: A System's Approach to Planning, Scheduling, and Controlling, that same prospective PMP, after achieving certification would certainly want this book in his library to read, re-read, dog-ear, and highlight.

The authors, with what would appear as a lot of support, start by introducing thirty-four essential competencies that should be employed by project managers who want to become successful project managers. The competencies are grouped in three categories: product, project, and people. I would refer anyone interested to pick this book up and start with the first chapter. Read it, and then read it again. To fully understand the remaining thirty-two chapters, the reader really has to understand the grouping and delineation of the competencies.

The thirty-four competencies work well in both project and program management, but the book is about software project management. I do not necessarily mean that as one term, but rather software, project, and management. This book touches on, and sometimes delves into, software engineering—a rather ambiguous term. To be quite outright, if you don't read any more than the first chapter, you still may gain insights into software quality management that you wouldn't get from volumes of other project management "how-to" books.

From novice to advanced skill levels, Quality Software Project Management offers insights, lessons, advice, and knowledge bites that are valuable. Each chapter opens with a quick few paragraphs describing that chapter, a section on where the chapter fits in the product development life cycle, the relation of that chapter to the thirty-four competencies and learning objectives. The authors do not write in a textbook style, per se; although, if the reader wanted to, they could take the text as it is presented and convert it with ease to a text for teaching project management as it can be applied to creating software with a high level of quality.

Go from product, to project, to people as you read the chapters, and find ways to cross-reference a chapter on product to people. How do you assign resources? Chapter 12 will give you the guidance you need, and you can track the answers provided to size of the project in chapters 7 through 10, or creating the process map for SLC process in chapter 4. Worried about legal issues? Chapter 32 guides you through this dangerous forest without falter. The authors know that many project managers worry about legal issues as they work with their development teams, so they break legal issues into product development techniques, project management skills, and people management skills in this chapter. Multiple charts and graphs help the reader grasp this slippery eel. While you might not be able to sit before the bar after reading the chapter, you can certainly sit across from a CIO and tell him what legal issues are going to jump up and bite the company as the project continues. Advertising, contracts, communications, Internet regulations, privacy, tort, and limiting software liability are topics addressed. (Until I read this chapter, I didn't realize that lawsuits can be filed for software being an embedded control product.) Chapter 32 is tied to chapter 18, "Determining Project Risks," within the text of both chapters. In fact, the chapter on legal issues has one of the best risk breakdown structures I have seen yet in print.