Ari Davidow (ari) Sun 8 May 05 10:43
Something that I really like about your book, Scott, is that it goes deeply into enough processes, that it puts project management principles in the hands of people who are not necessarily doing things that along enough or involved enough to worry about formal processes. At my current place of work, I was very relieved early on to realize that people really meant it when they insisted on process, but what they meant was "whatever fits the scope and resources of the project", not "fill out these forms and hold those meetings".
Scott Berkun (scottberkun) Sun 8 May 05 14:41
J Matisse: On itterative & design process: If you haven't already, definitely check out the book design methods by Chris Jones (http://www.amazon.com/exec/obidos/tg/detail/-/0471284963). While it is mostly about architecture and product design, the first time I saw this book it blew my mind - I'd never seen so many different models for the designing of things presented in one book before. Turns out there's a whole field, Design research & design methods, focused on this kind of thing.
Scott Berkun (scottberkun) Sun 8 May 05 14:48
Ari: Shhh - don't say the P word. Some people get very upset and angry when they hear the P word :) I guess the word process usually means system of order and control, and not a smart or convenient way to get things done. Somehow we all learn to believe that processes restrict us more than they help us - when it's not process, as an abstract idea that's good or bad, it's really how well the process has been designed for the kind of work being done. But I thought it best to avoid all the process talk, and just focus on kinds of work challenges, and how to approach them. I don't think I use the P word until late part 3 of the book (Although I do use the M word, methedology, heretofor refered to as m******logy as not to offend anyone, a few times in Chapter 2. There was just no way around it.)
David Adam Edelstein (davadam) Mon 9 May 05 08:04
It's always seemed to me like one of the flaws of most Systems of order and control (at least the ones I've seen in use) is that they rarely leave space for the creative chaos that seems to be essential for any really new work to be done. If you know exactly what you're going to do, then the Process will help you figure out how to march towards that, but that if your success depends on coming up with Big New Ideas, then the processes are helpless. From my word choice you can probably tell that as a designer I don't find this particularly useful -- "march towards that" etc. So I was pleasantly surprised to see your chapter 5, "Where ideas come from" -- and especially happy to see you talk about the discipline of improv, which is what the design process has always seemed like to me when it works well. Do you think people who are looking for another System will understand why that chapter is part of this book?
Scott Berkun (scottberkun) Mon 9 May 05 08:49
I agree David - i think many of the books on process and systems read like they were written by someone that never worked on a real industry product of any kind. Or if they did, they had a very strange idea of how it should be done. I always wonder, when reading those kinds of books, what did everyone else that worked on these projects with this guy think of him? Were they all driven insane? Did they all quit? Who knows. I think people looking for another system will be relieved - finally some coverage on this fuzzy, tricky, often frustrating experience of trying to come up with new ideas for things. I think for managers it will be a relief to understand creativity better - and be less afraid of it. As far as why it's a part of the book - I can't imagine anything more important to the making of things than ideas. Ideas for features, ideas for how to get work done, ideas for how to solve crisis situations... everything can be seen as a kind of idea. So any manager or leader who doesn't understand where ideas come from, or how to manage them, seems at a pretty big disadvantage to those that do. I have trouble imagining Systems seekers stumbling over those chapters - I think they'll love them. But I'm pretty biased about the whole thing :)
virtual community or butter? (bumbaugh) Mon 9 May 05 14:27
(Reading this on the Web and not a member of The Well? You can still participate: send e-mail to firstname.lastname@example.org and we can post for you.)
man with no pseudonym (cchoffme) Mon 9 May 05 17:03
Scott, were there any projects which you managed which were particularly creative? Which of the techniques discussed in your book (or not discussed) were most useful for this? I've seen project managers come right out and say "We are going to be creative now", while others have tried to hide that fact from the team and bring it out from within. Which is better, or do they both have a time/place?
J Matisse Enzer (matisse) Mon 9 May 05 18:20
(Just saw this in an ad for a Director of Engineering job: -Philosophy of iteration and continuous improvement over ivory-tower or complex-architecture projects )
Scott Berkun (scottberkun) Tue 10 May 05 16:31
I think all projects have their fun and dull spots - All creative projects have their tedious repitive tasks. Whenever things were dull, first bet was to find out who on the team thought the task was interesting. I'd rather have someone interested in the thing work on it than someone who found it dull. If I could delegate, or involve them, I would. If there was no one around that would touch the task, or the project, with a ten foot pole, then it's all about prioritization. How can I be sure that the time I spend on this thing is worth it? Am I doing the right things first? Getting others to do the right things first? Chapter 13 is all about this - prioritization - and it's the way to slice through things people (self included) don't want to do. Put it in an order, get buy in, and then just go attack it relentlessly until you hit stuff you find less dull.
Scott Berkun (scottberkun) Tue 10 May 05 16:32
Mattisse: wow - quite rare to see the world philosophy appear in an engineering job advert :) It sounds like their last director of engineering had some habits the job description author wants to avoid next time around...
J Matisse Enzer (matisse) Tue 10 May 05 16:56
Yeah, or they are a startup and are all under 30 :-) They mention java and python in the same sentence :-) My guess is they are XP people.
Mitsuharu Hadeishi (mitsu) Tue 10 May 05 17:24
Hello, Scott. Matisse and others pointed out this discussion to me. Quite interesting so far. I'd like to ask you if you can talk about team architecture and cost effectiveness of project management. I realize that all of us here understand the importance of good project management, but I want to compare trying to run a project or set of projects without a project manager versus having a full-time project manager. Naturally, with some very small projects they can be accomplished with, say, a lone programmer --- but at what point do you think it becomes cost effective to have a more formal project management process? And, on a company-wide level, where do you see project management fitting in interms of organizing the work over multiple projects?
J Matisse Enzer (matisse) Wed 11 May 05 09:19
Scott Berkun (scottberkun) Thu 12 May 05 07:23
I don't think there's a strict rule for when you need a project manager and when you don't. It depends on what engineers and programmers are willing to do on their own, for their own areas, towards project management. Generally speaking if the lead programmers see their value as helping manage the project, making decisions, co-ordinating with marketing and design, and tracking the project, one could argue they're in the best possible position to do it. But when project management tasks get dropped in favor of fixing bugs, or helping other developers deal with technical issues, that's usually a good sign that a deidcated project manager is needed. Typically the larger the team, the bigger the need for a dedicated project manager, since cross team co-ordination and communication will be more difficult, and odds of indivudal programmers and programmers being able to manage it all, while doing all their engineering work, are slim. And the same is true for process - ad-hoc, organic, "figure it out as we go" can be fine if individuals are happy working that way, goals are being met, and the quality levels are high. But as teams grow beyond 4 or 5 person teams, it gets harder to live up to that - and that's where adding a little more structure begins to make sense. How much stucture? As little as needed to make the team effective enough to reach it's goals. (fyi Chapter 10, How not to annoy people, has a big section on process, and figuring out when you need it, how much to have, and how to know if it's working.)
Scott Berkun (scottberkun) Thu 12 May 05 07:30
I'm actually on the road right now, talking about the book, and many of the questions that come up have been about process and structure. One of the answers I gave yesterday was that process is not a 4 letter word - it's not evil. People fear project management-ish stuff because it's often done in a away that takes control away from programmers and individuals - which really isn't the goal. The goal is to make the team more effective - good processes start by asking the team, literaly going door to door, and saying "what's not working well? Where are you wasting your time?" and then asking "What can we change about how we work together so you are more effective?". That's where specifications, or requirements, or schedules, or all of the other things generally known as project managagement equipment come in to play - to serve the solving of those problems... and if you come at it this way, the team should interested and supportive of these introductions because they're being done, at least in large part, to serve them. To make them more effective.
Scott Berkun (scottberkun) Thu 12 May 05 07:52
cchoffme: Just noticed there was a question of yours back there that I didn't quite answer. For projects that are more creative in nature, everyone needs to understand that the rate of progress and the way progress happens, will be less predictable than if we were doing boring, same-old, done it 50 times before, widget type X building. More creative work has more risks, and demnands more flexibility from everyone involved. The book talks about how to seek out ideas, and how to manage bringing them together into work (Chps 5 & 6) - and the tactics listed there are all about setting expectations. Once you have an idea of the kinds of problems you need to solve, and you've identified what it is your creativity needs to be directed at, that's when you begin the process of explorng ideas. You explore them, play with them, develop them, grow them - But you put some boundries on it - you say that after 3 or 5 weeks, or some unit of time that fits the schedule, you'll take the ideas you've found and start working the other way. Reducing them, eliminating ones that haven't panned out yet, and take 3 to 5 weeks to get the set of ideas down to one single design for what will be done. So if I'm working on a highly creative/innovative project, I want to make sure everyone understands that we need a structure, lightweight and flexible perhaps, but a structure none the less, for how we're going to bring all the ideas together. And then I want to make sure as we're going along, everyone knows where we are in that process - how much more time is there to find new ideas? When should we start turning the corner and start eliminating, narrowing, refining them? Sometimes this sort of thing implodes, because if it's not done carefully, everyone feels restricted and bound up, and has a hard time "being creative". But if it's done carefully, without the stereotypical fanatisicm project managers are often seen as having, it will help individuals and the team develop ideas and bring them together.
Mitsuharu Hadeishi (mitsu) Thu 12 May 05 12:20
Thanks for the thoughts, Scott. I am a developer, myself, but I personally much prefer working on projects that have a separate project manager. On anything but the most trivial projects involving just one or two coders and perhaps a graphic designer and a supporting HTML coder or scripter, I've found that my duties simply overseeing the programming, architecture, maintenance, etc., are far too time-consuming to do a decent job overseeing project management issues. What's more, while I have a passing understanding of good QA, documentation, and scheduling practices, it's simply not my area of primary expertise. I don't feel I have the authority to say "we should do QA this way" and be firm with clients or managers; I'd rather let the PM take the heat for that... :) Clients and managers often don't want to do, for example, a full QA process, and yet they also demand high quality results --- the two are not compatible desires, of course.
J Matisse Enzer (matisse) Thu 12 May 05 14:14
I want to re-raise the issue of eXtreme Programming - because this approach devolves more of the project process onto the developers, I am thinking that it may bring with it a real change in the day-to-day reality of being a Project Manager. I wonder what Scott and others think of that?
Scott Berkun (scottberkun) Thu 12 May 05 17:01
Mitsuharu: Having been a project manager, I'll admit I tend towards thinking more teams need them than don't - but it depends a great deal on the particular team, the kind of work, and of course, the skill set the particular project manager has or doesn't have. I've seen lots of people placed into the role of project manager that, for various reasons, become simply project trackers. The keep track, they record things, but they respond to what's happening, instead of actively leading what's happening. So one of the big questions about whether to have a dedicated person or not is how much authority or influence they'll be granted on what kinds of decisions. But I like your point: it does take someone that has a combination of skills, and a good perspective on both the individual tasks (QA/engineering/documentation) and how they need to come together to be effective in the PM role. And thick skins tend to be an additional trait that contributes to PM longevity :)
Scott Berkun (scottberkun) Thu 12 May 05 17:14
Matisse: I don't know that XP really places project management on the programmers. There is still a group of people choosing which stories to do when (the planning game) - in many ways this is a big part of deciding what the project is. Also there is still the roll of a team leader that helps settle disputes or disagrements, deals with managing the staff, and takes care of what happens when the process (XP or not) isn't working. So I think I disagree with you: Even if there is no dedicated project manager, and the team is using XP style organization, the tasks that are done in keeping the project together are very much the same. Or more spefically, there will still tend to be one developer, perhaps a lead developer, or a manager, that is the person primarily responsible for project management type tasks. I don't have Extreme programming explained in front of me, but here's some questions that might help sort this out: 1. What happens when a pair of programmers disagrees on what should be done? Or agree on what should be done, but produce poor results? Who's responsible for helping to resolve the issue? 2. Or more specifically, what happens when the overall quality of work drops below what the stories required? Who takes responsibility for recognizing this and responding to it? What if there are disagreements between the story writers and the programmers on what an acceptable level of quality is? 3. Who's responsibility is it to watch and support overall team morale? Performace? If the velocity is poor, and gets worse after each itteration, who should do something about it? And what would they do? 4. Who's job is it to makes sure the story board (or whatever the visual representation of current work and future work is called) is being updated, and used effectively? 5. Who leads the introduction of new development practices? Who evaluates team performance? Individual performance? 6. Who will represent the project to organization leaders? To other projects in the same organization? Who will be responsible for keeping co-ordination and communication healty between project team A and project team B? So while I agree XP distributes some project management tasks better, or at least provides a more organic process for them, I think there will always be many aspects of keeping the project healthy and on track that falls on some type of dedicated leader or manager. Their job title might not have the word project, or manager in it, but the kinds of things they'll be doing will be project maangement type tasks.
J Matisse Enzer (matisse) Thu 12 May 05 17:21
That's a pretty convincing argument, and I want to take the 6 things you posted and see how they feel as a basic list of what a PM does. Kind of a thought experiment. I would note that I wasn't postulating that XP does away with the PM, just that it might change the day-to-day reality of being a PM. Still, your 6 points seem very good, and I suspect that after thinking about them I'll come round and agree with you :-)
man with no pseudonym (cchoffme) Thu 12 May 05 19:53
Scott, Do you think the basic fundamentals of Project Management are going to change over the next 5 or 10 years? If so, what trends to do you predict?
Ari Davidow (ari) Fri 13 May 05 06:20
I just had an interesting conversation with my boss that illustrates, I think, some of the differences between what a Project Manager brings to a process which is different from programming. One of the biggest things the PM does is active listening and facilitating focus. I think it manifests in a lot of ways. I have had some very interesting conversations with one of the developers here where I would give him questions to pass on to the vendor whose software he is implementing. He would pass along some of the questions, and tell me the answers he already knows for others. I would then talk with him about how I was trying to get a sense of how the vendor sees the issue, and to start a dialogue to get the vendor to understand our perspective - it wasn't a "can you do this" question, it was a "if you can't do this, is it because you approach the problem differently. if so, how were you seeing the issue? If not, let's talk about why this is an issue for us and see if we can convince you to consider addressing this in a future release" question. Does that resonate at all? I'm not saying that not all developers see things quite so proactively narrowly, and certainly not all PM roles are quite so open-ended, but a PM is there to act, in many ways, as the project nanny/administrative secretary/always seeing the projet as a whole person. Even with one business user and one developer, it can be useful to have those cycles in place.
Scott Berkun (scottberkun) Fri 13 May 05 08:28
Matisse: Well, to be fair, some of those 6 things are just human management issues.. many of which wouldn't strictly be called "project management". But they're all in the neighborhood of things that are very difficult to distribute across a team.. and the larger the team the harder I think it is for the types of tasks I listed not to be assigned to specific, leader type roles.
Scott Berkun (scottberkun) Fri 13 May 05 08:45
cchoffme: Good question - never thought about that before. My first thought is to look back over the last 5, 10, 100 years and think about what progress or change in project management means. It's really a hard thing to talk about - each industry tends to shift in it's own way, and it seems every organization is different: while some teams and some organizations are progressing, others are, shall we say, regressing :) But that's a dodge of your question, so here's a less wimpy answer: I don't think the fudnamentals change much - ever. I feel that you have a bunch of people, you have something you're trying to achieve, or a business to run, and the challenges of organizing, leading, driving the work people do as part of business never change. You always have a project scope, a level of quality you want to have, and a pile of resources to use to fullfil the scope and quality. I want to say that the tough parts of running the project that was the Egyptian pyramids, that was Mozilla Firefox, that was Grand Theft Auto, or that was Adobe Photoshop, are all fundamentally the same. I bet leaders on those projects asked themselves the same kinds of questions every day: How do we know we're doing the right thing? Are we on track? Will this be sucessful? How can I make people more effective? Are we building this in the right way? etc. Sure there are differences - I bet every hacker or open source developer reading here cringed at the Pyramid reference - I'm not suggesting workers she be treated as slaves or the Borg is a model to aspire to - those are specific answers to the questions - but the questions, the fundamentals, the core challenges, are always the same. And here's an even less wimpy answer: 5 or 10 years from now most projects in the software industry will be managed in much the same way they are now. I think the sucess of XP and agile will have an influence - it will make organic processes more popular generally in management - say moving from 5% of leaders who have this kind of thinking in their aresenal of ways to solve problems to 20%. But it will still be a distant minority. (Actually, I'd love to see some kind of adoption statistics on how popular XP actually is. The books and the groups are very popular, but it's not clear at all how this reflects what people are actually doing, in what industries, and at what scale).
Members: Enter the conference to participate