Key Notes from the Art of Project Management
Scott Berkun’s book The Art of Project Management (now issued in a new edition and renamed Making Things Happen: Mastering Project Management (Theory in Practice)) is the best book I’ve read on project management. It is fantastically helpful.
The other day I came across these brief notes I had jotted down a while ago from the book. They are very incomplete, hitting on just a few of the key things that stood out to me.
But sometimes, that’s what can be most helpful. So here they are, in case they might be timely for you as well:
- Requirements vs. specifications. Requirements are the what, and specifications the how.
- The three perspectives: Business (including marketing), technology, and user. User is most important but also most often neglected.
- The importance of planning: “Plans provide an opportunity to review decisions, expose assumptions, and clarify agreements between people and organizations. Plans act as a forcing function against all kinds of stupidity because they demand the important issues be resolved while there is time to consider other options. As Abraham Lincoln said, ‘If I had six hours to cut down a tree, I’d spend four hours sharpening the axe,’ which I take to mean that smart preparation minimizes work.” (p. 41)
- On thinking outside the box. It’s not always best to say “think outside the box.” Eliminating boxes is not necessarily the hard part—it’s knowing which boxes to use and when to use them. Constraints are ever present. Art of Project Management, 93. “Do whatever you want with the box. Think in the box, out of the box, on the box, under the box, tear apart and make a fire out of the box, whatever, as long as you manage to solve the problems identified as the goals for the project” (p. 94).
- Where good ideas come from. To generate good ideas, ask good questions.
- Open issues list: “An open issue is anything that needs to be decided or figured out but hasn’t happened yet. It’s essentially a list of questions, and it should encompass anything that needs to be done, prioritized by its potential impact on engineering” (123).
- Different types of requirements and specs: Requirements, feature spec, technical specs, work-item list (the description of each programming assignment needed to fulfill the feature spec), and test criteria and milestone exit criteria (prioritized cases for the new functionality, along with goals for how well the code needs to perform on those cases to meet the quality goals for the milestone).
No related posts.
Comments
Leave a Reply
About Matt Perman
Follower of Christ. Husband of one, father of three. Former director of strategy at Desiring God. This blog exists to help equip Christians in good works, because that's what productivity is really about.
Learn more Contact me Friend me on Facebook Follow me on Twitter
Keep Updated
Subscribe by email
