twitter2  fb2  in2

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.

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.
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.

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.

Published in Process

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

Published in Process

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:

Published in Process

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
Published in Process

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.

Published in Process
by Larry Pendergrass, Principal

Tenet #7: Design tiered portfolios

In last week’s blog, I wrote about the value of using visual methods to cut, examine and present the data in many different ways. Visual methods have the advantage that you can quickly see large, complex data sets on a single page and perhaps best of all, can compare projects easily. This is essential as you are striving for a balance portfolio.

But a balanced project portfolio is fed by and in turn feeds other portfolios. While the exact list may vary with industry, included are typically:

  • Technology Portfolio – Before you can successfully create that breakthrough non-invasive glucose monitoring unit, you need first to develop the technologies for miniature Raman spectroscopy, low noise signal detection, wireless communication and data management. You need to decide which technologies will be developed and which will simply be bought from others. The best new product development organizations are able to recognize key technologies, especially those that present high risk and pull them off of the critical path of a particular project. Running parallel then to the project roadmaps should be another roadmap for the needed technologies beyond the current product roadmap. This requires vision, insight and highly skilled decision-makers. You need to create a Technology Project Portfolio along with processes to balance, authorize and manage these projects, and then have these technologies intersect your product roadmap.
  • Process Portfolio – In order to design and fabricate a new line of high speed semiconductor devices based on 10 nanometer gates, you need processes for ultra-fine line lithography, deposition, etching, and many other processes. Or before you begin that new business in high volume, low mix manufacturing (where all previous products required low volume, high mix) you have much work to do in altering manufacturing processes and/or identifying manufacturing partners. These efforts require projects and roadmaps, and should use portfolio management to balance, authorize and manage the projects.
  • Competency Portfolio – Before you are able to enter a new market like RF test equipment or Pulsed Radar equipment, you need to decide which competencies will be core to the business and therefore owned, and which will be needed on a temporary basis and are candidates for open innovation. Developing the competencies for new areas of business require a plan. They require an inventory of current skills, and a roadmap to get where you need to go. They require development of more than just the product development department competencies, but may also require development of the sales force, application engineering, marketing, manufacturing and other functional areas. Your competency portfolio may at any time require minor or very significant work.
by Larry Pendergrass, Principal

Tenet #6: Use visual analysis.

In last week’s blog, I wrote about the crucial need to balance your project portfolio along many dimensions, in careful alignment with top leadership in your firm. While this seems like common sense, many firms do not take the time to explicitly call out specific areas to balance, and gain clear guidance from top management to help in PPM decision-making.

In this blog, I would like to turn our attention to what seems to be a more tactical subject – that of using visual tools to both analyze for decision-making, and for use in communication to others. While this tenet may seem like a tactical detail, I believe it is essential enough to rise to one of my ten tenets of PPM. While I have seen attempts (and failures) at PPM in other ways, I believe strongly that the only practical way to pull out the key information necessary for these tough decisions is through visual analysis using pictures and graphs. From my experience, the primary use of tables of numbers will cause the team stray from the main strategic questions and to degenerate into a group discussing and questioning the specific numbers. Cutting the data in key ways will reveal critical data that speak to the firms most vital issues.

Page 1 of 2

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 .