The Art of Project Management

Following are (fair use) excerpts from the book by Scott Berkun, former Microsoft project
manager.

I invested so much time in these lists because I knew that having clear priorities was the
backbone of progress. Making things happen is dependent on having a clear sense of which
things are more important than others and applying that sense to every single interaction
that takes place on the team. These priorities have to be reflected in every email you
send, question you ask, and meeting you hold. Every programmer and tester should invest
energy in the things that will most likely bring about success. Someone has to be
dedicated to both figuring out what those things are and driving the team to deliver on
them.

What slows progress and wastes the most time on projects is confusion about what the goals
are or which things should come before which other things. Many miscommunications and
missteps happen because person A assumed one priority (make it faster), and person B
assumed another (make it more stable). This is true for programmers, testers, marketers,
and entire teams of people. If these conflicts can be avoided, more time can be spent
actually progressing toward the project goals.
.....
If you do use the three most common ordered lists, make sure that they always map to each
other. Every engineering work item should map to a feature, and every feature should map
to a goal. If a new work item is added, it must be matched against features and goals.
This is a forcing function to prevent random features. If a VP or programmer wants to slip
something extra in, she should be forced to justify it against what the project is trying
to achieve: "That's a great feature, boss, but which goal will it help us satisfy? Either
we should adjust the goals and deal with the consequences, or we shouldn't be investing
energy here." If you teach the team that it's a rule to keep these three levels of
decision making in sync, you will focus the team and prevent them from wasting time.
.....
Have you ever been in a tough argument that you thought would never end? Perhaps half the
engineers felt strongly for A, and the other half felt strongly for B. But then the smart
team leader walks in, asks some questions, divides the discussion in a new way, and
quickly gets everyone to agree. It's happened to me many times. When I was younger, I
chalked this up to brilliance: somehow that manager or lead programmer was just smarter
than the rest of the people in the room, and saw things that we didn't. But as I paid more
attention, and on occasion even asked them afterward how they did it, I realized it was
about having rock-solid priorities. They had an ordered list in their heads and were able
to get other people to frame the discussion around it. Good priorities are power. They
eliminate secondary variables from the discussion, making it possible to focus and resolve
issues.

http://msdn2.microsoft.com/en-us/library/aa480154.aspx
http://www.scottberkun.com/the-book-the-art-of-project-management/

Excerpts from the author's blog:

*** Driven development (ADD) - Any team where the biggest jerk makes all the big
decisions is *** driven development. All wisdom, logic or process goes out the window
when Mr. *** is in the room, doing whatever idiotic, selfish thing he thinks is best.
There may rules and processes, but Mr. A breaks them and people follow anyway.

Cover Your Ass Engineering (CYAE) - The driving force behind most individual efforts is to
make sure than when the *** hits the fan, they are not to blame.

Development By Denial (DBD) - Everybody pretends there is a method for what?s being done,
and that things are going ok, when in reality, things are a mess and the process is on the
floor. The worse things get, the more people depend on their denial of what?s really
happening, or their isolation in their own small part of the project, to survive.

Get Me Promoted Methodology (GMPM) - People write code and design things to increase their
visibility, satisfy their boss?s whims, and accelerate their path to a raise or the corner
office no matter how far outside of stated goals their efforts go. This includes allowing
disasters to happen so people can be heroes, writing hacks that look great in the short
term but crumble after the individual has moved on, and focusing more on the surface of
work than its value.

http://www.scottberkun.com/blog/2007/***-driven-development/
.

Quantcast