Innovation led Business Models for IP's in Product Engineering

By Madhu Parthasarathy, General Manager, DSP & Multimedia Group, Product Engineering Services, Wipro Technologies, Bangalore, INDIA.

Innovation involves two essentially different activities – coming up with a new idea and creating a market out of it. There is no need for the same organization to do both.
Constantious D Charitou and Constantious C Markides ²

Organizations, now a days have mastered the above concept well and hence are outsourcing the engineering and implementation part of innovation is getting more and more common. At our Product Engineering Services (PES) group of Wipro, we handle wide array of engineering services for our customers.

In this era, for a customer who approaches an Engineering Services Provider (ESP) for outsourcing the engineering activities (referred as Projects hence forth) it is imperative to view from an innovation perspective. We have found it useful to classify the projects in to three broad categories.

1. Productivity Improvement (Internally focused)
2. Neutralization (with respect to Customer’s competition)
3. Differentiation (with respect to Customer’s competition)

#	Innovation Focus	Key Attributes	Example Projects
1	Productivity Improvement	1. Reengineering a product 2. Do a lot more with much less on maintenance of product(s).	1. Focus on a subsystem (say a communication card) with in a large Telco switchingsystem; reengineer it to bring the cost of it significantly down and also taking advantage of the state-of-art technologies. (Cost reduction) 2. For SLA 1 of a Product (or Product family) significantly raise the bar for the maintenance.
2	Neutralization	Match or marginally outperform the comparable competitor’s product	1. Take the dominant product of the market and match the features list and in selected area attempt to outperform
3	Differentiation	1.More Experimentation 2.Unique features or user experience is expected 3. Understanding from the end user perspective is critical	1.Key emerging standard (yet to be finalized) to be implemented 2.Product or service delivers radically different user experience

Table-1

While these three divisions by itself may not be fully mutually exclusive, it does lend clarity in terms of where the dominant innovation focus lies for a given project As it can be seen from the Table-1, the degree of requirements clarity varies significantly in each category with least clarity in the Differentiation projects, relatively better in neutralization projects and its best in the productivity improvement projects. Our internal studies and metrics show that, there are two key vectors that influence the clarity.

1. Customer Originated Requirements (direct)
2. Market Originated requirements (Indirect)

Customer Originated Requirements usually represents technical risk of varying levels with respect to schedule. Some of it may be straight forward and easy, some of it may be very hard and require considerable stretch, but nonetheless it is that – technical risk.

Market originated requirements from customers, get lots fuzzier since the customer whom you serve cannot lend clarity at least in the initial phases of requirements. Unless, one explicitly opts to co-create with customer, it is not possible to size up the risks. This is an area where market risks and technical risks morph in to a single bundle and hence any decision on one side has a direct impact on the other.

Treating all the three type projects with same type of business model does not deliver appropriate value for the customer.

We have found that, IP’s themselves can be classified in to three categories from Product engineering stand point. Also, when we examined more than 200+ of the recent projects there is significant IP component only in the differentiation type of projects but certainly in some extreme special cases, we did find some exceptions in Productivity improvement projects as well as Neutralization projects. Hence this classification does have a caveat. To quote the George E.P.Box; “All models are wrong. But some are useful”. This model of classification is not mistake proof, but we have found it lot useful.

#	Nature of IP	Remarks
1	Standards based Implementation	While the standard by itself may be public or can be had for a low fee (example: some of the compression standards) the manner that is implemented could be unique
2	Unique Proprietary Implementation	A key or “kernel” of a product has a proprietary set of algorithms that are implemented making it unique in performance or functionality or both
3	Standards/Unique Implementation + Frameworks development + User experience	By framework, we mean a provision to accommodate relevant 3rd party applications/components in to the main stream of product or service By user experience, we mean focus on the factors that contributes directly to the overall perception of the product or service

Table-2

As can be seen from the Table-2, it involves escalating degrees of risk and fuzziness.

We are learning <3 that, crafting the appropriate business model forms one of the Critical success factor (CSF).

Standards based implementation:

The following factors that influence the Standard based IP’s, while it may not be exhaustive, the factors below would form the top drivers.

1. Main or Core development
2. Customization that required with respect to the customer
3. Testing efforts
4. Certification on the platform where ever applicable.
5. Performance Requirements
6. Updates as applicable

Taking a simplistic view of the first Main or CORE development with some testing effort alone does not reflect the true value of the IP/IP-Component. Usually, the value gets progressively loaded in the form unique customization on the platform (say some ingenious way to implement an algorithm taking advantage of the platform’s capabilities). Then, any complaint testing and certification adds more value. In this kind of development, one type fits all simply does not work. Either the estimate is too high to the point of overwhelming from the customer’s side or far too aggressive for ESP to sustain the delivery profitably. Hence Fixed Price for the full cycle does not work and on the other and on the other hand Time & Materials approach would make it expensive. We have found that a win<>win could be crafted when status is checked at each phase and business model is agreed upon. Our metrics suggest that, for customization, performance and certification T&M works the best and for the main development and update fixed price works the best. The suggestion takes in to account of the efforts that goes in to negotiation for the change request(s) efforts and the associated sign-offs with the customer.

Other key thing is that, performance requirements, the efforts are markedly asymmetric - that is, to reach the last few numbers takes a disproportionate effort. Hence it is prudent to have slabs on the performance parameters and tie an appropriate model based on efforts.

The next important external factor to be considered when developing reference implementation in an emerging standard is the change rate that is expected of the standard. Stepping in too early would mean too many changes in the design. At the same time, we have found that observing the key algorithms is vital whether they finally make it to the standard or not.

As standard evolves, periodic updates may have to done to customer depending on the agreement. Unless it is clearly thought out in terms of sustainable model, it can represent the huge drain.

Unique proprietary implementation:

The following factors influence Unique or Proprietary based implementation. The six factors discussed previously are also applicable here. But, this category has some subtle variations.

1. Main or CORE development

This is usually out-of-bound for the ESP being a crown Jewel of the client and only the rest would be OPEN. There would be either APIs or a software infrastructure to build over the same.

This is one of the cases, where, if the framework that is developed is broad enough, then, it can be potentially used for other similar ones there by reducing the cost to the current customer. For example, a framework to test a generic category of devices with respect to a compliance standard and so on. They are hygiene factors which every vendor playing in the market would have to do and hence standardization of the same would bring the costs down.

2. This is where Royalty/NRE type of business model reasonably fits in.

Customer usually takes the technical risk by implementing proprietary implementation and ESP can take the market risk (if assessed well in terms of potential) and collective Go-to-market indeed creates synergy. If the projections of the number of units shipped that would contain the IP are realistic, with provision to amend upwards or downwards depending on the market performance, then it works well.

Standards/Unique Implementation + Frameworks development + User experience:

Third in the category is where user experience is also there along with standard or proprietary IP development and framework.

In this category, the user connotes a much deeper meaning. It refers to the eventual end user who would ultimately use that product. It is imperative to get that end user perspective – the experience part refers to that end users.

This category has high component of customization and subjective judgment. Standard literature suggests that the buyer’s experience goes through the following stages

Strangely, the customer does undergo a similar experience even when they build a product with an Engineering Service Provider. In some sense, what is service to the provider would be a product for the customer. The “build” phase of the product approximately equals the Purchase + delivery. Here, customer does not have something to purchase direct, but a part of it alone is available. The buyer’s focus is on coming up set of additional features in the product which would have to be added on IP or over IP and then a framework. This assumes, the buyer of services knows in exact terms what are the additional items to be implemented. This does not happen often owing to extreme market dynamics. Unless, the Engineering Service Provider and customer together look at the market together and make decisions synchronously, there would be lots of bandwidth that would spent – here is where an appropriate business model would provide huge advantage for either side and allow to focus on project and market issues.

For example, after the market survey, if the customer decides to lease the product instead of selling the same for one time as a key strategic decision to differentiate compared to the competitor, it does have a huge impact on design with respect to supplementing, maintenance and the disposal phases.

It is easy to visualize if the product is implemented on the similar ways like that of the competitors, then the decision which appeared so sound could well prove to be a bad bet since the underlying design would not support the same. If the Engineering service provider is oblivious of this key decision, it has serious impact on the customer’s experience. By and large, it is safe to say, higher stickiness and looking at the market together are the key to success. Entire cycle should be taken in to account rather than view as mere design plus implementation.

What did not work?

1. One business model all through the life cycle of the project simply does not work.

2. Doing the risk assessment only once before taking on the project. Most of the external risk in terms of probability of occurrence and also in terms of impact varies significantly during the project’s life cycle.

3. Freezing performance parameters too early in the project. Even it is against the key competitors, we have observed it is better to classify as

    => Constraints (criteria should be met)

    => Preferences (optional conditions, it should always come from the customers)

By having this combination, customer can effectively choose during the correct phase of the project rather than committing too early. It is because some of the important performance decisions could be made only just past the design phase and after certain key mock implementation(s) or prototyping. It would provide vital data to base line. It is nearly not possible to get such data externally.

4. GUI:

Skipping the prototyping part or offering only one GUI option to the customer

From the user experience perspective this is very critical. The experience really shapes the way the product is perceived. Hence prototyping multiple times and constant feedback from the end customers if they can be identified in advance.

5. If there are internal risks that are unique to the project and it happens, trying to amortizing it would render the IP uncompetitive in the market

6. Performance Parameters: Efforts and Schedule asymmetrically increase towards the end. Hence any performance parameters commitments based on linear extrapolation is bound to fail.

What has worked so far?

1. Prudent Risk management is critical and the effort that goes in to it should be in proportion to size of the project. For example, if the size of the project is small, some of the risks can be simply identified and best left being there. The RISK management effort should not be overwhelming

2. Critical is the identification of outliners is a must. They may be going undetected when standard internal or external templates are used. Any technical risk which can totally render the basic design nearly futile should be identified as early as possible.

3. Business Model should reflect the risks that are foreseen in that phase of the project. Ideally it should be like Velcro – a seamless switching of business models

4. Business turns usually goes in a cycle. See the figure below. It is not to scale and would vary significantly from one sub-industry to another. Cycle to be read in clock-wise. In the centre would be the given industry segment (say Semiconductors or Automotive etc)

We have found that when price firming phase is happening for a given industry, that is best time, to invest on IP from the ESP’s view point. That way, when the market takes off, amortization happens ahead which leaves enough cushion to face the weak market cycle. This is specifically applicable for standards based IPs.

Conclusion

In the human resources handling, one of the key sage advices is that, treat people like players in CHESS board where every piece is unique rather than CHECKER board where all pieces are similar. Similarly, if we handle each project as piece in Chess, we would be able to offer well suited unique business model that provides win<>win for the customer and the ESP.

It is not sustainable any longer to stick to two extreme ends, Fixed Price Model or Time & Materials. Also predetermined royalty type of approach alone is grossly inadequate.

We are moving from an era of economies-of-scale to economy-ofchoices, hence variety and granularity of choices in terms of business model would be the key to success Henri Poincaré, makes a telling remark when he said, It is by logic that we prove, but by intuition that we discover. To know how to criticize is good, to know how to create is better.

We have had enough of criticisms and now it is time to create. Then, if we have to create, we have to go beyond the current ones, start experimenting continuously in a small ways before we can hit upon series of discoveries!

 

¹ SLA : Service Level Agreement

² Responses to Disruptive Strategic Innovation, MIT Sloan Management Review, Vol-44, #2, Page 63.

³ Certainly it would be a continuous learning process with refinements all the time!