SDLC Doc and Penis Enlargement

Over the past two years I have encountered companies which spent huge amounts of money purchasing SDLC templates and even larger amounts of money customizing those templates for their own location. Once they have their customized templates, they spend piles of money sending people suddenly titled “Business Analyst” to training on how to fill out the document templates for each project.

Why are they doing this? The root of this evil is Sarbanes-Oxley, but the vendors of SOX solutions have taken their marketing queue from penis enlargement commercials. “Get a big boost of confidence knowing your IT projects can no longer fail.” I have even been to sites that were stunned to find IT projects cratering. Managers were circling the wagons trying to figure out what part of the SDLC process the failed project skipped.

SDLC has a lot in common with “male enhancement” products. They both require you to believe and see what you wish to see. Where they differ is that investigators will have actual signatures on file when a project fails and someone tries to hide the cost in the books. SDLC documentation doesn’t ensure a project’s success, but it does identify who will go to prison when the failure is covered up.

Am I against SDLC doc? I am against many of the process steps imposed by commercially vended versions. Those vendors designed the SDLC so MBA’s could have input. They created a “Work Initiation” step which was more than a single line on a “to-do” list and less than a detailed analysis. The actual detailed analysis gets spread across three-four different documents, presumably to be filled out by three to four different people. Isn’t that just what you want on any project? Four different people all trying to steer the boat without any of them manning the sails. In actuality, this is exactly how the SDLC process is implemented at pretty much every client site I’ve been to that is SOX compliant. Guess what? If you aren’t publicly traded you don’t have to be SOX compliant.

To start with, no SDLC process can guaranty a project outcome. If any hint of that was in the sale pitch, you need to press criminal charges against the vendor. As currently implemented at most companies, an SDLC process serves only two purposes:

1)Turn tiny bug fix projects into massive things requiring sign off from many different people
2)Provide a predefined list of names to the criminal justice system.

You see, each and every SDLC process makes the grand assumption that “someone” working at your company actually knows what is going on. That assumption is the ultimate fraud. The process allows everyone who “thinks” they are in charge to feed their own ego by requiring them to sign off on various stages of the process. The process provides absolutely no defense from clueless ego feeders.

An even bigger threat for each and every SDLC process out there is that each person on the project will know only a little piece of the system you are working on. Each step in the SDLC process will pull the project in a different direction as each new player is encountered and your final system delivery won’t look anything like what was requested in the Work Initiation.

The most common train wreck every SDLC process creates is one which stems from piss poor management and scope narrowing. You have a system which has been in place for 20-30 years. It was originally purchased, then heavily customized. The only documentation which exists for it is the original system documentation, prior to modification. Other departments have taken over pieces of the system, rolling them into a new application by a new name. Some portions of the system are still using fixed width flat or indexed files for data storage. Other departments have written systems which makes use of the data at this stage, but they didn’t bother telling you. When you finally install your change in production, applications which haven’t been touched in over a decade suddenly fail and nobody has any idea how to recover them. All of your testing went perfectly, because you only tested for the couple of interfaces you knew about. There was no full scale production sized development system to run a complete production simulation, so you had to test only what you knew about.

This entire series of train wrecks gets even funnier when you toss in software development which is performed by illegal aliens who have no frame of reference when it comes to your business. They just code what they are told and don’t put up a fight like a seasoned professional would.

I don’t believe anyone reading this is willing to take before and after pictures using a ruler, and announce the “study” of a male enhancement product prior to some perceived “big boost of confidence”, which is why those products all promise they are shipped in a plain brown package without identifying markings. Did the SDLC product you purchased make the same promise?

This entry was posted on November 2, 2008 at 10:39 am and is filed under Information Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response or trackback from your own site.

| Print