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.
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.
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.
Tenet #5: Balance goals.
In last week’s blog, the essential nature of uncertainty analysis in the PPM process was shown. While few companies are well practiced in uncertainty analysis, the use of uncertainties in PPM discussions can illuminate decision-making and prevent many ills that are often taken as “necessary evils” in product development. In this week’s blog, we will address the need to balance many goals through the PPM process, and speak specifically about some of these goals.
Every firm tries to balance a set of conflicting goals in its efforts to maximize stake-holder value. And each firm will choose a different balance based on many things such as the maturity of the industry, the nature of their customers and of their stake-holders, the general philosophies of the management team, the current economic climate both in and outside the company, the competitive landscape, and so much more. One firm’s risk-averse nature may be very appropriate for the setting where another’s high risk approach may be called for in a different setting.
The PPM process is that place where this balancing act is most active and essential. The PPM process is the bridge between the theoretical strategic discussions and the daily activities that are necessary to execute the plan. In the PPM team, real balancing takes place as the team struggles with such decisions as accepting new projects in the portfolio, cancelling projects that have become either ineffective or no longer support the strategy, and making tactical changes to resources to further the highest priority projects. The PPM process is that place where the conflicting goals of the organization meet the realities of implementation, and a balanced portfolio is the ideal output.
Teams that develop new products are challenged to produce a high-quality, valuable solutions in as short a time as possible and within a tight budget. We all know that slippage in time-to-market; decreased functionality, or increased cost can have major negative consequences for the business, and may even determine the success or failure of a new product launch.
One major cause of such slippage is confusion within the team around roles and responsibilities. If nobody on the team knows who is empowered to make a certain decision, the decision can go unmade, wasting valuable time, or be made by the wrong person – the person who does not have the knowledge to make such decisions.
Many new product development (NPD) teams try to prevent this kind of “wheel spinning” by writing extensive Role Descriptions for each member of the team, attempting to make it clear who is “in charge” of each type of decision. Or they may use more generic corporate job descriptions for the same purpose. The problem is that most NPD projects are fluid and dynamic and problems may arise for which there is no clear owner. A common example occurs in deciding the feature set of a product or solution at its launch date. Who can decide? Is it the Project Manager? The Product Manager? The funding Business Leader? A major customer? Indecision in the feature set, or “creeping featurism” is one of the leading causes of project slippage and it’s almost always due to confusion about who can make the call.asd
Tenet #4: Apply uncertainty.
In last week’s blog, the critical need to agree on one unit of measure, money, was addressed. Even the toughest qualitative concerns about a project can be reduced to an estimate of the financial impact on that project. And any estimate is better than none, since it will force the discussions the team needs to have. Without this discipline, advocacy for a given project can degenerate into debates where the winners are not necessarily the best projects. Insist on one common unit of measure, and that measure should be money.
In Tenet #2, I admonished you to insist on being presented with alternatives when offered an opportunity. An effective PPM process must have options from which to choose. In some cases, these options may be modifications of the scale of the project being considered. But Tenet #2 should not be confused with this tenet, Tenet #4, “Apply uncertainty”. In this new tenet, we have picked a project baseline from the alternatives presented. We plan an “expected outcome” in all of the project measures. Uncertainty analysis is then applied by looking at each major variable (project scope, project schedule, project cost, market acceptance and market share taken, etc.) in the project and stating a range of probable inputs. In the end, it is possible to show how the primary financial measures (like NPV of cash flows) change over the range from worst case, to expected value to best case. Note that this uncertainty analysis is not just done once during the proposal phase and then forgotten. It must be carried with the project throughout the execution phase, updated as necessary and used at any time to compare to other potential projects.
There are at least 3 reasons to apply uncertainty: