Pity the poor project managers. They are not in the upper management echelons, nor are they programmers. In fact, they often get flak from both sides as they struggle to make projects succeed. Project management is not engineering, and many of the traits of successful project managers are elusive; it is probably more of an art than a science, justifying the title of this book.

The reader will not find development methodologies exposed here. The author instead opts to focus on higher-level issues that every project manager should be aware of, no matter the specifics of the project.

These issues are plans and how to make them, skills and how to acquire them, and management. They serve to divide the book into three parts. In the first part, we are given an overview of the tentative nature of schedules, how to arrive at a project vision, and how to generate and nurture ideas. The skills part includes writing specifications, decision making, communications, and crisis management. Finally, we read about the basics of leadership, typical activities undertaken during the project, and power and politics.

The book follows the path traced by Peopleware [1] and Death march [2]. That is, it is not a book about specific software engineering techniques, but a book about attitude (and with an attitude). Aspiring project managers will find plenty of advice on the correct view they should adopt and the stance they should take in particular circumstances. Almost all of the information presented revolves around the theme of enlightened leadership, and there are many references to popular management texts. However, enlightened leadership without a good technical background will not get you very far in software project management, so this book would be well complemented by some more technical titles [3,4].

The author worked for several years at Microsoft, and reading anecdotes from life in the world’s most successful software company is exciting. This is a well-written book, although I became tired of the numerous bulleted lists in the text. The author assures us, and it is true, that making lists is a crucial part of the project manager’s job, but having too many in a book leads to a staccato style of reading.

Although the issues described in the book apply to all projects, the way they are approached, and the resolutions proposed, may strike a dissonant chord across cultures. For instance, consider the author’s assertion, when recommending a certain book, that, “Yes, this is a book on therapy. And yes, if that bothers you, it’s probably exactly the kind of book you need to read.” Readers outside the US are likely to be bemused. Also, ideas on participatory design and power sharing emerged in Scandinavia a couple of decades ago, so the related material may be novel in some institutional contexts, but not very much so in others.

Will this book make readers good project managers? It is possible that it will make readers better project managers, but it does not discuss many of the technical details that software project management requires. One cannot be a good software project manager without being knowledgeable in methods, software tools, and quality assurance, among other things. Unfortunately, even those possessing this technical knowledge do not necessarily make good project managers. This book may push them into the right frame of mind and may make them ask themselves the right questions.