|
This sure looks pretty hard to achieve, but without it, the job will be botched. I'll bet not many firms do it the right way.
____________________________________
From: Hnodot@aol.com Date: Thu, 30 Jan 1997 11:56:38 -0500 (EST)
The false notion that the only way to deliver software functionality is to _break all the rules and get it done_ has been proven over and over again to be the most expensive way to do business.
That is because it causes REWORK
Programmers/analysts/managers have rework to:
Figure out what was done before Find pieces of code that have not been catalogued properly Figure out how the pieces of code work independently Figure out how the pieces of code work together Figure out how to test the pieces of code Figure out what to do when any change has a negative _cascade_ effect on the rest of the enterprise Figure out the impact of proposed change (estimating) Figure out change of scope during the effort (project planning) Use their time to the best benefit of the organization instead of wasting it on trivial efforts that must be supported in the future.
90% of the cost of running an application is in the ongoing maintenance. Only 10% of the cost is in the initial development. Anyone wanting to deliver an application without change management, project management, software configuration management, formal testing, and overall enterprise planning/positioning, is NOT delivering the best solution to their organization. They are delivering a future legacy of chaos, high cost, and slow delivery.
No manufacturing operation in the world can operate with the level of chaos that IT operates in today. Can you imagine a car manufacturer having an assembly line worker put a bolt on a car, test it, decide it does not work, and replace it -- 4 or 5 times before he is done.
But people developing C/S applications today are doing just this. They are merrily and uncontrollably developing applications that cannot be supported, that are out of standard, and that will cost the organization more in the long run.
So, about the Year 2000 Compliancy conversion. Why not put controls in place to:
Do the job right Know what you are changing Plan the change relative to enterprise-wide goals Coordinate so implementation and testing does not have to be repeated Eliminate the _gotcha's_ as much as possible (if only to keep your customers satisfied and doing business with you. Prevent having to change, test, implement, debug, change, test, implement, debug, change, test, implement, debug (I think you get my meaning)
If your management allows you to do chaotic work, without controls and proper planning, I suggest finding another company. At some point, YOU will be blamed because the systems are too expensive to manage, too dificult to change, and too non-standard to recover.
It is scary to me that, especially in the USA, we still reward the _cowperson_ who ignores the future and _does his/her own thing_. And leaves the poor schmuck who follows to understand the mess.
I can go on and on, but hopefully this will provide some food for thought.....
Copyright 1997, Synchronized Solutions, Inc. All rights reserved.
|