Vendor Contract Administration

Many projects cannot go forward without the products or services from third-party sources, or vendors. If you have contracted with vendors for work on your project, you will have a role in contract administration . This is the process of tracking and verifying that the vendor meets the terms of the agreement.

Although some of the contract administration may be done through a separate procurement department, your relationship with the vendor is key to a successful project. You will need to receive progress reports from the vendor, resolve disputes between the vendor and your team members , and deal with vendor delays.

Progress Reporting

Progress reports from vendors are just as important as progress reports from your team members. Your vendor deliverables are part of your project schedule and may have dependencies with other tasks assigned to your team members.

The specifics of progress reporting from vendors should be documented in your statement of work (SOW). Communications with vendors tends to be more formal due to the nature of working from a contract, which has legal implications.

Even though the progress reporting requirements are detailed in your SOW, you need to make sure you are getting the data you need in a usable format. A written weekly report should provide a clear status on the vendor deliverables, including percent of work completed, confirmation of target delivery date, and any issues or risks that might impact delivery.

Some project managers also have a monthly meeting with the vendor to review progress and discuss any issues. The need for regular meetings fluctuates based on the complexity of the vendor deliverable and the length of time a vendor is involved on the project.

Managing Vendor Disagreements

Project team members and vendors may not always see eye to eye on how to approach a particular deliverable. This puts you in a difficult situation. The vendor has been hired because of expertise or experience in producing something you need, but the vendor deliverable has to integrate with the rest of your project. So if a team member tells you the vendor is going down the wrong path , what should you do?

You need to sit down with the team member to hear what they are really saying. You also need to hear the vendor side. The source of the friction could be any number of elements, which we will discuss in this section.

Misunderstanding on the Part of Team Members

It could be that the source of the disagreement is merely a misunderstanding. Perhaps your team members have always worked with one product; this new product behaves differently, but they're expecting the same outcome as with the old.

Misunderstanding on the Part of Vendors

Alternatively, perhaps the vendor has misunderstood what your actual intent is for the product it's going to supply. The vendor, after understanding the nature of the misunderstanding, might respond, 'Oh, well, Widget A won't do that, but Widget B will.' Sure, you should've gone through this discovery process at design time, but this kind of thing has a way of slipping through the cracks.

Paradigm Shift

It could be that the vendor's product is just fine for what you're trying to do, but team members have to go through a paradigm shift in order to effectively use the new product, and they simply have not yet made that leap. Think about the shift that old-school mainframe programmers might have had to make when object-oriented (OO) programming methodologies came about. In this example, you may have had several mainframe programmers who were used to thinking in top-down programming format and might've had a hard time grappling with object-oriented code (where you put an object on a screen, then write the underlying code for that object). A paradigm shift was required. Unfortunately, especially in OO, that shift is a hard one to make, especially if you're coming from the old school of programming.

The Ego Factor

Sadly, IT is an industry that's fraught with large egos. It could very well be that one of your team members has forgotten more about the product than the vendor will ever know, and he's prepared to tell the vendor so. Managing this kind of thing may require that you use 'tough love' tactics where you tell the team member to do things the way the vendor says they need to be done. Alternatively (and most often), you may have to replace this talented team member, because he will derail the project, by doing things his own way, more than he will help to get his tasks done. In the final analysis, it is, after all, all about tasks and their timely and successful completion that makes a project successful.

The 800- Pound - Gorilla Vendor

Some vendors have a 'my way or the highway ' attitude when it comes to their product. Some products, especially enterprise-class software, are so cumbersome that companies are forced to wrap their way of doing business around the product, rather than the product wrapping itself around the way the company does business. Additionally, some of these 800-pound-gorilla companies think nothing of calling you up, telling you that the latest revision is out, that your current version will become unsupported in a few months, and asking how soon you can be converted-all at a substantial cost to you.

If it's apparent that this phenomenon may come into effect, project managers can benefit from heavily weighing this 800-pound-gorilla incident to see if this is somewhere they think the project should go. In other words, if you marry into a software or hardware product that's a phenomenon all unto itself, then you're stuck with that phenomenon . When you're on board the Queen Elizabeth II , you go where the captain wants you to go (unless you buy the boat).

This is a place to weigh the disadvantages of integrated systems against the advantages. Suppose that you're using an enterprise-class relational database management system (RDBMS), one that comes with its own software development environment (SDE) or perhaps even with some canned apps that may loosely fit some of the stated deliverables of your project. Should you invest your company's development environment completely in this one large offering, or should you investigate to see whether other SDEs and tool sets may do a better job-if for no other reason than simply to avoid having all of your eggs in a single vendor's basket ? Normally, with integrated systems, you're worried about two different platforms (whether hardware or software) talking to one another. But don't forget to ask, 'Should I sell my soul to this company?'

A very germane (and often overlooked) element of project planning is to analyze the proposed platform to make sure that you're not steering your passengers onto a ship that they will have to be aboard for many years to come. If you were not far-sighted enough to spot this in the initial planning phases, then the best you can do at execution time is to make sure that the future caretakers of the system are aware that there will be ongoing maintenance issues they'll need to routinely deal with.

Tip  

Project managers who unknowingly lead companies into an unwanted marriage with an 800-pound gorilla may experience what a project management expert friend of mine lovingly calls a career-limiting move (CLM).

Platform Wars

This phenomenon is especially prevalent in the network operating system (NOS), SDE, and RDBMS camps. One person likes Unix; another won't do anything that's not Microsoftoriented. One group loves Oracle; another thinks that Sybase is the best. Developers are really funny about stuff like this-one talented developer will insist on using the Java language and a particular Java SDE, while another says that the best code comes from C++ and has the SDE to prove it.

Proactively, as the project manager, it's up to you to create early on a standards-based environment that utilizes the best-of-breed technologies for the given task at hand-often regardless of one individual's personal preferences. This is a really difficult call to make. You can reduce the difficulty by going to websites that specialize in IT research, sites that can give you vendorindependent advice about choosing a product. Gartner Inc. ( www.gartner.com) and IDC Corp. ( www.idc.com) are two such companies involved in this kind of research. You can do a lot of your research for free without having to purchase a subscription to their extended services, but for heavy detail and Q&A, you'll need a subscription membership.

At project execution time, if you find that platform wars exist you have to manage them by keeping people focused on the goal of the project, and try to steer folks away from the platform religious wars.

Tip  

Check first. Your company may have a subscription to one of the research groups, and you can set up conference calls with SMEs in the subject you're interested in researching .

Vendors may experience delays in completing deliverables, and you need to be prepared to handle these according to the provisions of the contract.

Vendor Delays

Some project managers mistakenly believe that just because you have hired an outside vendor to complete a portion of the project work, nothing will go wrong, and you can just sit back and wait for the deliverable to appear. This is not how it works in real life.

You may be getting ready to distribute your latest status report, when you get a call from your vendor telling you that their next deliverable will be two weeks late. What should you do now?

Meet with the vendor. You need to sit down with the vendor to get more specific information about the delay. This discussion can help you determine if there are alternative approaches to the issue that can shorten the delay, or if a portion of the deliverable can be completed as planned. You may not be able to resolve the vendor issue, but you need to make sure you have all the facts and understand what action the vendor is taking.

Involve your procurement or legal department. A vendor is doing project work based on a legal contract. If there is going to be a delay in the vendor deliverable, you need to understand the potential contractual impacts. There may be penalties or fines associated with any vendor delay, or you could even have cause to terminate the contract. You should not agree to any change in the vendor deliverable or schedule without the involvement of your procurement or legal representative.

Review impact to the overall project plan. Any time there is a delay in a deliverable, you need to assess the impact this delay will have to the project scope, the schedule baseline, the cost baseline, and resource requirements. A delay in a major vendor deliverable may create new risks that need to be added to the risk management plan.

Notify the sponsor. You need to get with your sponsor as soon as you have all the facts regarding the delay and have assessed the impact to the project plan. If the impact of the vendor delay is severe, the sponsor may choose to escalate the problem with a vendor executive.

Communicate to stakeholders. Information needs to be provided to the project team, the client, and any other impacted stakeholders as quickly as possible. Vendor delays can drive all sorts of rumors about the viability of the project, so you want to make sure that everyone has the facts.

Another difference in dealing with vendors versus employee team members is the oversight of the payments vendors receive.

Vendor Payment Process

The contract with the vendor should spell out how and when the vendor is paid. There may be a regular payment schedule or payment may be tied to completion and acceptance of specific deliverables. Although your accounting department will probably handle the actual payment of vendor invoices, the project manager may be the initial recipient of the invoice.

If you are responsible for approving payment of an invoice, make sure you understand what you are being billed for and do adequate research to confirm the payment is warranted.

If a vendor is being reimbursed based on a phased schedule of deliverables, you need to confirm both receipt and acceptance of the deliverable. Review the process and quality checks that were established to approve vendor deliverables before you approve payment.

Reimbursement of vendor personnel expenses should include receipts and an accounting of the purpose of the expense. If you are not certain of what is required, ask your accounting representative to walk you through the process.

If you are not clear on how the payment process is stated in the contract, request clarification from your procurement team. They are the contract experts, and can help you through the legal terms. If there is a difference of opinion regarding the money owed to a vendor, you will need to involve a procurement expert to work through the resolution of the dispute.

Dealing with Vendors

In this section, we'll discuss some of the methods you can use when working with third-party sources.

Communicate Effectively with Vendors

As the project progresses, you will be maintaining high-quality ongoing communications with the vendors who are engaged in your project. ' High-quality ' means that you have set up routine meetings in which you and the vendor have an opportunity to bring out issues and discuss solutions within a framework that allows for positive communications and problem-solving. If you have not arrived at consensus on what the work would be when you first started out designing your project and you did not thoroughly review the SOW, project progress meetings will clearly reveal the shortcomings as you may hit problem areas where the vendor won't go any further because they are not within the boundaries of the co-agreed-upon SOW.

In other words, you will find that most vendors are eager to work with you toward solving problems on the project within which they have proper purview. But vendors understandably get a little nervous when you're asking them to help you with something that was not clearly delineated at project creation time. This seems to be the area in which most project manager and vendor relations get into trouble.

Make Sure the Vendor Really Knows Your Needs

Be sure to carefully scrutinize the SOW. It's entirely possible that a vendor will leave out an element you specifically asked for (and that they agreed to) just because they overlooked putting it into the SOW. The SOW is a document that specifies exactly what the vendor is going to do, in return for a given amount of money. If you initially thought you had everything you needed stipulated in the SOW, but at project execution you see that there are missing elements, you're going to wind up doing some things you may have wanted the vendor to do. Or you're going to have to pay the vendor extra money to handle the extra work. This is why it's critical to understand exactly what the SOW is saying.

Real-World Scenario: Vendor Pushing Back Due to Incompletely Defined Requirements

Theresa is a project manager working on a large software-development project. The new software will replace an old legacy mainframe system.

When Theresa began the project she and the business analysts performed interviews with various business subject matter experts (i.e., people who understood the business process flows thoroughly) to determine how the new system should behave. However, due to the large geographic dispersion of the system, it was difficult to pin down certain individuals who were deemed key to the project. They were busy, or it was expensive to fly someone out to do the business interviews-it just seemed to Theresa like it was difficult to get good quality information out of some of the individuals affiliated with the initial requirements-gathering and design efforts of the project. Hence, the information, while certainly not describable as 'dicey,' wasn't exactly complete either. Even though Theresa submitted this as an issue, project stakeholders felt that there was sufficient information to go ahead and begin the project.

Now well into the project, some of the business subject matter experts have come back to look at what has been done so far and don't like what they see! They have asked for changes-substantial ones-that impact the scope of the project. Because they are deemed critical business experts, the sponsor thinks that their ideas have credibility and that Theresa need to take them into consideration. In fact, she wonders why Theresa didn't initially 'hear these people out.'

The vendor, a good one of high reputation, is working under a contract and has worked solidly with Theresa throughout the life of the project so far. The vendor has been there for all design and construction meetings and has complied fully with every letter of what Theresa had asked them to do. The vendor is now into other development phases and does not want to go back to re-visit previous work, especially because what they have done meets the criteria Theresa asked for and the system works perfectly . The vendor is now saying that they will have to charge extra money to put in the additions being asked for.

The sponsor is insisting that they did not live up to their end of the bargain. Theresa has documents detailing the deliverables that have been signed off by all parties as well as successful phase completion documentation that was signed off.

Theresa feels as though she is in a no-win situation. She cannot ask the vendor to go back and put in the additions and corrections without being able to pay them for the additional work. The sponsor thinks that Theresa should've gotten the straight story at design time and isn't willing to pay extra for the vendor to make the changes. She says that the vendor should assume responsibility for the changes because 'it's the right thing to do.'

Unfortunately, there are no good solutions to this problem. You have a sponsor who is pushing the onus onto you to solve the problem and yet the vendor is pushing back on you to keep moving forward.

The recommended approach in this case would be for Theresa to set up a meeting with herself, the vendor, and the sponsor in which she lays the cards out on the table. If there are areas where she made mistakes, now is the time for her to own those mistakes so she can move forward. The primary point here is to focus on truth-telling and getting the whole story across to all sides so that the vendor can clearly hear the sponsor say that they need to help make things right and the sponsor can hear them say that they're not going to do so. This takes Theresa out of the middle of the equation and gets both sides talking. Theresa is going to be held responsible for whatever outcome is derived from such a meeting. However, it is crucial that all sides meet together to hash out and work on this one specific problem until there is a satisfactory solution for each side.

 

Additionally, you'll find that a vendor agreement isn't a 'set it and forget it' type of arrangement. Even reputable vendors with your best interests in mind lose their way from time to time and forget to include an element you talked about. If a vendor says that they'll have a part to you on Tuesday at 9:00 A.M. by Federal Express, then you'd better have your eyes open looking for that part. If you see the FedEx truck come and go, you should be on the phone asking the vendor where the part is.

Do Your Homework before Vendor Discussions

You should ignore the 'our product can do that' statements when you're in your initial discovery meetings with the salesperson and SE. Their system might very well 'do that,' but you should do some investigative work outside the heat of the sales presentation moment before signing on the dotted line. Suppose, for example, that you want a website software package that will calculate sales tax for anywhere in the state of California. The SE might blurt out 'our product can do that,' knowing full well that it really can't, but if you're willing to write some code that digs into the vendor's API then it can. Unfortunately, in a sales presentation, the products usually look really, really good, so you may be inclined to accept the 'our product can do that' at face value and not investigate further.

Unfortunately, usually it's at execution time that you find out exactly what the software will and will not do. If you've hung everything on the initial sales meeting phrase, 'our product can do that,' and you find out it really can't, the project execution phase is not the time to find out about it! A little pre-project research into the capabilities of the products being considered will go a long way toward eliminating this issue.

Practice Smart Negotiations

Finally, things get tacitly agreed to when it's you and the salesperson and he thinks he's closing the deal. As a general rule of thumb, the larger the sale, the more likely you're going to get a bone or two thrown your way at deal-arranging (but not necessarily closing) time. Be sure to write down those promises for later when you go into the room and close that deal. You'll actually say, 'OK, before we go forward, I just want to validate what you communicated to me the other day-that you'd do blah blah, and also blah blah.' You'll want these commitments in writing because after the deal's closed and the salesperson's onto other accounts, it may difficult getting him back to the table to talk about those add-ons he committed to.

Tacit agreements especially play themselves out during project execution. Suppose, for example, that you and the vendor were going over a component of the project and he said, 'I'll do some checking and get back to you. I think I can get the company to provide you that part at no charge.' You leave it at that for the moment. Now well into project execution, you need that part! Because the agreement wasn't committed to paper and agreed to by both parties, you may have a difficult time getting the vendor to do that checking and find that free part.

Tip  

Be sure to understand a vendor's maintenance and support policies as well. Lots of vendors offer Bronze, Silver, and Gold support plans. What is it you're signing up for and what do you get with that? What will be the annual maintenance costs (if any) that you'll incur as a result of purchasing this vendor's software or hardware? Some vendors make their real money through support and maintenance, not necessarily the software or hardware they're selling. So be sure you understand what their complete offering is going to cost you from this time forward.

Case Study: Chaptal Wineries-Email and Intranet

You're several weeks into the effort to bring your international winery acquisitions into the fold. France's and Australia's server and telco installations are complete. Weekly reports to Kim Cox look similar to the graphic below.

You've approved several invoices for payment-forwarding them back to the Chaptal finance office to cut the checks. You've approved payments for the Australian and French telecommunications installations (after validating that the installations were up and completely operational). The internetworking gear contractors for both of these regions have been paid and you've noted the tasks complete on the project plan.

Now you're concerned about the T1 dropping in Chile. You're beginning to wonder if maybe the internetworking contractor you retained has something misconfigured and doesn't realize it. You make a call to Metor and ask him to call the vendor to have someone else other than the contractor you've been dealing with come out to verify the configuration. Metor's afraid that the contractor may want to charge you more money for validating the configuration, but you fax Metor the SOW and point out to him that the contractor has committed to making sure that connectivity is up 99.8 percent of the time until you've released the vendor and okayed payment. Because the circuit has been up only about 50 percent of the time, you're clearly within your rights to force the vendor to send someone else out to validate the configuration.

Metor agrees to call the vendor and get a different technician out to check the configuration. Sure enough, the Open Shortest Path First (OSPF) settings in the router are not correct for the circuit. When the new technician makes an adjustment, the circuit comes up and stays up fulltime thereafter. At next project status meeting, you note that the task is 100 percent complete.