Making Things Happen by Scott Berkun (a book report)
Summer’s coming to an end. It seems like only yesterday that the school year ended, KU’s student population cleared out of Lawrence, and I cracked open Making Things Happen: Mastering Project Management by Scott Berkun. Now it’s August, the students are back in full force, and I’ve spent my entire summer with this book. Why so much time with one book, especially when my summer reading list was supposed to be much longer?Making Things Happen is very dense (my notes for about 80% of the book currently check in at 41 pages). It’s a summary of Berkun’s experience managing software development projects at Microsoft; in particular a few iterations of Internet Explorer during the original browser wars. It makes for an interesting perspective, especially at a time when Agile methodologies have overtaken most web-oriented projects. I’ll talk about that more in a minute.
If you’re like me and sort of fell into a managerial role for whatever reason (for me, I think it was because I was never afraid to speak up at work) but never had either the proper schooling or a solid manager to look up to at some point in your career, this book can answer a lot of questions you might have about how your job as a project manager is, at least in theory, supposed to be done. All of the stages of traditional software development are explained in detail, along with tips for documenting the planning process, making tough decisions, communicating, managing personalities, and damage control. The style is direct—blunt, even—with a good issue-to-example ratio (in my opinion, writers like Godin and Gladwell can really milk an idea by citing example after example after example, when one or two concrete case studies would suffice). Like I said, the content is geared toward software development, but I think if you’re able to think about it within other contexts you can glean some good information from it. In particular, instructional designers who use an ADDIE-style approach to instructional development can learn a lot.
That brings me to Agile within the context of Making Things Happen. Berkun espouses a traditional, planning-heavy approach to software development—think waterfall, though it’s not labeled as such, probably because it’s become such a derogatory term in software development. He acknowledges Agile (again, not by name), framed within the discussion of explaining the importance of planning to developers who think they don’t need to plan. Berkun’s high-ground takeaway is that all methodologies have their time and place; and from what I learned reading this book his projects at Microsoft would not have fit that approach for whatever reason. You may agree with him; you may not. Personally, I think there’s nothing wrong with a little bit of homework up front, provided you don’t spend all your time planning and not leave much time for doing. I also liked the overall tone of his explanation of his methodology, without resorting to some of the big talk (“software that matters”) and zealotry that always turns me off when reading about Agile (as much as I otherwise agree with it as a methodology).
One feature of this book I wish I’d taken more advantage of throughout is the activities section at the end of each chapter. I think if I’d read this book as a part of a group these summaries would have been useful learning and processing exercises. A reader might also be best served by treating Making Things Happen more as a reference than a textbook, to be called upon during specific tasks or situations. That said, I think it’s a good addition to a project manager’s bookshelf.