[
Lists Home |
Date Index |
Thread Index
]
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
<snip/>
> The next problem is getting someone to pay for
> the analysis, the tools, the design work, the
> implementataion and documentation, the training,
> and the redesigns for oopsies.
Quite true. Fixing problems can be costly. Not fixing them can be costly,
too. I remember one particular system error that cost a company somewhere in
the neighborhood of $2 million. It would have cost the company substantially
less than that to abide by the sort of sound practices that could have
averted that error.
I am not trying to cast things in black and white terms, here, and say that
nothing should be done on a system until a complete rigorous model of the
enterprise is completed. There are many shades of gray out there. The key
thing is when a team works on a project, they should endeavor to understand
the larger context, rather than view systems as islands. And when an
opportunity arises to get different groups working together to solve a
larger issue, they should not hesitate to seize the opportunity; it may not
be there for long.
> But yes, without a thorough understanding, this
> is difficult to achieve. There are also granularity
> issues that directly affect process. Sometimes,
> big Ol'Hog Memo fields have a lot of different
> kinds of data in them. One group (the bean counters)
> want very deep granularity whereas the proposal writers
> and developers neither want nor need to track at
> that level yet are the data sources.
Quite true, and there is no magic bullet for that problem. It's difficult to
get a team to consider requirements in which they have no stake.
> And so it goes. I have seen attempts to use manufacturing
> paradigms (part = price) forced on software groups
> and fail miserably.
The models I've typically worked with in my career have been imperfect
approximations. When applied with some common sense, they can be useful
nonetheless. When the model becomes dogma, problems result. And when
something is "forced" on the developers, they tend to just switch into CYA
mode rather than being focused on the success of the project.
Methodology has gotten a bad rap in many circles because of so many
instances in the real world where a burdensome methodology has been imposed
in a bureaucratic fashion, or has become dogma. I agree that such attempts
typically fail miserably. I have, however, had the good fortune of being
able to participate in a couple of process improvement efforts that were
genuine collaborative efforts between individuals at different levels of the
organization with sincere interest in seeing the effort succeed. In each of
these cases, the efforts originated as grass roots initiatives by developers
who were tired of working on failed projects, and who understood very well
why those projects failed, but did not get the support or cooperation they
needed from execs to succeed. When we managed to get that support and
cooperation, and were able to introduce useful methodologies and process
improvements, it was a wonderfully gratifying experience. We witnessed great
benefits from it -- in spite of the fact that the end result was typically
uneven, and usually involved considerable compromises. Enterprise
architecture was a factor in these efforts, but just to the extent of
providing some guiding principles for our efforts, not to the extent of
plopping thick binders on everyone's desk and saying "these are the rules
you will follow from now on".
I remember one particular process improvement effort that ultimately
resulted in a 10-20 page document with the word "Guidelines" in the title.
And when we said "guidelines", we meant it. It was an aid to project teams,
not bureaucratic constraints. And it was very well received because project
teams found it useful, and because they had a say in crafting it to begin
with. If a team had sufficient justification for breaking the rules, they
broke the rules. And meeting business requirements was sufficient
justification if the guidelines got in the way of that. We also had an
architecture document that was considerably longer than 10-20 pages, but it
was still just guiding principles -- not law.
I wish more people had the opportunity to participate in such an experience.
This stuff really can be done successfully, and its extremely rewarding and
enjoyable to be part of such a success. One very big challenge is overcoming
the politics and getting the sincere collaboration needed for success. It
can't be simply imposed from above, and it cannot succeed as purely a
grassroots effort. Getting over the political and cultural challenges is a
huge hurdle, and there are certainly environments where the hurdles are
simply insurmountable. I have no magic bullet for dealing with this
challenge, but I have had the good fortune of witnessing a couple of rare
instances where we were able to overcome this hurdle. I hope I will be able
to see more such instances in my career.
|
