Inkwell: Authors and Artists

    
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".
  

    
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.  
  

    
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.)
  

    
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?
  

    
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 :)
  

    

 (Reading this on the Web and not a member of The Well? You can still
 participate: send e-mail to inkwell-hosts@well.com and we can post
 for you.)
  

    
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?
  

    
(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 
)
  

    
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.
  

    
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...
  

    
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.
  

    
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?
  

    
ping
  

    
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.)
  

    
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.
  

    
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.
  

    
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.
  

    
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?
  

    
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 :)
  

    
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.
  

    
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 :-)
  

    
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?
  

    
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.
  

    
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.
  

    
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).