Review from 5.6 (September/October 2007)

I got an email a couple of months ago from the Pragmatic Programers group. They were putting out a new book called Manage It! about software project management. Johanna Rothman was the author, and she seemed to have a great reputation form what I could gather on the Internet. I thought I'd give it a try, and bought the book later that month.

Manage It! discusses things in a very straightforward manner. The author has years of experience in project management. The book approaches things from a consultant's perspective: managing a project in coordination with client in-house managers, developers, and top level decision makers. It gives processes and examples for how to define projects, and redefine them when they run short on a critical element (e.g. time, resources, or features). Better yet, it shows you how to document and keep track of the project so that you can explain to the client why you need more resources or why a project should be delayed. It even gives clear scenarios on determining with a client which features are truly necessary for the next version of the software and which features customers can live without until a subsequent upgrade. As a manager in my own organization, I can even use these processes for making business cases to my superiors.

The book's nuts and bolts style dives right into starting a project, and successive chapters delineate every phase of project management, down to completion, evaluation, and planning for the next project lifecycle. In fact the entire book is based on project lifecycles and how they live, breathe, grow, and die.

Rothman writes in a no-nonsense style, clear and concrete. I'm a sucker for books that feel like the author is there in the room talking with you in person. The author comes fairly close. The most important thing was that she gives concrete examples of her management processes and sidebars of real life scenarios. I hate books that are all promise and then vague, nebulous examples. Rothman's steps can be lifted directly out of the book and applied as is, or modified in any way you see fit. In fact, even though I read through the book from front to back, it's meant to be spot-referenced in any chapter that you need. The text is cross-referenced on each page to any other chapters that have relevant information. Now that I've read the whole thing, it'll be even easier for me to use it for reference as needed.

The book uses a lot of jargon for project management. I've read about Agile life cycle development before, but Waterfalls, project Dashboards, Iterative lifecycles, SMART, project "weather reports," Split Focus strategies, automated smoke tests, and more. Rather than being silly names for vague concepts, each term describes a concrete idea for keeping projects moving forward without hitches (or in many cases finding roadblocks before its too late to adjust course).

Not all techniques are computer-based. Some of the book's most effective strategies are paper or meeting-based. My favorite was Sticky Scheduling. You begin in a planning room and hand each team member a pad of sticky notes. Have them fill out one project item or concern on each sticky note. Then, have them organize the stickies on a white board and discuss how they relate. The team will (practically by themselves) categorize and organize the stickies into a plan for the project. Any items that become too controversial or can't be dealt with yet are placed on a section of the wall called the "parking lot," to be revisited later.

On a planning retreat for my organization last month, we used the sticky notes and whiteboards to map out our strategy for the coming year. I was amazed at how well the process worked. Everyone was involved, everyone was engaged, and real issues were addressed and prioritized. The sticky notes were boiled down during the day into a prioritized plan for both what we wanted to do and what we were capable of doing for the next year. Some stickies were shuffled to a next year board as important but not yet feasible. Some were consolidated. Some were discarded. I was particularly struck by how well the "parking lot" worked. Any stickies or issues that threatened to kill the forward momentum of the meeting were moved to the parking lot whiteboard to be re-introduced later. Some of these issues remain to be addressed in a later meeting, but the result was that real progress was made. We documented the results for reference later, and we left the retreat with a cohesive plan to move forward. It was clear what items were non-negotiables, and which items were desireable but not crucial to this year's goals.

The book discussed how this kind of planning crystallizes software deliverables for the consultant and the client. It becomes clear which features are necessary for the next version and which features customers can live without if development time becomes tight. Rothman gives examples of this concept in real life. In many organizations, the stickies were consolidated to one whiteboard and treated as sacrosanct. Developers could be seen walking up to the board, staring at various stickies, and rearranging their part of the project as needed by moving stickies around. It really helped keep everyone on the same page, and became a reference for discussions about schedules and priorities. Even though the sticky plan was documented in planning software (Omnifocus or Microsoft Project), the paper stickies became the main reference for developers.

On the whole, I found the book extremely valuable. I can't imagine running a project now without using these tools to keep it on track. In fact, I aim to get the author's companion book "Behind Closed Doors: Secrets of Great Management." The Pragmatic Programmers have done it again: a readable, concise book with great advice in a readable style.

Clearance Sale!

Book: Manage It!

Print:
PDF: