When you observe the software and IT solutions market in our country, an odd phenomenon catches the eye. We are constantly obsessed with the competence of software companies, the quality of their code, or whether a vendor managed to deliver on time. Yet, no one asks the crucial question behind the scenes: How prepared is the buying organisation to properly procure or select this technology?
Having sat on the other side of this table for many years, I have realised that buying technology is no ordinary purchase. It is not merely a matter of signing an administrative file or having a budget in your pocket. Procuring technology products and services is an art, deeply technical and highly strategic. Possessing the budget does not automatically mean you possess the capability to recognize the right technology. The true skill lies in diagnosing your internal business problems flawlessly and choosing the exact, appropriate solution required.
Table of Contents
Financial Muscle vs Strategic Competence
There is a major mindset flaw in our country: whoever holds the purse strings assumes they understand technology well. Having ample funds offers no guarantee that you will purchase the right system. If you do not understand technology procurement methodologies, you will not only overpay, but you could also end up stuck with the wrong product. Therefore, the skill to buy technology is just as vital as having the capital.
You cannot bluntly tell a corporate client, “You need to understand your own processes before buying technology.” This is precisely where the rift between the buyer and the vendor begins. Consequently, business goals and project requirements are never accurately defined. Once the work starts, the buyer continually changes the requirements. When the vendor tries to explain the logical boundaries or technical limitations of these changes, the buyer interprets it as reluctance or incompetence. Ultimately, both the project timeline and budget spiral out of control, and the project fails.
Core Functionality vs Aesthetic Veneer
Another major hurdle is the buyers’ fixation on the user interface over the software’s core functionality. There is far less interest in how well the software simplifies core business processes at the back-end, how flawlessly it manages data, or how much it accelerates decision-making. Instead of dedicating time and attention to the system’s core functions, performance, and security, hours are wasted debating screen colours, layouts, or the beauty of a dashboard interface. I am not suggesting that the interface is unimportant; I am saying that buyers must allocate exactly the right amount of time to it—no more, no less.
What Technical Skills Does a Buyer Actually Need?
Nowadays, buying technology does not mean just purchasing software. It directly involves infrastructure like servers, storage, backup systems, routers, and networking devices like radio links, alongside data centres. Therefore, decision-makers must possess specific technical and strategic insights:
1. Understanding IT Master Plans and Architecture
Software or servers should never be bought in isolation. An organisation must operate under an overarching 3-to-5-year IT Master Plan. There must be foresight regarding how a new solution will integrate with other systems a few years down the line. To grasp this, one should look into the basic guidelines of enterprise architecture frameworks (such as TOGAF) and analyse case studies of how peer organisations map out their IT roadmaps.
2. Differentiating ‘Best Technology’ from ‘Appropriate Technology’
The most expensive or latest technology on the market is not necessarily the best fit for your company. An organisation must have the maturity to choose the “Appropriate Technology” that aligns with its actual business needs. Look beyond vendors’ marketing materials and consult third-party IT consultants or experienced CIOs. Reading unbiased reviews and comparative analyses makes it possible to save the budget while selecting the perfect tool.
3. Physical Scalability and Capacity Planning
Due to poor planning, many organisations make a classic mistake: they fill up their server rooms with piecemeal, small-scale storage drives and servers. While this might suffice for the first year or two, the entire infrastructure becomes bottlenecked as data and users grow. Patching new devices together no longer yields performance. Eventually, they are forced to scrap their entire initial investment and buy everything from scratch.
To avoid this loss, buyers must understand capacity planning. There must be a realistic estimate of how much the data volume will grow over the next five years and how many users will hit the system during peak hours. Keeping that growth in mind, scalable servers and centralised storage (SAN/NAS) must be planned from day one, allowing storage or processing power to be upgraded easily without taking the system down.
4. Calculating Total Cost of Ownership (TCO) and ROI
When purchasing technology, buyers frequently make the mistake of looking only at the initial price tag of the software or hardware. However, the true cost of a project is never limited to the purchase price. It involves data centre cooling, power backups (online UPS or generators), licensing fees, and the vendor’s Annual Maintenance Contract (AMC). Buyers must be skilled at calculating the Total Cost of Ownership (TCO) over a 5 or 10-year period. Only then can they demonstrate the expected Return on Investment (ROI) to the management or CFO.
To refine this calculation, one must understand the relationship between Capital Expenditure (CapEx) and Operational Expenditure (OpEx). If there is a mismatch between the one-off cost of acquiring technology and the running cost of sustaining it year after year, the project will face a budget deficit midway. Practising cost-benefit analysis spreadsheets or Excel models for IT projects quickly clarifies the business logic behind TCO and ROI.
5. Comprehensive Procurement Requirements (Hardware and Network)
When drafting software requirement papers, many people overlook hardware and networking or leave them entirely up to the vendor. However, the procurement document must explicitly state hardware specifications—such as processor cores, RAM types, RAID configurations, and bandwidth capacity. If the buying team does not understand these technicalities, they are bound for trouble. Vendors often slip through with under-configured or outdated hardware. It goes unnoticed initially due to low user traffic, but the entire system crawls once the software goes live into production with full data loads.
To avoid being short-changed, buyers should get into the habit of reviewing technical white papers and product specification sheets from global hardware vendors like Intel, Cisco, or HP. Knowing the basics—how processor cores map, how RAID technology protects data, or how network throughput is calculated—equips you to vet procurement requirements. Consequently, vendors will not be able to push under-powered or incompatible hardware onto you.
6. Comprehending BRDs and SRSs
Buyers must possess the basic capability to document business needs into a clear Business Requirement Document (BRD) and technical details into a Software Requirement Specification (SRS). Without a grasp of these documents, you can never truly convey your needs to a vendor. The vendor will simply define the scope of work their own way, which will ultimately misalign with your business.
To bridge this gap, look into the fundamentals of Requirement Elicitation in software engineering and the basic rules of technical writing. Studying standard BRD and SRS templates available online or from experienced IT professionals makes mastering this language and format straightforward. This ensures you maintain control during vendor meetings and project scoping.
7. Concepts of RFP and SLA
One must have a crystal-clear idea of how to draft a professional Request for Proposal (RFP) and a Service Level Agreement (SLA) as a contract. This agreement must explicitly define parameters for both hardware and software, including downtime limits, parts replacement warranties, bug-fixing timelines, and escalation matrices. If these legal boundaries are left undefined, the vendor will likely become unreachable for support or maintenance once the project is delivered.
This requires some familiarity with IT legal compliance and procurement standards. Looking at international standards—such as how IT governance frameworks like COBIT define service levels and Key Performance Indicators (KPIs)—reveals the actual strategy behind drafting these contracts. This leaves no loopholes for vendors to escape their obligations.
8. Data Backup and Disaster Recovery (DR) Plan
The greatest threat to an on-premises system is data loss. The buyer must know how to design an effective backup policy and how to recover the system if the primary data centre fails. Without this knowledge, a major server crash or cyberattack could wipe out the entire company’s data overnight.
Hence, a foundational understanding of Business Continuity Planning (BCP) and Disaster Recovery is essential. Specifically, concepts like Recovery Time Objective (RTO)—how fast the system can be brought back live after going down—and Recovery Point Objective (RPO)—how much data can be successfully restored from backups—must be crystal clear. Reviewing data loss case studies and backup strategy guidelines makes understanding these recovery frameworks simple.
9. Security and Access Control
Buyers must be able to verify firewall configurations, data encryption, and Role-Based Access Control (RBAC)—which determines who has permission to view or edit specific data within a local network. Without these security checks, internal data leaks or malware attacks are only a matter of time.
This calls for a basic understanding of information security management standards, such as ISO 27001. Reading articles on network security fundamentals and Privileged Access Management (PAM) helps demystify the core philosophy of data protection. This ensures that a vendor cannot hand over a project riddled with security vulnerabilities.
10. Managing UAT
A project is not finished simply because a vendor delivers the software or hardware. The buyer must know how to execute stress testing and User Acceptance Testing (UAT) based on specific Test Cases. This is a critical skill required to evaluate the system’s capacity to handle a real-world load before going live. Neglecting this step often results in the entire system crashing under minimal user traffic post-launch.
Familiarity with the basic guidelines of Software Quality Assurance (SQA) and testing methodologies is highly beneficial. Learning how to write test scenarios and distinguishing between functional and non-functional testing can be easily mastered by studying actual test reports from past projects. Even if a vendor rushes to close the project, the buyer can confidently sign off only when completely satisfied.
Who Actually Bears the Loss?
In these scenarios, software vendors do take a hit, but the heaviest blow is dealt to the buying enterprise. An IT solution or software is not a ready-made, physical commodity that can be repurposed if it fails in one area. If a custom software ultimately fails to serve the business, the entire investment is effectively flushed down the drain.
The damage here extends far beyond financial metrics. A stalled or failed project wastes invaluable time and shatters the morale of the internal team. Crucially, it destroys the organisation’s trust in adopting any new technology in the future. A vendor merely loses one client or project; the buying company falls several years behind its competitors in the digital race.
The Path to a Solution
Before acquiring technology, one must understand the fundamental framework of procurement. Decision-makers in management should invest time in learning these basic concepts. If necessary, they should undertake short-term training or seek guidance from independent, third-party IT consultants. Spending a fraction of time and money upfront can easily avert catastrophic financial losses later.
This issue is even more critical at the government or corporate level, where public or shareholders’ money is at stake. Therefore, officials involved in technology procurement or project approvals must undergo structured training in Technology Acquisition and Project Management. Purchasing technology is not a mundane administrative task of moving files; it is a long-term strategic decision for the entire organisation.
Lessons from History
Developed nations, particularly the United States, learned this lesson the hard way through widespread IT project failures during the 1980s and 1990s. Poor requirements, flawed vendor selection, and inadequate change management caused millions of dollars’ worth of projects to collapse. They subsequently overcame this crisis by establishing robust IT governance frameworks and stringent procurement standards.
That history lies open before us. There is no rule stating we must learn every lesson through our own losses and blunders. There is absolutely no sense in constantly reinventing the wheel.
To strengthen our local software industry, upskilling developers is only half the battle; buyers must become equally mature technically. Buying technology without procurement or technology acquisition skills is tantamount to throwing money blindly into the dark. If we genuinely desire a sustainable digital transformation, we must place equal emphasis on both our procurement culture and the competence of the buyer.
See more: