Get to the core of vendor management problems

Among the organizations struggling with outsourced projects that have gone bad, or that have failed completely, the most often-cited reason is vendor management issues, as if the vendor is always the one to blame and the buyer is completely blameless. Rarely is this the case. Upon closer inspection, and in nine out of 10 instances, the root cause of these often unspecified vendor management problems leading a project astray or into failure can be traced to poorly defined requirements. While clear requirements are at the foundation of any project, they are even more critical for outsourced ones where the “rule of law,” in the form of a contractual relationship, governs the nature of the relationship between buyer and seller.

The results of a new survey conducted by ESI International show that the top risks of concern to organizations when outsourcing also can be traced essentially to poor requirements management.

Approaching requirements
In its simplest form, the way to attain better project requirements is to start by thinking about four things:

• What do you need to buy? – The project deliverable
• When do you need it? – The schedule for delivery
• How will you pay for it? – Timing to withhold payment along the project life cycle to mitigate risk
• How do you know you ultimately got what you wanted? – Process for quality review, inspection and acceptance

The best start to improving your requirements is to begin with the right team. Utilizing an integrated project team (IPT) model is a proven way to ensure greater efficiencies in project delivery and, in turn, better results in project and program management. Of the three major roles of an IPT – the contract officer/subcontract buyer role, the business analysis function and the project manager – it is the project manager’s job to ensure the four requirements questions are addressed in a clear, concise way.

Greater diligence required
In addition to forming the basis for success throughout the project life cycle, requirements also need to be gathered diligently and expressed clearly so that an appropriate contract type can be selected, and that vendors will actually submit a bid when the RFP is released. For example, if the requirements are “murky” and a firm fixed price contract is to be awarded, expect that the vendors, if they bid at all, will cover their risk by increasing their price of delivery.

Yet, the ESI survey on outsourcing shows that organizations are not as diligent about requirements as they need to be. Only 26 percent say they always clearly define requirements. That means three-quarters of organizations come up short when managing a key driver of project success. Is it any wonder that most contract files are stuffed full of “change orders”?

Additionally, as business analysts carry out the process for writing requirements, from gathering and defining requirements to writing a first draft and conducting the stakeholder review through to the final draft, they tend to go about the process the same way every time, thereby creating the opportunity to repeat faulty requirements gathering methods. Let’s steer clear of the “blame the vendor” mentality and get to the heart of the problem: poor requirements means higher costs, greater dissatisfaction and delays. So, rather than say we have a “vendor management” problem, let’s just own up to the fact that we have a “requirements gathering and writing” problem. That’s a problem that can be solved fairly easily.