A Warning Hazard: System Deficiency From AIDS

Even corporate systems have some deficiency syndromes that can catch on and spread like wildfire and eventually render a developed system, both fabricated and packaged, totally useless at some point in time. Most of the time, the cause for this is poor systems analysis and design that an organization wants the system to produce. The common know how is that once a company implements a system, it can produce anything that management wants it to have. While this may be possible, there is also the question on whether during the early stages of development; all needed inputs from the critical parts of the organization were properly endorsed to the assigned development team. Most of the time, there are small overlooked procedures that eventually become a major part for some aspects for proper analysis and evaluation by management.

This is something I refer to as the Allocating Information Deficiency System or AIDS. In a way, this is similar to the widely known sexually transmitted disease in terms of spreading and in some cases, even become the downfall for some developed systems. In the early stages of developing a suitable system for an organization, total focus must be given on the backbone hierarchy of the system to be. Some parties take this stage of development for granted, opting to wait for the final product that does not necessarily follow. While it is true that seeing a system operational takes away most of pressure, this can only hold true for a temporary period of time. Experience wise, the early stages may make the developers grinning from ear to ear. However, at some point of time this will be like a person who does not know how to swim. The more you fight the current, the more complicated your problem becomes. By this time, you may not be able save what is left and may end up trashing the system to which you have put in so much effort. There is of course the usual backup that you have, but unless the problem is addressed early on, you will eventually go through these rollbacks again and again.

The early stages may be boring and pressuring in systems development, but it is the most critical part before you carry on and start with the programming proper. That is why most system developers use a Time Chart to see that they are in schedule and to properly iron out the deficiencies to the last detail. Hard work and sleepless nights shall surely be a part of this, but if one looks closely, it is better to commit and identify the mistakes early, rather that realize the shortcomings of a developed system, after some years of operation. In these scenarios, its either you go back to the drawing board, itemizing each procedure one by one to see the problem, or for very extreme cases, trash that system and start anew… something that may be deemed as the worst nightmare for any company or system developer/s.