IT Procurement: Some Critical Issues


For more than a decade or so, I have been involved in procuring either capital items or revenue items pertaining to Information Technology. Here are a few critical aspects regarding the same that I’ve observed in my experiences. However, I have never worked in a purchase function and the views are, therefore, based on my involvement experience of some big/small procurement.

                                      

1. Specifications: we need to decide that why we are buying an IT Item and what is the expected delivery out of it. While preparing the technical specs it becomes important to note that the same item if purchased for a Project Procurement will demand separate attention if procured for a maintenance spare. Technical specs can be made independent of the vendor document /presentation. Many of us make mistake of calling vendors and take their opinions before this phase and we justify it saying that we are doing research on product. But what we forget that this is the time when vendors embed the ideas of their product with features which are not at all relevant for my business. Therefore, before if we call a vendor we must write a piece of paper of what we need discuss with end users and get their sign on. This saves the IT manager from harassment in days to come.

 

2. Selection of solution: It is a common habit that we haste in selecting a solution and many times start with a preconceived notion of solution before designing the problem statement. this way we lose opportunity of exploring many other options and may get biased by our thoughts. Hence, solutions need to be designed keeping in mind the specific business we are in and also the environment we are in. Which means the solutions suitable for company A may not be suitable at all for Company B although both are in same business. Some amount of brain storming with user community on the solution document may be a good idea although the onus on final solution document must be with IT Management and also accountability of success of the same.

 

3. Selection of Product: None of the products are bad or inferior and they are only need to be evaluated based on the solution we have in mind and while choosing the same we need not think of cost/price. the product should be self sufficient easy to install, ease of servicing and most important reliable. many a cases we go by Brand and the big organization bombard with name of national and international customer but the same may be meaningless. Many years back I remember dealing with different ERP vendors for designing a ERP solution of a SME business in Sri Lanka. It took close to a year for me in selecting the solution and product and the brands were not of the best in market but best suitable for the organization I was servicing.

 

4. Accessibility of senior management of the partner organization: a very meaningful point if we are dealing with a system where software development also involved or customization of the standard systems needed. as in many cases the sales team will be invisible post sale and service team would think you as a customer no. A reliable Senior management and accessibility to them becomes handy.

 

5. evaluation of quote: It is a best practice to look at the price only when we have finished the technical comparison and decided the T1, T2, T3, etc. as that gives an independent view. But in practical situation this kind of option is not available as we go with a brand and may be we can have one or only two quotes. We have a tendency to depend on the name of the brand. But in my opinion under such case it is worth cross checking with customers of the product anonymously. when we finally go for tabulation of bids we need to consider many other factors other than the price quoted by vendor. For example, an unbranded computer with limited service centre may cost less but the risk involved are much higher and must be accounted for. several questions to be asked to vendors to find out what are the hidden costs and probable future expenses, also need to ascertain a value towards the risk of failures. I think if we use a 10-point scale for every parameter in addition to cost then it becomes a better comparison.

 

6. price negotiation: Care needs to be taken that neither of the party lose. and it is a win win for both as a contract is not end of journey but a starting point. The conventional procurement team who are also entrusted to finalize the IT deal may go for a killing but that is harmful for the IT Management in long run and must be avoided. While negotiating if one party drops price to a great extent better to reject the option. negotiation of IT equipment is an art as the customer company has little knowledge of the profit margin and the components where supplier is making profit. I have seen many cases where we have closed a deal at much less than my budgeted figure only to discover later that the supplier has cut the corner and project has suffered. also during negotiation it is important to spend a considerable pause between each revised quote and check back with all concerns that probable loopholes.

 

7. IRR of a IT Project: Many a times it is a vague area and we simply say that for a IT project the IRR or ROI is not needed to ascertain. but in my opinion all attempts need to be made to ascertain a figure. While there is a myth in organization that all IT projects are meant for manpower reduction and trying to find IRR from that angle creates disaster. Instead IRR can include ease of working condition, reduction of wastage and enhancing productivity. many a IT investment are from compliance and statutory angle must and IRR can still be made from that consideration.

 

8. Closing a deal: The deal must be closed with participation of end user function as we normally deploy IT for them. Ideally if end users are involved in procurement the chances of acceptance of the project or equipment is better. Vendors want to push the deal in their financial year end and may give a good discount but if the solution /product is not acceptable to IT function and End User function it is meaningless to close a deal at a time when cost is less.

 

9. Post procurement action: Normally there must be a review meeting with IT management, end user management and procurement team after 6 months of procurement to ascertain if the intended use has happened and if not what lesson organization can learn. Such meetings may also happen in presence of vendor to provide him a feedback.

 

10. Handling failure of procurement: Although it is sad but IT Projects fail and when they fail we do not look at the procurement process. We need to look at the process also and find out what mistakes we have done during this process. The vendor's senior management needs to be involved and must be taken into confidence how the system product can be reprocessed/reused so that the project can be brought in line. Fighting cases with vendor although is a technical option but does not benefit anyone.


(This blog was originally published on LinkedIn and has been reposted here with prior permission from the author.) 


(Image Courtesy: Pixabay.com)

Categories: Management

About Author

Orange Themes

Suman Basu

Suman Basu is President IT and CIO at Viraj Profiles....

Read more

Write a Comment

Your e-mail address will not be published.
Required fields are marked*

*

Recent Comments