Books

Announcing Head First PMP, 2nd edition!

~ Andrew Stellman ~ Leave a comment

Head First PMP cover

“I teach Project Management for for a project management firm and its clients. Using Head First PMP exclusively as the course material, my students have an 84% first time passing rate for the PMP and CAPM. This is by far the very best and most complete book for anyone looking to improve their project management skills and pass the PMP exam.”

—Rocket Williams, PMP, MCITP, MCT
Director of Business Development and Project Management Processes
AdaQuest, Inc.


Jenny and I just put the finishing touches on the second edition of Head First PMP, and it should be out in bookstores as soon as it comes off the presses. We’ve brought it completely up to date to provide 100% coverage of the new version of the PMP exam. It was definitely a lot of work — and in case I haven’t mentioned it lately, I’m lucky to have a coauthor who’s as committed, hard-working, and quality-oriented as Jenny! You can download Head First PMP, 2nd Edition today as an O’Reilly Rough Cut PDF (see the end of this post for details).

I’m really impressed with all the changes that PMI put into the PMBOK® Guide, 4th Edition (which is what the PMP exam is based on). When we first wrote Head First PMP, there were a few concepts and ideas in the third edition that Jenny and I found a little challenging to explain in a straightforward way that’s easy to understand. When we read the new PMBOK Guide for the first time, I was happy to see that they’d improved some of the more cumbersome concepts that people had a really tough time understanding — like the difference between a scope statement and a preliminary scope statement, for example. Now that the preliminary scope statement’s gone, scope management makes a lot more sense.

And there are new additions that made me really happy. It was great to see a whole new process dedicated to collecting requirements. If you’ve read my Requirements posts, you know how important I think requirements management is to making sure your projects are successful. I’ve believed for a very long time that project managers — especially for software projects — have a responsibility, even an obligation, to make sure the whole team understands the project’s requirements. That’s why we put a whole chapter on requirements in our first book! So the Collect Requirements process is a really welcome edition to the PMBOK Guide.

There was another really interesting addition: the addition of iterative project phases. I think it’s really useful that the project management world has increasingly embraced iterative project development, especially in software. Personally, I attribute this, at least in part, to the fact that Agile development has soared in popularity over the last few years. The fact that project managers are being trained to work with teams working iteratively is a really good development, and it’s great to see that being reflected on the PMP exam.

Also, it was nice to see that the Manage Stakeholders process got a new name: it’s now the Manage Stakeholder Expectations process. I always thought it seemed a little… unrealistic? yes, that’s a good word — it always seemed a little unrealistic to think that a project manager could actually manage stakeholders on a real project. But managing their expectations is something that every project manager needs to do in order to keep a project running.

There are lots of other PMBOK® Guide changes, big and small, and we’ve put months of painstaking effort into tracking down each one and making sure the book is completely up to date. And we put together a phenomenal review team to help us ensure that Head First PMP, 2nd edition has 100% coverage of the new version of the PMP exam based on the PMBOK® Guide, 4th Edition.

Oh, one more thing. I wanted to take a minute and thank all of the people who’ve been writing to us and asking when the new edition of the book is coming out. I’m sorry I couldn’t write back to each of you individually; we’ve been working really hard to make sure the new edition is as accurate and easy to use as possible, and we just didn’t have time to answer all of your e-mails. But we definitely heard you, and want you to know that we think the second edition is even better than the first! And, as always, if you’ve got questions about project management or difficult PMP topics, definitely send them to us. We get a lot of questions and e-mails, and don’t always have time to answer each one, but we do love Q&A and if it’s a good question we’ll try to write a good answer!

Head First PMP back cover

You can download Head First PMP, 2nd Edition today as an O’Reilly Rough Cut. They’ve got a great deal where you can get the online rough cut PDF today when you pre-order the book! Or you can just pre-order the book and get 35% off.

The Secrets Of Great Teamwork

~ Andrew Stellman ~ 2 Comments

Beautiful Teams and Tim O'Reilly

Forbes picked up our Beautiful Teams interview with Tim O’Reilly and published it as an article called The Secrets of Great Teamwork.When Jenny and I talked to Tim, he had some intriguing things to say about what makes people work together. There’s plenty of good stuff in the interview, but one bit that really sticks in my mind is this excerpt:

Andrew: Do you think it’s possible to have a great team that doesn’t have a great leader? That has more of a collective leadership?

Tim: Yes, it is possible. But here’s the thing. Take Apache, because I think Apache is a great example of that. Tim Berners-Lee laid down the blueprint. He said, “I’ve created this idea for this hypertext server, this hypertext client.” And the genius of Apache was in embracing the constraints. I still remember back in the mid-’90s, this moment where Netscape had added this, Microsoft had added that, and everyone was saying, “Apache seems to be standing still. They aren’t adding all these features. They aren’t keeping up!” And the guys at Apache said, “Yup. What we do is a hypertext server, and we have this nice extension mechanism where people who want to do something else can add it on.”

And that goes back to that architecture of participation. They didn’t build this big, conglomerate, complex application. They kept to a pure vision. The vision did actually come from a visionary leader; it just wasn’t part of Apache. Apache came from a group of people who were abandoned by the NCSA server team when they all went to found Netscape. And there were a bunch of customers, so they said, “We have to maintain this, and keep it going.” What was wonderful about that kind of team was that they accepted the constraints that were laid down by the design of the system. They didn’t try to show off their ego or their creativity.

I think a lot of the work done by the IETF (the Internet Engineering Task Force) in the early years did the same thing. There were some wonderful principles laid down, and people really honored them. If you read some of John Postel’s stuff in the TCP RFC about the robustness principle, it sounds like something out of the Bible, for Christ’s sake! “Be conservative in what you do; be liberal in what you accept from others.” Literally, that’s what it says.

The point is that if you have the system architected right, you have a better chance of success for teams. You don’t want teams that are dependent on a single vision or leader, because if you loseWeight Exercise your leader, the whole team goes “pop.”

Something that came up over and over again throughout our many interviews and stories is the connection between teamwork and architecture.  I think Tim hit on exactly the right example with Apache, but there are a lot of other examples throughout the book. Peter Glück had some really interesting things about how the architecture restrictions of NASA projects affected the teams (and especially the practices they used). And Auke Jilderda talked about the “use-use-reuse” model for designing reusable code, and how it impacts teams. I have to be honest: before working on Beautiful Teams, I definitely didn’t make such a close connection between how great (or lousy) teamwork affects architecture.

You can read the entire interview — which, incidentally, is one of my favorites in the book! — on O’Reilly FYI.

Beautiful Teams — on its way!

~ Andrew Stellman ~ Leave a comment

Beautiful Teams - on its way

Beautiful Teams is finally on its way to the printer!

For those of you who have been wondering why our blog posts slowed to a trickle over the last six months, now you know. Jenny and I have been working pretty steadily on Beautiful Teams, and we’re both really happy with how it came out.

Here’s a — well, it’s not really a sneak preview. It’s more like the promo copy we came up with for the back cover:

What’s it like to work on a great software development team facing an impossible problem? How do you build an effective team? Can a group of people who don’t get along still build good software? How does a team leader keep everyone on track when the stakes are high and the schedule is tight?

Beautiful Teams takes you behind the scenes with some of the most interesting teams in software engineering history. You’ll learn from veteran team leaders’ successes and failures, told through a series of engaging personal stories — and interviews — by leading programmers, architects, project managers, and thought leaders.

Looking back over the project, I’m pretty amazed at how much I learned about how teams work — from an incredible group of people, many of whom I’ve admired and looked up to for most of my career. Here are just a few:

  • Scott Berkun wrote a great essay called “Why Ugly Teams Win” — and he did an incredibly insightful interview with Steve McConnell where they talked about the kinds of practices that make teams work
  • Barry Boehm — and his longtime colleague, Maria Penedo — wrote a fascinating story about one of the first software process improvement projects ever
  • Grady Booch talked to us about how he creates a better team culture
  • Karl Wiegers, whose books gave me my first grounding in software requirements enginering, wrote a wonderful story about one of his early experiences with using use cases on a project
  • Cory Doctorow — and, mind you, I think I’ve actually got a paper copy of Boing Boing lying around somewhere! — contributed a story about a team of IP activists
  • Scott Ambler talked to us about the kinds of obstacles teams face, and how he works to get past them

And that’s just the beginning.We have over thirty contributions from people all around the software industry (and a few very insightful ones from people who aren’t in our industry at all!).

Now that I’ve got a little time to post again, I’m sure I’ll be telling you more about the lessons I learned, not just from actually writing and editing the book, but from the wealth of knowledge and experience all of our contributors shared with us. I’ve already started applying that newfound knowledge to my own teams and projects.

Oh, one more thing — my favorite part of the project! Not a single one of our contributors asked to be paid. Instead, they donated their time and considerable expertise to this project. Instead, we’re contributing royalties from the book to PlayPumps International, a truly wonderful charity that digs wells and installs pumps to deliver clean drinking water to rural schools and villages in sub-Saharan Africa.

Happy Kids on a PlayPump Roundabout
Happy Kids on a PlayPump Roundabout

One reason I love PlayPumps is that it’s more than a charity — in a way, it’s a major civil engineering organization in its own right. And PlayPumps does what they do in a unique way: by driving the pumps with merry-go-rounds or roundabouts, which the children in the village play on. Not only does this give them clean water, it also frees up women, who in many villages have to literally spend
their entire day fetching water, often from polluted sources. We had the privilege of interviewing Trevor Field, the founder of PlayPumps, not just because he does great work, but because he does it through great innovation, engineering, and teamwork. That interview is one of my favorite chapters in the book.

Okay, so I hope I was able to write this post without turning it into too much of a marketing piece. Stay tuned, and with a little luck you’ll see much more frequent updates now that the book’s out the door.