This is a 5-minute read about the frustrations and inefficiencies of the usual procurement process.
In previous posts, I have discussed the bid decision and how to use systems thinking to provide a context and an analytic platform for project risk. This positions us to review and critique the Request for Proposal (RFP) ritual. It is a serious topic, as there are inherent and damaging inefficiencies in the current processes. The aggregate losses impact project, corporate, government, and national productivity, but the processes continue unchanged. The scope includes processes for soliciting proposals, selecting and contracting a winning vendor, and ensuring successful delivery.
The way procurement works
This is the way it is, with woefully few exceptions:
The client (buyer) gathers requirements and distributes the RFP to the preferred list of vendor firms. There are no standards that govern this. Occasionally a client has his budget checked by a third-party consultant who is privy to client details, but forbidden from bidding. Very rarely, vendor feedback will be solicited and incorporated into the issued documents. The losses engendered by this process are caused by failing to filter unqualified candidates, incomplete requirements, misrepresentations, and premature estimates leading to incorrect budgets.
The vendors work to prepare a proposal that is fully compliant with requirements. Alternatives are usually disallowed. Proposal formats are often dictated by the client, but there is no standard for clients to follow. RFP clarifications may be provided, usually in open forum at a bidders’ conference. Inconsistencies (e.g. need for high quality and rapid delivery) are seldom discussed at these meetings in order to avoid competitive disclosures or client antagonism and are therefore unresolved. Losses arise from lack of RFP clarity, discarded responses, cancellations, or withdrawals and re-issues.
Clients use a variety of techniques and processes to arrive at a winning bid. Although there is no standard, there is usually a degree of consistency (shortlists, decision matrices, presentation formats, references, legal T&C boilerplate) found in the market place. Losses can arise as a result of pre-judged preferences by clients and unwarranted assumptions by vendors.
The adversarial system governs contract law, and that is generally the underlying tone of the contracting phase. This can easily permeate into the delivery phase, which the sponsor rarely sees as a significant client responsibility because the vendor has signed up, usually for a fixed price! Losses can arise from selection of the incorrect contract type, inefficient terms, and excessive start-up delay.
More often than not, after a few drinks at the vendor’s Friday night stress-reliever, someone will say “You know, if it wasn’t for the client, this would be a good project!” Not really funny. Seeking false productivity, buyers and sellers tend to operate as silos. Communications get tangled, misunderstood, and complex. During delivery, the contractual relationship introduces brand new causes for failure, and amplifies the traditional ones.
Fixing the lifecycle
Although it seems like common sense, it is not usual practice to sort out the issues at the beginning of the project, rather than when things go wrong. From my experience, the project executes better when the client, the vendor PMs and the key contracting parties take a day or so to sit down early on and agree the basic standards and protocols that will apply to the project. This need not be complicated – for example, agreement on just half-a-dozen project processes will smooth the execution of 99 per cent of most projects.
If you ignore this advice, there is a very good chance that the deadly Delivery Dragon will get you!
Common errors
Commercial projects are also dogged by typical errors made by both client and vendor:
The client is frequently over-dependent on the vendor for risk, quality, and process management. The project environment can be overly complex, slowing things down and requiring political navigation. Clients fail to ask for meaningful status, fail to train their own staff, and often let the vendor drive the project by default. And if they don’t do that, then they micro-manage!
The vendor frequently underestimates the scope and ring-fences the project as it executes in a misguided attempt to limit scope pressures. This encourages the project to coalesce into vendor and client silos further inhibiting communications. Vendor reliance on PMBOK (Guide to the Project Management Body of Knowledge) as a common base for contracted projects is often unsatisfactory because the unique requirements of the commercial environment are not addressed. In fact, the negative silo mentality is reinforced by implication that the procurement process is initiating a second project, rather than a subcontracted portion of an existing project with which it should be integrated.
The takeaway
Procurement does not end at contract award. This misconception might have gained currency from the client view that fixed price contracts transfer all the risk to the vendor. This is true only in a limited way. A procurement lifecycle must be implemented by the client to efficiently manage project delivery as well as vendor selection and contract award. It would replace (thankfully) the steps described above, and actively promote vendor and client team integration. One critical point I must emphasize: this lifecycle is independent of the project lifecycle (aka application or development lifecycle) which is chosen to meet the needs of the work to be done (agile, iterative, waterfall etc.) and cannot meet the needs of procurement.
In ‘Commercial Project Management – A Guide for Selling and Delivering Professional Services’ published by Routledge and summarized here, I build a framework named the Commercial Project Environment to facilitate the vendor’s adoption of a full procurement cycle. This can easily be adapted to meet a client’s procurement requirements and in a future post, I will speculate briefly on how a more collaborative, but still competitive, procurement process could work (in the ideal world coming to a utopia near you). At the very least, the architecture identifies simple techniques that the vendor and client PMs can employ to eliminate silos and encourage management of an integrated project. No need to wait for utopia!
