The folks at the PMI Mass Bay chapter contacted me and Jenny a while back (using our convenient contact page) and invited us to give a talk at a chapter meeting, which we did last Thursday. We had a great time, and met some really interesting people. They’ve got one of the biggest PMI chapters in the country, with over 2,000 members. We had a full house, and they asked a bunch of great questions.
Here’s a PDF of the slides from the talk. The fourth slide is this video of the 1940 Tacoma Narrows Bridge disaster. And to anyone who attended, we’re always happy to answer questions — feel free to get in touch with us if you want to follow up on anything we spoke about.
Jenny and I had a great time doing our “Why Projects Fail” talk at a joint meeting between the International Association of Software Architects and NYC Java SIG (a couple of announcements) at the Microsoft office in midtown Manhattan last night. (Fun trivia fact: my first job out of college was in the same building, working as a programmer at EMI-Capitol Records.) It was an after-work session, so we’d only expected to spend half an hour or forty-five minutes, but we got so many great questions from people that we kept going until the folks at Microsoft had to close down the meeting room.
We promised to upload the slides and post a couple of links, so here they are. Here’s the PowerPoint presentation [PPT] and a PDF version [PDF].You guys asked great questions — some of the best we’ve ever gotten at one of our talks. Here are a few of the answers that we promised:
- A few of you had questions about estimation, specifically the Wideband Delphi process that we’ve had a lot of success with. You can read about it in Chapter 3 of our first book, Applied Software Project Management— here’s a link to a PDF of the chapter [PDF]. We give a pretty detailed description of exactly how to hold a Wideband Delphi meeting, and how you can use it on your own projects to improve how they’re estimated.
- One person brought up a really good point about integration, and how that’s an important failure point that gets neglected, and we mentioned that we’d post a link to an article we wrote for Dr. Dobb’s Journal on integration testing called “Better, Stronger, Faster Integration Testing: Giving developers a personal stake in software quality.”
- I think a lot of the questions near the end of the talk about open source projects were answered in our ONLamp.com article called “What Corporate Projects Should Learn from Open Source”. Also, here’s a link to the “What Makes Open Source Projects Work” presentation I gave last January at the SD Best Practices India 2007 conference.
- No, we don’t have an official release date for “Head First C#” yet, but we’re definitely making good progress on it. Keep watching this blog — as soon as O’Reilly has an official release date for it, we’ll post about it. And yes, it is really fun to write a Head First book.
- After the talk, a few people asked about our availability to come in and do training. Our consulting schedule is a little tight because of our pretty aggressive writing schedule for O’Reilly, but we do have some availability. You can use our “Contact Us” page to get in touch with us about consulting and speaking — serious inquiries only, please.
We’re always happy to answer questions about anything we talk or write about. Feel free to get in touch with us any time!
Ever spend time working up an accurate estimate with your team, and find that it gets rejected because it doesn’t match a magic number in somebody’s head? You did your homework; talked to the people who’ve done this kind of work before, compared your estimate to past projects, and made sure that your estimates are coming from the people who will actually do the work. But, your boss thinks the project should be done a few months earlier. He doesn’t doubt your work, the estimate just doesn’t feel right.
Estimates have a tendency to be more accurate when they’re based on experience. Having actual data on your past projects is so important when you sit down to figure out how long it’s going to take you to do a new one. The best estimates come from people who really understand the work that’s going to get done. And practices for estimation that stay grounded in project experience are less likely to be wrong.
That’s why your project will probably be really late if you just cave in and start shaving off time arbitrarily. It might not be easy, but you need to explain the reasoning behind the estimates your team has come up with and set your boss’s expectations realistically. Too many projects are in a bad position before they ever really get started because a project manager doesn’t correct this kind of misunderstanding.
It’s one of the toughest parts of the job because your boss doesn’t want to know all the details. He just wants you to get it done faster. And sometimes you can get done faster with more resources or with a different scope of work. But it’s always a mistake to just cut an estimate because it doesn’t match what people expect. You need to turn the conversation around and help everybody get to see what the real choices are. Just saying that project will take less time, never makes it happen that way– no matter how influential the person who wants it done yesterday is.
If you estimate right, you should never go back to your team and tell them to arbitrarily cut those estimates down. Instead, you should work with your boss to understand if there might be some work that can be cut from schedule, or some other ways to accomplish what needs to be done in parallel. If you set up a relationship where you and your boss are both doing everything you can to come up with a reasonable plan together, you stand a much better chance of succeeding.