(Originally published in Computerworld February 2003)
Stop blaming the IT department for crappy business processes and move on from Y2K-induced budget squeezes.
Let me start by apologising to all and sundry. The phantom Y2K problem was really my fault. I own up, I know it took ages to arrive at this apology but there you have it. Blame me, I created the problem so all the millions of dollars you spent fixing it are my fault entirely. So sue me.
I know most of you won't believe that it was my fault but someone has to finally step up and take the blame for it. That way the rest of IT can actually put the grieving period behind and move on. It took a lot of guts for the various CIOs to stand up and ask the board to take them seriously for once and actually allocate some budget to avert a looming problem. It took guts to admit that this was a serious problem.
Now for those of you just back from a quick round trip to the galaxy or just one of those countries that still exists on this planet without television, telephone, newspapers or any kind of contact with the rest of the world let me fill you in.
From the time computers were invented until about 1995 give or take a decade, systems stored dates in a six-digit field made up of day month and year. Since computers were not invented until after the start of the twentieth century it was assumed that all dates started with 19 so why bother storing the 19? This was praised as good practice by all and sundry but especially by the bean counters that reasoned that disk storage cost a lot of money, so why waste space on data that could be easily replicated such as a date.
What's more once programmers got wind of compressed numeric fields they started storing the same dates in three or four digit fields. Hands up those of you that remember what a COMP-3' field is. It's a numeric signed field that takes less space than an uncompressed field. Depending on the size you may save one or more bytes after you allocate one byte for the sign. Those of you that think programming didn't exist before Java finish your milk and cookies and get your blankey for your afternoon nap. Ok, here endeth the Cobol lesson.
Some systems developers distinguished themselves when they started storing seven digits for the date in the same space as the six digits. They reasoned the extra digit didn't take any more space and it could be used to signify the century. To avoid costly rewrites they also assumed that zero would represent the 20th century, one the 21st century and so on.
Such visionaries were few and far in between. The rest of the world awoke sometime between 1995 and 1999 with a potential headache. Doomsayers ran around predicting that planes and satellites would fall out of the sky. Trains would stop running, elevators would stop elevating and cows would run out of milk. The latter group were quickly rounded up and were quietly locked away for a few years with a mandate to create a new tax system, but that's another story.
The rest of us rolled up our collective sleeves and started figuring out what to do next. Lo and behold it came to pass that dates had to be fixed and systems had to be tested. And we set about testing and fixing and testing even more and fixing. And budgets grew and Cobol programmers were scarce. And people started to panic because the deadline moved closer and the deadline was immovable.
So more people were hired and Cobol programmers became minor deities and people came forth to worship. As the deadline moved closer budgets got even bigger and more people were trained to address the problem.
But there was panic in the streets. People started to bulk-purchase bottled water and tinned food and essentials such as soft three-ply toilet paper. Because when the end came and you wanted to kiss your arse goodbye, it would have been important to use soft three-ply paper in the process.
Experts quoted from the prophesies of Nostradamus that earth and fire and water would come together when the great machine maker (Bill Gates) held forth a new operating system (Windows 98) two years hence from the original release date.
And it came to pass that masses of leave got cancelled and thousands of people went to work on New Year's Eve 1999 and at the stroke of midnight nothing happened. Nothing kept happening around the world as time zones clicked over into the new decade. Planes steadfastly refused to fall out of the sky. Satellites stubbornly refused to alter their course and trains ran late as usual. Elevators continued to elevate, cars kept running and account balances stayed the same, except for those that needed to have interest applied.
That dear reader was when things started to get ugly. CIOs were immediately put on the rack and questions were asked on the wisdom of spending all that money to fix systems that had no intention of falling over. Nothing happened? What do you mean nothing happened? How could we have spent so much money and effort on something that didn't happen? Bad CIO, bad, really, really bad! Go sit in the corner, your budget will be slashed and your minions will be fired.
HELLO! Did someone forget to turn off the dumbkoff gas? Of course nothing happened. We took on a monumental task and delivered on time, to specification. Our greatest triumph became our greatest failure. That was the whole point of the exercise! We actually succeeded. But did we sell that success? Did we rest on our laurels? No; we of the propeller head designation shrugged and moved on. So the naysayers took on the fight and convinced everyone that we had done a bad job!
So here it is in black and white. We in IT took on a problem created and perpetuated by the bean counters and we fixed it. We should be congratulated. Why? Because when we were telling the bean counters to buy more storage they kept telling us it was too expensive. When we pointed out systems would not survive the turn of the century we were told by the bean counters not to worry because systems would be replaced by then. When we shouted from the rooftops that systems would crash and burn we finally caught their attention because they saw dollars disappearing from their accounts by the stroke of midnight. And when we finally fixed the problem we took the blame for the whole stinking mess.
Well no more. It's time we made the bean counters accountable. No more cutting IT budgets because if we don't have resources to do our work and time to deliver business requirements systems will fall over and millions will disappear into nether worlds that nobody can fathom.
If we don't have time to get business requirements, if we don't have staff to translate those requirements to systems specs, if we don't deliver systems changes and if we don't have time and resources to test these changes the whole shebang is going to curl up its toes and face the choir invisible. It's going to fall off its perch without the merest titbit of a squawk. There is no point nailing it to the bloody perch and expecting it to crow, if you don't feed it will die.
Now we are telling the bean counters that systems will fail if they get implemented without testing them first. They tell us to go ahead and implement anyway.
For my last trick let me dispel a few myths; IT will not solve your fundamentally screwed up business processes. CRM is not a magic wand. The Web isn't going to save you from a manufacturing process that does not deliver quality. Don't blame IT for your lame marketing department. Using IT as a scapegoat for every ill-timed business decision is a stopgap measure that is bound to fail in the long run.
Here is a thought to keep you warm at night. If BCF takes hold and we continue to ignore achievement and praise failure we might as well forget the golden rule of quality or at the very least revise it.
The price of failure is rework; the price of success is no work.