Measuring Value of IT LO15806

John Paul Fullerton (jpf@mail.myriad.net)
Fri, 14 Nov 1997 08:47:14 +0000

Replying to LO15773 --
I'm responding to quotes from that note.

> I'm running a participant observer study of a $.5B project, and
> the project is likely to stumble (both type 2 and 3). I'm asking:
> What else promotes failure that isn't addressed by the discipline
> we are aspiring to? Are people really doing poor engineering? Can
> any group realistically sustain a high level of engineering
> discipline in the face of political and organizational turbulence?
> Are the problems greater than the means being used? Are there
> other ways of managing complex projects that work sometimes but are
> overlooked or supressed?

The most relevant info that I've found from others (as it relates to my
limited experienced) follows. Though my practical mental focus is computer
programming (writing programs for computers), it seems to me that the
ideas and benefit of these ideas has to do with thinking in general,
perhaps purposefully adding or using thinking in work that is possible to
begin without as much thought.

Edward Deming, Videos of his lectures
Deming addressed people who's job is business management. Of them he
said, "how could they know" in cases of managing without measurement
that provides means of knowing. He talked about "operational
definitions". Extending the idea - what is a computer program
function, what is a class, what is defensive programming, what is the
guideline for turning in code (when may I turn in my code :)? Deming
forever (I may exaggerate :) for me has defined the thought that
people go about doing their work with much less understanding about
central concerns than we tend to think. Perhaps (no doubt) that net
surrounds me as well as others. "Well everyone knows why we're in
business!" "Did you ask them?" "No."

Peter Senge, "The Fifth Discipline"
Senge opens up in common parlance (wanted to use that phrase :) the
image of a shared culture that learns from whoever learns first.
Perhaps that simple comment considered in the arena of high-power
software engineering brings light to design practices. How do we keep
an open mind while we're in the process of building? Should we? Senge
said (or I took his book as saying), "go ahead, John Paul, it's OK to
think. Others do it as well."

Fred Brooks, "The Mythical Man-Month"
Brooks writing is pleasant to review. He said that communicating
technical information (and the amount of technical information that
there is to communicate) in a software project makes adding workers
more costly (at a certain point) than continuing with the present
number of workers. Brooks said (my view), "think about the following
- you can't get there (an easily hoped for ideal) from here (with the
means that have commonly been used). You may think about another
means of getting there!"

Ivar Jacobson, "Object-Oriented Software Engineering"
Jacobson's book may be the most concentrated (as in mentally
advancing and complicated) useful information I've ever encountered.
It's possible that my experience of difficulty has to do with pushing
myself through his book. He makes quite evident comments about
developing models (particular models with particular purposes) and
advancing from model to model in software projects. Jacobson put
clear thinking and thinking based on earlier thought and thought
supported, recorded, and advanced though advancing models on display.
(I saw in a recent book of his that he dedicated it to his mother
with memory of her helping him with his homework and the procedures
of thinking that it provided him though life. When I see those words,
it's like E. F. Hutton talking in a commercial :)

Steve McConnell, "Code Complete, A Practical Handbook of Software
Construction"
McConnell brings to the table enough info about the actual coding
part of software development that one is prone to say, hmm, I didn't
know that. There's much that may be said for clarity and purpose in
coding, and much of that is written in "Code Complete". "Code
Complete" is the only book that I know of (beside the Bible) that's
worth reading over and over (and planning to read over and over).

Mind maps, concept maps
Mind maps represent new ways of making technical information evident
or easier to see and understand.

The options represented in these comments cannot easily be furthered
unless those furthering them consider that they provide benefit and
have working knowledge of the meaning of the options. One has to
know what an "operational definition" is and why it is needed before
that phrase directs attention to something that should be said.

Very likely, these ideas work together advantageously.

Have a nice day
John Paul Fullerton
jpf@myriad.net

-- 

"John Paul Fullerton" <jpf@mail.myriad.net>

Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>