Cynthia Dyer-Bennet (cdb) Wed 4 May 05 07:07
Today we're delighted to introduce author Scott Berkun. Scott is a project management and interface design consultant. He worked at Microsoft from 1994-2003, and was on the Internet Explorer 1.0 thru 5.0 project teams, where he led the design and development of many major feature areas. He was also a lead program manager on Microsoft Windows, training manager for Microsoft's engineering excellence group, and a lead program manager for MSN. He's been writing online about project management and design since 1999 at www.uiweb.com and www.scottberkun.com. His first book, "The Art of Project Management," published by O'Reilly, should be available everywhere by the time you read this. David Adam Edelstein leads the conversation with Scott. David has worked at Microsoft for just over 12 years, most of those as a UI designer in the Visual C++, Visual Studio, and MapPoint teams. He's been involved with projects where amazing things happened and projects where it was amazing that anything happened. In his copious free time he's a photographer (www.noise-to-signal.com) and amateur student of culture and society. Welcome to Inkwell, Scott and David!
David Adam Edelstein (davadam) Thu 5 May 05 06:54
Thanks, Cynthia. As you might guess from our bios, Scott and I did know each other when he was at Microsoft, when he was a training manager. It may not always be obvious from the outside, but Microsoft really is filled with smart, passionate people, trying to make the world a better place through software. Scott's one of those people, and I was sorry to see him leave. It's particularly nice, then, to see that he's putting some of what he knows down on paper, and to get a chance to welcome him to this forum for a conversation. So, uh, Welcome, Scott :-) Let's start out with a general question: How did you come to write a book about project management, anyway? Isn't it kind of a dry subject to start your career as an author?
Scott Berkun (scottberkun) Thu 5 May 05 08:08
Thanks Cynthia and David - Very happy to be here. To answer your question "Isn't project management kind of a dry subject to start your career as an author?" Dry? Are you sure? You mean people aren't throwing project management parties anymore? It was all the rage just a few short... ok. There have never been project management parties. I fully admit that. Or if there ever have been, I certainly haven't been invited to any. I guess i think of the words project and management differently than many people, and the textbooks, do. I don't use the term in the chart making, clock watching, bean counting, pencil pushing way. Instead, I think of projects as things groups of people make together. Software, websites, Egyptian pyramids, whatever. And I think of management as answering all the tough questions about how to make things with other people so the results are actually good. And perhaps, as a bonus, doing so in a way that avoids having people want to strangle their co-workers. So I think making good things, and figuring out how to work together with 5,10 or 500 people to to make good things, are super interesting questions. Why do so many projects go oh so wrong? Can schedules ever actually be accurate? How do you make good decisions? What happens when things change before it's finished? Where do good ideas come from and how do you use em'? I think most people interested in engineering, design, technology, or even culture talk about these issues all the time. Or at least they complain about them over drinks after work. They just don't call it project management - but I guess to me, a project manager, that's the best label for wrapping everything together. And that's what this book is. Everyting I think you need to know to manage, or contribute to, the making of good things.
David Adam Edelstein (davadam) Fri 6 May 05 00:12
OK, so maybe it's not as dry as I said. :-) I have a bunch of fundamental questions, but one of the things you mentioned -- the bonus of doing things in a way that keeps co-workers from strangling each other -- caught my interest. Arguably one of the most important jobs of project managers in any field is to speak unpleasant truths in public: "you're not pulling your weight", "we're all going in the wrong direction", "look, I know working hard is a virtue, but bathe once in a while too, OK?" (That last one actually did have to be communicated to someone I worked with several years ago) Do you have any advice for project managers who need to say these kinds of things without alienating their team?
Cynthia Dyer-Bennet (cdb) Fri 6 May 05 13:55
(note: offsite readers who have questions or comments can send email to firstname.lastname@example.org to have them added to this conversation)
J Matisse Enzer (matisse) Fri 6 May 05 14:08
Hi, I'm popping in to say I started read the book this week, at first by skipping around. I'm often a Project Manager myself, and I really like the book - so far i'd say it says a great many true things in an easy to understand way. I hope lots of people who are not Project Managers read it.
man with no pseudonym (cchoffme) Fri 6 May 05 14:41
Scott, as one of those non-project managers (matisse) mentions I have to say that this is an excellent book. I wish they used this as the Project Management text in school! Your voice and experience is very clear, and it makes it a pleasure to read. At the beginning of the book, you talk about the "black books" of failures. Have any of your projects taken this approach? Did anyone really rad and act upon them? How much value do they actually have?
Scott Berkun (scottberkun) Fri 6 May 05 23:41
David: Covering difficult topics happens all the time. I don't think there's a single way to go about it.. there are so many variables that would change my advice on this. Do you have the team's trust? Have you covered difficult conversations with them before (sucessfully?) If no and no, I'd take it slow. I'd start with the people who knew me better and talk to them about the issue 1-on-1. Once I had some experience covering the issue with a few individuals, and improved my handling of it, I'd then bring it to the team at large. I think difficult conversations are much easier if everyone starts off with the same expectations - some of the chapters in the book (3 on figuring out what to do, 4 on vision documents, 10 on communication and relationships) go into detal about how to set expetiations for both what sucess looks like, and also how people are supposed to divide responsibility. With that in place it's much easier for a manager to come back and say "Hey, we're supposed to be going west... but right now my compass says we're going south. What do your compasses say?" and have an open/honest discussion about it. Most of the time, staying away from placing blame and focusing on identifying the issues and working to fix them makes these things easier for everyone.
Scott Berkun (scottberkun) Fri 6 May 05 23:48
J Matise: Glad you're enjoying it so far. Let us know how it goes - and any questions that come to mind as you're moving along. CChoffme: I think people keep their own mental black boxes even if they don't write them down - I mean, that's what experience is, in a way - a raw, unprocessed black box of data that we call on later. The most common way to formalize the process is what's called a postmortem, or project retrospective, where the team sits down at the end and tries to capture what went well, what didn't and what can be learned. These are hard to do well (I've done several of these myself), but when they are, they reward the entire organization. The things they discovered are guaranteed to be useful (and quite interesting) to many other people who work on similiar but different projects. Moreso, it validates the feelings and beliefs people on the team had about what happened, and gives them more solid footing in their own experience to use on the next project. But as you suggest, many postmortems are *not* done well. They can easily become witch-hunts and blame sessions, where the vibe is about protecting reputations and denying the truth, rather than learning, growing and understanding as a team. It takes a skilled person to do these well, which is why some organizations bring in outsiders, like myself, to facilitate the postmortem, and provide an objective point of view.
David Adam Edelstein (davadam) Sat 7 May 05 00:39
I've always preferred "postpartum", myself :-) The trick, of course, is to actually take that information, that hindsight view of the decision made and results of those decisions, into the next project. And the next one after that, which is often where the lessons are dropped. Why do so many projects spend so much time reinventing the project management wheel? It's surely not for lack of available methodologies, as you point out. Do people just have a poor grasp of history? What about those mental black boxes, anyway?
Ari Davidow (ari) Sat 7 May 05 07:24
Hi, just popping in to say that I'm in the middle of the book and really enjoying it so far. During the period when I spent progressively more time as a project manager, I kept looking for a book like this: detailed enough and interesting enough to be read and useful. I am also reading it as someone relatively-recently certified as a PMP, and note that not only is there an absene of PMI jargon, but that the organization doesn't even get a mention in the Index. I'm not sure if that is good or bad, but wonder if you could comment on that.
Scott Berkun (scottberkun) Sat 7 May 05 08:43
The lack of mention of PMI (www.pmi.org) or the PMBOK doesn't imply any sort of philosophical stance. And the lack of *any* reference to PMI is an oversight. If there's a second edition a reference should be added. It was just that during reserach for this book, and in the course of writing it, the PMBOK - project management body of knowledge (one of the primary documents produced by PMI), didn't come up much for me. I suspect that in wanting to write more about the *art* of project management, rather than the science of project management, the topics I wanted to focus on (leadership, decision making, strategy, human issues, stories from experience, etc.) didn't overlap well the resources I'd found from PMI.
Scott Berkun (scottberkun) Sat 7 May 05 08:47
David: On reinventing the wheel: I think reinvention is human nature. We all do it all the time in our dail lives, so it's not surprising to see team leaders and group managers do it. It's tricky to figure out when making changes is going to make a difference, and when making changes is just making changes (e.g. reinventing wheels). Chapter 5 in the book talks a lot about asking the question "What problem are you trying to solve?" and this applies here as well. Making a change to how a team is run has to be done with specific, and visible, goals in mind. Make the team faster, improving decision making, give away more authority.. etc. If everyone knows what problem the team leaders are trying to solve, and are invited to help evaluate how well they change suceeds/fails in doing so, odds of meaningful change happening go up. But if the plans are done in secret, criteria are never defined or publicized, or evaluation of the management changes is done privately, it's *very* easy for lots of stuff to happen without much progress.
David Adam Edelstein (davadam) Sat 7 May 05 09:52
I think planning in secret is a key issue. One group A Friend Of Mine is in just switched from lots of secretive management meetings to a much more open, let's tell the team everything early system, and it's definitely paid off in morale and involvement. The saddest part about the previous process was that the management involved weren't being malicious or deliberately secretive, they just couldn't see past their own noses.
J Matisse Enzer (matisse) Sat 7 May 05 10:40
Read more last night. Still like it :-) Here's a question: Scott, what do you feel are important trends and changes in Project Management, that are in progress right now? Over the coming 2-5 years what do you see being more widely adopted or rejected, for better and worse?
man with no pseudonym (cchoffme) Sat 7 May 05 11:11
On a project I am working on, the Project Office and the Project Manager decided that Extreme Programming must be used with no if's and's or but's.. However, there is only one full-time programmer, and one part time programmer assigned to this project so it really doesn't work out well at all. If management and project managers are making these decisions in "secret", is there any thing that the team members can do to bring these "secrets" to light and become more involved (even though they are kept out of the loop intentionally)?
Scott Berkun (scottberkun) Sat 7 May 05 12:31
As far as trends: The biggest in the last few years is definitely eXtrememe Programming and other agile methods - where the core values are about flexibility, adaption, and collaboration. But I'm not a fan of trends - there's an endless history of popular management trends (TQM, Six sigma, BPI, re-engineering, etc.) and it seems they have little effect on many organizations - following the letter of a system, but not it's spirit, doesn't get you very far. The following of trends puts the focus on a system, on a brand, rather than where it should be: on the manager and the team. Some managers like trends because they can blame the trends when things go wrong. Others like them because it's an easy way to seem progressive or "current". But none of these reasons have anything to do with making teams more effective or projects more sucessful. For this and other reasons I tried very hard to write the book without refering heavily to systems and methods. I think there are core skills, core tactics, that underly all management of anything, and I wrote the book about those things (That's what the chapters are). My hope is that any religous follower of any method can look at my book and find lots of things they agree with, or see implied/suggested, in their own methedology, without puting them on the defensive because I labeled everything "Berkunomics" or "Extreme Berkun" or some other new system that by definition questions existing ones. So i think in many organizations extreme programming has (sadly), or will have, a similiar fate - the systems is adopted and applied simply because they're hot and popular, rather than because they solve a specific problem the organization actually has, and solves it in a way that's likely to work. Then when there are problems, the system is scapegoated, and another one is found. There's a whole chapter in the book (I think it's 12 or 13) called "How not to annoy people", that is largely about processes and defining them without frustrating entire teams of people. I think each team and project is a little different, and the off the shelf application of any process/method isn't the right answer. Managers have work to do in figuring out what's unique about their team, and shaping the way work gets done to fit the needs of the team. The example cchoffme offers fits this well - why extreme programming? why now? If there are only 2 progammers, why can't they pretty much define their own process, as long as the right work gets done on time? What problem will extreme programming solve for this organization, and how will that be evaluated? Without making these things clear to everyone process is inflicted on a team, rather than used to help a team. It's much smarter to say to a team: ok, we need to get X done with Y constraints. Lets work together to figure out how we can achieve management goals (X & Y), in a way that you will be most comfortable/happy/effective with (Z). I think double secret management is a kind of disrespect - it communicates a lack of trust with the team, and minimizes the value individuals can add. Some privacy is needed for leaders to make progress, I grant that, but there should always be points of visibility and feedback where everyone can see the thinking so far, and offer commentary on it. The mature response to CIA type management secrecy is for individuals to do what's called managing up - an individual has to communicate to their own manager what they need in order to be sucessful. If you need a chance to give feedback on management direction before you are expected to follow it, you need to be proactive in asking for it. "Boss, it's very difficult for me to work this way. I promise you I will be more effective if I have some level of participation in major decisions that impact me." Same things for other things you need to be effective (a quiet office, a decent computer, whatever). If you are never granted the things you need to be effective (or at granted an honest discussion about the granting of those things), you should have a very clear idea about how important your effectiveness is to your manager. Alternatively you can go and talk to your peers and see if they feel the same way you do - then you can raise the issue collectively. "80% of the team feels they need X to be sucessful." But the process is similiar.
Dennis Wilen (the-voidmstr) Sat 7 May 05 13:09
Wow. That "managing up" concept highlights a lot of things I've had a hard time putting my finger on. I will now go order the book, although Amazon says it will take two weeks to get here. :-(
J Matisse Enzer (matisse) Sat 7 May 05 13:22
Scott your point about following the letter rather than the spirit is of course true in almost anything, and I'll take your answer to mean that doing so is a trend that has been and will be with us, sadly, as long as we are human. The trend of XP/Agile is of course an exciting one now, and I think any good professional will recognize their own best-practices in it in various ways. Here's a suggestion for the next edition :-) About "Good email" - Always use a good Subject: line!! Good Subject: lines ------------------- Subject: New Benefit Server Cut-Over Plan Subject: Contributions for employees with domestic partners Subject: mod_perl2 + Apache::AuthenNTLM 2.10 + mod_dav_svn Bad Subject: lines ------------------- Subject: PURGATORY Subject: another version Subject:
J Matisse Enzer (matisse) Sat 7 May 05 13:24
Something resonates for me in the book, and that could perhaps be more explicit, is the fractal and iterative nature of process... - At each stage of the process you end up creating smaller processes, smaller teams, smaller goals, etc. - At many steps in the process you may need to go back to an earlier step to revise the design, build a new version of a component, etc. Beware of doing this too little or too much. Those things happen over-and-over, and you bring this up in a variety of ways, which is great because it's something that people do not often realize about the process of making things (which is how I think of this - the process of making things.)
Brian Slesinsky (bslesins) Sat 7 May 05 17:20
Actually, Extreme Programming works well (says this advocate) even for one-person projects. Obviously you can't pair if there's nobody to pair with, but most of the other practices work fine. It's just as valuable to write unit tests, and it provides a structure for the conversation between the programmer and the customer (or project manager). I missed the earlier trends in project management. Were they as popular as Extreme Programming in the day? I was under the impression that earlier methods tended to be more popular with managers than with programmers.
J Matisse Enzer (matisse) Sat 7 May 05 17:44
That is a very interesting question - I bet you are right.
Scott Berkun (scottberkun) Sun 8 May 05 09:36
There are many things about Extreme programming that I like - I didn't mean to suggest otherwise - I just don't think it's immune from the same kind of abuses and misapplications as other methods are. No matter how good any method is, you still need leaders to apply/customize the method properly for the given project and the given team. Dennis: just fyi - managing up isn't my term - it's a term that's been used before. I cover managing up as part of the power and politics chapter (16). J Matisse: On itterative processes - yes exactly! There is a cyclical and back and forth nature to the making of things. I chose not too spend much time on it as a concept because I thought if I covered the individual activities properly (planning, designing, managing,etc.) it would come through on it's own. At least for you this seems to have happened (yay!), but we'll have to see if other people make the same connection. Brian: Yes I agree. I think there are many aspects of Extreme programming that work for projects of any size. What I suggested was that with a small team, there's every reason to let the programmers themselves decide their own processes, which if they choose could be XP-ish in nature. But you're right - most project management methods of the past were focused on management, and XP is more focused on programmers and how they work. As far as popularity - there really needs to be some adoption metrics: someone should put together reseach on methedology use by industry sector or something -it'd be facintating to see those trends change over time. Change in development practices of any kind across industries is a very slow process.
Scott Berkun (scottberkun) Sun 8 May 05 09:41
J Matisse: About the letter and the spirit. I think what I'm going after in the letter vs. the spirit point is this: The goal should be for a manager, leader, or programmer to take pride in saying "We make good software" not "We use Method X". So I cringe a bit when anyone places too much emphasis on any method - the emphasis should be on the results, and the quality of life for people involved in achieving those results.
J Matisse Enzer (matisse) Sun 8 May 05 09:54
(parenthetically, the stuff about the iterative nature of making, I'm rather sensitive to it because of my own experience and thinking - I have an outline for an article/book proposal on "How to Make Things" where the idea of iteration is very central. I'm happy to email to anyone who promises not to rip it off.) Back on topic, I'd like to continue the thread Brian raise, about PM tools for different roles - managers, vs. individual contributors (e.g. programmers) I think that is a really insightful distinction. XP and its ilk represent not only "another PM method" but one that is fundamentally different *because* it is actually in the hands of the workers, of the makers. XP involves a partial decentralization of the power or control of the actual PM workflow - the programmers are more intimately involved in shaping the flow of work. I see all of this as part of an endless process of evolution of our tools for communication and collaboration. Each improvement increases, a little, our ability to exploit the huge potential of cooperation between entities. I wonder what changes we might want to make in eXtreme Programming, and Project Management over the next 5-10 years?
J Matisse Enzer (matisse) Sun 8 May 05 09:55
Scott slipped in at 23, and I agree with every sentiment you expressed :-)
Members: Enter the conference to participate