Agile Partner Management for Product Development – Part 2 of 5
Partner Management Roles
In the previous blog (Part 1), we discussed the six phases of a partner relationship lifecycle, including search, qualification, engagement, symbiosis, leverage, and disengagement. The question before us now is: who in our organization should lead the relationship in these various phases, and what should they do?
Working closely with a partner is seldom handled by just one person in the prime organization. Much more often there are multiple people involved on both sides, leading to ample opportunities for mixed or crossed communications. The following are some typical roles we can define, 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 (PRO): Responsible for the qualification, contracting and business management of the partner
- Technical Lead (TL): The TL is the senior technical architect of the product under development – in some companies she doubles as the project manager
- Technical Specialty Lead (TSL): Responsible for the development in one engineering specialty such as electrical, mechanical, chemical, software, etc. TSLs often report to the TL on a system project
- Functional Manager (FM): Manages a group of technical specialists, such as electrical engineers, for example
- 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 to draw up and possibly enforce the legal terms of the contract
The roles and responsibilities of these people vary depending upon the phase of the partner relationship. An excellent way to clarify the roles is to use a Circle-Dot diagram, like the one on Figure 2. In this figure, the roles are printed along the vertical axis and the major process responsibilities, corresponding to the partner lifecycle phases, are written along the horizontal axis. Wherever the roles and responsibilities cross on the matrix, one of three types of circles or dots is drawn or it is left uncovered. A solid circle means that a person in that role has the lead for the responsibility indicated. A hashed 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 any decision regarding the responsibility, and no circle means that the person is not generally involved or even informed.
A best practice is to have just one person or role in the lead for each major responsibility; shared lead situations often result in conflicts. The example in the figure is just that – an example. The participants in your company should get together, list your major process responsibilities, and decide which roles are in the lead, heavily involved, merely informed or not at all involved for each one. It is important to have full agreement and buy-in from everyone concerned.
In the example in the figure (typical for many system development companies), the FMs take the lead in scanning and finding potential partner companies. They often 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 the PRO.
The PRO takes the lead to train all employees involved in dealing with the partner on their roles and responsibilities, their accountabilities, and the communication protocols. Early training and role understanding by all team members can avoid much confusion and miscommunication during the project. The next thing the PRO does in this example is to run the Qualification process (a tool for such a process is described in the next blog Part 3), using the FMs, TL and TSLs to examine the technical capacity and capabilities. The PRO himself looks at the business factors, including size, stability and track record. We recommend that at least two partners be qualified for any critical project, so that there is a back-up in case the chosen partner somehow fails to deliver or something goes wrong with the relationship.
Upon successful qualification, a formal engagement process is undertaken – led again by the PRO. This process involves writing a Master Services Agreement (MSA) with the prime company that may cover multiple projects, and usually at least one Statement of Work (SOW) for a specific project. The SOW calls out specific deliverables for the project, whereas the MSA covers more general items such as professional fees for time and materials, escalation processes, scope change management, post-project support, and contract terms and conditions. Legal or Contracting people are heavily involved of course to make the contracts as binding as desired, and all of the technical people who will interact with the partner are involved as well to establish the working and communication protocols.
One best practice for establishing communication protocols is shown in Figure 3. The figure shows which role in the prime company should take responsibility for communications with which corresponding role or person in the partner company. In this example, TSL1 might be the lead mechanical engineer who is working with the contractor’s mechanical designer, and perhaps TSL2 is the lead software engineer running that subproject with the partner. The “X” shows a communication path that should be avoided, mainly having someone like a Functional Manager talking independently to the partner’s mechanical designer without coordinating with her own mechanical TSL. These crossed communication lines can result in conflicting expectations and other problems. The Technical Lead should coordinate the technical subprojects, reporting progress and issues to the Project Manager. The major job of the Functional Manager is to assure that the competency and capacity of technical resources are in place, either from partners or internal groups. The Procurement Specialist helps to make sure that the partner is delivering on business and compliance issues, and the Executive Partner Manager works with his counterpart to keep the two companies aligned and address any major relationship issues.
As Figure 3 shows, the day-to-day interactions with the partner are usually managed by the technical specialty leads, or possibly by the overall technical lead who may be treating the partner resources as regular team members. In addition, the Tech Lead should be monitoring the contractor’s technical performance, including the quality and timeliness of deliverables. A best practice is for the Procurement Specialist to hold a formal review of the partner’s performance periodically (quarterly is typical) to discuss objective measures such as actual vs. predicted quality, cost, and timing of deliverables. We present a useful tool for this kind of review in the next blog (Part 3).