Andrew Stellman: Why Projects Fail

By Caitrin McCullough

Here's the latest from Andrew Stellman, coauthor of Head First PMP and Head First C#.

Jenny and I have been doing a really neat talk lately called "Why Projects Fail". (You can download a PDF of the slides from this post our blog, if you're interested.) Near the beginning of the presentation, we have a slide that says this:

Software projects are a lot like cheesy horror movies. After you've seen a few of them, you know that the first guy to leave the group is going to get an axe in his head. Projects are the same way. People keep making the same mistakes over and over, and it keeps getting their projects killed.

Project failure is a really interesting topic. When we were working on our first book, Applied Software Project Management, Jenny and I spent a lot of time talking to lots of different people who were on projects that didn't go so well, and we read a lot about the kinds of problems that projects fall into. And what we found was that a lot of projects fail in eerily similar ways.

This was actually somewhat surprising to us. We've both spent our careers building software, and one thing that seems really obvious is that software projects are really different from each other. Every time you start a new project, you're building a new product that's unique—that particular code has never been built before, and your team is often solving problems that have never been solved before.

But just because software projects themselves are unique, that doesn't mean that the problems that teams face building the software are unique. In fact, the opposite is true—teams face the same problems over and over again. And that's what we decided to do our talk about: the kinds of problems teams face, and how you can avoid them.

So we started giving the talk. The first place we did it was at a meeting of the International Association of Software Architects (IASA). It was going to be a crowd of pretty senior people -- software architects, designers, and pretty experienced programmers, people who really understood code. It was a bit of a stretch for us at the time, because most of what we'd written about in the past was project management. (We hadn't finished Head First C# yet.) We weren't really sure how the talk would go. The meeting was in the evening, and most people were there after work. We figured we'd run through the slides in maybe 35 or 40 minutes, take a question or two, and then go home.

When we got there, there were about 80 people. We got started talking. Jenny and I have an interesting way of doing talks—we're pretty informal, we interrupt each other, and we encourage people to interrupt us, too. Usually, people are shy about it. But something about that crowd really clicked. As we started talking about the way projects fall apart, heads started nodding. People started asking questions, interrupting us with stories, and really getting involved. We ended up staying for over two hours... and almost nobody left!

But what was even better is what happened about six months later, at a joint NYC SPIN and PMINYC meeting. It was pretty big—I think there were almost 200 people in the room. And the crowd was really different from the IASA folks. This was a room of project managers, process engineers, six sigma guys... people who thought about how software teams work, rather than the specifics of how software is designed.

You know what? They loved it! We got a lot of great questions, and the room really got involved. And that's when it struck us that we'd found common ground between groups of people who typically have trouble seeing eye to eye. Project managers and programmers really can find common ground, because they all want their projects to get done. And the idea that projects fail—which is usually a very uncomfortable idea to a lot of people—can actually bring us all together, because everyone loves talking about war stories. People who have been part of many software projects recognize that failure, because they've lived through it. And it's been really need to be able to connect to so many different kinds of people on exactly those terms.

Luckily, there are all sorts of great ways to keep your projects from failing. We've spent a lot of time writing and speaking about those ways. That's one reason I've been so happy to see more and more programmers interested in things like Agile—they're starting to take a step back and think about ways to build better software.

Andrew Stellman: Why Projects Fail

Comments

Post a comment: