Re: The Art of Project Management

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

In article <4f9um3dbmdd0fn08hmma3s8l63p9as4f7b@xxxxxxx>,
Robert <no@xxxxxx> wrote:
On Mon, 24 Dec 2007 00:21:21 +0000 (UTC), docdwarf@xxxxxxxxx () wrote:

In article <n3ptm3dslcg5oubru6oc61t1ktbsets438@xxxxxxx>,
Robert <no@xxxxxx> 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.'

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.

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 not big
organizations.

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.

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

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,

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.

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

Only in organizations that fight it, or haven't figured out how to do it efficienetly. The
right way is to turn the paperwork over to process specialists or low paid interns. 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 good will be
accomplished. They'll forever be solving yesterday's problems rather than tomorrow'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 generators 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 explicitly
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 done 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 occurred 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 involved 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 doing. It was
surreal. He was befuddled and I kept wondering why the process was wasting both of our
time.
.

Quantcast