The Art of Project Management

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

I invested so much time in these lists because I knew that having clear prio
rities was the
backbone of progress. Making things happen is dependent on having a clear se
nse of which
things are more important than others and applying that sense to every singl
e 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 sh
ould 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 miscommunica
tions 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 alway
s map to each
other. Every engineering work item should map to a feature, and every featur
e 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 proj
ect is trying
to achieve: "That's a great feature, boss, but which goal will it help us sa
tisfy? Either
we should adjust the goals and deal with the consequences, or we shouldn't b
e investing
energy here." If you teach the team that it's a rule to keep these three lev
els of
decision making in sync, you will focus the team and prevent them from wasti
ng time.
....
Have you ever been in a tough argument that you thought would never end? Per
haps half the
engineers felt strongly for A, and the other half felt strongly for B. But t
hen the smart
team leader walks in, asks some questions, divides the discussion in a new w
ay, and
quickly gets everyone to agree. It's happened to me many times. When I was y
ounger, I
chalked this up to brilliance: somehow that manager or lead programmer was j
ust 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 real
ized 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 p
ower. They
eliminate secondary variables from the discussion, making it possible to foc
us and resolve
issues.

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

Excerpts from the author's blog:

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

Cover Your Ass Engineering (CYAE) - The driving force behind most individual
 efforts is to
make sure than when the shit 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 pro
cess 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 sur
vive.

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 incl
udes allowing
disasters to happen so people can be heroes, writing hacks that look great i
n 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/200...en-development/

In article <n3ptm3dslcg5oubru6oc61t1ktbsets438@4ax.com>,
Robert  <no@e.mail> wrote:
>Following are (fair use) excerpts from the book by Scott Berkun, former
>Microsoft project manager.

[snip]

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

VP (or other Boss): 'What part of 'I sign your timesheets/write your
performance reviews' do you have difficulty in understanding?  It may not
make sense to you but that's because I have the Big Picture and you don't;
questioning this will be treated as grounds for transfer to the mailroom.'

From
<[url]http://groups.google.com/group/comp.lang.cobol/msg/9b3c2b947a2a9169?dmode=source[
/url]>

--begin quoted text:

Date: 1997/12/29

[snip]

Hmmmm... decades back, when I got my First Job, my sainted Mother, may
she sleep with the angels, gave me the following sage counsel:

'Then it comes to work remember two things:  you can be wrong about
something... and be fired for it; you can be right about something...
and be fired for it.'

--end quoted text

DD

On Mon, 24 Dec 2007 00:21:21 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <n3ptm3dslcg5oubru6oc61t1ktbsets438@4ax.com>,
>Robert  <no@e.mail> wrote: 
>
>[snip]
> 
>
>VP (or other Boss): 'What part of 'I sign your timesheets/write your
>performance reviews' do you have difficulty in understanding?  It may not
>make sense to you but that's because I have the Big Picture and you don't;
>questioning this will be treated as grounds for transfer to the mailroom.'

Management by fear is good for maintaining the status quo; it doesn't work f
or fostering
innovation. The same has been said about Cobol, by some proponents as well a
s critics.

Berkun's prescription is a central feature of formal processes, where the li
sts are called
Detailed Design, High Level Design and Business Requirement. The document th
at relates
them is often called Requirements Tracability Matrix. In order for a VP to a
dd a pet
feature, he or she would have to intimidate three committees and a group of 
auditors.

In article <4f9um3dbmdd0fn08hmma3s8l63p9as4f7b@4ax.com>,
Robert  <no@e.mail> wrote:
>On Mon, 24 Dec 2007 00:21:21 +0000 (UTC), docdwarf@panix.com () wrote:
> 
>
>Management by fear is good for maintaining the status quo; it doesn't
>work for fostering
>innovation.

What fear?  This is Management by Objective; if someone objects then the
objective of a paycheck is not meant.

>The same has been said about Cobol, by some proponents as
>well as critics.

Something was said about paying the piper and calling the tune long before
Babbage's Analytical Engine was dreamt-of, as well.

>
>Berkun's prescription is a central feature of formal processes, where
>the lists are called
>Detailed Design, High Level Design and Business Requirement. The
>document that relates
>them is often called Requirements Tracability Matrix. In order for a VP
>to add a pet
>feature, he or she would have to intimidate three committees and a group
>of auditors.

'(A) central feature of formal process'... Mr Wagner, some people might
say that this is antithetical to progress, with RAD
two-coders-to-a-keyboard programming and JIT implementation of features
that weren't thought of back when someone said 'wouldn't it be nice if we
could...' and other aspects of Modern Design.

Centralised, formal processint... what comes next, requests for User
Sign-Off?

DD

"Robert" <no@e.mail> wrote in message
 news:4f9um3dbmdd0fn08hmma3s8l63p9as4f7b@
4ax.com...
> On Mon, 24 Dec 2007 00:21:21 +0000 (UTC), docdwarf@panix.com () wrote:
> 
>
> Management by fear is good for maintaining the status quo; it doesn't work
> for fostering
> innovation. The same has been said about Cobol, by some proponents as well
> as critics.
>
> Berkun's prescription is a central feature of formal processes, where the
> lists are called
> Detailed Design, High Level Design and Business Requirement. The document
> that relates
> them is often called Requirements Tracability Matrix. In order for a VP to
> add a pet
> feature, he or she would have to intimidate three committees and a group
> of auditors.
>
Not at all.

I have worked in places where a VP simply overrides the process and says:
"That's what I want."

You can have all the checks, balances, lists, correlations, processes, and
accountability you like, it is trumped by ego and power.

(Dealing with this, is covered in a forthcoming book I'm writing... :-))

Pete.
--
"I used to write COBOL...now I can do anything."

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
>
> You can have all the checks, balances, lists, correlations, processes, and
 accountability you like, it is trumped by ego and
> power.


Or stupid/ignorant/etc. and power. The main ingredient is power. :-)
--
Judson McClendon       judmc@sunvaley0.com (remove zero)
Sun Valley Systems     http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

On Mon, 24 Dec 2007 12:56:06 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <4f9um3dbmdd0fn08hmma3s8l63p9as4f7b@4ax.com>,
>Robert  <no@e.mail> wrote: 
>
>What fear?  This is Management by Objective; if someone objects then the
>objective of a paycheck is not meant.

Before 1980, IT shops were managed intuitively like factories, retail stores
 and offices.
You imply they still are. Small and some medium sized shops still are, but n
ot big
organizations.

The informal approach was found to be unreliable because it depended on mana
gerial skills.
It was replaced in the '80s and '90s by formal methodologies such as CMM, IS
O9000, SDLC,
etc. Formal processes wouldn't have been necessary if managers had been comp
etent.

Berkun is 20 years late. He's telling managers what they should have done. N
ow the process
tells them the same things in excrutiating detail.
 
>
>Something was said about paying the piper and calling the tune long before
>Babbage's Analytical Engine was dreamt-of, as well.
> 
>
>'(A) central feature of formal process'... Mr Wagner, some people might
>say that this is antithetical to progress,

The foundations of formal processes are basics that managers should have kno
wn without
being told. There are two main criticisms, both unfounded:

1.  It prevents incremental development, i.e. making changes on the fly base
d on feedback.

That was done on purpose. It prevents feature creep and forces organizations
 to plan
BEFORE cranking code. We all know the undisciplined programmer mode, which w
ants to start
writing code immediately.

2. It is excessively burdensome; it kills productivity by turning programmer
s into paper
pushers.

Only in organizations that fight it, or haven't figured out how to do it eff
icienetly. The
right way is to turn the paperwork over to process specialists or low paid i
nterns. The
benefit is in the controls, not the paperwork.

A valid criticism of formal processes is that they're not scalable to small 
organizations.
In a shop having 1 (you) to 20 developers, the manager needs to apply Berkun
's ideas in an
informal way. If he or she thinks like a programmer, nothing great or even g
ood will be
accomplished. They'll forever be solving yesterday's problems rather than to
morrow's.

>with RAD
>two-coders-to-a-keyboard programming and JIT implementation of features
>that weren't thought of back when someone said 'wouldn't it be nice if we
>could...' and other aspects of Modern Design.

Some blame the proliferation of methodologies on immaturity of the computer 
industry.
Gimme a break. We've been cranking code for more than 50 years.

Some hope for a magical solution from the computer itself. Application gener
ators appeal
to that idea. We learned nothing from the failure of CASE tools in the '70s.
 Generators
keep popping up like weeds. Their supporters are programmer types, who think
 every problem
can be solved with code.

Interpreters are a variation on the code generator theme. Rather than explic
itly
generating code up front, they generate equivalent decision processes on the
 fly at
execution time. It's not apparent they're generating code because they don't
 spit it out,
they just execute it. OO is another attempt to disguise interpretive code as
 real code.

Formal processes don't rule out that mode of design. They say it should be d
one with
prototyping tools during the DESIGN phase rather than the programming phase.

>Centralised, formal processint... what comes next, requests for User
>Sign-Off?

Some see User Sign-Offs as ass covering. No, it corrects abuses that occurre
d during the
undisciplined '70s, when systems were forced on users without any feedback. 
Users need to
be involved in high level planning and final verification (UAT).

Some think the programming act should be so transparent that users are invol
ved there, as
well. I remember sitting with an accountant, an honest to god bean counter, 
and having to
explain line for line what my changes to an assembly language program were d
oing. It was
surreal. He was befuddled and I kept wondering why the process was wasting b
oth of our
time.

In article <re31n3lbpvdvr9vsdr82j1ieavsor2a9ub@4ax.com>,
Robert  <no@e.mail> wrote:
>On Mon, 24 Dec 2007 12:56:06 +0000 (UTC), docdwarf@panix.com () wrote:
> 
>
>Before 1980, IT shops were managed intuitively like factories, retail
>stores and offices. You imply they still are.

Since 1980, IT shops I have worked in still seem to maintain some kind of
link, however tenuous, between 'do what is asked of you' and 'get paid'.

>Small and some medium sized shops still are,
>but not big
>organizations.

Wow... in big organisations there's no link between doing what's asked of
you and getting paid?  Such a Brave New World!

>
>The informal approach was found to be unreliable because it depended on
>managerial skills.
>It was replaced in the '80s and '90s by formal methodologies such as
>CMM, ISO9000, SDLC,
>etc. Formal processes wouldn't have been necessary if managers had been
>competent.

Acronym of the W might have been received a bit differently were that
to have been the case, as well.

[snip]
 

[snip]

>The foundations of formal processes are basics that managers should have
>known without
>being told. There are two main criticisms, both unfounded:
>
>1.  It prevents incremental development, i.e. making changes on the fly
>based on feedback.
>
>That was done on purpose. It prevents feature creep and forces
>organizations to plan
>BEFORE cranking code. We all know the undisciplined programmer mode,
>which wants to start
>writing code immediately.

I barely know what *I* know, Mr Wagner, let alone anyone else... but I
recall seeing a single-panel cartoon of a fellow looking at several
desks'worth of coders captioned 'All right... now all of you get busy
programming while I go off and find what the user wants'.

Mr Wagner, in the few snippets above you've managed to question the
competence and capabilities of Managers - who did not know What They
Should Have Known - and Programmers - who want to code without any prior
planning - and there's a good possibility that in the next few snippets
you'll most likely cast a few aspersions towards the Executives, the
Organisations they head, the Governments under which said Organisations
are chartered and the Forces of Nature which shape the globe on which they
all exist.

It is a difficult and complex world to live in... but hey, if it were easy
then *everyone* would be doing it.

DD

On Tue, 25 Dec 2007 20:09:30 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <re31n3lbpvdvr9vsdr82j1ieavsor2a9ub@4ax.com>,
>Robert  <no@e.mail> wrote: 
>
>Since 1980, IT shops I have worked in still seem to maintain some kind of
>link, however tenuous, between 'do what is asked of you' and 'get paid'.

I've never heard of anyone being denied pay for an hour spent at work.
 
>
>Wow... in big organisations there's no link between doing what's asked of
>you and getting paid?  Such a Brave New World!

In big organizations there is more clarity in communicating what is being as
ked. It used
to be communicated verbally, scribbled on a napkin or written on a whiteboar
d.
 
>
>Acronym of the W might have been received a bit differently were that
>to have been the case, as well.
>
>[snip]
> 
>
>[snip]
> 
>
>I barely know what *I* know, Mr Wagner, let alone anyone else... but I
>recall seeing a single-panel cartoon of a fellow looking at several
>desks'worth of coders captioned 'All right... now all of you get busy
>programming while I go off and find what the user wants'.
>
>Mr Wagner, in the few snippets above you've managed to question the
>competence and capabilities of Managers - who did not know What They
>Should Have Known - and Programmers - who want to code without any prior
>planning -

I didn't impose a formal process. Your charge should be directed at the exec
utives who
did.

>and there's a good possibility that in the next few snippets
>you'll most likely cast a few aspersions towards the Executives, the
>Organisations they head, the Governments under which said Organisations
>are chartered and the Forces of Nature which shape the globe on which they
>all exist.

We already have an excess of commentary on politics and religion.

>It is a difficult and complex world to live in... but hey, if it were easy
>then *everyone* would be doing it.

The world is unnecessarily complex. For example, the fine structure constant
 is set at
7.297352..E-3. Where did that number come from? It should be e**2 E-3 = 7.38
9056...
We can compute e to any precision we want as (1 + 1/n)**n, where n is any la
rge number.
There is no way to compute the fine structure constant.

The increase is only 1.25%. If we increase the gravitational coupling consta
nt by the same
percentage, thereby maintaining the same ratio, formation of carbon and othe
r heavy
elements will not change at all. Better yet, let's change it from 1.752 E-45
 to 1.7725,
the square root of pi.

To whom do I write about cleaning up these obvious design errors?

> Berkun is 20 years late. He's telling managers what they should have done. Now the proces
s
> tells them the same things in excrutiating detail.

For some, sure. For others, namely all the web folk, they haven't made
those mistakes yet (though their ignorance of software history, often
a blessing, sets them up to be personally acquainted with them soon).

If there's anything in my book that's of value to this thread, it's
the essential need of trust for good work to happen. The growth and
protection of trust between any two people working together is really
all that any programmer or manager on a team ever has.  Most of the
process rubbish I see is an attempt to replace the manager's
responsibility for building trust with rules that try to prevent
mistrust from happening - but the side-effects (lack of empowerment,
the fleeing of bright mavericks, committees and their Kafka-esque
meetings, general massacring of passion) are nearly always worse than
the problems the process was intended to solve. And when the process
fails, process-mongers always blame the process and start hunting for
a new one, instead of examining their basic incompetencies as managers
or leaders of people.

Given the choice between A) a team of people that trust each other,
but have no awareness of formal process, vs. B) a team that has
memorized every software process guidebook ever, but have no faith in
each other, and I'll take A every time. Their relationships will allow
them to build whatever process they need and grow. Team B, despite
their individual talents and process knowledge, is doomed.

Sure - I like team C (a team that trusts each other *and* understands
the value of lean, well crafted processes), but they're less fun to
argue about :)

-Scott
www.scottberkun.com