Guide to Agile IT Vendor Management

Tech companies almost always use IT vendors, yet managing them to produce a polished, releasable product on time, is a challenge. The challenges multiply when projects involve multiple parties, each producing parts of a whole using Agile methodology. 

We have seen companies manage IT vendors effectively by using a lean and effective, small ‘a’ agile product development process. First, they define roles and responsibilities clearly and completely. Then they extend this small ‘a’ approach by putting a ‘ring fence’ around your development vendors. In addition to any legal agreements, they generate an informal contract between partners. This agreement allows your partners to be creative and allows you to manage your project’s targets.

200+ companies from 25 countries outsourced software development to Relevant

We provide companies with senior tech talent and product development expertise to build world-class software. Let's talk about how we can help you.

Contact us

Partnership Life Cycle

The first step to managing IT vendors is to understand the life cycle of a partnership. This life cycle includes the search for potential vendors, qualification, official engagement, achieving a symbiotic and optimum relationship, leveraging the partnership through the project and across the company, and then possible disengagement. The figure below illustrates these stages.

Search

The pre-phase for any partner engagement is to search for the best possible partner for the project. Since the most fruitful collaborations may occur with partners located anywhere in the world, searches might be quite extensive and complex, and they are usually going on continuously among the development and procurement groups.

Qualification

During the Qualification phase, you will select a potential partner and then go through a process to determine if that partner has the competencies, capabilities, capacity, and compatibility with your company to accomplish your goals. This phase might include executing a small development project to see how well the partner team works with your company’s team. For more on the partner selection process see Relevant Software’s ebook. 

Engagement

In the Engagement phase, you negotiate contracts and/or service agreements, which are often written by a professional from a procurement or a contract management function, and then reviewed by the legal departments of both companies. Both parties will select people or teams that will interact with one another. Then the partners establish communication protocols, and the work will begin.

Symbiosis

When the first engagement is well underway, the relationship enters the Symbiosis phase, in which the teams on both sides optimize the working relationship for maximum effectiveness and efficiency. This phase might be very short if you have chosen your partner correctly; or it may take a considerable amount of time, and may include changes in personnel or roles, to get the relationship working well.

Leverage

Finding, qualifying, and achieving a symbiotic and productive relationship with an IT company is a big investment. The best companies follow-on with a Leverage phase to find additional areas in which they can use the same partner for other valued contributions or for other projects. Note that the figure above has a dotted line indicating that engagement with the partner may wax and wane as projects start, end, or enter different phases. This variation is normal and healthy, providing your company with valuable flexibility.

Disengagement

Finally, there may be a Disengagement phase that can occur for a variety of reasons: Perhaps the next set of projects does not require the expertise of the partner, or your company decides to bring the partner’s core capability in-house, or there is a business change or dispute, etc. In most cases, there is a wind-down period; although in other cases it may be a very sharp cut-off of communications between partners. 

Or it may be that there is never a disengagement phase, if it is truly a long-term symbiotic relationship. An example is the decades-long partnership between Hewlett-Packard and Canon to co-develop LaserJet printers.

Read our guide on extended software development teams.

Roles and Responsibilities in Partnerships

Managing IT vendor, especially in lean enterprises, is seldom handled by just one person in your company. Much more often there are multiple people involved on both sides, leading to ample opportunities for mixed or crossed signals. The following are some typical roles, assuming a project or program that involves internal resources as well as one or more partners:

• Project Manager (PM): Responsible for the main deliverables, budget and schedule of the overall project.
• Partner Procurement Specialist (PPS): Responsible for the qualification, contracting and business management of the partner.
• Technical Lead (TL): The senior technical architect of the product under development – in some companies she doubles as the project manager.
• Functional Manager (FM): Manages a group of technical specialists, such as electrical engineers in companies that produce hardware.
• Executive Partner Manager (EPM): This person is usually a high-level executive manager (Director or VP of Engineering, for example) who has a side-job of acting as an overall executive contact to one or more key partners.
• Legal or Contracting (LC): Responsible for drawing up and possibly enforcing the legal terms of the contract.

Using a Modified RACI Chart to Clarify Roles

The roles and responsibilities of these titles vary depending upon the phase of the partner relationship. An excellent way to clarify all of the roles involved in a partnership is to use a modified RACI diagram, like the one below. In this figure, the roles are printed along the vertical axis and the major process responsibilities for a hypothetical company are written along the horizontal axis. 

Wherever the roles and responsibilities cross on the matrix, you draw one of three types of circles or dots. A solid circle means that a person in that role has the lead role for the task in question. A hash-marked circle means that the person in that role is heavily involved in the process, but not in the lead. An open circle means that the person is informed, but not necessarily involved in decisions regarding the task. No circle means that the person is neither generally involved nor informed.

It is best practice to have one and only one person or group in the lead role for each major responsibility; situations where there are shared leads often result in conflicts. The stakeholders in your company should get together, list your major process responsibilities, and decide for each task which roles are in the lead, heavily involved, informed of what’s happening but not involved directly, or neither involved nor informed. It is important to have full agreement and buy-in from everyone concerned.

In many companies, the Functional Managers often take the lead in scanning and finding potential IT companies. They have the best combination of technical depth, awareness of the suppliers, and business maturity to develop the short list of contenders. After that, the leadership of the qualification process is handed-off to a Partner Procurement Specialist (PPS).

The Role of the Partner Procurement Specialist

The PPS takes the lead in training all employees who interface with the partner including their roles and responsibilities, accountabilities, and communication protocols. Early training and role definition by all team members can avoid much confusion and miscommunication during the project. 

Also, the PPS leads the Qualification phase using the Functional Managers and Technical Leads to examine the partner’s technical capacity and capabilities. The PPS examines the partner’s business essentials, including the potential partner’s size, stability and track record. Many companies have a back-up partner in case the chosen partner fails to deliver or something goes wrong with the relationship.

Boundary Conditions: An Agreement Between Partners

At the beginning of each project, an agreement between you and IT vendor creates key parameters, boundary conditions for the project. These conditions define approximately five key aspects of a project. These include parameters like:

• Product Cost
• Features
• Schedule
• Quality
• Reliability

Quantitative Measures

The partners agree on quantitative measures for each boundary condition. For example, the boundary condition for the release schedule might tie to a trade show. These conditions bind the project to key success factors and set expectations. They quantify the project’s goals and, taken together, they measure its success. If the project meets these quantitative targets, then you have a clear way to measure the effectiveness of the IT vendor.

Partners Empowered to Innovate

If the IT vendors foresee that they are on track to meet the targets, each partner minds their own business. Development partners are not harassed with requests for status updates and are free to innovate and use their own processes to get the job done. On the other side of the partnership, software project management can have confidence in the direction of the project, having defined with care its broader goals.

Hire Ukrainian Developers: Top 10 Reasons Why Outsource to Ukraine

When the Boundary Conditions are Broken: Out-of-Bounds Review

If the partner perceives that they aren’t likely to hit the target – this is called “a boundary break” – then it is their responsibility to inform you which boundary or boundaries are likely to be broken. This triggers an out-of-bounds review (OOB), which is an escalation process, a means of resetting projects with a minimum of time wasted.

If the development partner perceives that there will be a boundary break, it sends a communication proposing a solution to the break. If you concur with the partner’s solution, then each side comes to an agreement around a new quantitative measure for the boundary condition(s) in question, and the project goes forward on that basis.

If you do not agree with your partner’s suggested solution to the boundary break, then that triggers a face-to-face meeting where the agreement is renegotiated. The partners will then agree to new boundary conditions, create new metrics, and move forward with these revised measures of success as the new baseline.

Keep Projects on the Boil

It is extremely important for you to respond immediately if your partner says a boundary break is likely. The out-of-bounds process, where you come to an agreement on new boundary conditions, should take hours or days, not weeks or months. Projects that are near an impasse because there is no clear escalation path are in deep trouble. The boundary conditions and out-of-bounds review approach is intended to keep projects on the boil.

After the out-of-bounds review is complete, the partners continue as before, assuming that the new agreement re-establishes the project’s targets. This ensures that partners aren’t micromanaged, while providing a simple escalation process for projects that stray from agreed upon bounds.

Getting The Details Right

The boundary conditions approach depends on getting roles and responsibilities right. For example, get clear on what subset of management oversees the IT vendor. The process champions also have to define who gets informed when there is a boundary break. 

Partners might also negotiate what exactly constitutes a boundary break, and the timing of communications around them. It is also important for IT vendor to understand that it is their responsibility to propose a solution in the event of a potential boundary break.

Read also about where to outsource software development and IT outsourcing to Ukraine.

IT Vendor Management: Competitive Leverage Point

Managing IT vendors to precise targets, is a challenge for many management teams. It requires a cultural shift in organizations where hands-on management likes to meddle.

For example, we had one client that insisted on weekly status meetings (in this case with their internal teams) even when it was clear that the team was well within bounds. There was no need. Why waste time meeting for an hour (plus prep) to explain to management that the team is proceeding as promised? Pure time waster. It’s the antithesis of lean and agile product development.

Defining roles and responsibilities using the modified RACI chart, and creating boundary conditions for your projects, eliminate waste and churn, freeing up a well of resources. Partners working to clear and defined specs require less managerial time and effort on your part. If projects start to go awry, there’s a relatively blame-free, pain-free way to set them back on track by focusing on quantitative goals that remain objective targets. This empowered approach improves relationships between partners.

Few companies manage IT vendors well. It’s an area where you can grab an advantage, with a bit of planning, and a lean approach to developing apps with partners. 

– John Carter, Founder, TCGen Inc.