Best Practices in Vendor Management

This article was originally published in VSJ, which is now part of Developer Fusion.
Without a textbook to clearly outline a set of techniques for dealing with vendors, learning-by-doing becomes the norm. Project experience becomes the teacher. Over time, architects must learn to develop strategies and techniques for working with vendors to ensure a successful project implementation.

My first learning experience in vendor management was in the role of lead architect on a global portal project. It was a brave new world of Internet applications, and clients were clamoring for portals to create online communities. The integration of new technologies introduced plenty of risk to our project without the added challenge of managing a stable of vendors and their products. Looking back on the project, I realize that the lessons I learned provided me with invaluable experience to draw from in later projects.

Vendor Evaluation and Contract Negotiation

Soon after I joined the project, I encountered our first vendor-related challenge. The personalization engine was slowing down page loads. While our on-site vendor specialist did try to resolve the problem, we weren’t seeing any improvement. I approached our account manager with the issue and received a response for which I wasn’t prepared. I was told that a specific SLA for page loads was not in the contract. In other words, if it wasn’t in the contract, the vendor wasn’t required to deliver it.

Not having been involved in the vendor selection and contract negotiation process, I was at a disadvantage from day one. Our client had selected the vendors, and my company was the implementer in place for integration. The contracts covered a lot of ground, but when it came to some key technical acceptance criteria, I didn’t have much in the contract to measure the vendor’s performance against.

While technical resources are typically not the primary players in contract negotiation, architects are able to contribute valuable insight and thoughtful questioning to the process. Executives and legal personnel will focus on things like licensing fees, payment schedules, and deliverables. As technical experts, architects should provide guidance in areas such as performance criteria – spelled out with quantifiable measurements. A comprehensive, detailed SLA is important to make sure the vendor delivers on its verbal promises about their product. Being very specific leaves no room for either side to misinterpret the agreement.

Outside of the actual negotiation process, an architect’s expertise is important when evaluating the vendor’s product. Executives might be impressed by conference room slide presentations, but they need a technical expert to ask the tough questions. Don’t rely on vendor claims. Provide value by asking the critical questions to determine how complete their solution is. The best way to verify what the product can really do is to evaluate it in a true operational demo or in-house proof of concept (POC). If integration with other modules or applications is critical, make the vendor prove it can be done. Focus your POC on the most critical features of the product that must be deployed, and the ones that introduce the most risk.

While questioning the vendor about a specific technical issue, don’t let them get away with the answer “That’s not a big issue. We can work that out later.” Tie up those outstanding loose ends before the contract is signed. That unanswered question may turn into a very big problem that prevents you from delivering a complete solution. Near the end of our project, my team found itself in that very situation. A vendor sales rep told us that our ad banner administration GUI would run on Windows workstations by the time our portal was deployed. That GUI never appeared.

Another challenge I encountered involved the installation of our chat software. Numerous unbudgeted hours were spent trying to get the various modules up and running and there hadn’t been any budget allocated for professional services from the vendor for installation. I learned in the early days of the project that the cost of the software had been quite high and our client wasn’t able to negotiate it down as low as they had wanted. One helpful technique I have since learned is that if a vendor refuses to budge on price, ask them if they will provide extra services or support for that price. As an architect you can inform your management which services or add-ons would save time and money on your project.

Another way you can provide assistance to your organization as it evaluates vendors and negotiates is to arm your management with alternatives whenever possible. You will put them in a better negotiating position if they are prepared to walk away from a particular vendor.

Relationship Building

A strong, collaborative vendor relationship is critical to the success of your project. Focus on building a good working partnership with your vendors so that they will be willing to go the extra mile for you. When project challenges come up (and they always do) would you rather have a vendor on your team, or a partner?

Vendors know that if they make you successful, they will be successful. I stumbled on a way to cultivate a partnering relationship based exactly on that concept. The content management system we were implementing for the portal was quite robust, but some key digital asset management functionality was available in a module that had not been purchased by the client. I enlisted the help of our vendor resources to prepare the business case and some ROI analysis. Together we made the case to the client for the needed module and made the project a greater success – as partners.

Even the most sincere attempts at relationship building can be derailed by typical project challenges. My team was particularly challenged by a client who frequently changed our requirements. My company held the primary relationship with the client, so the vendors often didn’t have first-hand knowledge of where the changes in direction were coming from. When things got tense, I remembered to take a moment to stand in the vendors’ shoes and see things from their perspective. Communication and morale can be improved drastically by understanding what your vendors are going through as well.

Communication

Never underestimate the importance of keeping the lines of communication open with your vendors. Weekly status meetings are a good start for dealing with open issues and various discussion points, but there are other ways to encourage and support the sharing of information.

Not all of our vendors were on-site, so we set up a web-based discussion and file-sharing system that was open to all members of the team. Aside from incremental progress reports and design discussions, we stored deliverables. We also encouraged team members to stay connected to the collaboration site by sprinkling in some humor and notices about post-workday get-togethers. It was a virtual water cooler that stayed current – which was key. Everyone knew that the most up-to-date information about the project could always be found in one location.

There are lots of technologies to support team communications, but nothing compares to the collaboration that takes place by walking over to someone’s cube or by picking up the phone. Sometimes the formality of a meeting can put up walls between internal team members and vendor team members. Impromptu conversations are important for open, free-flowing communication.

Ongoing Evaluations

Monitoring your vendors’ performance is critical to achieving your project’s objectives. Periodic reviews contribute not only to overall communication, but they enable your team to take corrective action when things begin to go off track. To prepare for formal reviews, I completed evaluation materials based on the performance of each vendor. Using the contract as a baseline for agreed upon metrics, I documented what was or wasn’t going well, and also wrote up recommendations for how things could be changed going forward. I sat down with the vendor leads and account managers to ensure I had documented things correctly before the official meeting. I didn’t want anyone to feel blindsided by my evaluation.

The actual review meeting included key team leads, vendor account managers, client executives, and various stakeholders. We reviewed the progress made to date, discussed outstanding issues, and agreed on an approach for resolving each of them. Occasionally these meetings turned into finger-pointing sessions, but usually we all emerged feeling like we could make positive adjustments to keep the project on track.

In Summary

Learning best practice vendor management techniques may not seem like a high priority to an architect. But if you find yourself involved with a project that relies on vendor supplied assets or personnel, it will be critical for you to manage the vendors’ performance in order to ensure a successful implementation. Don’t depend on your project manager to “handle” the vendors. Actively participate in vendor evaluation and when necessary, be an agent of change to improve their delivery.


About the Author

Denise Cook is a method architect and method content author with IBM Rational, contributing to the definition of IBM’s software development methods, including the Rational Unified Process (RUP). Before joining the Rational team, Denise worked as a lead consulting architect for IBM and Andersen Consulting. She has 17 years of experience in the field of software engineering.

She is a member of the International Association of Software Architects, a 5,000-member non-profit organization focused on defining and supporting the professional duties of IT architects. This article is based in part on material that Cook provided to the IT Architecture Skills Library.

IASA

You might also like...

Comments

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“There are only 3 numbers of interest to a computer scientist: 1, 0 and infinity”