It was twenty years ago today, Sgt. Pepper taught the band to play. They’ve been going in and out of style…

Actually it was more than 25 years ago when I was graduated in Computer Science from university and got my first assignment. I was hired by a SME and independent software vendor to develop software for shop floor terminals (SFT). Since I got two degrees, one in electronics and one in computer science I was very well skilled in using new and higher programming languages for steering low level electronics like SFTs. I developed a complete operating system to offer a platform to develop applications for the 6509 Motorola processor, which was the heart of the SFT. My programming language at that time was C. An almost unknown language then, since most software was at that moment written in Assembler. I managed to installed a very good C cross compiler and wrote my software on a PC and not on a very expensive development system specially designed by the manufacturer. This wasn’t seen before!  I was considered a wonder kid and for me the sky was the limit. I would teach the band how to play.

The first end-user application that I wrote was for a bank. They requested a time registration system for their personnel. A quite controversial issue at that time, since it was not really done that ‘white collars’ had to go through a registration (control) system to keep track of all their actions (and movements). Electronic time registration was at the dawn of its inception and was only well known by ‘blue collars’ on a real shop floor in a production plant.

I wrote for nearly three months on the application when I finally could deliver the first version. The software kept track of the begin and end times of the working day for all employees. There was also a credit system for all employees by which they could go to the restaurant for a snack and for their lunches. The SFT kept track of the lunch pause and calculated the correct times and spendings. The local collected data on the SFTs was send by an own developed communication protocol to the central host computer where the payroll application processed the captured data.

My God, I took pride on that application! I had tested the software till my fingers bled from batching in and out. Nothing could go wrong on the day that I was supposed to installed the software into the terminals. I even developed a special app to load the software into the SFTs. Remember, this was prior to the Internet!

Before I could install the software, the hardware needed to be installed by the technical staff. Bur connections and cables where tested and everything worked fine. I got green light for installation. The next day I was already more than a hour earlier at the appointment and I checked the application in the operational environment. Guess what? It worked smoothly! Then the acceptation tests took place with the customer and the users.

Before we could go into the application the office manager made already a remark. He was responsible for the ergonomics in the workplace and took care for the environmental conditions of the offices. I was already surprised to hear what possible problems my terminals could have with problems of heating, ventilation and air-condition. I soon found out what the problem was. Not the software or the application, he never took notice of it, it was the … color of the terminals. The color was blue with yellow edges. It seems to me a very contemporary choice at that time. According to the office manager these colors could not be reconciled with the light brown colors of the walls. Anyway this was never an issue nor a requirement condition. And even if so, it was not something where I as a humble programmer had any experience to give some professional advice. Although I had to admit that the color palette of brown, blue and yellow was not a perfect match.

We spend more than three hours discussing how my SFTs could get another color. At a certain moment somebody even suggested to repaint the walls. I was not me. Then the meeting was closed and I got my first IS failure to take home.

Lessons learned.

IS failures have nothing to do with technology and are not equal to engineering failures. IS failures are an outcome of a human process. All different stakeholders have to find there correspondence in the information system before you can call it a non-failure (not equal to a success). The correspondences of all stakeholders find there roots in the social values their cultivate. For IT-ers this could be a flawless software, for the CEO this could main saving money, and for the office manager this meant a perfect match with the ‘right’ colors.



About jangdevos
I'm an IT/IS professor, a late Baby Boomer, married with Ann and father of Hélène and Willem, a Stones fan and interested in almost everything. I work at the UGent (campus Kortrijk), Belgium. My research domain are: IT Governance in SMEs, IT/IS Security, IT Management, IT Project Management, IT Trends and IT/IS failures.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: