So, what did happen? Well, not much really. Yes there were a few gotchas here and there. There were none where I work, though. Y2k proved to be a non-event catastrophe speaking and I have to smile when I think of all those people eating dried survival food for the next few years. Dig in, guys!
The lessons from this event may not be clear to everyone, so I hope you don't mind me spelling out a few things. Firstly, the money invested in Y2k was not a ripoff by the IT industry. Sure there was some of that, but for the most part there was a lot of money tied up in people working insane hours just to make the deadline. A lot of IT people worked very hard to provide the 'business as usual' result, it is simply not fair to ask why we spent all the money. The answer should be self evident. Not only do we have better hardware and the latest off-the-shelf software, but our in-house developments were greatly improved by the Y2k scrutiny.
There were a lot of companies out there that didn't even know what they had! Y2k taught them the value of a register, and now that these registers are created I doubt most companies will let them lapse. Change Management was looked at in almost every enterprise. Those who didn't have a good system in place do now, it will be much harder for cowboys to throw their code into Production systems now.
Other follow-ons of the Y2k scare are more subtle. One major point is that up until this point most IT units were always receiving a bad reputation for getting projects delivered late and over budget. Y2k was the first major industry wide issue which made it's delivery date. Why? Because management of the enterprises were not afraid to throw money at this project. It simply HAD to be done. This meant that for the first time ever, IT managers were not tugging at purse strings trying to scrounge a reasonable figure from the Executives. The result: a win.
The lesson here is obvious - The problem with IT is not a technical one at all, at least in the vast majority of companies. It is FUNDING. Technical teams can't just 'make do', there is always the small matter of technical constraints in the way. Sure, like every industry there are subtle gains to be made in productivity concerns, no business or industry is a perfect model of efficiency. Still, the lesson that Y2k bears out is that a quality result can only be gained by a quality budget.
This is a scary thought for most managers because it means that there is something fundamentally wrong with how they apportion funding for their activities. There is, of course. The problem is that since the introduction of the computer to the MIS arena, managers have been making decisions based on quantification, not qualification.
Computers are very good at quantifying results and data. This means that most managers now have a vast array of information available to them on their operation, information that has not been available before now, ever. That information can contain detailed breakdowns on every statistic it is possible to gather through company operations. What the computer can't do is qualify the data. The computer is in fact so bad at this, that most qualification systems are really quantification systems in disguise. How many of you are judged against meaningless data, like the number of calls you receive in a day over the average time? Most call centre people faced with such a silly system get RSI of the tongue saying "I'll call you back." The reality is that most Executives think they are getting a good idea on how good their teams are with these sort of statistics, but all they are doing is teaching their staff how to fudge the figures to make themselves look good. The person who loses out in this contest is the customer.
From this we can deduce that the computer is it's own worst enemy. It is providing the mindset to the managers that quantity counts more than quality, and then IT managers are at a loss for words when asked why they need so much money to get the system operational. Corners get cut, and the first things to go are testing and documentation, which have nothing to do with the actual construction phase (quantity) but have everything to do with ensuring the product is fit for use and easily maintainable (quality). Thus the IT manager does what everyone else is doing, and that is make his own quantifiable figures look good, perpetuating the problem.
Y2k is a good opportunity to look at our practices and change them. For once, the money was there and so was the result. The users benefitted, meaning the customers benefited. Good IT systems are robust, stable, intuitive, not a specific figure in lines of code. The sooner that message gets through, the better.
This page ©Copyright 1999 - 2002 Acid
Site: acid.commandline.com.au