Tech Support: “I need you to right-click on the Open Desktop.”

Customer: “OK.”

Tech Support: “Did you get a pop-up menu?”

Customer: “No.”

Tech Support: “OK. Right-click again. Do you see a pop-up menu?”

Customer: “No.”

Tech Support: “OK, sir. Can you tell me what you have done up until this point?”

Customer: “Sure, you told me to write ‘click’ and I wrote ‘click’ – two times”

JOHN Littlewit, the new member of the Information Technology Department, made the following statement in the system review meeting on Friday: “It would cost us $800,000 to build this system, but we can purchase an equivalent package for $125,000. Therefore, we can save $675,000 by purchasing the software package.” As the business manager, you are in the meeting because the application is to be procured for your department. How do you critique this statement?

Managing software

As I indicated last week, the business manager needs to have an understanding of some of the more critical issues involved in managing an information system. It is no longer adequate to just “leave it to the IT people.” You would be surprised to know that many IT people may know IT, but are not conversant with some of the management issues relating to IT! As the functional area manager, you’d better know some of these critical issues that will be affecting your section/department/division!

You cannot escape the fact that in order to understand the few key issues that I am asking you to understand — you must know some of the related IT jargon. So please bear with me on this enlightenment trip.

If you refer to the end of my MBA Forum article last week, I mentioned that when you buy packages from software vendors, you will be dependent on them for the entire life of that application software. It is also possible that the maintenance fees that are usually required to be paid annually (forever — or until you stop using that application), may be draconian. I know of Jamaican firms being required to pay US$40,000, US$60,000 and more in annual maintenance fees!

Critical software issues

OK — here are some technical details. When a programmer writes a program, he/she writes it using a programming language like C++, Java or Visual Basic. What the programmer actually writes is called the source code, but the computer cannot process this code. The source code has to be converted to something of a totally different format called an executable code.

The executable code, as the name suggests, is what the computer actually executes. Let us take an example — for Microsoft Word that many MBA Forum readers would know — the actual primary file that the computer would execute is called WINWORD.EXE – where the last three letters (called the file extension) EXE represent the fact that this is an executable file. Similarly, the MS Excel file would be EXCEL.EXE – and these files are hidden deep in your computer’s file system so that the un-initiated will not abuse them! (When you click the big Excel X on your desktop it points to the EXCEL.EXE file and executes it.)

So why does a business manager need to know all that? Here’s why. When you contract a programmer or consultant or programming firm to build an application software for you — they will typically develop the source code, then convert that to the executable code. Now here is the crunch. They will typically only give to you — their client — the executable code! The source code the programmer will keep. You CANNOT edit the executable code! So if there is a simple spelling error on one of your application screens you cannot correct it at the executable code, ONLY at the source code. But if you do not have the source code, and typically do not own the source code — then you have to go back to the vendor!

We mentioned only an error. But suppose there is a process change, or a business rule change, or an additional procedure? Again you need to go back to the vendor as you are trapped into that relationship as long as you keep using that application. With an unscrupulous vendor, you could end up as a veritable feeding tree!

So with this little piece of knowledge, when negotiating with someone to build software, you should know that you must enquire about the ownership of the source code. Now — the programmer may very well offer to let you have the source code at an extra cost (sometimes significant), or may outright deny your request. But at least you would know what you are getting into!

The same principle applies when you buy pre-written application software. You will only be buying the executable code, and the vendor typically keeps, and retains ownership of the source code. Again, you should realise that up front, as typically you will be charged maintenance fees annually as long as you use the software. So what if you choose not to pay the annual maintenance fee? No problem — as long as for the period you use the software you don’t need any technical support, software changes, bug fixes nor software updates!

John Littlewit

So what was the issue with Mr Littlewit’s statement at the start of this article? It is seriously flawed, because before you spend the $125,000 for the package, you must spend some money on a feasibility assessment. Then you will need to spend some more money — possibly a lot more — doing a requirements definition analysis. We will look more closely at the requirements definition in another installment of the MBA Forum as it is really, really critical for every business manager to know about! We are not done yet — after you purchase the package — you will still need to spend more again!

The total cost to procure the packaged software could therefore be much, much more than the $125,000 — so this number should not be compared to the $800,000 to build the package from scratch!

Dr Kenroy Wedderburn is an MBA part-time lecturer. Send your e-mails to drkwedderburn@gmail.com.