Africa’s infrastructure financing gap—estimated at $50–90 billion annually in 2025—represents a critical barrier to sustainable growth, costing the continent up to 2% of GDP each year and perpetuating challenges like energy poverty and low productivity. Cumulative shortfalls could reach $1.6 trillion by 2030 without intervention.

Closing this gap could boost GDP by $180–300 billion annually, drive poverty reduction, and create millions of jobs, particularly through initiatives like the African Continental Free Trade Area (AfCFTA).

Public procurement, accounting for 17% of Africa’s GDP (approximately $527 billion annually), is a linchpin for infrastructure delivery but is hindered by inefficiencies, corruption, and fragmentation. EdgeworthBox, an advanced e-procurement platform, addresses these pain points by breaking silos, enabling collaborative discussions, hosting adaptable contracts, and ensuring total transparency—now enhanced with AI consultation for intelligent needs definition, real-time collaborative RFP design, smart execution automation, data-driven analysis, intuitive user experiences, complete audit trails, AI-accelerated RFP processes, enhanced supplier discovery, and outcome-based pricing. Widespread adoption could yield $69–195 billion in annual benefits through cost savings, fraud recovery, efficiency gains, and mobilized private funding—directly contributing to gap closure and economic transformation.

This whitepaper outlines the scale of the challenge, the barriers (with a focus on procurement failures), and how EdgeworthBox can catalyze change, supported by data from leading institutions like the African Development Bank (AfDB), OECD, and McKinsey.

2 Mind the Annual Gap

The infrastructure gap in Africa refers to the annual shortfall in funding required to develop and maintain essential physical and digital assets, such as energy, transport, water, and telecommunications, which are critical for economic growth, trade, and quality of life.

According to multiple authoritative sources, including the African Development Bank (AfDB) and the African Union Development Agency (AUDA-NEPAD), Africa’s total annual infrastructure needs range from $130 billion to $170 billion [20][21][22]. Current investments average around $80 billion per year, resulting in an annual financing gap of $50–90 billion [70][71][74]. This gap reduces the continent’s GDP growth by approximately 2% annually and exacerbates issues like energy poverty (affecting nearly 600 million people without grid electricity) and low productivity [7].

Recent 2025 reports, such as those from the Africa-Europe Foundation and AUDA-NEPAD, reaffirm the $130–170 billion annual need, with the gap persisting due to factors like poor project preparation (80% of projects fail at feasibility), limited private sector involvement, and insufficient domestic resource mobilization [5][6]. The AfDB’s updated estimates highlight a slightly narrower gap of $70–90 billion, emphasizing the need for innovative financing like Public-Private Partnerships (PPPs) and blended funds to unlock up to $2 trillion in domestic capital [23]. Older estimates, such as McKinsey’s 2016 projection of $150 billion needed by 2025 to reach 4.5% of GDP in infrastructure spending, have largely been superseded by these figures but underscore the long-standing nature of the challenge.

Closing this gap could add up to $180 billion to Africa’s GDP by enhancing connectivity and industrial capacity, particularly under initiatives like the AfCFTA and the Programme for Infrastructure Development in Africa (PIDA), which has 69 priority projects costing $160.8 billion overall [18][19].

3 Mind the Overall Gap

Based on reports from the African Development Bank (AfDB), OECD, and others, the cumulative infrastructure financing gap for Africa—i.e., the additional funding needed beyond current investments to close disparities and meet needs—is estimated in the range of $800 billion to $1.6 trillion over the 2021–2030 period (roughly 10 years, with ~5 years remaining from the current date). This cumulative figure is derived from annual gaps projected to grow from the current $50–$90 billion in 2025 to $80–$160 billion by 2030, reflecting rising needs due to population growth (projected to reach 2.5 billion by 2050) and urbanization.

4 Benefits of Closing Africa’s Infrastructure Gap

Closing Africa’s infrastructure gap would yield substantial economic, social, and productivity gains, primarily by enhancing connectivity, reducing costs, and enabling initiatives like the AfCFTA. The $180–$300 billion in annual GDP gains referenced earlier draws from sector-specific projections, such as digital infrastructure (up to $300 billion in internet-related GDP contribution by 2025) and AfCFTA trade facilitation (contributing $292 billion cumulatively toward a total $450 billion income boost by 2035, or roughly $30–$40 billion annualized) [10][11][12]. Broader estimates from the African Development Bank and World Bank focus on a consistent 2 percentage point increase in annual GDP growth, equating to approximately $60–$70 billion per year based on Africa’s ~$3.1 trillion GDP in 2025 [7].

These benefits compound over time: for instance, AfDB projections suggest sustained investments could raise infrastructure spending to 4.5% of GDP, unlocking $2.5 trillion in project pipelines by 2025.

5 Consequences if Status Quo Persists

Maintaining the current financing levels (~$80 billion annually vs. $130–$170 billion needed) perpetuates a vicious cycle of underdevelopment, shaving off economic potential and exacerbating inequalities. The AfDB estimates this status quo already costs Africa 2% in annual GDP growth, while broader impacts include stalled industrialization and persistent service deficits. Key stats illustrating the ongoing toll:

If unaddressed, the gap could widen to $100+ billion annually by 2030 due to population growth (to 2.5 billion by 2050) and climate costs ($10–$20 billion extra/year), further entrenching a $1.6 trillion cumulative shortfall by decade’s end and reducing poverty alleviation by 25%. Initiatives like the AfDB’s $50 billion lending pipeline offer hope, but without scaling private investment, these drags will compound.

6 What’s Getting in the Way?

Africa’s infrastructure financing gap, estimated at $50–$90 billion annually, persists due to a combination of structural, institutional, and economic barriers. Based on recent analyses (as of 2025), the primary obstacles revolve around financing constraints, project preparation deficiencies, and enabling environment issues. These factors create a “paradox” where demand for investment is high, but supply-side hurdles prevent scaling. Below is a ranked overview of the top factors, drawn from reports by the African Development Bank, McKinsey, OECD, and others, with approximate contributions to the gap where quantified:

These factors are interconnected—e.g., poor preparation amplifies financing risks—and if unaddressed, could push the cumulative gap to $1.6 trillion by 2030.

6.1 The Role of Procurement Failure

Procurement failures play a significant but not dominant role, contributing an estimated 20–30% to overall project failures and exacerbating the broader gap by inflating costs and delaying timelines—particularly through inefficiencies like non-competitive bidding and compliance errors, which account for 30–50% of delays and ~$5–$10 billion in annual wastage continent-wide.¹ They are most acute in the early stages (feasibility and tendering), where they intersect with governance issues like corruption and poor strategic planning, with corruption alone causing ~20% of failures (e.g., misallocated funds and wrong-site builds) and 25% of public procurement system breakdowns attributed to weak anti-corruption commitment.

Credible data pegs procurement-related issues as a key driver of the documented 80–90% early-stage failure rate, but not the sole cause—design errors, funding shortfalls, and leadership gaps share the blame. Procurement is a “gatekeeper” process: failures here prevent 70–80% of projects from advancing due to lack of budgets for robust tenders and unfamiliarity with best practices. However, it’s amplified by external factors like funding constraints (top cause at 40%) and governance (30%). Reforms, such as strategic procurement frameworks, could reduce failures by 15–25%, unlocking $20–$30 billion in viable projects yearly.

Addressing procurement through digital tools and capacity building (e.g., AfDB’s initiatives) is low-hanging fruit, but holistic reforms targeting financing and preparation are essential for full gap closure. Procurement’s gatekeeper role makes it pivotal: improving it not only cuts direct losses but also builds investor confidence, potentially mobilizing 20–30% more private funding.

7 How EdgeworthBox Can Break the Status Quo of African Procurement Processes

Public procurement in Africa, which accounts for an average of 17% of GDP across the continent (equivalent to $527 billion annually), remains a critical driver of economic development but is plagued by inefficiencies, corruption, and bureaucratic hurdles.

While there has been progress in legal frameworks and digital adoption in countries like Rwanda, Kenya, and South Africa, the overall status quo is characterized by manual or semi-digital processes, fragmentation, and high vulnerability to corrupt practices such as bribery, fraud, collusion, nepotism, and bid-rigging. This contrasts sharply with the capabilities of a platform like EdgeworthBox, now supercharged with AI consultation for intelligent needs definition and vendor scoping, real-time collaborative RFP design, smart execution automation, data-driven comparative analysis, intuitive user experiences, complete audit trails for compliance, AI-accelerated RFP creation and supplier matching, enhanced supplier discovery networks, and outcome-based pricing for transparent ROI.

In summary, while African procurement has seen advancements (e.g., e-GP systems in Rwanda and Kenya improving inclusivity and data accessibility), the status quo is largely manual, opaque, and inefficient, particularly in infrastructure where funding constraints, customs delays, and political risks compound issues. EdgeworthBox’s features—now including intuitive user experiences that reduce training time and boost adoption across departments—represent a significant upgrade, promoting collaboration, reuse, and accountability with seamless, user-friendly design regardless of technical proficiency.

8 Quantifiable Impact of EdgeworthBox Adoption

Adopting a comprehensive e-procurement platform like EdgeworthBox could transform African procurement by digitizing processes, reducing corruption, and enhancing efficiency, based on evidence from existing e-GP implementations in the region. While continent-wide data is limited, studies from countries like Ghana, Rwanda, Uganda, and Nigeria provide proxies, showing benefits in cost savings, time reduction, and fraud mitigation—now amplified by EdgeworthBox’s new AI consultation, collaborative design, smart execution, data-driven analysis, audit trails, AI acceleration, supplier discovery, and outcome-based pricing, which further streamline workflows, match suppliers intelligently, and ensure measurable ROI.

Impacts are estimated below, scaled to Africa’s ~$500–$600 billion annual public procurement spend (derived from 17% of ~$3.1 trillion GDP):

• Cost Savings and Efficiency Gains: E-procurement can reduce procurement costs by 10–20% through streamlined processes, better supplier competition, and minimized overpricing. In Ghana’s construction sector, adoption led to improved firm performance via time and cost reductions. Scaled continent-wide, this could save $50–$120 billion annually, including 30% efficiency improvements in operations as seen in COMESA countries—now enhanced by smart execution automation for repetitive tasks and deadline management, collaborative real-time RFP design with change tracking, and outcome-based pricing for transparent, value-aligned costs without hidden fees. For infrastructure, it could cut the 20–50% cost overruns from delays and inefficiencies.
• Time Reduction: Procurement cycles could shorten by 50% or more (e.g., from months to weeks), as evidenced by Rwanda’s UMUCYO system, which accelerated transactions and reduced administrative bottlenecks. In COMESA, digital platforms cut processing times by up to 50%, enabling faster project delivery and potentially unlocking $10–$20 billion in annual productivity gains for delayed infrastructure—supercharged by AI to accelerate RFP creation, analysis, and supplier matching (cutting weeks to days) and intuitive user experiences that minimize training and boost cross-departmental adoption.
• Corruption and Fraud Reduction: EdgeworthBox would reduce corruption by 25–30% through transparency and minimized discretion, as in Rwanda where e-GP curbed fraud and ensured fair market rates. Given Africa’s 10–25% contract value losses to corruption (~$50–$150 billion annually), adoption could recover $12–$45 billion yearly—reinforced by complete audit trails for every decision and communication, ensuring accountability and easy historical data retrieval.
• Broader Economic and Social Impacts: Enhanced competition and inclusivity (e.g., for SMEs and marginalized groups) could boost local economic development, as in Kenya where reforms increased access for women and youth. Common contracting could reduce redundant RFPs by 20–30%, freeing resources for infrastructure and potentially adding 1–2% to GDP growth via better value for money and innovation. In Uganda, e-procurement improved supply chain efficiency and SME reach—now elevated by AI consultation for optimal vendor identification, data-driven comparative insights for confident selections, and enhanced supplier discovery for faster, more efficient partner matching.

Overall, EdgeworthBox could help close Africa’s infrastructure gap by making projects more bankable and attractive to investors, potentially mobilizing an additional $20–$30 billion annually in private funding, with new capabilities ensuring seamless, AI-powered execution and measurable outcomes.

9 The Bottom Line

Based on Africa’s estimated annual public procurement spend of approximately $527 billion (17% of a ~$3.1 trillion GDP, as per World Bank and AfDB data) combined with benchmarks from e-procurement studies and EdgeworthBox’s enhanced capabilities—including AI acceleration, collaborative design, smart automation, and outcome-based pricing—the total potential annual dollar value benefit is calculated using a structured approach to avoid double-counting.

9.1 Methodology

• Data Sources: Drew from global and Africa-specific e-procurement impact studies, including percentage-based savings (e.g., 5–20% cost reductions), corruption mitigation (10–25% of spend lost, reducible by 25–30%), time/efficiency gains, and additional funding mobilization. Key benchmarks include: Cost savings: 5–20% of procurement spend, aligned with World Bank estimates of 5% total savings and up to 10–20% in transaction/efficiency gains. Corruption recovery: Based on 10–25% losses reduced by 25–30%, per Brookings and Open Contracting Partnership analyses. Productivity/efficiency from time reductions: 50% shorter cycles unlocking $10–$20 billion, as seen in Rwanda and COMESA implementations. Additional private funding mobilized: $20–$30 billion annually for infrastructure, via improved bankability and investor attraction—now boosted by AI-driven supplier matching and data insights. Assumes phased adoption; pilots in Kenya/Rwanda suggest 20–50% metric improvements (e.g., Rwanda’s UMUCYO system), scalable to continent-wide.
• Excluded Overlapping GDP Boosts: 1–2% (~$31–$62 billion) to focus on direct benefits, as these are indirect outcomes of the above.
• Calculation: Summed low- and high-end ranges for direct categories. Assumed full adoption across public procurement (realistic with EdgeworthBox’s scalability, intuitive UX, and outcome-based pricing, though phased rollout would scale benefits gradually).
• Conservatism: Used mid-range estimates where data varied (e.g., avoided extreme 7–88% pooled savings for specificity). Benefits from unique features like AI consultation, collaborative design, and smart execution are incorporated into efficiency gains, with audit trails ensuring verifiable ROI.

9.2 Breakdown of Annual Benefits

This total ($69–195 billion annually) is a conservative baseline, reflecting proven e-procurement outcomes scaled to Africa. Emerging capabilities like AI-driven efficiencies could push benefits higher (e.g., up to $248.5 billion with full adoption), but such projections await validation through pilots.

10 Call to Action

For P3 units and infrastructure financing organizations, EdgeworthBox offers a proven pathway to efficiency, transparency, and revenue generation—now empowered by AI consultation for strategic guidance, real-time collaborative design for seamless alignment, smart execution for bottleneck-free workflows, data-driven insights for confident decisions, intuitive experiences for rapid adoption, complete audit trails for ironclad compliance, AI acceleration for days-not-weeks timelines, enhanced supplier discovery for optimal matches, and outcome-based pricing for clear, value-driven ROI. By integrating this platform, you can not only mitigate procurement risks but also unlock private capital and accelerate project pipelines. Contact us to explore tailored pilots and demonstrations, where we could validate potential benefits exceeding $195 billion annually with full AI integration.

EdgeworthBox: Transforming Procurement for Africa’s Future.

Bibliography

All of these questions (and the philosophy they represent) revolve around the transaction of acquiring the technology and the solution These questions mainly address the requirements of the procurement department. Indirectly, they address the question of how the procurement department fits into the organization chart. How will the C-Suite see procurement?

They implicitly ignore the end users, the ones who actually translate “strategic goals” into tangible action.

This is entirely the wrong way around. In discounting the end users, the ones who actually translate “strategic goals” into tangible action, the buying organization sets itself up to fail. It is a well-established fact that user-adoption is one of the primary reasons for the failure of technology-centered transformations.

Procurement’s customers are the people who are the future end users of the acquired solution. These are the people procurement should serve in the same way that the company focuses on its own customers.

If we are buying a solution that we intend to use for the next five years, the primary consideration should be the value created over the next five years. The bulk of the return on investment (ROI) comes from this, not from negotiating the price down with the vendor by a couple of percentage points.

The real ROI is going to be determined by those who use the solution, the intensity of their engagement with it, and the outcomes it generates that the organization would not obtain otherwise.

If procurement buys a tool that nobody uses, it’s a failed outcome. It is bad for the organization because they have wasted money. It is bad for the end users because they have to revert back to their old ways or produce kludgy ways to work around the newly acquired good or service. It is bad for suppliers who had hoped to build a lasting relationship.

It is a massive misallocation of resources no matter how compliant the process is.

The ROI of a product nobody uses is -100%.

Early-stage companies focus on building and determining what works and what does not. The nascent entity strives to improve features in their own product offering that the customers like and kill those that the market does not. This is the explore phase. The firm concentrates on determining what the customer needs the most and then works on making the customer successful in the most-efficient manner. When it comes to buying goods and services, procurement talks to internal end users and invests the time and effort to determine their exact requirements. While the procurement approach may be transactionally inefficient, using pen-paper, spreadsheets, and emails, the emphasis is on getting what the users need rapidly. Diligence may be incomplete. The firm may not get the lowest price or generate sufficient options from which to choose or buy the first-best solution, but rapid early-stage revenue growth can make up for these deficits. At least they prioritize end-user needs.

A company enters the exploit phase when it switches focus to managing growth and fulfilling demand for the product they have built during the explore phase. It implements processes designed for rapid completion and execution of tasks rather than on the accretion of value. In procurement, the objectives (and the KPIs) shift to narrow in on compliance, consistency, and efficiency. However, there are very few later stage organizations that incorporate feedback loops to assess how well the end user’s needs have been addressed and to measure the return on investment.

Currently, the entire global economy is undergoing massive change. End user requirements are changing as are the options available. It is imperative today to retain the user-focus of the explore phase. Central to this is collaboration and communication between the various stakeholders of the procurement process. At the same time, efficient processes and thorough risk management are imperative given the intensity of global competition.

In the explore phase, firms should implement a process much earlier than they do in practice. In the exploit phase, procurement should not forget that their primary allegiance is to their internal customers who are responsible for generating real economic value.

Traditionally, the buyers of procurement technology and services have been later stage companies because of the explore-exploit dynamic, so incumbent solutions tend to be over-priced and over-featured. They are not designed for companies in the explore phase. Incumbent solutions do not promote collaboration at all. They are built to support established practices with little to no capability to incorporate the needs of end users and various stakeholders

That’s why we built EdgeworthBox. We have built an easy-to-use platform for procurement that enables firms to establish robust processes when they are in the explore phase and allows firms to retain the collaboration and user-focus when transitioning to the exploit phase. We would love to talk to you about your procurement challenges. Please reach out to us at chand.sooran@edgeworthbox.com or naresh.rao@edgeworthbox.com.

Here’s MIT Nanda talking about the current state of affairs:

“Despite $30–40 billion in enterprise investment into GenAI, this report uncovers a surprising result in that 95% of organizations are getting zero return. The outcomes are so starkly divided across both buyers (enterprises, mid-market, SMBs) and builders (startups, vendors, consultancies) that we call it the GenAI Divide. Just 5% of integrated AI pilots are extracting millions in value, while the vast majority remain stuck with no measurable P&L impact. This divide does not seem to be driven by model quality or regulation, but seems to be determined by approach”

The study also states that the key features of the successful 5% are a focus on a few specific business functions viz. BPO/ Back-office operations and customization of the tools to focus on business outcomes. Vendors who succeeded in these areas are reportedly securing multi-million-dollar engagements rapidly.

The unsuccessful majority leverage tools like ChatGPT but fail to handle integration complexity, fail to align with daily operations and existing workflows, and are slow at contextual learning.

We have seen this movie before with earlier avatars of digital transformations.  However, we firmly believe that the Procurement Technology space is ideal for getting the sought-after success with Enterprise GenAI.

Jon Hansen, the procurement guru – a prolific commentator on the state of procurement technology – summarized what was promised with ERP. It seems eternally relevant:

“Enterprise-wide integration

Automated workflows

Significant cost savings

Process standardization”

Here is what he identifies as the fatal conceit of procurement technology:

“At the heart of this change is a growing realization of a fundamental truth that process and not technology is the driving force behind a successful e-procurement initiative.”

Most procurement technology is built for the large enterprise. It is neither suitable nor economic for small and medium-sized enterprises (including semi-autonomous divisions within larger organizations, such as IT). People, including Hansen, have made the analogy that many of the leading systems are like a Ferrari. One wouldn’t buy a Ferrari SF90 Spider to haul rocks or take the kids to school.  A more suitable vehicle might be a Ford F150 or a Hyundai Santa Cruz which is not only cheaper but may more appropriately serve the need of a family or small business.

Sometimes, it pays to start small and simple. This, in turn, provides a flexibility that is necessary to function as a business. Yet, the existing suite of procurement technology takes a one-size-fits-all approach. They are built for the large enterprise with plenty of large enterprise features and a large enterprise price tag. Many of them are older. They lack a contemporary user experience. They bolt on AI as an afterthought, not as a central part of the functionality.

There are so many players in the procurement technology space because there are so many different types of buyers.

In procurement technology, there need to be tools targeted for small to medium-businesses that seek to transition from running RFPs with emails and spreadsheets to running a lean operation leveraging the most appropriate AI-enabled capabilities.

EdgeworthBox is a flexible platform of tools, structured data, and community focused on executing RFPs. Our AI suite integrates and adapts to existing customer workflows, improving rapidly with usage by propagating best practices, replicating successful approaches, and significantly enhancing collaboration across business functions

We’d love to hear from you. Please reach out. And watch this space.

While this blog focuses primarily on topics related to Procurement & Contracts, I am taking the liberty of discussing some principles that apply to other areas as well.

I read the MIT article stating that over 95% of GenAI initiatives have failed with mixed emotions. Finally, a prestigious institution stated a fact known to those who of us who have worked in this area. Having driven significant digital transformations successfully, I can confidently assert that there really is no excuse for these failures. With the possible exception of integration, the primary technical & technological limitations – processing power, computational speed, storage, network connectivity and speed, analytical libraries – have been largely addressed. IMHO, there are two main reasons – other informed sources will give you between 5 and 7 – viz. data quality and user education/adoption. Address those early and the scales tilt dramatically in your favor.

With regard to GenAI, let us state some basic facts

• Agentic AI / GenAI work on relationships primarily within a textual content. Simply put, it identifies combinations of words to make sentences, paragraphs, posts & presentations. Thanks to the incredible underlying technologies, it builds layers upon layers of relationships and amazingly produces high quality content which appears to make sense. Note however that it is not trying to do a traditional optimization nor make a true business decision i.e. caveat lector applies to all recommendations.
• The content that GenAI generates is dependent upon the information that it is fed. As was seen with Grok, it generated some extremely antisemitic content since the corpus of information inadvertently included some very inappropriate content. On the flip side, the higher the quality of the corpus content, the better the recommendation.
• GenAI is not free. The more extensive the search, the more expensive it is. As information proliferates, the cost of tokenizing the content – a geeky way of saying searching for and incorporating content – will at least partially offset the efficiencies due to improvement in technologies.

Having said that, I am extremely optimistic of the value that can be realized through GenAI and Agentic AI. Both are extremely well suited for text heavy business functions such as Procurement & Contracts. Using a very rudimentary version of the AI agents (think primordial Agentic AI), my team was able to save over $1.5 Million per quarter and it took only 3 months to set up and to start generating the value. Just FYI, this number was validated by the CFO. I am certain that today’s initiatives will realize significantly larger benefits.

A couple of quick points to consider a possible approach for your GenAI / Agentic AI initiative:

• Focus on the problem not the technology – (This is surely a trope by now). Most initiatives focus solely on leveraging a single capability or technology. That is similar building a house with only vertical pillars. A holistic or complete solution may also incorporate ML/AI (the quantitative part of AI), visibility, optimization, etc.
• Address the aforementioned bottlenecks by:
  • Educating the end-users at the onset of the project … or earlier. Increasing the user involvement significantly improves user-adoption, a key factor for success.
  • Limit the data scope and focus on high quality data. As much as possible, focus on data relevant to your business objective. Adding additional data has diminishing returns and usually brings additional issues such as data quality.

While developing and deploying such solutions, I had some very pleasant surprises.

• Value realization is actually quite rapid. Bottom-line benefits show up in as soon a month. Set up KPIs to track the realized value.
• Data quality improves quickly. A virtuous cycle is created where data is used more when the data quality is high and the increased usage improves data quality.
• Business silos start to break and cross-functional collaboration increases significantly. A second virtuous cycle occurs when the high(er) quality data and information is used by other business functions which in turn drives improved analytics and data quality.
• The users directly improve the solution quality. An educated user has an intuitive idea of what “good” looks like and where the value lies. They take it upon themselves to suggest modifications and actively participate in issue resolutions.

Regardless of whether you are planning to start a GenAI / Agentic AI project or planning to pause one, I recommend an excellent (free) book about building AI agents by Sam Bhagwat. It gives you several ideas to incorporate into your own efforts. If you need any assistance, please do not hesitate to reach us – Naresh Rao or Chand Sooran. We would love to connect.

Siloed data means that teams draft and issue RFPs with a subset of the information they require to write a comprehensive document soliciting supplier proposals. The buyer’s team lacks a full sense of the problem the firm wants to solve with the procurement or its importance. They may not know the full spectrum of suppliers who can address their requirements.

Siloed people means that not every stakeholder who should be part of the procurement gets to join. This includes some of the end users or others who will be affected by the purchase, as well as people who have domain expertise regarding the space.

Siloed opportunities means that the RFP process limits the number of organizations collaborating on a problem. For example, if both marketing and finance need a similar software, they may end up running separate procurement events instead of a joint one. Companies or government agencies purchasing the same solution might benefit from issuing a single RFP but are prevented from doing so by policy restrictions or, more likely, an inability to discover like-minded partners.

Silos can be thought of as fractal; they look the same at different scales. Procurement silos can appear similar at the department level, at the firm level, and at the level of multiple companies. Divisions within a department fail to collaborate effectively, just as departments within a firm disappoint. There can be significant obstacles to joint procurement that spans multiple buying entities, e.g., cities in different states or provinces.

All of these things contribute to sub-optimal outcomes. What does that look like practically? An optimal procurement outcome is one in which the buying entity buys the right solution, from the right supplier, at the right price.

These silos emerge for many reasons including politics, organizational design, compliance policies, fear, or an inefficient approach to data. People use different language to describe the same problem, making it difficult to communicate what they want.

These silos emerge organically because they exist within the context of both internal markets for information and power, as well as external markets for goods and services.

Conceiving of these dynamics as market-based is the first step towards resolving the frictions that stand between the buyer and value-for money, between the supplier and a long-term valuable customer relationship.

MIT’s Andrew Lo has written extensively about what he calls the adaptive markets hypothesis:

“The adaptive market hypothesis, as proposed by Andrew Lo, is an attempt to reconcile economic theories based on the efficient market hypothesis (which implies that markets are efficient) with behavioral economics, by applying the principles of evolution to financial interactions: competition, adaptation, and natural selection. This view is part of a larger school of thought known as Evolutionary Economics.”

It is a radical departure from the prior way of thinking about markets as machines that process information instantaneously to reflect the correct, rational view in the price of a security.

Adaptive markets mean that markets are more like biological ecosystems that may or may not be efficient at any given point in time in the ways that they process information. Under some conditions, at some points in time, they can be very good at processing information and allocating resources; in other circumstances, they can be wildly off the mark.

Adaptive markets are made up of individuals and organizations that are themselves flawed and irrational. People are overconfident. People exhibit loss aversion. People can be lazy. People have a difficult time seeing things with a systemic perspective. People use heuristics and rules of thumb to proceed. The relative impact of different types of investor can change over time, shifting the market’s underlying structure. Strategies like value that worked twenty years ago stop working in a zero-interest rate environment disrupted by significant technological change in the economy. Ten years ago, individuals didn’t influence options markets; now they dominate them.

Things work until they don’t.

Lo’s thesis is a way to synthesize the original mechanistic models of financial markets with the subsequent rise in behavioral economics developed by researchers like Daniel Kahneman.

The efficient markets hypothesis cannot contemplate meme stocks or bubbles; adaptive markets can.

Markets exist within a broader framework in which everything is part of the complex adaptive system that is our social, corporate, and economic life.

To succeed in a biological environment, one needs flexibility; the conditions change constantly.

One needs to evolve.

This is true of procurement, too. The problems that firms try to fix with purchases are in flux. The people and suppliers who are involved in these decisions shift constantly. New technologies like AI emerge to change the landscape. Geopolitics interferes.

Buyers in markets for goods and services, just like investors in financial markets need a clear, complete picture of the chess board.

Silos are problematic in a stable environment. Silos are damaging in a dynamic environment. Silos are devastating in a disruptive environment.

If we accept the premise that a rules-based, mechanical approach is doomed to produce the sub-optimal procurement outcome, then what do we need to do for adaptive success?

• Collaboration and sharing of as much relevant data within the enterprise and across organizations as possible
• Increased participation to solicit maximum input to shape the discussion with suppliers, identifying possible solutions, and evaluating submitted proposals
• Joint RFPs within the firm and across organizations
• Standardized language that minimizes jargon to maximize the efficiency of communications

Which brings me to Figma.

Figma is the market leader in product design software. People use it to design and prototype software applications. They mockup so-called wireframes to show what the different sections of an application will look like and then they make prototypes to show the user flow within the application, usually before the developers write a single line of code. It’s not about making it look pretty (although that’s part of the outcome usually). It’s focused on simplifying the user experience and addressing edge cases in which users can arrive at dead ends when navigating the application. It is also about ensuring that the application includes all the necessary functionality, manifesting the vision of the software architect as closely as possible.

Before Figma, there was Sketch. Sketch appeared on the scene in 2010. It created the category, recognizing the explosion in app design as new ways of interacting with increasingly sophisticated software emerged. Before Sketch, designers would try to adapt existing tools such as Adobe Photoshop for the purpose, but this was difficult. Sketch was a desktop app built for the MacOS. It enabled a single designer to whip up complex wireframes quickly. It was distinguished by its functionality; it was built for this purpose.

Figma came later. It took the company years to write its code, but it disrupted the space. It had similar base functionality as Sketch, but it was built natively for the browser (not as an installed desktop application) and it added an important layer: collaboration. Here’s Stratechery’s Ben Thompson:

“Think about my brief description of this “product design and development” segment: multiple app views created by design and implemented by engineering imply at least two different people working on a project (a designer and a developer); in reality, the huge number of different views and increased functionality in apps meant that there were increasingly large teams on both sides. Sketch definitely made it easier to design an app in one place, but it did nothing to make it easier for teams to work on an app together; Figma, because it was native to the web, effectively got collaboration for “free” from the beginning.”

Figma took off. Thompson quotes Figma’s S-1 filing related to their recent blockbuster IPO:

“As more designers and their teams started using Figma, they began to understand the benefits of designing together in the browser. It was more fun working collaboratively in the same file; it was also faster and more efficient to work in a single product that brought storage, asset creation, prototyping, and other parts of the design toolchain into one place. The ability to easily share work with a URL led people to bring collaborators into their files earlier, placing more emphasis on co-creation and less on the “big reveal.” It also led Figma to spread quickly within companies and design communities globally, while giving teams something they’d never had before: a single source of truth to access the most up-to-date designs. Today, the openness and accessibility that Figma helped pioneer is no longer a novelty; it’s the expectation, a way of working that has spread across teams, tools, countries, and industries — and transformed the way products are designed and built.”

Figma was built for an adaptive market for information and influence within the organization (and across the organization if you include consultants and third parties).

Figma owns the market.

Sketch was an old-school approach, an application built for a different era which limited the number of stakeholders involved in the project. Figma recognized that their customers could build better apps (obtain better outcomes) with more collaboration and more flexibility. They made the user experience simple and accessible.

Figma also noted that it was going public, not because they perceived AI to be a threat that would put them out of business, but because they wanted to add AI as a complementary layer to their collaborative suite.

An adaptive markets approach to RFPs would do the same thing. It would explode the process in terms of enabling more data and more input from a wider array of people, supplemented with AI tools, wrapped in a simple, elegant user experience.

AI will not replace procurement; it will enhance it. It is a bicycle for the mind, in the logic of Steve Jobs.

Does this characterize the RFP tools in the market today? Were they built natively for collaboration? Are they easy to use? Do they bolt on AI as a replacement or is AI an adjunct function?

This is what we’ve built at EdgeworthBox. We’re a collaborative, adaptive suite of tools, data, and community that enables flexibility and joint procurement. Watch this space. Important new things are coming this Fall.

This is a human tendency.

Software developers are no different. You see this in the initial phases of a new technology roll-out.

Consider for example the early days of search online.

Companies like Yahoo!, AltaVista, and the like merely digitized the analog way we would find things. Before the Internet, if you were looking for a plumber to fix a leaky faucet, you would pull out the Yellow Pages directory and look under the letter “P.” There was a listing with a name and a telephone number and an address. Some plumbers would pay for an ad in the form of a box that might show their logo with some slogan. You had no way of distinguishing one plumber from the other based on the information in the book.

As I recall,  Yahoo! had listings of links in alphabetical order. So did everyone else. You used Yahoo! because it was there and everyone else used it. I believe it even started out as something like “Jerry’s List” named after founder Jerry Yang. Advertisers would pay Yahoo! for the equivalent of the boxes in their listings. Instead of phone numbers, clicking on the name of Plumber X would take you to his website. The listings were links.

The experience had the merit of being familiar, at least.

That is until Google came along and did two things that were interesting.

One, the user interface was entirely different. Instead of a home page in which one could see listings of categories, clicking on which links would take you to another page for a specific set of goods or services or interests like Plumbing, there was just a single box under the now-familiar Google logo. It was clean. Yahoo! and the others were cluttered. With Google, you typed in the name of the thing you were searching to find in Google’s box.

Two, the results, presented on a separate page, were a listing of links, including a brief description. However, the links were in the form of on an ordered list. Google determined the ranking of each individual listing based on the number of citations for that link in other sites or the frequency with which people clicked on it. It was like the way in which academic papers are ranked based upon the number of citations. Now, there was a way to distinguish based on relevance or quality that the Yellow Pages methodology did not contemplate.

Yahoo! was a directory. Google was a search engine.

Simplicity and rank ordering won the day.

Rank ordering was so important that an entire cottage industry sprouted up of people who told you they could game the system and trick it into giving you a higher ranking than you would have obtained without their help.

The company didn’t even advertise itself in the old days. It spread by word-of-mouth. I remember when a colleague told me about Google and my shock and awe when I pulled up the site at work for the first time.

Similarly, ERP systems digitized the analog version of bookkeeping and procurement systems and HR systems and payroll systems. Where the accounting had been done manually with clerks updating paper spreadsheets based upon specific functional activities and those spreadsheets rolled up into the general ledger, now those functional activities took place in a digital interface that updated databases. The databases then provided the information for other systems to automate their aggregation into the general ledger. Productivity increased in the sense that there were fewer accounting clerks, even as there was greater IT expense for software licenses and computers and networking equipment and IT professionals. As they say, the productivity was everywhere to see but the financial statements.

Digitization meant taking a pencil-and-paper task and making it screen-based. That’s it. That’s typically all it meant. The business process didn’t change meaningfully.

Even today, there is little distinction in the way in which a Request for Proposals auction takes place between a paper process, an email-and-spreadsheet process, and a contemporary procurement technology approach. The tools may be different but the business process is the same. Perhaps there is some automation on the margin that makes the digital process easier, but maybe it’s offset by a reduction in the quality of the bid solicitation document. Maybe people spend more time focusing on the quality of the process when it’s manual. Maybe.

In anticipation of the introduction of artificial intelligence and leveraging lessons from financial markets where millions of auctions take place daily, EdgeworthBox took the first steps to change the business process.

• We added structured data regarding previous RFPs and contracts and made the data shareable across all the stakeholders in the RFP process, not just people in procurement (for the buyer) or sales operations (for the seller).
• We built a social network with messaging and profiles to help users from both sides and across organizations collaborate.
• We added rapid onboarding tools so that buyers could cast a wider net beyond the narrow ken of suppliers with which they had existing relationships.
• We enhanced the group dynamic at the level of the value chain and the internal stakeholder group.
• We enabled joint RFPs issued by multiple organizations.
• We added scoring tools to speed up and improve the quality of vendor selection.
• We wrapped everything in a cleaner user experience to simplify the process on both sides.

All of these features were designed to deliver specific functional improvements: faster RFPs, better-written RFPs, and greater competition in terms of price and solution that would lead to better problem-solution fit.

Just as Google cleaned up the user experience and added utility in terms of ranking links by quality and utility, we simplified the RFP process to remove the bureaucracy while making it much easier to surface actual intelligence.

We did it with a view to developing troves of the kind of data that we anticipated AI solutions would need. (With our background in matching buyers and sellers in financial markets, we like to think of our approach as closer to a Bloomberg terminal than Google.)

From what we can tell, many incumbent procurement technology providers have rushed their AI products to market with another layer digitizing the analog process. At least that’s my working hypothesis. The AI tools in the market have more in common with the pen-and-paper RFP auction than they do with what AI should be able to do.

Digitizing a process means it goes from pen-and-paper to a screen.

For many solution providers, converting the process to AI so far seems to be just an extension of this digitization. There’s nothing new when it comes to improving the process. At best, AI moves the process from a screen to a software robot. Maybe.

In any case, it’s still the same process.

The only thing we can say for sure is that AI is a way to generate fear-of-missing-out for some solution providers to exploit.

This is why there must be the inevitable adoption blowback, the dip in adoption. People don’t want to overpay for something that doesn’t move the needle.

What AI needs to do is to fix the RFP business process because it is broken. It is bureaucratic. It is inefficient. It is centralized. It is the opposite of nimble.

It is risk averse. It is afraid.

Here are several predictions about how AI agents and more sophisticated AI tools can change the RFP business process.

First, AI will lead to a decentralization of the process. Instead of having procurement officers supervise the process with massive bureaucratic oversight, business units will execute their own RFPs. For example, the CTO will execute his own reverse auction to decide which cloud services to purchase. Procurement will have full transparency into the process and will trust the agents to execute the workflow the organization is comfortable letting the agents use. But the business users will run the process, not procurement. This means it needs to be simple and it needs to be functionally efficient.

Second, procurement staff will focus more on more strategic functions like contract enforcement and vendor performance evaluations, helping the firm ensure that they get the value they paid to obtain.

Third, suppliers will have their own AI agents. We may see a fully decentralized process in which buyer agents deal with supplier agents.

Fourth, the process will be much faster and much less expensive.

Fifth, it may be the case that firms replace the use of catalogs managed by expensive middlemen with hasty RFP auctions.

Sixth, the combination of collaborative transparency and AI agents may make procurement-as-a-service a much more attractive option, especially for smaller organizations. It will be cheaper to execute. It will be more efficient.

These are the things we’re working on for the next iteration of EdgeworthBox. We love to talk. Give us a shout.

Imagine the early days of the automobile industry. Cars were made by hand. Skilled individuals used tools (screwdrivers? wrenches? hammers?). The quality of the cars was variable. It was difficult to produce in high volumes.

Then, Henry Ford applied principles developed in other industries (like meat packing) to automobile manufacturing. He standardized components, broke down the process into steps, and set up a production line in which workers (specializing in individual stages) sequentially performed all of the tasks necessary to make a car. Production engineers studied the line constantly, using the data they gathered from time-and-motion studies to tweak the work at every point to make output more efficient on the margin.

“By 1914, Ford was producing more cars than all other automakers combined, with a Model T rolling off the line every three minutes.”

Automation of the Ford line brought prices down, making cars more affordable. He also took care of his workers, raising wages and implementing work rules that improved their lives and enabled them to afford the cars they manufactured. The impact this industrialization had on the broader face of America was even more significant. Other industries adopted his production techniques and his labor policies. Urban geography changed as automobile adoption became widespread with the rise of the suburbs; Ford had compressed distance. Other countries followed suit.

Car companies started to outsource some of their production lines, such as the assembly of parts (or, in some cases, whole cars), sometimes sending work outside of the country.

Fast forward to today and many automobile manufacturing plants employ robots instead of humans. The robots work tirelessly. They are less expensive. They are more reliable. They use more specialized tools. They are custom-designed; a robot on the automotive line is different from a robot in a shoe factory.

The modern company is full of so-called knowledge workers who work with data, using their judgment to make decisions. They have specific expertise in one or more functional areas, including procurement. Often, they must collaborate with other knowledge workers within the firm who have access to different data and look at it through the lens of different knowledge.

To quote Daniel Kahneman, Olivier Saboy, and Cass R. Sunstein from their book Noise, “Judgment can therefore be described as measurement in which the instrument is a human mind. Implicit in the notion of measurement is the goal of accuracy – to approach truth and minimize error.”

There is a parallel here to the evolution of manufacturing.

In the beginning, there was pen and paper. Procurement staff did everything manually. At the RFP end of the spectrum (EdgeworthBox’s area of focus), this meant coordinating internal stakeholder committees, developing requirements, writing bid solicitation documents, and mailing potential suppliers. It involved tracking everything in spreadsheets kept up by hand. Suppliers wrote out their responses and buyers evaluated them.

The advent of email and spreadsheet software made this easier to track and coordinate. Instead of corresponding with suppliers using letters, buyers could do so with electronic forms of communication. Spreadsheets helped procurement staff plan and organize reverse auction RFPs and RFQs. Theoretically at least, it was easier to manage and retain data for subsequent use.

In practice, the judgment of the staff derived from their experiences. Procurement events were noisy and biased in that there was tremendous variability around the outcomes. Even for one-off decisions, the outcome could be very different depending on who was running the process. Purchases of goods and services did not always obtain the best value-for-money in terms of the problem-solution fit the firm sought or obtaining the right price from the right supplier. Procurement judgment was prone to missing the truth.

ERP solutions and other sourcing software tools emerged over the past thirty years. These sought to take the knowledge worker’s process (for various functions) and to translate them into code, replacing the use of email and spreadsheets. The underlying (unstated) assumption behind these systems is that all companies execute these functions using the same process. Developers held this assumption even more firmly when building software for use in a specific industry, say manufacturing. All manufacturing companies were deemed to use roughly the same accounting, for example. And they were thought to approach RFPs the same way.

It makes sense to do so from the developer’s perspective. There are fixed costs to writing code. To the extent that you can sell the same code to more people, you amortize these over a larger base, improving your profitability. However, you avoid contextualizing the solution for each company.

You can have any color suit you like, sir, as long as it’s grey.

This lack of contextualization is a problem. Consider system A. It was originally written for manufacturers to help them execute RFPs. The vendor obtained tremendous success and sold themselves to a large ERP company. The ERP company then integrated the acquired solution into their offering as their procurement module, something its customers could elect to bolt on as an option. The ERP company wants to have a comprehensive suite of solutions so that they become the single source of back-office truth for their customers. Software is about scale, after all.

What happens if your company is a medical products company that is using system A. You have to jam your square peg into their round hole. What’s even more difficult is that the ERP system sells expensive seat licenses. Your CFO wants to control how many people get these, so it’s typically only people from the procurement department who warrant access. The other stakeholders are left on the outside.

In the end, many people end up using email and spreadsheets to overcome the limitations of the ERP module. Combine this reduced business-software fit between system A and the user firm’s context with the fact that the data in the system is restricted in terms of who can access it (and who practically does look at it), judgment gets noisy and biased.

Companies don’t buy the right products. They don’t find the right suppliers. They don’t pay the right prices.

Companies don’t get value-for-money.

AI takes two forms: tools and agents.

An example of an AI tool is chatbot, like ChatGPT. People use ChatGPT to write the emails that they send to suppliers or to other internal stakeholders. They may ask ChatGPT to write the Statement of Work. In this case, the machine is predicting a series (sometimes a long one) of next words. We use judgment to predict. The machine has some judgment that it has distilled from its training on vast amounts of general data. The user provides some context (in what is called the context window) and the machine does the rest. For some tasks, it’s probably fine. For other tasks that require more specific knowledge and greater experience in making decisions, it may not be the best solution.

We can think of AI agents like the robots on the manufacturing line. We give them access to tools, some of which may be AI tools like chatbots and others may be more general like access to Internet search or a calculator for performing mathematical operations.

I suspect that many of the early AI tools and AI agents were nothing more than wrappers for the legacy systems and ERP modules they were meant to augment. The predictions were just as biased and as noisy. If anything, the process became opaquer.

Over time, the agents will be more effective and more transparent. They will use chain-of-thought reasoning to emulate the judgment of their human overseers, showing their work. They will have access to a broader array of tools.

Their judgment will improve.

Most importantly, though, the agents will be customizable for the specific context of each user firm and each user case. This will be made much easier for agents using software tools that have built-in flexibility and collaboration around structured data. The flexibility makes it easier to integrate idiosyncratic conditions; no more trying to fit in questions about penetration testing in an RFP template designed for buying diesel generators. Collaboration is key because the agents will become members of the team; the more information and context they can obtain from the team, the better the outcome will be. Structured data, say from prior RFPs and responses received, will be vital for developing the agents’ judgment.

This kind of thoughtful approach will be far superior to just creating an agent backed only by a general large language model, or one reliant only a limited set of tools.

The efficiency gains of a robotic manufacturing line compared to manual assembly are staggering. The gains from agents will be just as impressive.

Please reach out to us. We love talking about the future of procurement and AI, in particular.

With the Request for Proposals process, the answer is likely no.

Consider the evolution of the RFP. You can imagine industrial companies in the 19^th century looking to purchase blocks of commodities like copper of a specific grade or wool for their mills. Commodities have a standard grade. They are fungible; one pound of prime beef is the same as another pound of prime beef. When we isolate characteristics related to quality, then the sole remaining factor is price. Buyers want to pay the lowest price. The supplier that is most motivated to sell will be most aggressive on price, perhaps reflecting an excess inventory that costs money to finance.

The RFP process, or more accurately, the Request for Quote process, is optimized for purchasing commodities where there is only one deciding factor.

There are several issues that derive from this, though.

One, we have trained buyers to focus on price as the dominant factor in selecting solutions. The problem here is that not everything is a commodity. When we need to distinguish between solutions across multiple dimensions, trying to reduce the problem to just one leads to sub-optimal outcomes. We may end up paying the lowest price today only to forego higher revenue or to incur higher costs in the future because we picked the wrong proposal.

Two, we have come to rely on the convenience of the RFP. Because it’s a process with which we’re familiar, we default to the RFP, ignoring the possibility of any other approach. We’ve baked it into our compliance policies. We won’t get fired for running an RFP.

Three, we presume to have enough category knowledge to be able to write a bid solicitation document that will generate plenty of responses. We assume that if we issue an RFP, suppliers will respond with plenty of free information either because they understand what we’re looking to buy or because they’ll do anything we ask in the hope of obtaining our business. The lazy default of the buyer is to be arrogant about their power relative to the supplier base.

The truth is that when it comes to complex procurement, we are not purchasing commodities. We need a process that is designed for the thing that we’re buying and we are blind to the possibility of alternatives to the RFP because of administrative inertia. We shouldn’t assume that we know more than the suppliers or that we are very good at communicating our intent. Writing is difficult. Most people struggle with it as individuals. Things can only get worse when we start crafting a bureaucratized instrument by committee.

Charlie Munger was an American lawyer and investor with a legendary track record. He was famous for his wisdom, expressed in clear language. These consisted principally of a set of mental models that enabled him to understand the world. Here’s Farnam Street discussing one of Munger’s favorite techniques: inversion.

‘It is not enough to think about difficult problems one way. You need to think about them forwards and backward. Inversion often forces you to uncover hidden beliefs about the problem you are trying to solve. “Indeed,” says Munger, “many problems can’t be solved forward.”

…

‘Despite our best intentions, thinking forward increases the odds that you’ll cause harm (iatrogenics). Thinking backward, call it subtractive avoidance or inversion, is less likely to cause harm.

‘Inverting the problem won’t always solve it, but it will help you avoid trouble. You can think of it as the avoiding stupidity filter. It’s not sexy but it’s a very easy way to improve.’

To apply this approach to the RFP, let’s start with the desired outcome and think about all the steps that it would take to get there, moving backwards in time.

When we purchase something significant or complex using a reverse auction like an RFP, we want to solve a problem. It’s more than that, though. We want to solve the problem as quickly and efficiently as possible while paying a reasonable price. We want to buy the right solution, from the right supplier, at the right price.

To solve the problem, first we need to understand the problem. It’s not enough to state it. We need to pull it apart. We need to assess how it interacts with other parts of the system of our enterprise. We need to think about the things that can go wrong. We need to understand the tradeoffs and conflicts in our existing approach, so that we can appraise how our solution will impact all aspects of the organism.

We also need to understand all the different options on the market and why suppliers made the choices they did in coming up with the variety of products we confront.

Moving backwards in time from our optimal outcome, the most immediate step is having a way to evaluate the options in front of us. Ideally, we have been able to convince a large number of suppliers to present us with alternatives. We have a representative sample that is indicative of the diversity of solutions from which we could choose. We don’t need every solution provider to offer us a sample solution. We just need to know that we have considered all the broad types of solution.

We need a way to compare these surfaced options that systematically helps us to pick the right one across multiple dimensions, not just price. To make an informed decision about how this will work as a system within the enterprise and the complexity of all its myriad moving parts, we need people who understand all those pieces and how they complete the puzzle to be part of the process.

Moving backwards another step, we need multiple suppliers to engage with us. It’s not sufficient to have a sophisticated evaluation process if we don’t hit the critical mass of proposals. We have to convince people to engage with us. This means we have to reduce their costs significantly. (It might even make sense to pay their proposal costs up to some reasonable limit.) But to really get suppliers to plug into our conversation, buyers need to showcase the problem in a way that appeals to their interest in the problem in the first place. We need to include them in the definition of the problem so that we can elicit from them their intelligence about the market. Ideally, the buyer enterprise doesn’t develop their requirements in a vacuum but relies upon the supplier knowledge to help them refine the specifications before suppliers begin to write their proposals.

Moving backwards through the decision tree, before looping in the suppliers, the buyers must have detailed conversations with all of the stakeholders within their enterprise, including staff who face the problem this procurement intends to address.

The one common denominator to all of this, and the thing that is underwhelming in most RFPs, is collaboration around various groups of people. There are fractal levels of groups starting with the prime contractor and its subcontractors (i.e., the supply chain). There is the internal committee of stakeholders who contribute to the process (and also those who will be affected by the final decision). There is the possibility of joint purchasing across organizations.

Collaboration is key. This is where the RFP process fails. This is the source of the iatrogenic effects of linear thinking and a forward progression through the problem that fails to also look backwards from the desired end. This is what nobody tells you.

The ideal solution will include these groups in direct collaboration from the beginning of the project to identify the full reach of the problem and to surface as many ideas as possible about how to solve it, in an inclusive manner that encourages feedback and engagement. This is not an adversarial competition in which buyer and supplier are arrayed on opposite sides of a zero-sum negotiation, but rather a collaboration to generate a long-lasting, transformation.

Incidentally, this lack of collaboration in the current status quo is a key reason for the failure of most digital transformation projects.

At EdgeworthBox, we have built a platform for collaboration that spans these different layers: the supply chain, the internal stakeholders, and partner organizations. We have built a platform that removes the frictions inhibiting genuine sharing of information. We enable inversion of the problem for complex procurements. If you’re a commodity buyer or someone purchasing small amounts, a traditional P2P system is what you want. But if you’re buying complex, long-lived, strategic solutions for critical problems, then you want EdgeworthBox as a layer in your procurement technology stack. Let’s talk.

They are very good at steering the buyer to weight certain features heavily and to discount other features entirely in the pre-RFP phase. This is, of course, “shaping” the RFP.

They are very good at writing slick proposals. These make the buyer feel good about the purchase.

They succeed at making the buyer feel good about themselves.

Note that none of what I have described has anything to do with the buyer purchasing the item with the best problem-solution fit or at a reasonable price. Value-for-money is not part of this conversation.

The salesperson’s job is not to solve your problem; it’s to convince you to buy their stuff.

It comes down to getting the buyer to think it was their idea to buy the widget that the polished salesperson is peddling.

Salespeople who are good at responding to bid solicitations are really like jedi knights.

Those aren’t the droids you are looking for; mine are.

Let’s conduct a thought experiment. Consider the following scenario.

Imagine a buyer who does their independent research. They don’t hire a consultant. They think about things from first principles. They develop their own expertise by speaking to their internal customers, the people who will use the good or the service the organization proposes to buy. They focus on what’s important and what’s not. Perhaps they talk to people with the same needs in other organizations to understand how they would approach the problem with a clean sheet of paper.

People can be remarkably candid and helpful if you know how to ask the right questions and you have the courage to do so.

Our intrepid and self-directed buyer team puts together a description of the thing that they believe will most closely address the problem their purchase is meant to resolve.

They do all of this without looking at what’s available in the marketplace and without speaking to any supplier. They don’t want to be infected. They want to approach this situation with a beginner’s mind, free of assumptions and history.

Inevitably, this pleasant reverie will collide with market reality.

At some point, our buyer team must speak with the suppliers. Perhaps it’s a pre-RFP conference call to talk about what they want.

Imagine the fireworks.

Invariably, the buyer will describe something that is innovative or that challenges the status quo approach to this particular problem.

Cue the wailing.

What you’re talking about doesn’t exist, the consultants will say. What you’re asking for will require millions of dollars in development spend, the leading incumbents will say. (This is especially true for SaaS software.) I’ve seen situations in which all of the participants on the call take turns laying into the buyer, gently. It’s a delicate balance. They have to get the buyer team to second guess their internally developed understanding of the problem and what’s feasible, but without individually being the bad guy who makes the buyer upset. It’s amazing how organic this shared responsibility diffuses; every supplier seems to do their part in negging the buyer. It’s tacitly collusive.

If they get this right, one lucky supplier will get the opportunity to educate the buyer on the realities of the marketplace for these type of solutions in a follow-up “consultative” session. If, coincidentally, the emergent understanding happens to align with the individual vendor’s product line, then so be it.

But it’s even worse than that.

Our buyer team, having been scolded into timidity, will write an RFP that now caters obviously to one particular supplier. Perhaps they understand this, so the buyer (sheepishly) waits to release the RFP until the Friday before the July 4^th long weekend at 5 pm, the netherworld for buried press releases and bid solicitations.

Anyone sophisticated reads the RFP and realizes that this deal is “wired” for a particular supplier. Unless they feel obligated by the relationship to write a proposal, suppliers drop out. A competitive auction becomes a failed auction quickly. The buyer scrambles to find respondents. An auction with three proposals is still an auction, right?

Even when the buyer does manage to convince several suppliers to respond, potentially by cajoling them with promises of a fair fight or better access on the next one, the default tendency for the committees that vet the final submissions is to lean towards the slick proposal. You know them: the ones with the great graphics and the jargon and the case studies. If there is an oral presentation, these people deliver beautifully.

Here’s the secret that nobody tells you: there is no correlation between proposal quality and ultimate value-for-money.

The better way to do this is, ironically, simpler.

First, the buyer should describe the outcome they want to obtain. If your problem is that you need to figure out how to handle snow clearance now that your current municipal fleet of snow trucks is getting older, then the outcome might be saying the City of Rimouski is interested in having clear streets within six hours of any snowstorm that deposits more than 2 cm of snow in a three-hour period. This would include a description of the constraints particular to Rimouski in the wintertime. This contrasts with the conventional response: issuing an RFP for snow trucks with an overly prescriptive explanation of what the trucks should look like.

Second, instead of being swayed by a glossy proposal, do real reference checks and speak with as many people as possible to understand the actual performance of different suppliers under real-world conditions. If you had to do it all over again, would you still select vendor A?

Very few people check references properly. They may ask the suppliers for the names of some referees, but these are cherry-picked for positive reviews. If you’re interviewing someone for a job, would you rather speak with their best friend or someone who was on the other side of a deal table from them? It’s difficult to find the right people, but it’s not impossible. Even then, you have to know the right questions to ask. Nobody is going to tell you outright that company XYZ is terrible. People are nice. People are afraid of litigation. Buyers need to be able to ask questions in such a way that their interviewees reveal their true preferences. This is an artform.

If the buyer can get this right, they obtain value-for-money nirvana.

You need the right tools, though.

This is what we have built at EdgeworthBox: a flexible RFP platform that enables outcome-oriented sourcing and real communication (not stilted pro forma FAQs) using our built-in messaging functionality. We can facilitate sophisticated vendor reference checks, too. We would love to hear from you. Please reach out.