Kent makes many intereseting observations in this post.
>I don't have any ERP cases to report, but I am thinking that cases are
>needed because the rhetoric from salesmen and disappointed clients, and
>especially the rhetoric from nanny engineers, is getting very stale. I've
>grown suspicious of the following self-sealing argument: if you use
>version x software engineering discipline you will succeed (never
>demonstrated); people are failing; therefore people need to redouble their
>efforts to use version x software engineering discipline.
>
>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?
>
>It's the last question where I think there is something new to say, and
>that needs case research. If anybody else is interested, I would like to
>maintain a loose group of correspondents.
Much of the failure I've seen in the implementation of "software solutions"
have had three parts:
1. organizational structure has not been redesigned to take advantage of the
model provided by the software system
2. silo organizations which have not "broken down the barriers" learn the
system in a function/human by function/human approach
3. the human/function approach only assures that the human can access the
function through the software. It doesn't assure that the function is a
part of the human's knowledge.
I've experienced this in organizations which decide they are going to
become a project management company. They buy the software, teach
everyone to use it, then can't figure out why it's not working. By
modeling and simulating in the learning process, using simulators (such as
the beer game) which are doomed to fail, debriefing, guiding and coaching,
the rearrangement of tacit skill sets to take advantage of the new
explicit knowledge needed to take advantage of the software model begins.
Tools require training require practice.
John
--"John Zavacki" <jzavacki@greenapple.com>
Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>