All project managers (PMs) should have at least a passing familiarity with vendor management. Many projects require that certain aspects are handled outside of the organization for which the project is being completed, by vendors external to that organization. Furthermore, as a PM involved in a project that you may be completing for an external client, it is essential to understand how you may be managed as a vendor. Similar concepts may also be employed intra-organizationally, in cases where an internal Information Technology (IT) group is supplying services to departmental, business unit or similar organizational divisions, particularly in cases where internal chargebacks for services are applicable.

In this article, we will expose various aspects of vendor management that may be readily apparent, and some that may very well be hidden. If your organization routinely outsources projects of any type, the concepts included here may help you to wring the most value from your chosen vendors. Even companies, in which the vendor management discipline is institutionalized, may wish to review these fundamentals against their own strategy to determine whether additional tactics can or should be employed.

It is important to remember that the essence of any vendor-client relationship, in order for it to bear fruit, is that of a win-win. Both sides must derive some value from the combined effort of the partners, if the collaboration is to be considered a success. If either party fails to achieve a win, neither party should consider the engagement to be a success.

The scenarios discussed in this article will relate to software – either bespoke development or commercial package implementations – as these are the cases most familiar to me. However the concepts apply to virtually any service-oriented, contract delivery.

Individual tactics will be discussed as the building blocks needed to formulate an overall strategy. Ultimately the strategy should reflect your organization’s fundamental core values.

Preparation

There may be many factors leading you to a decision to outsource or contract out a project. These may include (among others):

• Resource constraints – your existing staff may not have the availability or technical skills.
• Risk – it may be prudent to outsource projects that are higher risk to your organization because they may not represent that same level of risk to a vendor.
• Non-core activities – the requirements of the project are such that the expertise necessary is not a core competency of your business.
• Tax considerations – it may be possible to capitalize certain project costs.
• Lower labor rates – this is mostly the case if the outsourcing is to an offshore vendor from a location with high internal labor costs.

As with nearly any well-defined processes, vendor management goes through specific stages. The initial preparation consists of:

• Making the decision to outsource based on one or more of the reasons stated above.
• Gathering the background information on the project.
• Preparing a Request for Information (RFI), Request for Proposal (RFP) or Request for Quotation (RFQ). Henceforth these will be referred to collectively as RFP, with the understanding that the actual request could be any of these three.
• Estimating the effort of doing the work internally (if possible) as a means of validating whether you’re getting a fair price.
• Establishing the parameters for vendor assessment.

All of the stages of the process are shown below with major milestones included.

Initial Skirmishing

After preparation, management of a vendor is typically initiated by submitting an RFP. Describing what goes into an RFI, RFP or RFQ is beyond the scope of this article, but suffice it to say that many companies may have their own, different ideas about the expected response, so you should clarify to each vendor what you expect to be included. To a certain extent, you should judge each vendor on how clearly they frame any questions to you regarding the response and the scope of your RFP.

Sometimes, your initial inquiry may consist of a Non-disclosure Agreement (NDA) that is preparatory to issuing an RFP. Do so if any information in the RFP should be considered confidential. You should take it as a sign of professionalism on the part of the vendor if they ask you whether an NDA is required, when you have not already requested one. Since NDAs are typically formalities, the execution of such a legal document should proceed with little delay. Once again, responsiveness on the part of the vendor should be considered during assessment.

Vendors should be given a reasonable time frame to respond to your RFP. In IT projects especially, it is often times the case that initial effort estimates may be low. Usually a well-crafted, project estimation should undergo multiple levels of review to improve the accuracy. Issuing an RFP with an unrealistically short time frame is a tactic that may reduce the price offering, or it may inhibit prospective vendors from responding due to this same concern. Remember that prospective vendors always have a choice as to whether to submit a response to an RFP, and my previous article on Simple-Talk describes some of the considerations in making that choice (see The Proposals Conundrum).

Obfuscating complexity within the scope of your RFP is another tactic that can be employed to reduce the price point of responses from prospective vendors. While not specifically recommended, it often occurs unintentionally due to confidentiality concerns. It may not be prudent to disclose all details of a project to your prospective vendors, even when an NDA has been executed. However doing this may diminish the likelihood of achieving a win-win with the winning vendor.

Typically, when an RFP goes out, you’ll want to send it to multiple vendors. It is important to level the playing field among them by ensuring that all are provided the same level of information. Typically vendors will ask questions while they are preparing their responses (that is why this period is called Discovery). All vendor questions and your answers should be consolidated and distributed in a time frame that is reasonable to allow them to complete their proposal preparation within the deadline you have set. Setting a deadline for submitting Discovery questions is important to facilitate this.

The Proposals Conundrum article recommends that prospective vendors should attempt to engage you in a small, compensated business consulting session to allow them to expend the resources required to do a deep-dive into unclear requirements. This is a great way to get to know a prospective vendor, particularly if you’ve never worked with them before. Consider this as an opportunity for you as the client as well; however I wouldn’t recommend engaging multiple vendors in this manner, at the same time and for the same project.

Once the responses come in, the Assessment stage has begun. Consider asking the vendor to do a defense presentation of their proposal. Again, this is a great way to judge the professionalism of the vendor, and it provides you a specific forum to receive answers to questions you may have from their response. Note that the proposal defense presentation is not the right forum to begin price negotiations (although this often happens). After the defense presentation, don’t be surprised if some revisions to the vendors’ proposals are needed. The more revisions necessary to a specific proposal, the lower the assessment of that particular vendor probably should be.

Other specifics of the assessment process are probably too detailed to go into here. Some companies are quite methodical, some are a little more qualitative and for others the main determining factor may solely be price. My recommendation is that you develop a quantitative assessment matrix that incorporates qualitative and quantitative aspects of the response. You may wish to include in that assessment a measure of how financially viable each vendor is, so that you don’t get an ugly surprise in the middle of your project when that vendor files for bankruptcy.

Once you’ve completed your assessment, then and only then, is it appropriate to begin negotiations on what the project is to consist of. The proper sequence of negotiation is scope, responsibilities, deliverables, timeline and lastly price. It may be appropriate to begin to address the first four during a proposal defense, but ultimately further negotiation on these points may be prudent after the assessment, once you have seen what all of the vendor are offering.

Vendors need to be particularly cognizant of the proper ordering of negotiations, because the last thing you want to happen is to agree on a price and then have the prospect change any of the other aspects of the project. If you find that your prospect focuses on price in the initial stages of negotiation, it is a likely indicator that they are particularly price-sensitive and/or may be judging the proposal solely on the basis of price.

Normally at this time it is appropriate to short-list the vendors down to two or three.

Next comes negotiating the price. Some may consider it a bit unethical to negotiate on price with more than one vendor at once. For other companies, this may be routine. Doing so allows you to play off pricing of one vendor with another, without the competing vendors understanding that there may be subtle nuances between the proposals that account for price differentials. Depending on the initial proffered discount, the vendor may have limited room to negotiate additional discount. My personal preference when submitted a proposal is never to offer a discount on initial submission, thus allowing the most flexibility during negotiations and maximizing profit potential.

Once again, the tactics of negotiation have filled many books, so a detailed description is beyond the scope of this article. A fictional character known as Lord Chandos once said that “flattery is the infantry of negotiation,” so don’t be afraid to throw in a little flattery about the vendor’s abilities, professionalism or candor, and you may find a concession or two thrown your way. In the end, you’ll make a selection, and if you truly value your vendor relations, you will consider other things besides the lowest price to get you the best possible service.

Finally, in many cases there will be a legal agreement that details the specifics of the project and its delivery. In the software development business, this may be called a Software Development Agreement (SDA), and it establishes the framework upon which the change management process is predicated. When defining the project scope in any legal agreement, do not be surprised if the vendor wants to include specifics of what is not in scope, in order to clearly establish the boundaries of what is in the scope.

During the Engagement

Managing your vendor during the engagement stage is certainly as important as the managing you did in prior stages. There are companies that like to “throw a project over the fence,” and simply stand passively by while the vendor completes them (often with much struggling). Engaging with the vendor throughout the process is much more productive.

If it hasn’t already been done, roles and responsibilities (to individuals rather than positions) should be clarified and agreed at this time. Also, and again if it hasn’t already been done, you should clearly establish what your expectations are with regard to the quality of deliverables.

There will always be questions that come up while the project is in progress, so be sure to allocate plenty of time for your resources to provide support; both material and knowledge. You know your business much better than your vendor will, so it is essential that sufficient business knowledge is transferred, to the extent that it supports the requirements of the project.

At this point in time, it is the project that should be the central focus for success. You’ve determined that you need it done and you’ve also decided which vendor is the most likely to be successful in getting it completed. Now is not the time to allow personalities, environmental factors or politics to stand in the way of project completion.

The most important behavior to exhibit during the engagement stage is facilitation. You’ll want to remove any obstacles that may delay or prevent delivery by the vendor. When issues come up, and they always will, you need to focus on clarifying or eliminating them as quickly as possible, so that ultimately they only minimally impact the project.

The second most important aspect of managing your vendors during the engagement is to ensure that what they deliver is what you agreed on initially. This should have been clearly laid out in the proposal, the SDA or equivalent.

Change management, once again a process too detailed to describe well here, deserves a significant amount of consideration with respect to your management of the vendor during the engagement. Some companies I’ve encountered actually try to establish Key Performance Indicators (KPIs) that discourage changes from being accepted into a project, so that the initially agreed price is not affected. My perspective has always been (and my experience has confirmed) that some change is inevitable during the course of a project. Expect some change and handle it gracefully. During the initial budgeting, you should plan for some amount of cost change (usually between 10-20%) to creep into a project.

Finally, and this is also something that you must continually assess throughout the project, is whether the quality of all project deliverables meets your expectations. Since you’ve already established what those are with the vendor, establishing that they are met should be relatively straightforward. You should not feel obligated to accept deliverables that do not meet your expectations of quality, assuming these expectations are reasonable and previously communicated.

The Aftermath in Perspective

Once the project completes, the vendor management lifecycle enters the Valuation stage. Companies that have institutionalized vendor management will at this time assess the value delivered by the project in terms of how its vendors were managed. The first consideration should be whether the project can be considered as a preliminary success (see How to Avoid Software Projects Failing for some considerations).

While measuring whether all project deliverables have been delivered is rather simple, evaluating the quality of those deliverables is more subjective. You should go through the exercise of rating each deliverable on a scale that supports cases where the vendor has actually exceeded your expectations.

Rarely is there a project that can be deemed an unqualified success, so extend that rating to each aspect of the initial contract including any schedule or budget variance, and whether the vendor actually exhibited all of the skill and talent that you were initially led to believe during the selection process.

Finally, share these vendor and project ratings across the organization, as they will be useful the next time a project comes up for bid.

Recap, Conclusions and the Final Word

Some of the sub-headings in this article are reminiscent of the battlefield, mostly written this way to add a bit of theatrical effect. It is important to remember that the vendor (or your customer) is not your enemy, but it is nearly as important to remember that often, they are not your friend either. The ideal relationship to achieve the goal of the win-win is best described as a partnership, in which neither side is overly competitive with the other. If either party is too competitive, it is likely the relationship will end up as a loss for the less competitive party. If both parties are overly competitive, this will surely distract from the engagement and reduce the win for both sides.

Engaging with a vendor is a good way to offload risk, assuming you select a vendor that is in a better position to manage that risk. If risk is a major factor in the decision to outsource, be sure that you select a vendor that has the capabilities available to reduce that risk for them, otherwise the project is likely to be impacted and the win-win scenario will not be achieved.

We have not mentioned excellent, accurate and timely communications so far, mainly because this is essential in any project management scenario and is important across all stages of the vendor management lifecycle as well.

If you start with the goal in mind that the win-win scenario is essential to your project’s success, you will likely achieve it. As win-win scenarios accumulate with your vendors, you’ll be continually turning towards the vendors that have achieved the most successes, to further reduce the costs to your business that failed projects bring with them. If you constantly win but your vendors lose, don’t be surprised if those wins are not repeatable as vendors start to decline opportunities to serve you.

Finally, I have a word of caution to prospective vendors that don’t have a lot of maturity. If you are dealing with clients that have significant vendor management maturity or for whom vendor management is institutionalized, you must be circumspect with respect to the quantity of concessions that you accept, lest you sacrifice the win-win in favor of simply winning the business. Remember the words of Konrad Adenauer – “The one sure way to conciliate a tiger is to allow oneself to be devoured.”

I’d like to thank my valued readers for their attention, while together we explored these fundamentals of vendor management.

Dwain Camps