Product Value Management

I have recently had a chance to review two projects that used VCOR model and methodology for continuous improvement, one in a semi-conductor company, the other in a consumer packaged goods company. Although both targeted same space - product development, they pursued somewhat different steps. First company did not have any internal model to start with and VCOR was a great jump start for them, They could quickly pick applicable VCOR elements and then build their own decomposition for a semantically rich process model. The CPG company had already amassed process knowledge but it was very unstructured and had many implicit elements (implicit metrics and inputs/outputs were the major pain point). It is unclear what is better, just to use VCOR and jump start it, or reconcile internal model first with VCOR. I’d say it depends on how structured your internal model is. For example, at Chrysler it made a lot of sense to reconcile CDS (Chrysler Development System) first, because it was a semantically rich model with well organized structure. In many cases, however, starting models are a mix of activities, deliverables, inputs/outputs, criteria for gates, …

Either way, it is very beneficial to complement VCOR with the domain specific dictionaries as decompositions of the VCOR level 3 elements.

The process has three steps:

1. Tease apart the existing model elements into the categories such as activities, inputs outputs, metrics and events (look for words, verbs should be activities, e.g. “delivering…”, “defining …”, “assessing …” nouns should be I/O-s, e.g. “…definition”, “…report”, “…assessment”, passive voice should be events, e.g. “…delivered”, “… defined”, “…assessed”. For metrics use simple rule of calculability, quantification and use for supporting trade-offs.

2. Once teased apart, the elements have to be grouped and mapped to VCOR categories. This gives high level buckets of where they belong according to VCOR level 3 processes and VCOR metrics and I/O classification schema.

3. Then, use classification according to the organizational or functional divisions to assign groupings to elements below level 3 of VCOR.

This way you can obtain a great dictionary fully complementary to VCOR, with ability to use either VCOR or this dictionary whenever modeling processes, to show both higher and lower level process flows.

This topic requires easily an entire book in order to describe and illustrate all challenges, traps and potential mistakes a manufacturing company can make when adopting or improving product portfolio management practice. I will try however, to highlight some key ingredients and prerequisites of a successful effort.

Let me introduce basic concept (very basic). Product portfolio management, just like any other investment decision making, has a goal to maximize return from available investments options - in this case new product development ideas and current programs that have not reached the economic “point of no return”. Often, it is done by rating and sorting all available options based on some common trade-offs such as projected revenue, product margin, time to market, investment required. etc. Right away, the simplest possible model of the problem consisting of three elements come to mind:

- What are product alternatives to choose from
- What are criteria for evaluating them (sorting them based on trade-offs)
- What is the best technique for choosing between alternatives

To accommodate first element, each product needs to be defined with standard comparative parameters, e.g. target/actual market share, target/actual profit margin, target/actual value proposition (features, options, availability, price, …), target/actual competitors, technologies required/involved,… Then you have a hierarchy or grouping where products share some common parameters like target market, or common feature sets (let’s call these product families), or common production assets and technological foundation (let’s call these platforms). Thus, product families share common technologies that also need to be developed, and you get a matrix of two portfolios - product families with products and derivative offerings, and families of technologies (a.k.a. platforms) associated with products. Suppose we can define a data model describing all products in this way. It is a complex model, but quite doable and there are some best practice product models to choose from.

Then, you have to define second element, the criteria. There are two generic sets of criteria: goals and constraints. Goals are what each product needs to accomplish to be a value added member of the portfolio, e.g. margins, revenues, etc.. Constraints are what all products may have to share, like budgets, production assets, human resources, competitive price levels, etc. There are also available best practice criteria models as well.

Then, there are techniques of optimizing the portfolio. Here, you have to establish algorithms for sorting and selecting the best options, or eliminating worst options. These algorithms contain instructions on how to make, rank and compare different portfolio make-ups (a.k.a. scenarios) to choose the most favourable one given the criteria and constraints. There are some quite elaborate algorithms - yet they exist and they can be found.

Now, what makes this difficult if there are best practice models for the three basic elements? This would sound easy if it was a static model, like a spreadsheet with cells and each cell has a value. You have to add to this - uncertainty and changing goals and constraints, and you get a dynamic set. So, more accurate model would be a spreadsheet where each cell is not a number, but a statistical distribution. So, how do you model the uncertainty surrounding the portfolio becomes the most critical element indeed. Some companies have in fact done quite well in establishing the portfolio management framework. I would rather discuss here what common approaches worked for them, what issues they needed to overcome, as well as some traps that others fell into and did not succeed nearly as much.

First of all, you have to choose techniques you are going to use for selection of alternatives. And here you have a myriad of options, but only one type works for innovation intense competition. Many companies have failed right here opting for measuring value add based on effort, such as net present value or earned value management. These techniques are based on the premise that the amount of effort spent is proportional to value. Then to fix the obvious shortcoming, they introduce a concept of “risk adjustment” to multiply the estimated effort with some risk coefficient, thus penalizing product alternatives that may consume more effort but are deemed more risky. Again, double wrong, since the effort should not be the measure to begin with, the risk cannot be calculated objectively along the effort dimension.

The only useful measure of risk is along the time dimension. And time is not proportional to effort, because you can adjust the sequence of work once you know the risks and thus change the effort distribution (a.k.a. front-loading for risk work-off). The effort based techniques are oblivious to the real risk measure (variance of schedule) and force you into two dangerous assumptions: to compare alternatives, you have to assume that each product development effort should go through same flow - WRONG, and you can contain risk by adding resources - WRONG. Hence, one approximation gets compounded with another and you get a totally skewed portfolio optimization technique. Best companies in this regard take risk based portfolio balancing techniques involving variances of schedule and budget estimates, and get much more meaningful scenarios to deal with. Advanced discussions of these concepts can be found in the works of Murray Cantor of Rational.http://www-128.ibm.com/developerworks/rational/library/mar06/cantor/

Another challenge of technical nature is to bring all data required for a complete definition of the three elements into some orderly process and tool. Some new data needs to be managed, existing data extracted from other processes. The portfolio dynamics needs to be accurately measured based on real execution status, and then reports compiled and discussed according to some rules and guidelines agreed upon by decision makers. Often, only when finished defining the entire framework companies actually discover that they cannot use it until they have implemented all interfaces and integrated data environment. Here, the trick is in developing your data management model in parallel with your framework, thus making adjustments as you realize something cannot be done the way you though it would. Companies can easily loose several years by not considering this along the way, because only when they start considering the data they realize that a slew of other processes needs to change - namely program management, project management, product definition management, requirements management, resources planning, etc. Portfolio management is NOT an isolated discipline and it is to be viewed as an integrated practice throughout the entire product development spectrum of processes.

To summarize, if you want to implement portfolio management process at minimum you will have to do following type of work upfront:

1. Define your most natural product model top down - families, products, offerings, technology platforms, features, … Strictly from the customer value added perspective - what is it that we sell and how are customers obtaining the value - features, product availability options and regions, product serviceability, etc. All of these versus price makes for simplest value equation. Think lean. Common mistake is to use a set of projects as a model for portfolio. Project is not something you sell, it is a folder of tasks that you need to do, it does not show what customers really want, value and judge relative to competition, it does not show underlying aspects of innovation such as differentiated technologies, intellectual property, features, competitive pricing issues, production assets allocations, projects can be only objectively compared by how much resource they consume. Everything else should not be taken for granted, at least it is definitely not by your customers.

2. Define a good model for constraints and goals - e.g. shared pools of human resources (architects, engineers, managers,..), production assets required/allocated, new investment available/allocated, revenue targets, competitive prices, margin targets, innovation indices… Again, use normalized definitions that mean something to people, so you can for example calculate “what the production yield should be given the allocated production assets and target price to make sure the product will achieve target product margin over a period of time”. Then ask if you have significant risks in achieving such production yields and what are the impacts of these risks on variances of schedule and budget. That way the rating algorithm deals with meaningful and balanced set of measures to compare product alternatives based on realistic and measurable scenarios. Common mistake is again to use subjective voting charts whereby selected people (undoubtedly smart, but) vote based on their own understanding of the goals and constraints, choosing between ideas. And then they sort out best bets, minus their perceived risks rated again using simple voting charts and subjective scales. That way engineering knowledge, the only true source of risk elimination gets completely sidelined. Only by capturing, reusing and constantly updating its knowledge can a manufacturing company effectively reduce development risks and make more predictable schedules (think Toyota’s trade-off curves).

3. Above all, do not even try to use effort based value measurement techniques. Human resources are just some of constraints, but you have no clue when comparing early ideas how will each program pan out and if any risks can be fixed by adding people . These techniques can ONLY be used in relatively highly predictable processes, with upfront recognizable recurring risks. If you are in commodity materials business, maybe, but not in technical innovation business offering highly innovative products striving on velocity and reliability. You will need to develop adequate risk/return ranking technique based on more meaningful models of processes based on front-loading and decision postponement, not overly simplistic phase-gate models. Portfolio decisions are not better advised by simplified program reporting, it is about making accurate and meaningful projections of key product value measures. Common mistake is to believe that portfolio management starts with standardized program deliverables reporting (we will first make standard phase gate model with common reporting of deliverables’ readiness…). Portfolio management actually ends with meaningful set of measures and deliverables to be tracked and reported for each program, what makes it work is lining up everything in between.

4.Last, but not least, the process needs to be defined to make sure all required data is available, particularly that program management and project execution processes are FULLY reconciled with portfolio management, using same set of tasks definitions, metrics, resources definitions, etc. This requires a common strategy for process rollout and tool implementation between program management and portfolio management initiatives, since they will share data model and processes.

Few months ago, I asked a senior executive at one manufacturing company, that was just about to spend significant investment on portfolio management solution - how they rank in these four categories. After checking with their initiative team the answer was very pessimistic. Then they searched for answers particularly preparing themselves in regards to recommendations 2 and 3, and are now reconsidering entire process and strategy for selecting solution.

If you are in manufacturing business, trying to compete based on innovation and velocity, asking yourself these four simple questions can be your best start towards improving portfolio management…. then, your inquiry with vendors and consultants may be better advised before you start spending time and money on selecting the solution.

I was sidelined for couple of weeks by a recurring respiratory infection, but feel again in the writing mood. Few interesting events have happened last month and I’d like to comment on both of them.

We had a workshop on applying semantic frameworks to continuous improvement of product development processes in Troy, Michigan on January 18. The audience was diverse: end users, vendors and consultants alike. We were somewhat overwhelmed with both diversity and numbers (over 20 attendees), what is always a challenge for getting the best of open interaction. Based on the responses, the workshop went very well, many have gained better understanding of VCOR, and how to apply semantic frameworks to continuous improvement, and in particular have made a leap of faith that PLM after all is not out of reach of BPM methods and tools. Some comments and questions from the audience raised a concern that PLM strategists and planners in manufacturing may not be fully aware of capabilities of BPM tools, thus missing on an excellent opportunity to apply logical order of steps and above all business sense to their PLM implementation efforts. We will most likely repeat the workshop, since this type of education is critical for anyone searching for simpler and more meaningful ways to manage PLM transformations. Stay tuned for the new date…

Another event that took my attention was the announcement of Siemens to acquire UGS. Now that the first dust has settled, the open question remains: how will UGS strategic focus change; we are still awaiting the answer. In particular, two aspects come to mind: a) will the focus on bill of material management as a backbone of information exchange between design and manufacturing sharpen and expand; b) will the role of part and assembly geometry as a simplest way of communication of mechanical designs evolve into new usage contexts. The common thinking is yes to both, since the two aspects are the key focal bridges between product design and production process design, and that is reported as a key rationale for the acquisition of UGS software and IP assets.

However, two subtle strategic considerations remain to be verified: One thing is to focus on BOM management as a key to reconcile geometry with product configurations for accurate manufacturing release - traditional engineering automation focus, the other is to focus on BOM as an enterprise meta-data backbone spanning all phases of life cycle, serving concurrently production process design and quality planning, manufacturing execution, cost planning, purchasing and sourcing, forecasting, portfolio management, etc. We yet need to find out if there will be any changes to the UGS BOM management focus.

Similar situation is with geometry. Apart from authoring and managing its creative evolution what is a strong side of CAD tools, geometry can be used in a myriad of ways and contexts to speed up and improve communications in production, purchasing, service and maintenance, not to mention brand development, sales and marketing. UGS has already committed and pushed hard to open formats, but beyond raw data publishing, registering and multi-purposing of XML data for other enterprise uses has not been the stronghold of engineering automation vendors. Yet, the power of multi-purpose XML documents registries and repositories is obvious (think why PTC acquired Arbortext, why Adobe sees 3D CAD as an opportunity, why Seemage already expands into BOM management, or simply imagine how to use of some of the newest Vista features).

Overall, the acquisition is a proof of increased maturity of the PLM market - recognition that PLM in manufacturing requires engineering automation to be convergent with production and enterprise data management and collaborative communication. But, we need to stay alert in the near future to completely understand Siemens strategy here. We will look for signals of Siemens expanding acquired footprint to address above mentioned and some other strategic considerations - portfolio and program/project management, to name few others. If the signals do come along, this will open a new chapter of the PLM market - an already overdue true consolidation.