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