On Fri, 9 May 2008 02:36:21 +1200, "Pete Dashwood"
<dashwood@[EMAIL PROTECTED]
> wrote:
>
>
><docdwarf@[EMAIL PROTECTED]
> wrote in message
news:fvu996$5ns$1@[EMAIL PROTECTED]
>> In article <68f55lF2rpuveU1@[EMAIL PROTECTED]
>,
>> Pete Dashwood <dashwood@[EMAIL PROTECTED]
> wrote:
>>>
>>><docdwarf@[EMAIL PROTECTED]
> wrote in message
>>>news:fvsi79$iae$1@[EMAIL PROTECTED]
>>
>> [snip]
>>
>>>> Mr Dashwood, consider the following:
>>>>
>>>> Given that a cor****ation has finite resources then how are user
changes
>>>> (which consume resources) to be co-ordinated and allocated in a
manner
>>>> which is not reflective of 'the squeakiest wheel' and which is most
>>>> profitable to the organisation?
>>>
>>>It's easy. Change the way you develop stuff. Take a look at Active
>>>methodology. (Both IBM and MicroSoft have recently...)
>>
>> Mr Dashwood, I've taken a look at Active methodology and have found
>> nothing which addresses this question above.
>
>Then you simply didn't get it. It specifically addresses how resources
can
>be allocated in a way that is most profitable to the organisation.
>
>User changes do consume resources, but NOT doing them costs more.
Delivering
>systems that don't provide what is actually needed, (rather than what was
>specified), is simply a waste of everyone's time. (And consequently,
money).
When the users actually know their end of the business and why they
want things this is true but when they are clueless and aren't certain
of what they are trying to accomplish, it can be frustrating. It also
gets to be interesting when two departments disagree on the way things
should be done or what the rules are.
>
>Fortunately, after 40 years, we now have technology and methodology that
can
>deliver systems that DO provide what is needed right now. Techniques like
>object modelling, prototyping, and goal oriented rather than task based
PM.
>Iterative, evolutionary development using timeboxing are all ways to make
>the best use of resources and deal effectively with change. The Active
>movement is an embodiment of many of these.
>
>(DISCLAIMER: You can't do it easily with COBOL. The effort required to
>produce anything that requires thousands of lines of manual code is just
too
>great and will take too long. If you want responsiveness to change, you
need
>smarter, component based, systems that can be assembled and disassembled
>quickly and easily. Tools that generate most of the code are a big help
>also.)
>
>
> Second request, then...
>> given that a cor****ation has finite resources how are user changes
(which
>> consume resources) to be co-ordinated and allocated in a manner which
is
>> not reflective of 'the squeakiest wheel' and which is most profitable
to
>> the organisation?
>>
>
>Last response, then...
>
>It's easy. Change the way you develop stuff.
That can help but I have found many times that the major problem is
coming to a common understanding and a full realization of the
implications of a request.
>
>Pete.
|
