Book Review: The Principles of Project Management

(This post contains affiliate hyperlinks. Please read my full disclosure.
“Delivering value” is the only reason to do a project.
Sitepoint’s Principles of Project Management includes web projects as a part of its stable. It’s not about managing a web project. It was easy to read on a slow train ride to the Kent countryside and back. Meri Williams’ writing style is fluent, which makes it easy to understand and not too technical. It was actually easier to read than Project Management for Dummies. It is also aimed at those who are just starting project management, which means that any jargon she uses is well explained.
Williams uses real-world examples to show how project management tools can be applied in real life. The chapter on project discovery, which is the process of justifying why you do what you do, is especially interesting at the beginning. This approach is not something I’ve seen in many texts, but it’s very useful, especially since Williams’ core audience is techies who are moving into project administration. As she explains, asking the right questions upfront will make it easier to move the project in the right direction and ensure that you are doing the right thing. She also mentions that understanding is key to reducing project problems and gives advice on what to do if a project is not well thought out. It takes until page 53 before any “real work” (as she calls them) is done. This is great because it is so important to have the foundations right.
Although the book won’t teach you how to manage multimillion-pound projects, it is not intended to. There are some practical and useful tips you can use right away. I love adding photos and phone numbers on the project organisation chart. This is a great idea for virtual teams or dispersed teams. Principles covers a wide range of topics, even though it doesn’t go into detail on non-project topics. It also touches on Hersey’s situational leadership model, RASCI collaboration matrix, and Tuckman’s model for group development (forming and storming, norming and performing, adjourning).
Williams discusses the SMAC goals:
Specific, Measurable, Actionable, Consistent.
What is a consistent objective? What is consistent with? I prefer SMART goals:
Specific, Measurable, Actionable, Realistic, Timebound.
The section on moving to operations is also important for software projects, particularly small ones where developers may end up providing day-to-day support. I disagree with the notion that all operational questions can be solved by reading the Project Initiation Document or change log. These documents will explain why a decision has been made, but not what should change to meet the new operational requirement or how to best use a particular function. Technical documentation is missing. These code specs, etc. are part of a project documentation and not a work package. Williams mentions handover and training documents, which could be necessary to resolve operational problems. However, if you have a question, it is likely that it was not something you thought of during the project. Therefore, it may not be in your documentation. It is better to have something. Williams recommends that you give full support and provide detailed documentation. However, you cannot fix all problems. Sometimes, the people who manage and support the project’s operations have to just get on with their jobs.
Appendix A contains a summary of the main points. It would be a good idea for you to photocopy them and use them as a desk reference. Or, better yet, print the poster and stick it up in your workspace.
Appendix B contains a list of re