Dr. Scott Elliott
Scott Elliott is well known globally for his experience in high-tech and electronics design, manufacturing and supply chain management. With over 35 years of engineering, management and consulting experience, Scott brings unique, practical insight to all aspects of technology business, including business strategy alignment, supply chain management, world-class manufacturing and R&D management. He has the technical breadth and depth to understand any technology, and the business and management experience to make it a commercial success. Scott founded TechZecs LLC in 2001. learn more
Many people talk about product innovation, but few develop a full understanding of what innovation really means or what it takes to build an innovation culture and new solution engine. There are four fundamentals that must be in place for a truly innovative company:
- A profound understanding of the customers to be served, and unmet or poorly-met needs of those customers,
- A process for creating compelling solution ideas to meet those needs,
- A process for prioritizing, selecting, and funding the most promising solution ideas, and
- A development capability that rapidly turns the selected ideas into competitive products or solutions.
So-called “Waterfall” or “Phase-Gate” product development methodologies often give management the illusion that they are under control of the project, while they are actually just meddling and slowing it down. Each formal gate meeting or project review is an opportunity for every manager to put the project team under scrutiny about what they have accomplished and whether they should continue with the next phase. I have been on both sides of the PC projector for many of these reviews, so I know what I am talking about.
When a gate checkpoint meeting or formal review is approaching, the project slows down. The project manager and key technical contributors view the meeting as an opportunity to show their value or possibly to slip up, which may affect not only their project, but quite possibly their personal ranking and stature. Therefore they spend a lot of time and emotional energy on perfecting slideware – deciding what to emphasize or perhaps what to obfuscate about the progress of the project. These meetings drive other suboptimal behavior as well; for example, in order to show a “quick win” at a review, the team may take on a quick, low-risk piece of the development instead of concentrating their talents on retiring the higher-risk elements as early as possible. These deferred high-risk elements can cause major project problems and delays later.
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.
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
Many of today’s leaders try to coordinate business resources that are scattered over a large geographic area – perhaps even the whole world. It is common for such people to have direct reports on two or three continents, plus possibly key partners, subcontractors and suppliers even further afield. Leading such a dispersed group can be physically and emotionally very taxing, as those of us who have logged 200,000 flight miles or more in a year can tell you. And keeping the group coordinated and productive – a group of people of different cultures, different time-zones, and different mother tongues – can be a monumental task.
Is there a way to survive and thrive in this kind of job while maintaining a reasonably normal personal life? Here are seven tips that may help.