10.2 Existing Vendors

< Day Day Up >

Many projects require the participation of vendors that your corporation or agency already has under contract. Vendors whose behavior is generally proscribed by this process typically provide "commoditized" products or services such as:

Network transport - voice or data circuits and services
Hardware - routers, switches, computers, and servers
"Shrink-wrapped" software - spreadsheets, accounts payable
Operating systems - desktop and network
Support - help desk, fault management, "break-fix"
Procurement - resellers who deliver equipment and software
Staff augmentation - short-term help or technical consultants

A formalized relationship management team tasked with managing vendor relationships is probably in place in your shop. Vendor, product set, or service type may align the team. The focal point may be in a product management group, or within the purchasing department. The degree of control they exercise over the relationship may be quite strong. Likewise, such mechanisms can be extremely political, particularly if you approach the vendor without understanding your vendor management's mission and process. In other words, circumventing their process, either willfully or through unfamiliarity, can be hazardous to your project calendar's health.

Therefore, if you intend to leverage existing relationships to buy products or services, make it your business to hook up with your internal vendor or product management team before you get too far into the process of engaging that vendor. This includes requesting budgetary pricing or initiating exploratory conversations regarding services they offer that appeal to you from a project perspective.

Exhibit 2 highlights preferred behavior when engaged with the people in your organization who are charged with overseeing vendor contracts.

Exhibit 2: Rules of Engagement for Your Vendor Management Team

Make them aware of your project and your interest in leveraging an existing relationship.
Provide detailed requirements you look for the vendor to provide.
Determine if any requirements are provided, or precluded, by existing contracts between your organization and the vendor.
Ask what specific benefits may accrue to the project (e.g., discounts, free services, etc.) by using this incumbent vendor.
Understand how you can, and cannot, communicate with the vendor.

I have seen cases where it is okay to go directly to the vendor without vendor management tagging along. I have also seen the opposite, where I could talk to a vendor about approved products or services (i.e., technical things), but was definitely prohibited from discussing pricing or other business-related topics. The bottom line is that you need to gauge, as early on as possible, how your company does business with this vendor and whether or not that meets your needs. I have had as many pleasant surprises in this area as disappointments. For instance, I learned that existing contracts with two big vendors provided certain project services at prices far lower than an internal group I was told to use would charge, with the same or better service levels.

On the other hand, I have been told that Vendor X could not provide a product or service I felt quite certain they could, or that their pricing, service levels, or availability was disadvantageous to our initiative. Equally distressing is the discovery that vendor management can exercise veto power over certain kinds of purchases, particularly based on technology standards. Please refer back to Chapter 2, where additional detail on this topic was provided under the tag of "standards police." You may find that vendor management appears to have more input about how you can implement your requirements than you do. Not that this happens all the time, but when it does, technology and calendar issues are usually too pressing to allow you the luxury of working your way through this without intense escalation and negotiation.

Not only can the process not necessarily be tailored to meet your needs, but there is a chance that the vendor is unaware of you and your project. I once had to escalate a technical issue with a vendor with whom we were soon planning to place a multimillion-dollar order based on corporate standards. I chose to go to the senior account manager to get our problem resolved. Fortunately, he knew about our project. Unfortunately, my name was unknown to him. As a result, his initial response back to me was a tad more lackadaisical and pompous than I was comfortable with. We worked our way past that glitch and resolved the real issue to my complete and total satisfaction - and rather quickly at that.

This is lesson one in vendor management for project managers. We may have been forced to buy through this person. He, in turn, may have felt I was just another yippy customer not in his cell phone speed dialer, at least until I took it upon myself to impress him with my importance! Some folks shy away from this scenario, while others enjoy thumping the table. The approach I prefer is to inform the vendor that I am responsible for making this project fly right, and I need his or her help to ensure that no one is embarrassed by the results. It turns out that this vendor rep was adequately conscientious once I pushed the right button.

That button is likely to be that these individuals have strategic goals within your organization - goals upon which their commissions are based, perhaps as much as those quotas related to sales volume. Knowing this, I asked the salesman what his strategic goals were. One of them happened to involve a technology we were considering using, so I offered to push his goal if he would move heaven and earth to solve my original problem. We both honored out commitments, and the project was definitely helped by this.

< Day Day Up >