twitter2  fb2  in2

Rate this item
(1 Vote)

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.

Rate this item
(0 votes)
by Larry Pendergrass, Principal

Tenet #10: Institutionalize learning.

My previous blog dealt with the need for rigorous monitoring. This monitoring is of two types:

  • Monitoring by the PPM team of the execution of projects, and of the markets they will serve, taking corrective actions in the face of new data to make sure the company’s goals are met.
  • Monitoring by the leaders sponsoring the PPM team of the effectiveness of that team and the processes they use, and taking corrective actions to assure team and process effectiveness.

Without careful and rigorous monitoring, and with the ever changing climate of business need, it is quite easy for projects to get off track and for PPM teams to become ineffectual.

Rate this item
(1 Vote)

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):

Rate this item
(0 votes)
by Larry Pendergrass, Principal

Tenet #9: Monitor rigorously.

In my last blog I encouraged you to recognize that the PPM team with the associated processes has in its hands the largest lever to improve product development flow, that of the number and type of projects in the pipeline at any given time. Most firms tend to push the utilization levels up above 100%, believing that this is the best path to superior economic efficiencies. But in reality, our greater understanding of traffic flow and similar phenomenon has shown us that this will cause a system to slow down and eventually come to a complete stand-still. The PPM team must pay careful attention to these utilization levels and reduce them (to around 80%) if maximum flow of new products is expected. Since utilization and queue levels are directly related and since queues are often more easily measured, many firms choose instead to measure queue levels at critical points in the product development, pulling pre-arranged corrective action triggers as queue levels exceed an acceptable level.

In this blog I would like to discuss the need for rigorous monitoring of the PPM process and its results. This admonition has two parts:

  • Monitor portfolio progress: The PPM team must be chartered to dig deep into project execution details, to revisit market assumptions regularly and in general never assume that what is started will hum along as expected without occasional nudging. This nudging may include reprioritization of certain projects, or more drastic action.
  • Monitor the PPM team and process: The leader or leaders sponsoring the PPM team must regularly evaluate the charter, goals processes, and the performance of the PPM team to assure that the team is effective and accomplishing the current business goals.
Rate this item
(0 votes)

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:

Rate this item
(0 votes)
by Larry Pendergrass, Principal

Tenet #8: Improve flow.

In my last blog, I spoke of the need create a tiered set of portfolios and associated roadmaps, to pay careful attention to supporting frameworks such as technology, process and competency roadmaps. The PPM team must insist on, and have personal involvement in the creation of these ancillary portfolios and roadmaps. They are feeders into your PPM process, and directly into your project roadmaps.

In this blog I would like to discuss the need to act to continuously improve the flow of projects through the pipeline. The PPM team has the capability through its decisions to improve or completely shut down the flow of projects through the new product development process. At first, many may not see the direct contribution of the PPM process to project flow; however, the PPM team has perhaps the largest lever available to radically change the flow, that of choosing the number and type of projects in the pipeline at any one time. Thus, the balance chosen between “trying doing too much” and “doing too little” is an essential decision-point for the firm.

Rate this item
(0 votes)

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

Corporate Headquarters:

TechZecs, LLC
1730 Kearny Street,
Suite F-3
San Francisco,  California
94133 USA

Principal and Founder

Dr. Scott S. Elliott
Telephone: +1.415.830.5520
Email: scott.elliott@techzecs.com
           info@techzecs.com

Grab our contact information

qr-linkUsing your smart phones, open your QR Code reader and quickly scan this image to save our contact information automatically .