Make your own free website on

My Articles      On God & Religion      On Computer Tech         Home




Prem Kamble


Golden Rule for Software Support

Problem Definition

Bottleneck Area or Where the Shoe Pinches Most


(The following piece was written for a regular column in our office magazine where I planned to share interesting people related experiences while performing my role as a CIO (Chief Information Officer) there.)

Welcome to this column which I call Camble's Rambles  (pronounced Cambel's  Rambles). Camble is what my friends used to call me at college. Rambles is a word which rhymes with Camble. The synonyms for the word are "Discuss" and "Elaborate".

I plan to discuss in this column certain strategic issues related to  IT  Management. I hope to come back to you with this column from time to time and share my own experiences in tackling various IT related problems in my day to day activities. On several occasions I have come across instances which are  really interesting and worth sharing with you.

Ramble,  according  to  the  dictionary  also  means  "walk   for pleasure". Through this column I will also have a "Pleasure walk" down memory lane. I am certainly not old enough to be sitting  in an armchair proudly relating my experience such as "When I was in Gergovia..... ". But here goes...




What I can remember today is a situation I faced only a few  days back - a situation when one of my users had rained on us requests for changes in the Purchase system which was already  implemented and running for a few months. I had no resources to allocate  for carrying out these changes as each of the few programmer analysts that I had was busy in some project.


Golden Rule for Software Support


In such a situation, how does one support the user or satisfy his ever increasing appetite for system changes as judiciously as possible? One of the golden rules which I follow is to try  and find a solution to his requirement as much as possible within the system  rather  than outside the system. The idea is to find a solution to his problem with innovative use of  the  existing package instead of with additional programming or any modifications to the system.

This has several advantages. For one, you get a tested product to solve  your problem. When you use the running system for  solving the  problem, the built in checks and controls are  available  to you. While the system which you would be using is  a  tested  and tried  product,  any  new program you may write will  not  be  as reliable  since it will be put to use for the first time. As  the new  program would most likely be written in a hurry,  you  would tend  to skip providing enough checks and controls.  Leave  alone the  time  required  to  write  or  modify  a  program  and  most important, the problems or risk of introducing a bug in a  tested program by modifying it.

The  instance I want to narrate illustrates how  the  programming resources can be optimally used by keeping maintenance activities to  the bare minimum. And how in this case a detailed  discussion led to a solution within the existing system.

The Purchase system was being used by the Purchase Assistant  for almost  a  year now. She was fairly conversant with  the  system. Suddenly  my Systems Analyst came to me saying  that she  had  requested  some changes in the  system  related  to  PO Amendment, two of which we shall discuss here. The problems  were reported as follows:

Firstly,  she was unable to raise a PO Amendment to increase  the item quantity beyond the original PO quantity. She wanted this to be made possible.

Secondly,  the PO Amendment print format presently lists out  the full amended PO. She wanted the amendment to show the old figures and the new amended figures.

We shall discuss both these problems in details. An analysis of the first problem will show us how important it is to define the problem clearly. The second case shows how an exact understanding of the users’ problems helps to pinpoint where the shoe pinches the most.


Problem Definition


You  must have noticed that sometimes the problems  reported  and changes  suggested by the operating personnel cannot be taken  at face  value. Some probing is normally required to understand  the exact requirement.

Let us try and understand the first problem. Further  discussions with my Systems Analyst revealed that the problem she was facing was  not that the system does not allow increasing the  quantity, but  that it does not allow for increasing the PO  item  quantity beyond the Indented quantity. That is, through a PO Amendment, it is  not  possible to increase the quantity  beyond  the  Indented quantity.

I  thought that the restriction was fair. You cannot provide  for allowing  the quantity to exceed Indent quantity without loss  of control.  I was wondering what could be the  situation  requiring such  a  facility. I was sure her boss would not desire  to  have such  a facility. I thought of talking to her Boss, the  Purchase Head.

I asked him what exactly was the problem. I wanted to know how he saw the problem.

He said that he asks his Purchase Assistant to make an  Amendment and she comes back saying that the computer does not allow her to amend  the  quantity. He also asked me to change  my  program  to allow  this.

I explained to him what exactly she meant when she said that  the computer did not allow. I explained that the system allows you to decrease the quantity.

"Oh really?"  was his reaction.


I said it allows you to increase the quantity also.

"Oh  really?  Then  why does she say she cannot change the quantity ?"

I explained that the quantity can be decreased for sure and  also increased  so long as it does not exceed the  Indented  quantity. Only  if  the  PO quantity exceeds the  indented  quantity  after amendment, the system disallows.

"Well, that is exactly how I want it to be. Then where is the problem?"

You  can  see  how  a communication  gap  leads  to  an  improper definition  of  the  problem. The Manager was not  aware  of  the problem  because the Purchase Assistant could not clearly  define it. He only knew that there is a problem in the computer  program -  that  it does not allow amendment in quantity.  But  the  real problem she was facing was that she was not able to increase  the PO quantity beyond the Indented quantity.

Now  the  question was why did she at all need such  a  facility? What could be the situation when such a facility is required?

Interrogations  revealed that this was the case with  only  Steel POs.  For Steel Purchase, no formal Indent is received. Based  on the  Projected  requirements, the Purchase Manager  asks  her  to prepare a PO for some specified quantity for immediate  purchase. She  on  her own makes a dummy indent for the same  quantity  and then a PO.

Further  discussions revealed that if the indent itself  is  made for a higher quantity, the problem would be solved.

Indeed  that  is what the Manager wanted. He said he  can  easily make  an indent for the total projected requirement  (instead  of for  the quantity of immediate purchase) and keep on raising  the POs  from time to time. As a bonus, he can at any time  know  the pending quantity to be purchased.

I  suggested  that  a  proper indent format  is  made  for  steel purchase  which  will be raised and authorised  by  the  Purchase Manager himself.

That  was some relief to me as one of the two problems  at  least could be solved effectively using the current system without  any modifications.  Any modifications to the programs on  this  count would  be  quite  some  effort,  not  to  talk  of  the  risk  of introducing fresh bugs while modifying.

The second problem remained, that of printing the PO Amendment in a different way giving both old and amended figures.

The  requirement  seems quite justified.  For  whatever  reasons, during  the  design  of  the software,  the  system  and  the  PO Amendment  format  were  accepted by the user.  (Of  course,  the Manager  now requesting the change was not there in  the  company when  the system was designed). Any change now again  would  mean some programming effort which was very difficult to spare at that time.

Again I asked the manager what exactly was the problem - I wanted the problem to be defined as he saw it. He explained to me thus:

As  the  PO amendment looks exactly like a PO and lists  all  the items again with the amended data it is difficult to  distinguish an  original PO with the Amended PO. Secondly, and what  is  more important,  the  suppliers  misbehave  and  send  fresh  material treating the amendment as a fresh order.

I explained that firstly there is a clear difference between  the PO and PO Amendment. " Amendment No # " is printed on the top  of the PO Amendment to distinguish it from the PO. It can in no  way be  mistaken  for  a  fresh order.  The  Manager  asked  for  the printouts of POs and PO Amendments and found that indeed that was there to serve his purpose. However I decided to probe further.


Bottleneck Area or Where the Shoe Pinches Most


I noticed that his main concern was that suppliers treat it as  a new  order. That was what was worrying him most. If we be in  his shoes,  we  find  that that is where the  shoe  pinches  most.  I thought of addressing his most pressing need.

For his second problem, I agreed that an ideal solution would  be to print a different format, but as this format was accepted  and provided  in  the system,  making a new format  would  take  some time. 

I knew I could not give him a complete solution in a short  time. I  thought  I  will  at least solve  his  most  critical  problem immediately.

An  alternate  solution  within  the  existing  system,  which  I suggested they could start using immediately, was as follows.

The PO program allows to enter about ten lines of footnotes which can  be entered and directly printed as comments or footnotes.  I suggested  that  if  his problem was to  prevent  suppliers  from treating it as a fresh order, a clear message could be entered as a footnote by the operator saying that this is not a fresh  order and that there are amendments only in item serial nos. so and so. This was acceptable to the Manager.

As a follow-up activity, I requested him to give me a format  for PO Amendment, on the basis of which I would make a fresh program.

The Manager then felt that as the Purchase procedures were  being reviewed at corporate level by a committee which is also going to recommend  standard  formats  for  each  document,  it  would  be advisable  to wait for the committee's recommended format for  PO Amendment rather than make our own and make a program for it.  As a result it was decided to continue with the existing format with the solution just suggested and postpone any new development.

Probing into the problem and understanding the users requirements better led to a solution acceptable to both. It saved the need to immediately divert my resources which would  also  disturb my programmer in his current assignment. At the same time I have time to plan out and give him a proper solution. I was successful in finding solutions for my user within the existing system with absolutely no changes required in the system. My user was  happy and so was I.




The above incident highlights a few things:

With  the right strategy, considerable maintenance effort can  be saved.

The changes requested by a user should always be ratified by  the department head - he often has a different and wider view.

The  exact  problem is sometimes not clear to  both  the  systems persons  and  the user and we tend to hit the keyboard  to  start modifications. A little deliberation reveals what exactly is  the problem, what is it that the user is exactly concerned about  and what  could be an alternate solution (perhaps a  better  solution than  the  change requested by the user) which will  address  his most critical problem (where the shoe pinches most).

I hope this article has kindled your thought process too. I  will look forward to your reactions and views.