Systems Development Life Cycle

To use Life-cycle Processes, Or Not to use Life-cycle ProcessÐ'....

Perhaps if Hamlet had had access to spread sheet analysis he would have been able to determine the bottom-line and know which option was his best. Today's managers have a lot more information available at their fingertips, however they still ask the question Ð''process' or Ð''no process'. Arguments against process often include: Schedule concerns and too much paperwork, customers will walk away if they perceive us wasting time, long lead time and big expense to retrain staff and lastly the sad whine of "Ð'...some day Ð'...". I want to address these issues one at a time, and hopefully convince you that the right answer is always Ð'... PROCESS.

Time to market is always a concern for mangers. You do not want the competition to beat you to market, and yet you want to ensure a loyal customer base by generating quality product. It seems as if life-cycle processes would generate a lot of paperwork and ultimately slow the life-cycle to a halt. The truth of the matter is that over the length of the schedule, the womb to tomb life-cycle, all this paperwork is beneficial. Often undocumented decisions need to be repeated and verbal specifications lead to miscommunications and diverse interpretations. This really hits a product development team hard during the test and integration phase, when the system design is conflicting among developers. The other phase that is hit hard by undocumented projects is during maintenance. Once the project development team has dispersed, the design and implementation becomes an enigma.

Customer perception is concern number one for most companies, and the arguments against using process are the hardest to mount when there exists an element of truth in them; however, customers are not only lost due to an lengthy development schedule, but also due to poor quality products and unsatisfied technical needs. The trade-off is heavily inclined toward a longer development schedule in exchange for a better product. Often time's companies that do not use good processes quote much shorter development schedules,