Network Tender Management: Where Most Infrastructure Projects Go Wrong

Where projects fail before they start

The network infrastructure project that comes in over budget, under-delivered, and six months late almost always has its roots in the same place: the specification document that was written in week one. Not the vendor who won the tender. Not the project manager who struggled to control variations. Not the procurement team that signed off a contract. The specification.

Under-specified tenders hand too much interpretive latitude to vendors. When a specification says “supply and install enterprise networking equipment” without defining throughput, latency, coverage density, protocol support, or SLA obligations, each vendor fills the gap in their own favour. The cheapest bidder fills it most aggressively. The organisation that issued the tender gets a network designed to win a price comparison, not to serve an operational requirement. The gaps — and there will always be gaps in an under-specified tender — become variation requests after contract award, each one adding cost and schedule.

Over-specified tenders create a different problem. When a specification is written to a level of detail that effectively prescribes a specific product — a pattern discussed more fully in Section 3 — the organisation has locked in a solution before the problem is properly understood. If the spec was written three years ago for a different context and copy-pasted into the current project, the locked-in solution may have nothing to do with the current operational requirement.

In Malaysia, both failure modes are endemic. Government procurements conducted through e-Perolehan, using the standard MOF-registered vendor framework, routinely feature specifications copied from previous projects or lifted from vendor white papers. The people writing them are often procurement officers with limited network engineering background, working under deadline pressure, who reach for the nearest available template. The result is a specification that describes a network from three years ago for a site that has different requirements today. Private sector tenders have their own version of the same problem: the specification is frequently written after the vendor has already been chosen informally, and the document is crafted to match the preferred vendor’s product catalogue rather than the client’s operational needs. The tender then “opens to competition” in a process that is competitive in name only.

In both cases — the copied government spec and the vendor-written private spec — the downstream consequences are the same. A project that costs more than it should, delivers capabilities that were not actually needed while missing capabilities that were, and arrives late because the variation process that was inevitable from the beginning takes time to negotiate and price.

Figure 1. A pattern seen repeatedly in Malaysian network infrastructure procurement. The project does not fail at commissioning — it fails at the specification stage. Every subsequent problem is downstream of that initial error.

Why scoring on price produces the wrong winner

The second systematic failure in Malaysian network tender management happens at evaluation. Price weighting of 60–70% is common in government procurement — it is built into the Ministry of Finance’s standard scoring frameworks, and many private sector organisations have adopted similar approaches on the assumption that it is the “safe” way to evaluate. It is not. For network infrastructure specifically, heavy price weighting almost always produces the wrong outcome.

The vendor who wins on price in a network tender has typically done one or more of the following: misunderstood the scope and priced against a narrower interpretation of the requirement; built the contract on the assumption that variations will deliver the margin that the headline price does not; underspecified the hardware, substituting lower-grade components that meet the letter of a poorly written specification while missing the intent; or planned to under-resource the delivery team and rely on the client’s internal team to fill the gaps. None of these represent a genuine cost saving for the procuring organisation. They represent a transfer of cost from the headline contract price to the variation budget, the operating cost, or the replacement cycle.

The reason price weighting dominates Malaysian government procurement is straightforward: it is easy to audit. A price score is objective and defensible. A technical score requires evaluators who understand what they are evaluating, and technical expertise is not uniformly distributed across procurement committees. The answer to this problem is not to abandon technical evaluation — it is to ensure that technical evaluation is done by people who can do it, and that the scoring framework reflects the actual cost structure of network infrastructure.

The correct weighting for network infrastructure procurement is not a matter of opinion. It follows from the cost structure of the asset class. Network infrastructure is a long-lived asset with significant operating cost and support cost over its lifetime. The total cost of ownership — hardware, software licensing, support contracts, power, maintenance, and eventual replacement — over a five-year period will typically be two to three times the initial capital expenditure. An evaluation framework that weights initial price at 70% and ignores TCO is systematically selecting vendors whose hardware depreciates faster, whose support contracts cost more, and whose replacement cycles are shorter.

Figure 2. A 70% price weighting selects for the cheapest day-one bid, not the best outcome over the asset lifetime. Network infrastructure — with 5–7 year hardware refresh cycles and ongoing support costs — demands a TCO-led evaluation.

The recommended weighting for network infrastructure procurement is: technical solution quality 40%, commercial terms including total cost of ownership 30%, vendor capability and track record 20%, and support and SLA structure 10%. This framework is not radical — it is the standard approach recommended by independent network engineering bodies and used by mature procurement organisations worldwide. The reason it is not the standard approach in Malaysia is institutional inertia and the absence of technical expertise on evaluation panels, not any principled argument for price-first evaluation.

A note on TCO in the Malaysian context: network hardware from tier-one vendors — Cisco, Juniper, Aruba, Huawei — typically carries a five to seven year enterprise support cycle, after which hardware enters end-of-life and software support ends. Hardware sourced from grey-market channels or from second-tier vendors without Malaysian after-sales infrastructure frequently falls outside this support envelope. The CAPEX saving at tender stage is often recovered, and then some, in the cost of out-of-warranty support, software licensing complications, and early hardware replacement. An evaluation framework that captures five-year support and licensing costs as part of the commercial evaluation catches this problem. A framework that only looks at the initial price does not.

Recognising the spec that was written by a vendor

There is a specific pattern in Malaysian network procurement that experienced vendors recognise immediately and that procuring organisations often do not: the specification that was written by the preferred vendor, or by a consultant with a relationship to that vendor, to precisely match their product range. The tell-tale signs are consistent. Model numbers appear where performance specifications should be. Proprietary protocol names are specified where open standards would serve equally well. Performance thresholds are stated at precisely the levels that tier the market to include one product and exclude its closest competitors. The word “or equivalent” may appear, but the combination of requirements is designed to ensure that no equivalent exists.

This is not a hypothetical. It is a documented pattern in procurement markets across the world, and Malaysia is not an exception. It occurs in both government and private sector procurement, though the incentive structures differ. In government procurement, it often arises because the specification author has a personal relationship with a vendor’s sales team, or because a vendor has offered “free” specification writing as part of a pre-sales engagement. In the private sector, it occurs because the IT department already has a vendor preference — often legitimate, based on existing infrastructure — and the tender is a formality required by governance rather than a genuine exercise in market testing.

The antidote for independent organisations procuring network infrastructure is straightforward, if underused: specify outcomes, not products. A specification written in terms of outcomes describes what the network must achieve — throughput, latency, coverage, uptime, security standards, protocol support — without prescribing how those outcomes must be achieved. It creates a genuinely competitive environment in which multiple vendors and hardware platforms can respond, and it ensures that the evaluation is focused on whether the proposed solution will deliver the required performance rather than whether it matches a specific brand’s feature list.

Figure 3. The difference between a product specification and an outcome specification. The left column locks in a vendor before evaluation begins. The right column creates genuine competition while protecting the procuring organisation’s technical requirements.

The practical difference between a product specification and an outcome specification can be illustrated simply. A bad specification reads: “Supply and install Cisco Catalyst 9300 48-port switches.” A good specification reads: “Supply and install 48-port access layer switches supporting 802.1x authentication, LACP bonding, minimum 10GbE uplinks, with a minimum five-year vendor hardware support commitment.” The second specification permits Cisco, Juniper, Aruba, Huawei, and any other vendor capable of meeting those standards to respond competitively. The procuring organisation gets genuine market pricing for an outcome, not a monopoly price for a specific SKU.

The same principle applies to every layer of the network stack. Wireless access points should be specified in terms of minimum RSSI levels, client density capacity, protocol standards (Wi-Fi 6 / 802.11ax), and security requirements (WPA3, 802.1x), not in terms of specific models. Firewalls should be specified in terms of throughput at specified inspection levels, concurrent session capacity, IPS performance, and SSL inspection capability, not in terms of vendor brand. Management platforms should be specified in terms of capabilities — SNMP support, syslog forwarding, REST API availability, role-based access control — not in terms of specific products. The underlying principle is consistent: the specification should describe the network you need to operate, and leave the selection of the technology that delivers it to a competitive evaluation process.

e-Perolehan, GLCs, and Bumiputera requirements — what actually applies

Network infrastructure procurement in Malaysia does not happen in a neutral environment. It happens within a framework of procurement regulations, vendor panel requirements, and policy objectives that are specific to the Malaysian context. Understanding which framework applies to your procurement — and how to write specifications that attract quality vendors within those constraints — is as important as any technical specification detail.

The e-Perolehan system, administered by the Ministry of Finance, is the mandatory electronic procurement platform for all federal government agencies and most state government bodies. Only vendors registered with the MOF under the relevant category codes can bid on government contracts above the direct purchase threshold. This registration requirement serves a legitimate compliance function — it confirms that bidding vendors are financially solvent, tax-compliant, and appropriately categorised — but it also artificially restricts the competitive field. MOF panel registration takes time and is not universally pursued by all technically capable vendors, particularly smaller specialist firms. Procuring organisations that issue specifications requiring specific MOF code registrations — particularly when those codes are narrowly defined — may inadvertently exclude vendors who have precisely the technical capability the project requires.

Government-linked companies — Petronas, Tenaga Nasional, Celcom Axiata, PLUS Berhad, and others — operate their own procurement frameworks that are separate from e-Perolehan but no less structured. Petronas has its Vendor Registration System and the Petronas Technical Standards that govern technical specifications on their projects. Tenaga operates its own approved vendor list for telecommunications and IT infrastructure. Each GLC has its own variation on the theme, and organisations supplying into these environments need to understand which framework applies before designing their tender process.

The Bumiputera participation requirement adds another layer. The Skim Vendor Pembangunan Nasional (SVPN) framework and various sector-specific policies typically require a minimum percentage of Bumiputera participation — often structured as a 30% sub-contracting requirement to Bumiputera vendors — in government contracts above certain thresholds. This is a policy objective with legitimate developmental rationale, and it is not going away. The practical question for organisations writing network infrastructure tenders is how to structure the requirement so that it does not compromise technical quality. The answer is to be specific about what must be delivered by the prime contractor and what can be delivered through sub-contracting arrangements. Site preparation, cable laying, civil works, and logistics are areas where Bumiputera participation can be structured without compromising the technical quality of the core network equipment supply and configuration, which should remain with the technically evaluated prime vendor. Poorly structured tenders that require Bumiputera participation in technical delivery — without specifying minimum qualification standards for the participating sub-contractors — risk introducing unqualified parties into technically sensitive commissioning activities.

One further timing consideration specific to Malaysia: if the network project involves any radio spectrum — Point-to-Point microwave backhaul, TETRA/TETRAPOL radio, LTE private networks, or any other form of licensed wireless — the MCMC spectrum assignment process must be factored into the project timeline from the outset. The standard MCMC processing window for a spectrum application is three to four months for straightforward cases and longer for frequency coordination requirements or novel applications. Project managers who do not build this into the baseline schedule from day one will find themselves with installed hardware sitting idle waiting for a licence, with the client asking why the project is running late. It is a foreseeable delay that has no excuse for being a surprise.

Similarly, import lead times for enterprise networking hardware from major US and European vendors should be factored in at tender stage. Hardware from Cisco, Juniper, Aruba, Ericsson, and Nokia typically carries lead times of 8–14 weeks from order to delivery for non-stocked items, reflecting both manufacturing lead times and the logistics of shipping enterprise hardware to Malaysia. Tenders that specify a commissioning date without factoring in procurement and delivery lead times — and without requiring vendors to confirm stock availability or lead time commitments as part of their bid — will produce delivery timelines that look credible on paper and prove impossible in practice.

The elements of a well-managed network tender

Good tender management for network infrastructure is not complicated. It requires discipline, the right expertise at the right stages, and a willingness to invest time at the front of the process — in the specification stage — that pays back in reduced variation cost and faster delivery at the back. The following elements are not aspirational standards. They are the minimum requirements for a network tender that produces a reliable outcome.

Independent specification

The person or team writing the technical specification should have no commercial relationship, current or historical, with any of the vendors who will bid on the tender. This seems obvious. It is frequently violated, most often through the “vendor engagement” that precedes tender issuance — where a vendor is invited to help define requirements and naturally does so in a way that advantages their own product range. An independent specification author — whether an internal network engineer with no vendor relationships or an independent consultant engaged specifically for specification writing without any downstream implementation role — is the structural solution. Where internal expertise does not exist, engaging an independent technical advisor whose engagement contract explicitly excludes any role in the subsequent supply or delivery is the correct approach.

Pre-bid site visits

Mandatory pre-bid site visits serve two functions. They ensure that bidding vendors understand the physical environment of the deployment — the building types, existing infrastructure, cable routes, access constraints — before they price their bids, which reduces the scope for “we couldn’t have known about that” variation claims after award. They also create a level playing field: all bidders see the same site at the same time, under the same conditions. A site visit that is open only to invited vendors — or that is timed or structured in a way that advantages a vendor who has already visited privately — undermines the competitive process before evaluation begins.

Structured Q&A

Questions from bidders should be submitted in writing, within a defined window, and answered in writing, with the answers distributed to all bidders simultaneously. This is standard in well-managed tender processes and routinely violated in practice, where informal phone calls and bilateral conversations between procurement officers and preferred vendors pass information unevenly. The structured Q&A is not bureaucratic excess — it is the mechanism that ensures all bidders compete on the same information, and it creates an auditable record of every clarification provided during the tender period.

Technical evaluation by people who understand networks

This point cannot be overstated. Technical scores awarded by procurement officers who cannot distinguish a layer 2 switch from a layer 3 router, or who cannot evaluate a radio frequency link budget, are not technical scores. They are checkbox scores, and they reproduce the same failure mode as price-only evaluation — the evaluation is being done by a process rather than by judgment. The solution is to include at least one qualified network engineer on every technical evaluation panel. Where internal capability does not exist, an independent technical evaluator engaged specifically for the evaluation phase — again, with no relationship to any bidder — performs this role. Reference site visits for shortlisted vendors are a closely related practice: sending the technical evaluator to a site where the vendor has previously delivered a similar project, to speak with the client’s technical team, tells you things that no bid document can.

A clear variation framework

Network infrastructure projects generate variations. The question is not whether they will occur, but whether the contract framework provides a clear, pre-agreed mechanism for pricing and approving them. A well-drafted variation clause specifies the process for variation requests, the timeframe for pricing and approval, the basis of pricing (typically rates agreed at contract award for defined labour categories and a priced BOM for additional hardware), and the governance threshold above which variation approval escalates beyond the project manager. Contracts that lack this framework turn every variation into a commercial negotiation in which the contractor has significantly more leverage than the client — because the work has already started and the cost of switching vendors mid-project is prohibitive.

10 things to get right before issuing a network tender in Malaysia

The following checklist is not comprehensive, but it addresses the ten failure points that most consistently produce poor outcomes in Malaysian network infrastructure procurement. If you can answer yes to all ten before issuing your tender document, you are better positioned than the majority of organisations that have issued similar tenders in the last three years.

1. 1
   Specification written by someone with no vendor relationship Confirm that the person who wrote or reviewed the technical specification has no current or historical commercial relationship with any vendor likely to bid. This includes consultants who also act as resellers.
2. 2
   Outcomes specified, not products Remove all brand names and model numbers from the specification. Replace with performance standards, protocol requirements, and capacity benchmarks. If “or equivalent” appears anywhere in the document, remove the product name it qualifies.
3. 3
   Evaluation weighting reflects TCO, not CAPEX alone Confirm that price is weighted no more than 30% of the commercial evaluation, and that the commercial evaluation includes five-year support costs, software licensing, and hardware refresh provisions — not just the initial supply price.
4. 4
   At least one qualified network engineer on the evaluation panel Identify the person by name before the tender is issued. If no suitable internal resource exists, engage an independent technical evaluator under a conflict-of-interest declaration that excludes any supply or implementation role.
5. 5
   Pre-bid site visit scheduled and mandatory Set the date in the tender document. Make attendance a condition of bid submission. Ensure the visit is open to all registered bidders at the same time, with the same information provided to all.
6. 6
   Written Q&A process with responses shared to all bidders Define the submission deadline for questions and the response date in the tender document. Commit in writing that no bilateral oral clarifications will be provided. Issue all Q&A responses as a formal addendum distributed to all bidders.
7. 7
   Hardware lead times factored into the commissioning date For enterprise networking hardware from US/EU vendors, add 8–14 weeks from order to delivery. Require bidders to confirm stock availability or delivery lead time commitments as part of their bid. Do not commit to a go-live date that cannot accommodate this lead time.
8. 8
   MCMC licensing timeline in the project schedule if spectrum is involved If any element of the project requires MCMC spectrum assignment — microwave backhaul, private LTE, TETRA — add minimum 3–4 months to the baseline schedule for spectrum approval. Initiate the application at contract award, not at commissioning stage.
9. 9
   Variation and change order framework defined in the contract Before contract award, confirm that the contract includes a variation mechanism with pre-agreed labour rates, a priced BOM schedule, defined approval authority thresholds, and a maximum timescale for variation pricing and approval.
10. 10
    Acceptance testing criteria defined before work starts The definition of “done” — the acceptance test criteria against which the vendor’s delivery will be measured — should be agreed and documented before the contract is signed, not negotiated after commissioning. Acceptance criteria should be measurable, objective, and aligned with the performance specifications in the original tender.

Network infrastructure procurement is not a process that rewards shortcuts. The organisations in Malaysia that consistently procure network infrastructure well — that get what they specified, delivered on time, at a price that reflects genuine market competition — are organisations that have invested in getting the fundamentals right at the front of the process. They have independent specifications. They have structured evaluation frameworks that capture the real cost of ownership. They have technical expertise on evaluation panels. And they have contracts that define, precisely, what done looks like before a single cable is pulled.

If any of the ten items above represent gaps in your current process, the time to address them is before the next tender is issued, not after the current one has generated its first scope variation. Aminia’s team has direct experience on both sides of Malaysian network infrastructure tenders — as the integrator winning and delivering them, and as the independent advisor helping clients write better ones. If you are preparing a network infrastructure tender and want an independent technical review of your specification before it is issued, we are available to assist.