Product family master plan

Developed by Daniel Vorting

Abstract

When rationalizing or developing a new range of product projects (a platform), it is essential to get an overview of the entire product program. An overview should “describe the structure of the product family and the variety with in the product family”

This article clarifies how a platform manager in charge of a product family rationalization or development projects, can benefit from using a product family master plan (PFMP). The PFMP is a tool for visualizing a complete product family, and how customer specified requirements impact the product family. The PFMP describes the product family from three different perspectives – the customer view, the engineering view and the part view. A platform manager can utilize this overview when deciding on how and where project resources should be focused. The PFMP overview yields a practical insight into where product modules should be developed, that can benefit the entire program of product projects depending on customer requirements. The PFMP is sought applied to project as a 'product' regardless of whether the project objective.

The process of developing a PFMP is dependent on a 7-step process, which guides and serves as a facilitator of discussion within the group. This forces the team to agree and have a common understanding on product terminology, product systems, modules etc. which in return greatly enhances communication between both team members, the project managers, the platform manager and other relevant stakeholders. The PFMP’s credibility is highly depended on the correctness of product details which is why it is of high importance, that it is developed in collaboration with key stakeholders, that bring important knowledge to the table.

Purpose of article

The purpose of this article is to give a thorough insight into the possibilities and limitations of the PFMP as a tool for communication of similarity and variance in order to reduce complexity in an organization. A platform managers can use the proposed 7-step method to understand the similarity and individual variance of his product projects and where the variation is beneficial or uneccessary. The PFMP has mainly been used on product projects, but can in theory be applied on all kinds of projects without altering the approach.

Background and application

Structure of this article

• The first section of the article will discuss the theory supporting the PFMP as a tool for program management. The theory is separated into 3 different sup-areas, which contribute to the holistic understanding of the PFMP. Firstly the theory behind project communications management will be adressed, secondly the theory of project management and lastly the theory revolving platform management.
• The second section will account for the 7-step process of developing a PFMP. The process steps will be presented with details on actual execution along with reflections on pitfalls, scoping, and general assumptions.
• The third section will describe the usability of the PFMP as a communication artifact, hereunder the limitations it holds under actual application and practical use.

Definitions and terminology

• Platform management is defined as a way to solve the "fat design" problem and maximize partial commonalities and efficient technology transfer across projects
• Module A collection of functionality - e.g. a car engine that has the functionality of converting chemical energy to rotational energy. A process module can be a series of steps that ensures a functionality e.g. opening a closet, deciding on what to wear and donning the clothes.
• Best of breed is an abbreviation which is used when discussing whether one solution is better than another at solving a specific functional requirement. The best of breed is the solution, that based on analytical insight, gives the best performance measured on company KPI's.

Application of the PFMP

The PFMP is generally applied when making decisions concerning the product assortment and can contribute to the understanding of:

• value and non value adding elements (where is the unnecessary variance, that does not give any value to the user
• Identification of engineering complexity (the causal link between customer and engineering view yields an insight into the complexity of the entire product portfolio
• Creating consensus between sales, engineering and production (using the PFMP as a communication artifact between various projects and departments
• Documentation of common terminology, platform overview etc.

State of the art

Project communications management

According to PMI 28% of projects fail due to poor communication and it is by far the biggest contributor to failing projects. Every project needs effective direction, management, control and communication and the maintenance of these are essential to the project's success. As an essential part of the PRINCE2 approach, an effective approach to manage communication flows to and from stakeholders is one of 4 essentials, that a successful management team should incorporate. A substantial part of developing good communications thus lies in ensuring that information flows to the involved project members as well as its stakeholders. This information flow is met through "development of artifacts and implementation of activities designed to achieve effective information exchange" . Relevant stakeholders are naturally subject to huge variations within different projects and platforms. In a product development project it could include sales staff, product developers, project managers, production managers, staff purchasers etc. who all contribute to producing an insight into what the company wishes to offer in their future platform. A common vocabulary is an essential element of a professional discipline which means that getting all stakeholders to agree on the current as-is situation is an important part of moving forwards with projects. The inclusion of stakeholders in project reviews has been identified as essential to successful delivery of project objectives . By developing a common understanding of the platform by use of a methodology, communication is more likely to be uniform regardless of cultural and

Project management theory

A project is by PMI definition a temporary endeavor undertaken to create a unique product, service or result . In order for business to thrive and evolve they must constantly maintain business operations (maintain profitability, service quality, productivity etc.) while transforming the business in order to be competitive (changing the business, rationalizing, developing new products etc.). As the pace of change is ever increasing it is essential that businesses do not 'fall behind' and focus only on maintaining business but also put effort into changing, which a project is an essential part of. Project management theory asses the methodology and theory behind ensuring that project objectives are met . The objective of a project is to produce one or more of the following:

• A unique product or component that is new, an enhancement or a correction
• A unique service
• A unique result (e.g. a document, knowledge, process)
• A unique combination of one or more of the above.

In order to enable business value creation

Platform management theory

A platform is an multiproject management approach where the objective is to identify and use the commonality between different projects - be it product development projects, process optimization projects or any other type of project. The platform management differs itself from program management, by grouping projects in order to help investment and cost reduction through product and process commonalities . Programs focus on grouping projects in order to reach benefits that could not otherwise be obtained through individual project management

The benefits of platform management lies within the fact, that through re-use of product or process commonalities we do not have to 're-invent the wheel' each time we are starting a new project. This enables the company to achieve both cost reduction and market competition effects through offering a larger diversity of products to the customers . Often products are separated into two domains; the specify-to-order products (e.g. a cement factory) and the mass produced products (e.g a car). In a project management context, the design-to-order products are similar to the projects 'exploratory learning' when the company experiments with new project practices required to cope with unfamiliar activities . Projects are generally really good at exploring what customers want but bad at exploiting what the company already knows. In the other domain a series of conservative product manufacturers often utilize their knowledge on mass production to produce thousands of non-customer specific products. The strength of platform management in a project context lies in exploiting the knowledge we have already gained and exploring the fields in which we have no prior experience. The PFMP is a tool for developing innovative products buttom up, while multiproject management ensures a top-down ressource management, risk balancing etc. . The combination of buttom up and top-down is a good way of combining product or project driven innovation and correct multiproject management. Thus the project can exploit knowledge on e.g. mass production while exploring where customers wishes to diversify their product. This enables customers to 'pick and choose' between modules that should be included in their product, and with special requirements a new module can be developed while maintaining the core-product. In parallel the same approach is used within project management. To exploit the 'modules' of knowledge the manager knows, and simply bring those elements together, so that the project can focus on developing the new areas in which no prior experience has been gained.

7-step process to developing a PFMP

Figure 1: Part-of and Kind-of modelling formalism example (car)" .

Model formalism

The PFMP has a model formalism based on object-oriented software development. The formalism consists of two 'structures':

• The part of structure, which informs about the class hierarchy. A class can consists of one or more classes. As the example on the left on figure 1 shows, the car can have an engine class in which an engine block, piston etc. are sub-classes thus breaking down the product or project
• The kind of structure is used for displaying the variety of a given class. As the example on figure 1 shows, an engine can be either 2.0 liters, 2.2 liters etc.

The development of the PFMP can be broken down into 7 steps, that should be followed chronologically:

Figure 2: PFMP overview - based on literature from reference, but made by Daniel Vorting" .

1) Establish common terminology Since communication is of such high importance to the success of a project, the first step is to establish common terminology. Whether the project is revolving processes or products, all stakeholders needs to agree on what the different aspects of the project should be named. To do this make sure you as platform manager make a conceptual drawing that either illustrate the product or the project parts and from there interact with the stakeholders. Scoping is essential - make sure that time is spend effectively, and naming essential processes or components is more important than having a half-done highly detailed description.

2)The customer view

The customer view is developed by putting yourself in the shoes of the customer. If you were to buy the product or manage the project what would be interesting for you to impact? - In a product project context, this could be e.g. the number of gears on a bicycle and from a project managers point of view it could be the human resources he can use. Understand the mindset of the 'customer' and write down the part-of classes and the kind-of instances as shown on figure 2. Be mindful, that project management requirements or product requirements are not mixed with platform or engineering requirements.

3)The engineering view

The engineering view is developed by understanding the variation in 'engineering principles'. In a project contest this could be the different ways of assembling a project team: Via Belbin test, via Open-space, An executive decision etc. in a product context this would be the different ways of solving the a function. With the bicycle example this could be different ways of transferring force from the pedals to the rear wheel. This could be done by crank, chain, belt or even gears as shown. The engineering view gives insight into what different principles are used to solve the same problem. One should ask whether different solutions to the same problem is always a good experience, or whether the best of breed should be applied over all the projects or products. Investigate what in what parts of the product or projects that different solutions are used. Write down the function that is being solved as the part-of structure and then list the different variations in the kind-of structure. Be careful not to misinterpret what is different principles and not just different instances (e.g. different sizes in a team does not mean we use different methods for assembling the team)

4)The part view

In the part view all the project material is gathered or the product parts. Consider what content the project or product consists of. E.g. when doing a project, where we wish to assemble a team - we need a programmer, a project manager, a mechanical engineer etc. All of these 'physical' parts are what we can put together in order to form a project or a product. In the product domain this could e.g. be the frame, the chain, the wheel etc. Be careful not to go too deep into the details, as it can be very time consuming. Consider what classes that the project or product consists of and write them in the part-of structure and then put the different instances in the kind-of structure.

5)The part sharing matrix

The part sharing matrix is the overview that gives us insight into how good the platform is a reusing the parts. If for instance we have 5 projects running, and 3 of them use 1 programmer and the other 2 use 3 programmers or if our mountain-bike uses a different chain than our race-bike. The important finding is whether the sharing-matrix visualize a 'stair' (showing little or no reuse) or a flat line indicating high level of reuse. Let the parts from the part view be the rows in the matrix, and the different projects or products be the columns. Then for each row indicate how many times and in what project or product it is used as shown on figure 3.

6)Attributes

The attributes are descriptions under each class indicating additional information that should be considered in the part-of. It can be constraints e.g. no project team can be formed without a project manager. Write under the relevant classes what attributes are connected to that class.

7)Causality

The causality is what links the entirety together. The causality are red lines going from the customer view and the engineering view down to the part view. This is how we visualize how customer requirements impact our parts. For instance if a customer only wants 3 gears, how does that impact our engineering view and our part view? We might see, that 3 gears means that we impact what frame, chain and wheels we can use on our bike. Also it means that we can only use 'chain' as a driving method for transferring power from pedals to wheel and not crank. Draw a red line from where the impact is triggered to where it impacts (as shown on figure 2)

Figure 3: Sharing matrix - based on literature from reference, but made by Daniel Vorting" .

Using the PFMP

After conducting the PFMP analysis, one should have a clear overview of the entire platform. What are the reuses in our projects, what is value adding and non-value adding variety, how are the requirements impacting the platform etc. Use this information when discussing what a future platform should look like. The PFMP should facilitate discussion and serve as an important insight into the current state of the platform. Especially the sharing matrix should reveal how well performing the platform is. It is important to notice, that every time a PFMP is conducted it can vary, meaning that different stakeholders might disagree with the class breakdown, what is different engineering principles etc. Thus explaining what is in scope, how the PFMP was conducted and what is left out is an important part of using the PFMP as a communication tool. The PFMP can naturally give a good insight into the current as-is situation. However it can be a tool for scoping the future platform as well. By developing a to-be PFMP, stakeholders can get a common understanding on what to aim towards in their projects. Furthermore the PFMP can then be used to measure performance of proposed solutions. By comparing the old PFMP with the new PFMP the platform manager can quickly get insight into the performance of a new platform. This is only possible if the PFMP is then developed with the same stakeholders and teams.

Limitations

• The PFMP is highly dependant on the information that can be withdrawn from the stakeholders. In a large portion of organizations the crucial information needed to do a PFMP can be hard to find. The data can be part of several different systems or might not even be in a system. If the information is unavailable it can be extremely time consuming to get the data necessary to develop a meaningful PFMP. If the PFMP fails to include the necessary data it will quickly be disregarded by the
• The PFMP is made for product projects only, and stretching it to fit general projects might induce some confusion and limitations to the applicability of the tool.
• The PFMP can be conducted in different ways - even though a process is proposed, the different steps do give some room for diffentiation

Annotated bibliography

1. Developing product families based on architectures - contribution to the theory of product families
2. Multiproject lineage management: bridging project management and design-based innovation strategy
3. Managing Successful Projects with PRINCE2
4. A Guide to the Project Management Body of Knowledge (PMBOK guide)
5. Product Customization
6. The Standard for Program Management
7. Building Project Capabilities: From Exploratory to Exploitative Learning