Product Value Management

Establishing strong leadership to drive motivation and focus on change is a pre-requisite for transformation. Employing creative architects that can quickly find best solutions to match business needs is another great enabler. However, without well defined and explicit methodology, transformation effort cannot be planned, communicated and managed as an organized initiative. Just as great coaches and players define and fine tune their playbook to know how to communicate and organize themselves in any situation, PLM transformation team needs to establish transformation methodology.

Methodology defines a set of deliverables that transformation team needs to deliver. It also specifies what deliverables are applicable to what situation or type of transformation. For each deliverable, the methodology clearly stipulates a set of techniques, methods and tools applicable. Another important aspect of the methodology is that it reinforces basic process improvement principles to which the company subscribes, such as Lean or Six Sigma. These principles need to be carefully embedded in techniques and methods used. There are many methodologies used in practice today with less or more success. Often, unsuccessful methodologies are transplants from other areas of enterprise. As much as it is useful to standardize on tools and methods across the entire scope of enterprise operations, the nature of product development imposes certain limitations to what is really applicable. There are several characteristics that any PLM transformation methodology needs to be sensitive to:

a. Process modeling and analysis. Do not use process models based on discrete events, use informational dependencies network modeling.

Product development process consists of multiple concurrent threads of activities and decisions. Product development activities and decisions are not sequential in nature, but represent an elaborate network of information dependencies with many possible process flows. To address evolving market needs and to differentiate from competitors, development programs involve various degrees of innovation and consequently may have very different technical and program risk profiles. Development organization adjusts process flows for each program in order to deliver on required innovation yet minimize impact of risks on schedule, quality and budget. That means that on each development program, management may change process flows to best match given situation. Hence, a sequence of discrete events may be a good model only in retrospect, since optimal program flow is not known in advance and is in many aspects a moving target even during the program execution. Real sequence of events evolves dynamically in response to various technical and business choices. Some portions of the process do establish a more repeatable pattern over time, however within the overall flow these patterns cover a very small subset of dependencies. If we were to model all possible sequences of events, the number of combinations would make the effort impractical.

Representing process flows with all possibilities of discrete events can be a daunting task. At the same time, selecting few possible flows and missing a large number of realistic scenarios will render the analysis as irrelevant in the eyes of engineering managers who have to proactively manage resources to respond to all possibilities. Every attempt to model product development process as series of discrete events has been historically met with resistance. Typical arguments for rejection of the discrete events models by engineers involve “bureaucratic mandates”, “subjective interpretation of the process”, “static nature of the model”, etc.

b. Standard process building blocks. Develop a normalized dictionary of standard activities, inputs, outputs, metrics and practices.

Nothing gets in the way of establishing consensus like terminology. Most process models, even when structurally realistic, come with significant semantic noise. That is, people will disagree with the meaning of dependencies and their applicability to the situation if there is no established dictionary with all terms used for process definition.

Even though, sequences of activities and decisions take shape dynamically based on evaluation of the progress metrics, at some level of granularity they are always built of standard elements representing each value added activity and decision, their informational inputs and outputs, roles, rules, practices, tools and technology, and practice maturity levels. For example, standardization of work is a pre-requisite for Lean product development, what has been so far one of the best methodologies for continuous improvement.

Definition of standard activity or decision covers all possible situations within which that activity or decision adds value. Each standard activity is associated with its current and targeted levels of maturity.

However, to perform meaningful value stream analysis (imagine value stream as a connected flow of activities and decisions that provides measurable outcomes of value to the final customer), activities need to be modeled in the context of connected process flows. Within different value streams that they participate in, activities will have to be represented with only a subset of their definition elements (I/O-s, metrics, rules, practices,…) specific to the objectives of that value stream. The number of value streams within which standard activities need to be represented can be very large.

Consequently, each reference of an activity in a value stream has to be just an instantiation of the standard element, not an addition to a growing set of independent elements that happen to share same name. Thus, maintaining a centralized definition of each activity should be decoupled from maintaining every possible instantiation.

Good analogy to understand this risk is administering engineering changes on an item used across a large number of fixed BOM-s. Configurable BOM is much better option here. Each item master should be maintained independently of its instances of use. Similarly, in product development, standard activities and practices constantly evolve, and there should be a single master definition of their latest version.

c. Balanced metrics. Apply a small set of relevant and balanced metrics that can be measured and benchmarked.

Product development is general has a mandate to increase throughput of differentiated products that can generate targeted revenue and product margins. Thus, key measurements must involve rate of differentiation of the new products (product innovation index), variability of the development cycle time (schedule variance), cost of development and work in process. In other words, good development organization maximizes throughput of new revenue generating features and products, while minimizing schedule variance, product and process cost and work in process (churn and rework that is not adding value).

These measures are coupled into a balanced set. Thus, to have high throughput of new products and features (more revenue generating features and/or products over a targeted period of time), the development team cannot afford much churn. At the same tine, the higher the innovation index, the higher the schedule variance. Best balanced is achieved at the portfolio level, where the development team sets targets for each program.

When transforming the product development, the initiative team needs to develop the business case and assess each improvement idea by a common set of metrics, preferably the same ones used for portfolio balancing. Initiative sponsor and architects need to explain how will each improvement idea enable higher throughput of innovative products, while making schedules more predictable and reducing costs by eliminating waste. Establishing a common set of criteria for evaluating each initiative is best way to normalize discussions about possibilities and achieve faster consensus by focusing on what matters in the context of the company’s strategy. The strategy is always first evaluated to establish relative weights to each of the metrics used for analysis.

When applying methodology that does not use business metrics as criteria for evaluation of improvement ideas, applies wrong modeling paradigm or leaves process definition open to subjective interpretations, the team is setting itself for failure. No matter how sophisticated their techniques of data gathering and analysis are, wrong models and criteria will always lead to suboptimal choices. Typical problems that arise from inadequate methodology are:

- Process models are not accepted as adequate representations, and consequently process analyses are not seen as relevant to drive consensus for change;
- Over time, the number of process flow models grows and maintenance of the models when standard activities change becomes very cumbersome and expensive;
- The organization gradually fails to recognize the value of task standardization and consequently cannot properly practice Lean methodologies for continuous improvement and scalability.
- Inconsistent measurements applied to different initiatives lead to promotion of local optimum mentality and siloization of product development;
- Imprecise communication of business impacts of different ideas promotes subjective political preferences and divisive culture.

Defining methodology that is best suited for improvement of product development processes may be actually first step required to establishing a complete framework. Other aspects of governance discussed in the previous parts of the blog are as important, however are directly tied to the choice of the methodology. Tools that need to support methodology are then consequently last issue that needs to be addressed. Once the governance and methodology is in place tools can be compared using a common scorecard based on the governance and methodology defined. Unfortunately, many companies underestimate the importance of clearly defined governance and methodology, pursuing rather expensive tools and trivializing the impact of information systems on product development performance.

It is partially upon PLM vendors and solution providers to develop comprehensive governance and methodology packages that can assist their customers with proper approach to improving business performance. PLM systems have grown in coverage and complexity far beyond the automation tools for engineering and design functions. They are now evolved into fully blown enterprise solutions that can meaningfully impact company’s bottom line and strategy for growth. Communicating that strategic value and impact of PLM solutions is only possible with well defined governance and methodology for transformation of global manufacturing enterprises into highly competitive, fast and efficient value chains.

This entry was posted on Thursday, November 15th, 2007 at 1:52 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.