Inkwell: Authors and Artists

    

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!
  

    
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?
  

    
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. 
  

    
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?
  

    
(note: offsite readers who have questions or comments can send email to
inkwell-hosts@well.com to have them added to this conversation)
  

    
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.
  

    
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?
  

    
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.
  

    
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.
  

    
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?
  

    
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. 
  

    
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. 
  

    
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.
  

    
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.
  

    
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?
  

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

    
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.
  

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

    
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: 
  

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

    
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.
  

    
That is a very interesting question - I bet you are right.
  

    
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. 
  

    
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.
  

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

    
Scott slipped in at 23, and I agree with every sentiment you expressed :-)