## Introduction to vendor management

Once an agency has awarded a contract to a vendor to build custom software, its goal is to foster a healthy working relationship with the development team and make sure it delivers working software that meets the needs of its intended users. This work is typically called “vendor management.” 

As day-to-day management of a vendor’s work on a custom software development project is the responsibility of the [government product owner]({{ "/derisking-government-tech/principles/#principle-3-product-ownership" | url }}), this section is written primarily for people in that role. Where government technical leads and other staff should be involved, they are mentioned specifically.

In government contracting, “**vendor management**” means the activities and interactions with a vendor that occur after a contract has been awarded. That work should result in the vendor fully performing its duties under the contract and the organization achieving its desired outcomes from the contract. 

In the context of a performance-based services contract, vendor management is not about enforcing the letter of contracts. It’s about developing a productive relationship with the vendor, engaging closely with them as they work to identify solutions, and regularly evaluating the actual software they were hired to produce. 

The contract broadly defines the outcomes you want to achieve together and sets the boundaries of how you and a vendor will work together. It doesn’t dictate the exact nature of the day-to-day work of building software. 

Indeed, it is a sign that you and your vendor have a healthy relationship if you rarely need to discuss the contract. If you’re meeting multiple times a week and working closely together, your conversations focus on the work itself: what the team is doing, how they’re doing it, and obstacles, complexities, and solutions they’re discovering. There’s no need to refer back to the contract. 

Good collaboration and communication are the cornerstones of effective vendor management of a custom software development project. This is why the government product owner (whether or not a technical expert) must actively participate in the project team and in meetings where work is being done, and from the earliest stages of planning.

This section outlines good practices for building a healthy relationship with an outsourced development team through active collaboration and communication. It starts by explaining the principles of agile oversight, which underlie our guidance, and explains the practices in relation to the following aspects of vendor management:

* [Setting up the relationship](#setting-up-the-vendor-relationship)
* [Reviewing the vendor’s work](#reviewing-the-vendors-work)
* [Maintaining a healthy vendor relationship](#maintaining-a-healthy-vendor-relationship), including managing conflict

### Principles of agile oversight

The [agile manifesto]({{ "https://agilemanifesto.org/" | url }}) established a set of values for agile software development. They are explained here for a government context. If you followed the [solicitation process for a performance-based services contract]({{ "/derisking-government-tech/buying-development-services/#writing-a-solicitation-for-a-performance-based-services-contract" | url }}) as explained in this guide, you have set up your relationship with your vendor to abide by these principles.

#### Individuals and interactions over processes and tools

You took the time to run a good procurement and select the best vendor. Now, create an environment that gives the vendor team space to do the work you hired them to do. Focus on building your relationship with the vendor team and communicating expectations for how you will regularly evaluate its work and not on how closely the vendor complies with established agency procedures and culture. 

#### Working software over comprehensive documentation

Use regular demonstrations of working software rather than written reports to measure the progress of work. To evaluate the quality of demos, you’ll use the quality indicators articulated in the performance-based services contract. (Some documentation is still required during the project to record details about how the software was built, security and privacy protection mechanisms, and instructions for its maintenance. Check out [Reviewing the vendor’s work](#reviewing-the-vendors-work) for specifics.) 

#### Customer collaboration over contract negotiation

As already noted, a sign of a good relationship with your vendor is that you’re in constant communication. Setting up an environment that enables professional, open dialogue between you and the vendor team is imperative to successful collaboration. 

#### Responding to change over following a plan

A development team can build working software only if they can respond to needs as they evolve over time. The purpose of acquiring the team’s services through a performance-based services contract was to enable the team to be able to work in this fashion.