Cost of Progress I Won't Compromise

The other day, I was stuck at the Mumbai International Airport with heavy downpour and cyclonic conditions disrupting all the airline schedules. After a long tiring wait for the weather to improve, the airline finally cancelled most of the flights. The travellers were left in the lurch as they were asked to go out of the boarding area, back to the check-in counters, to cancel or reschedule their tickets. The scene out there took me back in history, some 30 years back, when the railway booking clerks used a manual register to reserve or cancel a seat and therefore, there was no other option but to stand in that very counter if one wanted to do any transaction for any day in a particular train.

So, what happened to the grand automation story that we seem to be so proud of. One single disruption in the workflow caused such a havoc that hundreds of travellers were jostling around one booking counter to either cancel or reschedule their tickets. The ones who originally booked their tickets from the comforts of their air-conditioned homes and offices, were left to find their way to a single airline executive in such a melee. Gentlemen, this is not what you call end-to-end automation or straight through processing. The scenario for failure of one link has not been planned and tested for. The customer experience has been far from satisfactory.

And this scenario is not very different in the most organized software services industry as well. Just a few days back, I was reviewing a software solutions program wherein the application malfunction had caused considerable disruption in the client services. The application was well tested and deployed in good faith. However, as in the case of the airline scenario above, the breakdown of one link in the entire workflow caused complete disruption of the business for many hours. The root cause here again was the same. A particular case for failure condition was not planned for. In a centralized operation, when an otherwise straight-through transaction creation fails, there is hardly any time and bandwidth available to handle the scenario procedurally. The otherwise well-oiled machinery posed a challenge of manual intervention of humongous proportions. Nobody knew how to handle such large set of transactions manually with stringent cut-off timelines of a payment system. There were a set of tools built over a period to obviate such a situation but none were handy or tried out by the team. And thence the disaster.

Going back to the basics of program management, I am reminded of the most powerful statement that I had ever read during my certification – every assumption is a risk. And therefore, assuming that the entire chain of the workflow will run without a break was the biggest risk; and therefore, the assumption that there will not be a situation where some twenty flights will get cancelled at the same time was the biggest risk. These may be one off scenarios and the cost of building a safety net around these scenarios could be high but only that will separate a great solution from the good ones; only that will separate a solution designed by the men from the ones put across by a bunch of boys.

Introducing new developments and achieving growth at breakneck speed is the new norm across industries. Bringing in new thoughts and continuous evolution at work is a welcome change. However, this cannot be at the cost of the very basics and the hygiene factors. There is no point in taking four steps forward only to slip down by two.

Coming back to my experience at the Mumbai International Airport, when the flights resumed the next day and I was patiently waiting for my rescheduled travel, I noticed a glitch in the display systems at the boarding gates. The display announced boarding for a flight to Lucknow which had completed boarding long back. The board had not refreshed to Vadodara and it was only those standing around were aware of the next flight boarding. Many of the travellers pointed it out but the lady at the counter couldn’t help with correction.  It is good to have a ‘silent’ airport but shouldn’t there be exceptions? The calls made by the lady at the gate could reach only those in the vicinity of 5-10 meters. There were no broadcasting systems used in the ‘silent’ zone. In a crowded and chaotic lounge, people were sitting wherever they got a few inches to seat themselves and in the absence of any announcement and a malfunctioning board, a few would have missed their flights.

So, it is good to evolve to a modern system; it is good to adapt to new ways of working; it is good to adopt more mechanization; it is good to automate mundane processes to increase throughput. But we need to be prepared for an eventuality of a process breakdown. Can we not plan for an alternative tool to push through transactions? Yes, we can. Can we not have a temporary battery operated amplifier to meet emergencies? Yes, we can. Can we not have an online ticket cancellation and rescheduling mechanism? Of course, we can have. We need to plan for these and communicate these effectively. Jumping up four steps on a pole to slip down by two is a monkey trait found in typical aptitude test questions – but we are different from the simians. We have evolved to become humans and are capable not to slip those 2 steps. We should maintain that differentiation.