Managing the Vendor
Value for money is the name of the game in relationships with the vendors engaged by your project. The intent of this article is to provide the project manager with tips and tricks which will help you get the most value out of your relationship with your vendors. It does not contain any advice on how to select the vendor; that’s the subject of another article.
Your relationship with your project’s vendors will be shaped by the nature of the goods or services that vendor provides to the project. The relationship you need to cultivate with a vendor providing all the construction services for a real estate development project won’t be the same as the one you need with the vendor of your office supplies. The activities required to manage the relationship will also vary with the scope and complexity of the goods and services they are supplying to the project. Some of the tips and tricks in this article will be applicable to any relationship, while some will only be applicable to the largest.
Customer/vendor relationships should not be adversarial even though the goals and objectives of the customer do not align perfectly with those of the vendor. The best relationships are those where there is mutual benefit to both parties from the relationship. You are the customer in this relationship and this gives you a majority of the power; use it wisely. You should take ownership of the relationship and responsibility for establishing a cordial relationship.
Treat the vendor like a partner because that’s what they are. They are (or should be) committed to seeing your project succeed; if the project fails, the failure may have a negative impact on the vendors profit. Even if there is no impact on vendor profits from a failure it will likely have a negative impact on future relationships, especially if failure on the vendor’s part is perceived to be a cause of the project’s failure. No vendor wants that kind of outcome. Here’s a checklist of some of the things you will need to do to foster your relationship with the vendor:
- Be accessible to the vendor’s representative. Be available in person, by phone, or by e-mail.
- Invite the vendor’s representative to status review meetings.
- Create a distribution list for each person in the vendor’s organization requiring project information. You can let the vendor’s project manager assume responsibility for information distribution, if the project is large enough to require one.
- Include everyone on the vendor distribution list when communicating with the team. This includes weekly status reports, issue logs, etc.
- Require status updates from the vendor’s project manager, or representative. These updates should be in the same form as others from your project team.
- Invite the vendor’s project manager, or representative, to Project Sponsor or Steering Committee meetings. You don’t have to invite them to every meeting but they should attend those meetings that occur during critical points in the vendor’s project. They may or may not wish to present but should be on hand to answer questions.
You start the relationship during your solicitation process. Readers who are PMP® certified, or who have prepared for their certification by taking a PMP® course, will know that informing the solicited vendors is a key project management responsibility during this process. My intent here is not to offer any advice on conducting that process, but to emphasize the importance of providing the vendor with all the information they need to be successful, starting with the RFP, RFQ, RFI and concluding with final delivery of the last product or service. Start the communication process early and cultivate it throughout the project.
Start by communicating your project management plans with your vendors. For most projects most of the planned activities will be described in the MS Project file which will include the WBS and project schedule. The vendor may have their own MS Project file (or other files that include their WBS and schedule) in which case they should have read access to your file and you should have read access to theirs. Your schedule should include the vendor’s key deliverables and milestones. Their schedule should support the forecast completion dates in your schedule and the schedules should be updated and synchronized at least once a week. Dependencies between activities in the two schedules should be captured and tracked.
The other plans that comprise your "project management plan” also need to involve your vendor. Depending on the size and complexity of the products and services the vendor provides, they may need to craft and implement their own plans in the following areas: Communications Management, Change Management, Requirements Management, (Human) Resource Management, and Risk Management. The only part of the project plan you should not expect your vendor to share with you is their Procurement Management plan. Any items procured externally be your vendor which are critical to your project should be covered by the contract, SOW, WBS, schedule, or other plan.
Your Communications Plan should should include any information and reports that your vendor is responsible for providing. These may or may not be referred to specifically in the SOW, or be an outcome of your joint planning sessions. The SOW should be the starting point for the communications you receive from your vendor, as you plan the project together with the vendor your information needs will become clearer and the lack of specific reference to a report in the SOW should not prevent the vendor from providing it. You will however, need to agree with the vendor on any information not covered in the SOW. Your communications to the vendor will also be covered in the plan. Review those communications with the vendor and be prepared to alter it to include any information not included that the vendor deems important. Updates to the plan should also be coordinated with the vendor.
The Change Management plan is a critical touch point with your vendor. Your responsibilities in this area may be limited to keeping the vendor informed of any changes that could impact them. Your Change Management plan will be constrained by the contract between your organization and the vendor in larger, more complex, relationships. Requested changes to your project that would change a vendor deliverable or milestone, will require a "shadow” vendor change management process. This process should be captured in a plan which is synchronized with your project’s Change Management plan. Key elements to capture in both plans will be:
- Type and timing of change request information. This includes any forms used, registers to capture change request information, and response times.
- Key contacts for receipt of change request information for both yourself and the vendor. If either you or the vendor have identified a change manager, or change coordinator other than yourself, or the vendor PM, identify those people.
- A description of the estimation process. Procurements that are governed by a contract will usually provide for a cost estimation process for requested changes. This process should be captured in both Change Management plans.
- An escalation process. The plans may refer to the escalation process in the contract where one exists and should define one in the absence of a contract process.
- A description of the implementation process for approved changes. The description should support the coordination of the changes to both sets of plans.
Both change management processes (yours and the vendors) must conform to any contract terms governing changes to the project. A contract should stipulate the escalation process to be used when you cannot agree on what constitutes a change or how much a requested change should cost. Include the escalation process in your plan if a contract does not exist. Both plans must detail how they interface. When your stakeholders raise a change request which would require a change to the vendor’s sub-project, how will the vendor be notified? Will the two processes use the same change request form, or will each require its own?
Coordination of changes to the project is critical to project success. Changes that are not coordinated will cause planning to become asynchronous and your project’s goals and objectives will not be achieved as a result. Avoid this disconnect by holding regular meetings with your vendor to review requested changes. These meetings should resolve timing issues (when a vendor’s estimate will be received, when your project decision will be communicated to the vendor, etc.) and align requirements across project and vendor change requests.
The vendor should not need to coordinate their Requirements or Scope Management plan, Risk Management plan and (Human) Resource Management plan with you and your only interest here is a reassurrance that they are robust enough to achieve the objectives of the sub-project the vendor is managing. You should not be managing the vendor’s project for them, but you can offer to coach the vendor in this area.
Vendor Project Manager
The contract may cover the engagement of a project manager to manage the work contracted for with the vendor, it may even specify the skill set and professional accreditation that project manager must have. Your only responsibility in that case will be to ensure the project manager selected by the vendor meets the criteria set forth in the contract. Your responsibility, in the case where these criteria are not covered in any contract, will be to identify a reasonable set of criteria for that role and ensure the proposed project manager meets them. Make your criteria fit the size and complexity of the sub-project. It’s unreasonable to expect a vendor to assign an experienced, PMP® certified, project manager full time to a $5K sub-project. Provide your input into this decision early. It’s likely that your vendor will take reasonable measures to ensure you are happy with their choice but cannot take your criteria into consideration unless they know them.
Now that you have the ideal project manager controlling things on your sub-project, it’s up to you to cultivate that relationship. You wield power and influence in this relationship because of your position as the customer representative on the project and can use that influence to increase the vendor project manager’s chances of success. Vendor success increases your chances of success and the larger and more complex the sub-project is, the greater its influence. One way of influencing the relationship is by showing all the project stakeholders, on your side and on the vendor’s side, that you have a high regard for them. Base that regard on their importance to the project, not on their qualifications. This should be the case even when the project manager does not have the qualifications you wanted.
Treat the project manager as a peer on a personal level; reserve your influence for situations where it can help the vendor project manager. There may be project information that does not affect the vendor which you are not at liberty to share with them. Share everything else and explain the reasons for your inability to share sensitive information. The more aware your vendor PM is of the project environment, the better job they can do managing their sub-project. This is especially so in the area of risk management.
The vendor project manager’s project plans are components of your overall project plans and must be properly integrated so your planning activities should be integrated. There may be planning areas where your involvement will not add value. This will be the case when planning details of the work that is the vendor’s core competency. Don’t intrude in those cases; you should limit your interest to ensuring that deliverables are produced on time and milestones are met. Other areas will require you to work closely with the vendor project manager, make that working environment as comfortable as possible for the vendor PM. Some areas that may lend themselves to a combined approach are:
- Risk workshops
- Scheduling work
- Identifying dependencies
- Managing changes
Once you have coordinated your plans integrate your project management. Be the first escalation point for the vendor PM when the vendor sub-project encounters obstacles. You can use your influence to resolve issues for your vendor PM. Let’s use the case where your vendor PM identifies a need for a critical resource in your vendor’s organization, but is denied access by someone in the organization with more political power than your vendor PM. Don’t hesitate to help them overcome this disadvantage by explaining the importance of the resource to the vendor. You may even want to have your project sponsor/executive sponsor help in getting the critical resource.
Establish an environment of trust where information is shared without fear of retribution. You can do this by looking for an early opportunity to turn the disclosure of bad news into a positive experience for the vendor PM and you do that by looking for ways of helping him or her deal with the problem. One situation which is bound to arise when the vendor is performing project work for you is a late delivery. Your vendor PM should approach you as soon as they become aware that a delivery is likely to be late, and when they do so you need to look for ways of helping them deliver on time, or deal with the shortfall if that can’t be done. Offer them resources that would help them to meet the deadline, if that can be done without jeopardizing the project. The key to this relationship is your knowledge of issues with the vendor’s sub-project in time for you to help resolve them.
Your procurement management plan should support a verification process as part of acceptance of the vendors deliverables. This holds true whether or not your project is responsible for any quality or not. This process should be coordinated with the vendor payment system. Payment should not be released by your finance department without your authorization. Your authorization should only come when the deliverables have met all the conditions stipulated for them in the SOW or contract.
Deliverables that fail to meet standards or criteria set for them should be returned to the vendor for correction. Failures should be tracked in a bug reporting system and approval of the deliverable should only be given once all reported errors have been corrected. Your procurement management plan should also describe audit activities required to validate vendor work or products. You should identify a hold back amount so that final payment will not be made until all deliverables have been received and all defects corrected. Your dispute resolution process should also support disputes over product defects, so that disagreements between your testers and the vendor’s testers can be resolved.
The SOW is the document that describes all the work the vendor is to do for you, all the deliverables they are responsible for producing, the milestones they are responsible for meeting, and quality standards they must support. The SOW will support the contract, if a contract exists. The original description of the work may be captured in the SOW and transcribed to the RFI, RFP, or RFQ. Otherwise the SOW must be produced from the RFP, RFQ, or RFI used to engage the vendor. Procurements that do not require any of these documents should not require an SOW either.
The SOW should not only cover all work and goods required by the project, it should contain all the administrative work as well, including the work of the vendor’s project manager. Some of the items that should be included are:
- Vendor progress reports
- The vendor’s work breakdown
- Creation and maintenance of all vendor project plans
- Phase Exit Reviews, Gate Reviews, Business Decision Points, etc.
- Issue Logs/Action Registers
The SOW need not be specific as to which reports, meetings, etc. are to be included as long as language is included that specifies the standard of management expected from the vendor. The reason for including these services in the SOW is so that the vendor’s senior management does not harbor a mistaken expectation that you will manage their sub-project for them.
From the point of the engagement forward, any work that the vendor performs for you, or goods they deliver must be contained in the SOW or introduced to the project via a change request. Conversely, you should ensure that the vendor is not doing work or producing products that are outside of the SOW as this may have a negative impact on their ability to deliver the planned work or goods.
The key to a successful procurement is to establish a solid working relationship with the vendor. Your job is to establish that relationship and nurture it over the course of the project. This article assumes that the vendor is genuinely committed to fulfilling the conditions of their engagement. Where that is not the case, you must confront the mistake you made in selecting the vendor and escalate the issue to your project sponsor. Nurturing of the relationship starts with accurate and timely sharing of information. It is also helped by a well defined dispute resolution mechanism so that minor disputes don’t derail the project and major ones are resolved by the right people.
Your best ally in the customer/vendor relationship is the vendor’s project manager. Encourage the vendor to engage a project manager by stipulating that role in the SOW. You should also include any criteria you feel are important to the project, such as PMP® certification, etc. Once the vendor places a project manager in front of you, do your best to foster that relationship by treating them as a peer and offering them support whenever possible. Share all project information with them that you can and expect the same from them. Make certain that they alert you to trouble in their sub-project as soon as they become aware of it.
Ensuring that the vendor lives up to their end of the agreement is your responsibility. You must protect your organization from any mistakes by auditing the quality of the services and goods the vendor provides. No invoice should be paid until you have verified that the goods and services billed for have been provided and there are no outstanding issues with them. You should ensure there is a final hold back that does not get released until all goods and services have been delivered and all issues have been closed.