## Setting up the vendor relationship {#setting-up-the-vendor-relationship}

{% include 'derisking-government-tech/section_image.html' img_path: "assets/derisking-government-tech/img/vendors-relationships.svg" %}

Along with a strong understanding of product leadership, setting up the government-vendor relationship is key to effective vendor management. This begins in the project kick-off meeting and involves being ready to onboard the vendor team and establish healthy patterns for working together.

### Project kick-off meeting

Once the contract is awarded, the first interaction between the government and the vendor takes place at the post-award orientation meeting — the **project kick-off meeting**. 

This is the first opportunity for the product owner and vendor team to talk about the product vision and desired outcomes for the project together. This is also the time to establish how the development team will operate as a unit by sharing expectations about communicating and working with each other, including discussing how particular issues and challenges will be resolved by the development team, government, or both.  

Kick-off will involve a lot of new information for the vendor team. It’s important to be thoughtful in designing this orientation so the team members have time to process and ask questions. 

Consider spreading out orientation topics over a week rather than scheduling the typical half-day or full-day post-award orientation meeting. A multi-day format will allow more robust discussion of each topic area and allow time during and in between meetings to reflect, synthesize, craft follow-up questions, and strategize next steps. Each day should have no more than four sessions. Keep each one to 60 minutes or less to maximize information retention. (Review a [sample kick-off week agenda]({{'/derisking-government-tech/resources/kickoff/' | url}}).) Make sure to capture key orientation information in a written format, such as a README or guide, that the vendor can reference later. (Documentation will also help when onboarding new staff to the project.) 

The project kick-off week should set the expectation for collaboration, so invite the vendor to lead a session of their choosing. They may want the opportunity to lead a team-building session or an open working session where they can ask questions about what they’ve learned.  

It is important to limit attendance to the project kick-off week to only individuals that will participate in the day-to-day work. The week should serve as team-building for the newly formed team. Looky-loos or curious parties should not attend. However, it’s a good idea to invite the project’s executive stakeholder to the first meeting to stress its significance. 

The week after kick-off, the product owner should schedule one-on-one meetings with each member of the vendor team. We encourage all team members to meet in this fashion, especially the product support and technical support on both sides so they can set up recurring meetings and establish open lines of communication early.

### Onboarding {#onboarding}

**Onboarding** a new vendor team involves getting them the access they need to systems, buildings, and government-furnished equipment. An agency typically has processes in place for a common level of access, but a custom software development project will often require a more specialized level of access. The process of getting it can be an arduous journey of paperwork, permissions, and authorizations and take a few weeks to a few months. During that time, the vendor can still bill the government for hours worked.

You can make the onboarding more efficient if you [clear the “path to production”]({{ "/derisking-government-tech/principles/#clear-the-path-to-production" | url }}) during solicitation so software development systems and deployment environments are in place by the time the contract starts. If that work has been done, onboarding is a matter of getting the team access to these environments as early as possible. If not, then that prep work needs to be done and comes with the additional issue of often enmeshing the vendor team in messy discussions about its need for access.  

### Patterns for working together 

By the end of kick-off week, the government and the vendor team should know how they intend to work together, including:

* How often they will meet  
* What will be covered at meetings  
* Who will participate in each type of meeting  
* Who will lead each type of meeting 

As noted earlier, the government should convey the product vision during kick-off and check in about understanding of and alignment on vision and goals quarterly. 

In a best-case scenario, you and the vendor team do planning and review activities together. Whether you use a Scrum-based approach or not, you’ll need enough collaboration time to commit to and complete specific pieces of work in a one- or two-week cycle. You can expect to spend at least three hours per cycle on regular activities, including planning and review meetings in which the team:

* Frames work and discusses desired outcomes  
* Agrees on work to be done next  
* Reviews completed work together   
* Interprets new information and feedback, and decides what to do about them  
* Reflects on how to work better together as a joint team 

#### Regular check-ins with the contract administrator

The product owner should set up regular meetings with the vendor’s contract administrator (or whoever is the step above the vendor team lead) in case a situation requires escalation. These regular check-ins should be at least once a month and last no more than 30 minutes. 

The point of a check-in is to establish a frequent and open channel of communication with contractor leadership to discuss the project’s progress, successes, and challenges. The contracting officer or equivalent isn’t required to attend, but it’s a good practice to invite them for their awareness.

### Establishing internal agency communication and collaboration  {#establishing-internal-agency-communication-and-collaboration}

The start of a contract is a good time for the government to set up ways to track progress, deliverables, invoices, spend rate, and project risks. Even though the designated contract administrator is contractually responsible for approving invoices and accepting vendor deliverables, the product owner and government technical lead are also critical because they will work with the vendor team on a daily basis and will have firsthand knowledge of the team’s roles, responsibilities, and performance.

The contract administrator, product owner, and tech lead should be in frequent contact about the vendor’s performance. Documenting the status of the contract and vendor performance in one shared document will also help make sure that all government roles are in the loop. Common data points that should be tracked during performance include:

* Invoice numbers and dollar amounts (to monitor spending levels)  
* Deliverables and their respective [quality indicators](#quality-indicators)
* Any relevant materials or artifacts that the government and vendor team agrees are meaningful and valuable for tracking performance 

Reporting the development team’s progress to agency leadership is the responsibility of the product owner or contract administrator. Information that shows the vendor’s actual progress, like software demos or communications that articulate the status of work toward outcomes or perceived risks, should be shared to minimize misunderstandings or miscommunication, and surface issues that may need to be addressed by all of those involved.