Manuscript Review: "Project Decisions"
An editor for a publisher reached out to me via LinkedIn on January 8, 2019 with an opportunity to provide input on the second edition of a book in exchange for a flat fee. I was given 1 calendar month to complete the review, and I submitted my feedback on February 9, 2019.
While I've reviewed quite a few technology and business texts over the years, including those at the request of authors and publicists, this was the first time I was paid to perform a review.
In addition to providing me the book manuscript in Microsoft Word format, the editor also posed a number of questions that she wanted me to address, so my deliverables to the editor were two-fold: (1) an edited book manuscript with my inline comments, and (2) a 4-page document that I wrote to address her questions. My work on this manuscript review, including a reading of the book, was performed in 1 calendar day.
At some point I'd like to write a post about all of the reviews I've performed directly for authors and publicists. Some colleagues have asked why I do this for (typically) no pay, just like I've been asked why I do pro bono work.
While my reasons for doing pro bono work differ, the following are my reasons in a nutshell why I perform these reviews: (1) to grow my network, including for a time when I might want to be published myself, (2) to develop my writing and editing skills, and (3) because I find it enjoyable to give back from my work experience.
The following is the text from my manuscript review, including the bolded editor questions.
Review by Erik Gfesser for Charlotte Ashlock and Sarah Modlin at Berrett-Koehler Publishers “Project Decisions: The Art and Science (Second Edition)”, by Lev Virine and Michael Trumper:
If possible, it would be great to also receive a digital copy of the manuscript with your inserted notes and observations. I will share your content review with the author and the editor on the project.
In addition to this document, I am also providing an edited manuscript with review notes constrained to the material added for the new edition, which is understood to be highlighted in yellow. My review of this new content could not help but make note of a considerable number of grammar and spelling mistakes. As a prolific reader and writer, I often get annoyed when coming across such mistakes in published material because my presumption is that the authors of such works should be better writers than myself. And as a reviewer, I tend to rate books lower simply because of such mistakes. Most books have a small amount of grammar and spelling issues, but it is extremely distracting to me as a reader when I need to additionally think through what I am reading simply because of the manner in which the material was written. As the manuscript provided to me is likely not the first draft, these issues should have been resolved by now, and I highly recommend that the second edition not reach publication until the notes I have added to the manuscript have been addressed. Note that my inline review notes were written during my initial walkthrough of the manuscript, so this document includes additional thoughts following this additional reading (apart from my notes on grammar and spelling issues, which are constrained to the manuscript).
What additions to the new edition are you the most pleased about? What do you think is most compelling about the new and revised version?
Page 23, 197-198
The evolution of Tesla Model 3 manufacturing over such a short time period is bound to be a classic example for a long time to come, regardless of whether this car model has long-term success. As an avid Tesla follower myself, I think it will, and as such I think this addition to the new edition is a good one and will remind the reader that they are reading a recently published book, a book attribute that some will undoubtedly find of value.
What are parts of the book you think are working less well? Please give examples of where you see this, and how you would revise it to make it work better.
Page 12:
The “Test Your Judgment” section includes a question which makes use of an example citing Kim and Kanye, and the text for the new edition qualifies these individuals as being Kim Kardashian and Kanye West. I recommend use of a different wedding couple, although I realize the intention is probably to make use of a well-known couple while still being as apolitical as possible. One of the reasons for this suggestion is to help prevent this book from becoming outdated when this couple's popularity fades away. I suggest use of a royal couple instead. What I'm not immediately clear about here is that if this phrase is what was added from the first edition, how anyone would have known when reading the first edition who "Kim and Kanye" might be in the remainder of the example.
Page 13:
Similarly on the following page, my presumption is that “Mike Zukkerfield” is a play on "Mike Zuckerberg", in which case I'm not sure why this name wasn't used to begin with, especially since "Kim and Kanye West" were already cited earlier. Why wasn't something like "Kim and Kanye East" not chosen if there is a concern about citing real individuals? Alternatively, I would choose another name here since Mike Zuckerberg is losing favor as of late with the public.
Page 39:
Inclusion of Figure 2.4 is understandable, but I recommend a photo that shows the car from a different enough angle so that the logo is not visible. The reality is that I naturally looked at the image before reading the sentences leading up to it, and already knew that the depicted car is not from Mazda, Toyota, or Kia simply by my not recognizing the logo.
Page 49:
I am not sure whether Figure 3.1 provides much value to the discussion other than possibly to help the reader visualize the relationships between the 3 components. If it is decided that this image does provide value, I recommend replacing it with one that more properly fits the word "Comprehensiveness", or using something like "Compre-" and "hensiveness" so that syllables are broken down correctly.
Page 63:
While the author should be careful in general when using drug firms as an example here, the author’s added remark for the second edition that “a significant number of drugs never make it through the approval process” should be used with caution. While this statement might be technically true, just keep in mind that many drugs are fast-tracked, the ramification being that some risks might not be discovered until a later point. In addition, my understanding is that drug firms have enjoyed zero liability for vaccine injury as of the 1980s. The number of injuries was getting so high at the time that firms threatened to stop making vaccines unless they were granted immunity.
Page 135:
It might be worth noting that not only can everything be benchmarked, but everything can be measured. The practice of measuring everything is an important one because I have often heard from others in the workplace that many aspects are not measurable. The reality is that everything is measurable, but it needs to be determined whether doing so is worth the cost, financial or otherwise.
Page 147:
I have extensive experience with agile processes (and have multiple Scrum certifications), and Figure 12.5 of the waterfall model is not accurate. Instead, this diagram represents how individuals have misinterpreted the model. While I am definitely not an advocate of traditional waterfall methods, keep in mind that each phase as originally defined was supposed to loop back to its prior phase to act like a feedback loop. The author who first discussed this model included these feedback loops, but others have since excluded. If you wish to include this diagram in the second book edition, I recommend either calling this out, or explain in the context of how the waterfall method is typically carried out.
Pages 201-204:
The “Event Chain Diagrams” section needs to be cleaned up, and I have a few recommendations with consideration for its inclusion within a broader “Basic Principles of Event Chain Methodology” section that lists six principles. What is confusing to me as a reader is why diagrams are listed as a principle, and if these are really a principle why section principle #3 is not explained prior to the diagrams of principle #1 and principle #2. I think it makes sense to explain diagram notation before the diagrams of these earlier principles, and as such I recommend either reconsideration of whether event chain diagrams are a principle or just a communication mechanism used for the methodology. Either way, perhaps an introductory sidebar should instead first explain how to read such diagrams. Additionally, the author should be consistent in their structure of each bullet point. For example, I mention in my manuscript notes that each bullet should follow the pattern of symbol followed by explanation. The author goes back and forth with this pattern and explanation followed by symbol, and I found myself restructuring each bullet point as I was reading through all of these, distracting myself from likely author intent.
Page 252:
The author’s list of technologies to solve problems with scarce resources should probably be framed within the context of the fact that these technologies also pose risks and costs. For example, as someone doing "big data" work I know that while this type of work can provide significant value to an organization, this is not always the case, with "small data" sometimes providing a more relevant solution. Additionally, the terms "big" and "small" in this context have been largely irrelevant for approximately the last 5 years and I don't make a habit of using them.
Pages 254-256:
Appendix A provides a table of risk and decision analysis software. I highly recommend that the paragraph preceding this table be elaborated to explain that every customer of such software will have their own unique requirements, so whether these will be of help is only a possibility. If the author has not already done so, I also recommend that research reports from firms such as Gartner and Forrester be consulted as input to this table to help ensure that a survey of software within the domains of quantitative project risk analysis software, enterprise risk management software, and “other” decision and risk analysis software used in project management covers enough ground, and that high-level considerations for choosing a software vendor be listed. Additionally, I would define the difference between the categories of the first two tables, because it’s not clear to me as a reader what distinguishes these two. The author should also consider breaking down these tables further or adding a column that indicates subcategory of software. Alternatively, every single entry in the first table is described as Monte Carlo software: if this type of software really dominates “quantitative project risk analysis software”, why not just describe this table as “Monte Carlo software” instead?
What themes and topics are missing from the new edition that you would really like to see added into the new edition? Where would you like the author to go into greater detail? Is there something the author does not discuss that you wish she had?
In reviewing what the author presents about “agile”, I think it’s important to note that the concept of agile is not a monolith. Additionally, not everyone views agile methodologies as forms of project management, with many going so far as to say that project management in many cases is not even needed, and I share this opinion. I strongly recommend going into much greater detail on this subject matter, since agile methodologies have had such a profound impact on how work is performed. For example, I recommend breaking down the agile universe a bit to discuss some of the key approaches. While agile methodologies were still relatively uncommon in 2007 when this book was first published, the ensuing 10 years have seen widespread adoption, for better or worse. As such, the author should include discussion as to the scenarios in which each of the key approaches is more appropriate, especially within the context of corporate culture, which I’ve found to be a weighty success factor.
Are there any parts of the revised manuscript that you would recommend cutting or shortening and why? What do you think is the least crucial information within the book, if cuts have to be made?
I would remove chapter 5 (“Creativity in Project Management”). Additionally, I would not add Appendix A (“Risk and Decision Analysis Software”) unless the author addresses my comments earlier in this document.
How does the new edition deepen and strengthen the themes and contributions found in the original work? What do you personally find most interesting in the work and most useful for your own work and life? What do you like least?
My own work has increasingly concentrated in three areas: enterprise architecture, data and database architecture, and custom software development. Since reading the first edition of this book, I have increasingly come to the conclusion that in all of these areas (which cover a significantly large portion of corporate technology work), I largely see no need for project management. As such, I personally do not find much practical value here for my own work. That said, I am always open to new ideas, and reading books such as this one provides different perspectives that will inevitably feed my evaluation of work approaches for clients in the workplace. And of course, not everyone shares my opinions, especially those working in firms who approach work in a traditional manner.