Partner Agreement Thoughts, Case References and Summary
In the first three parts of this series of blogs, we introduced tools and best practices for finding, qualifying and managing a product development partner relationship in a robust manner, independent of the type of project or product under development. In Part 4, we included the principles of the Agile Manifesto to demonstrate the benefit of those principles for developing either software or hardware products. The reason for this order is that Agile product development requires a much tighter collaboration than traditional “waterfall” methodologies, so the organization should first develop excellence in the basics of partner management before attempting agile methods.
Regarding partnership agreements, agile product development as described above calls for much more trust-based contracting than just a fixed fee for a fixed deliverable. Time and materials contracts can work, but many prime companies fear that they represent a “blank check” for the partner. This fear is understandable, but usually not well-founded because the partner would like to be a long-term contractor and so is motivated not to overcharge. Such contracts often include incentives for early delivery and corresponding penalties for lateness or other problems.
Agile Product Development with a Partner
Whether you are developing software products, some combination of software and hardware products, or even pure hardware products there are advantages to be gained by using some or all of the Agile Software Development principles in collaboration with your development partner. These principles are different from the traditional “waterfall” project management methods in that they:
- Empower the overall product development team
- Catalyze innovation (even by the partner)
- Embrace changes in the product definition throughout the development cycle
- Encourage frequent hardware and software prototype intervals
- Tighten the relationship between the developers and the end use cases
- Utilize predictive progress metrics
- Encourage mid-project retrospectives and process improvements
The principles involved in agile software development were first published as the Agile Manifesto in February of 2001. However, many of these principles hold well for any kind of electrical or mechanical product development process. In the twelve Agile Principles below, I have replaced the word software with either product or prototype or both (notice that I needed to make only 3 substitutions – underlined below):
Partner Qualification and Performance Reviews
In the previous two blogs (Part 1 and Part 2), we introduced the concept of a Partner Relationship Lifecycle, and showed how different roles within our organization lead or are involved in different phases of the lifecycle. In this letter, we will discuss some best practices for qualification of the partner and periodic performance reviews.
The most robust way in which to qualify potential partners is to use a formal framework that breaks the qualification down into specific areas, and attach a score along with reasoning for each axis. As an example, suppose that your project is looking for a software development partner who can work well with your fast-track system project. You are searching for a company that uses Agile or Scrum methodology to match your fast-paced team and flexible market requirements. The first thing your Procurement Specialist should do is to meet with the project team to determine the most important characteristics they are looking for in a partner. An example of such characteristics for this case might be:
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
Introduction and The Partner Relationship Lifecycle
Hardware, software and system product companies routinely use partners for part or all of their new product development, and yet only a few companies are truly competent at managing those partners. The challenge of working with partners is multiplied if we want to take an Agile approach to product development. Using Agile methodologies such as Scrum, Kanban, Dynamic Systems Development Method (DSDM), or Feature Driven Development (FDD) requires an extremely closely knit and empowered team, so we cannot afford an “arm’s length” relationship with any partner working within the team. Before attempting a partnership for employing the principles of Agile development, a product development organization should have achieved excellence in partner relationship management basics.
In this blog Part 1, we discuss the Partner Relationship Lifecycle. In order to get the most out of a partner in developing innovative and profitable products, we first must recognize that a firm’s relationship with their partner follows a lifecycle of phases, similar to a product lifecycle. Several different people in any one organization deal with the partner, and the right person or role to lead the partner relationship changes, depending upon the phase of the lifecycle. For a successful relationship, people need to be trained for these roles – competency does not happen by osmosis.
In any kind of project or program, situations often occur that require escalation for decisions to be made above the level of the project team. Typical examples of such situations include changes of project scope, unforeseen technical problems, overspending, lost expertise, and schedule slippages or changes. The problems can get especially costly in a heavily matrixed organization, wherein people who report to various functions (engineering, marketing, finance, manufacturing, etc.) are essentially “on loan” to a program manager to complete the deliverables. Some or all of these people may be working on more than one program team, plus contributing work to their functional teams.
When a program encounters a roadblock in such a system, something close to chaos can occur, putting a halt to productive progress and polluting the organization with animosity. For example, say that something technical happened that will cost the program 10% more money and require more resources or time. The finance team member may go back and report to his boss – the controller – that the engineers want to go over budget. An engineer may go back to her supervisor saying that the scope changed and now they can’t meet the technical requirements. The product manager may go back to his boss – the marketing manager – and say that the engineers aren’t smart enough to meet the customer requirement, and so forth. Those managers may kick the problem up to their bosses at the VP-level. In the meantime, the program manager is pleading with her PMO team or boss for more time and money. These supervisors may then meet one-on-one or in various groups to discuss the situation, argue about whom is to blame, etc., as illustrated in Figure 1.
For technology companies, the growth and success of individuals (and the company) can be inhibited by poor communications – somewhat due to that fact that many of the key contributors are engineers or other technical professionals. These people (and I am one) were educated and steeped in “the scientific method” of discovery and analysis. This method, to state it simply, is:
- Pick a topic or problem
- Collect some data
- Form a hypothesis or model that is consistent with those data
- Conduct experiments or otherwise collect additional data
- Test to determine if the new data are consistent with the model. If not, change the model or get a new one.
- Repeat these steps for refinement
This method works extremely well for discovering phenomena of nature and inventing new gadgets and systems, but it is a terrible way to listen to people.
[Note: This blog is for technology companies who have matured beyond the first phase of start-up chaos.]
Every excellent company has a systematic way of driving business planning and execution cycles. Usually, the time element of the planning process is controlled by a calendar. Most businesses have annual cycles dictated by required financial reporting, seasonal sales, etc. In addition, the business may have multi-year programs or initiatives. These time-cycles amount to a "heartbeat" rhythm that can be used to control and improve your business.
If you don't yet have a robust planning system, start by synchronizing your company’s planning and execution calendar with the timing of companywide business processes such as fiscal year reporting. For example, the annual planning and execution process starts on the first day of the fiscal year. Quarterly reviews of the plan and course adjustment activities are tied to end of each quarter. A companywide planning and execution calendar, well publicized within the organization, gives time for people to prepare data for planning and review activities. Asynchronous, event driven elements of the planning process are triggered by changes in external events impacting your company’s business focus. Ongoing continuous scanning of the external environment helps to prepare people for these event-driven planning activities. However, major unplanned events can seriously disrupt the rhythm and profitability of the business.
Knowing the core competencies of your organization helps you to focus on your strengths and to create significant competitive advantages.
Core competencies are a combination of unique skills, pooled knowledge, technical capabilities, company and personal connections, intellectual property, and cultural values that have accrued in the organization that allow it to develop and deliver value.
A start-up or growing company may first try to identify, and then focus on, its core competencies. Over time, the company may develop key areas of expertise which are distinctive and critical to the company’s long term growth, allowing it to establish a footprint while gaining a solid reputation and brand recognition.
The criteria for identifying a core competency are:
- It is something we know or do as well as or better than anyone else in the world,
- It provides clear customer benefits,
- It is not easy for competitors to imitate, and
- It can be leveraged to variety of products and markets.
A start-up or small company can usually operate effectively with few structured policies or business processes. The employees all meet frequently and informally and fill multiple roles to develop and deliver value to their customers. However, as a company grows in size and complexity and workers specialize, a set ofdefined work procedures (processes) is needed to coordinate efforts and organize the results. In developing and implementing these processes, many companies try to implement too many rigid processes, hindering their ability to serve their customer flexibly. So, how do you define the right level of process to serve customer’s need efficiently?