When I saw that Scott Berkun was writing a book called The Art of Project Management I was pretty excited. Scott spent much of his career as a Program Manager at Microsoft, and I knew that the book would be chock full of information that goes into great detail about what this wacky job is about, and what it means to be a great Program Manager.
On my flight to and from Shanghai, I read the book mostly cover to cover. I say mostly because it’s 448 pages! The reality is that some of the chapters were just plain obvious to me, so I skimmed them. This book will be whatever you want or need it to be. If you are brand new to the PM job, or a seasoned veteran who joined a new team and is trying to explain to the folks around you what your job is about, this book will help you. I know it’s going to help me.
I would go so far as to say this. If you are in this role at a software company, and have been doing it for less than 3 years, this book should be your text book. Nothing will matter more in your career than having a good grasp and mastery of many of the skills highlighted in the book. If you are an old timer, then this book will be an interesting read to say the least, if not help you with a situation you might be facing today (or tomorrow).
While I’m not going to write pages and pages about this book, I though I would highlight some of my favorite chapters or sections. I wrote and underlined a lot in my copy and I plan to go back and reference these things when necessary.
A Brief History of Project Management
This is the first chapter in the book and has a lot of meat! The main take always for me in this chapter were “The simpler view of what you do, the more power and focus you will have in doing it” and “simple doesn’t mean easy”.
The best example Scott gives here is that of running a marathon. What’s simpler than running? You start running and you stop after 26.2 miles. If I were to do this, there would be an ambulance at the 5th mile to take me to the hospital.
I’ve seen a lot of PMs run projects by creating massive amounts of tools to analyze and report on data about the project. This sounds great and fancy stuff always looks neat, but the tools aren’t going to ship the product, you are. I like and do maintain a very simple view of complex systems. It allows you to be agile. It’s no excuse for not knowing or understanding everything about what is going on, but try and create the least amount of overhead for yourself and your team.
Scott also discusses the history of the PM role at Microsoft. It’s critical to understand why there are so many PMs at Microsoft, and how critical they are in getting stuff into customers hands. He discusses the various traits of PMs and what good ones can do. For me the most important trait is tolerate ambiguity/pursue perfection and courage/fear. “The brave are those who feel fear but chose to take action anyway”.
There is a great topic on confusing process with goals. It’s easy for a PM to try and quantify things that don’t need to be quantified, and fall into a trap of unnecessarily paying attention to your charts, tables, and tasks. Scott paints a good picture of how you evolve into someone who ends up believing that the data and the process are the project, and you lose sight of what your team is trying to do for the business. He makes a bold statement that “your project is your team. Manage the team, not the checklists.” I can’t tell you how important those words are. Sadly for some people, they don’t know what managing the team means, but the good news is that Scott goes into much greater detail in Chapter 10.
On Leadership, Scott states “…leaders and managers are hired to amplify the value of everyone around them”. Again, if you are a great leader you allow people to work to their potential, and you can even increase the abilities and output of the team. These are hard things to measure and very intangible traits (unlike writing code or a test case). Scott also states that “It takes a combination of conviction, confidence, and awareness to be effective and happy as a leader of a team”. If you lack, or haven’t developed as a leader yet, I can guarantee that you won’t be happy, and neither will your team. Leading a project is like drinking from a fire hose, and you need to be prepared or have the support to be coached to do this job well.
Scott ends the chapter with a phrase to describe how he added unique value. He calls this “Making good stuff happen”. On our team, Aditya and I have coined the phrase, “Less talking, more doing” and I think we have the same idea when we say this. The premise is that you can accomplish much more and add a great deal of value if you, as a leader, spend more time with each person on the team than anyone else. In doing this you may influence more decisions than anyone else in the organization, and what you bring to the team will be contagious (good or bad) for the rest of the team.
Final Thoughts
There are many excellent chapters in the book, and hundreds of sentences and insights that really tell the story of Program Management and how to be better at this role. I learned much from this bug and validated much of what I know and do. My favorite chapter is Chapter 10 How not to annoy people:process, email and meetings. This is a must read for every Microsoft Employee 
.
A couple more things I picked up are that empowering people isn’t necessarily being a good manager, but caring about the work that they do, and staying involved with the decisions they need help with go hand in hand with personal growth. Chapter 13 has a great example of this when Scott had to solve a cross team problem and his boss at the time, Hillel Cooperman, provided him guidance that allowed Scott to make the right decision for himself and the business.
Get the book, read it. You won’t regret it. You’ll likely find something that you aren’t doing well, or could be doing better. Or something you can do to help make your team better.