How to get employee engagement in R&D strategy

Time and again, I have found that most employees do not understand or even know about the company strategy.  Corporate Executve Board has some good data in Get Your Frontline Onboard: Communicate, Clarify and Cascade CEB Views – Finance and Strategy:

A surprising number of employees don’t know what their company’s strategy is. A study by the International Association of Business Communicators found that only one in three companies say their employees understand and live the strategy. Robert Kaplan and David Norton, the founders of the Balanced Scorecard, found the situation to be worse. They found only 5% of employees understand company strategy. Without understanding, execution is impossible. Therefore, communication is critical, not only to promote understanding but to help employees appreciate how the strategy relates to what they do.

Of the three Cs, communicate and clarify have been discussed pretty thoroughly.  I want to reemphasize Cascade.  That is the crucial, and pretty much the most difficult portion of getting employee engagement.  Most front-line employees do not or can not figure out what they can do to help with company strategy.  Management needs to make the effort to actually help employees understand what behavior is expected of them.  Sending employees the strategy and asking them to follow it is not it.

A funny anecdote: The presidents of a company actually tried to enforce strategy buy-in.  The strategy was very generic (Reduce Costs and Increase Revenues).  At first, they communicated and celebrated the strategy and assumed everyone would follow it.  That did not happen.  Then the president set up mandatory meetings between mid-level managers and senior executives to get buy-in.  That did not work either because the mid-level managers did not know what they were supposed to do (nor did the senior executives).  These mandatory meetings became question answer sessions that generated no results.  The president than decreed that the mandatory meetings will only be about how mid-level managers would implement the strategy.  No questions will be answered.  That failed as well.  The strategy and the entire effort was then dropped.

I will leave you with the recommendations on CEB on cascade:

To help employees take ownership over their role in the execution, communications about strategy should always be accompanied by goals and metrics. These should be goals and objectives that employees can relate to and can be integrated with their daily tasks. Also, be sure to give them visibility into the goals that everyone up the line is trying to achieve as well so they understand how what they are doing contributes to the larger objectives. Ultimately, front line employees need to know:
What I need to do – goals and tasks
Why I need to do this – the value it provides the customer, the employee, the department and the organization
Don’t create too many goals. Prioritize to make it more manageable. If employees are overwhelmed by the scope of the strategy, or the number of goals they need to achieve, they are less like to perform well.


Three Lessons for Sustainable Scenario Planning

I have always been a fan of scenario planning.  It really does provide great insights into R&D strategy and allows organization to develop robust R&D plans.  The article Six Lessons for Sustainable Scenario Planning talks about how interest in scenario planning is increasing because of the turbulent economy:

One business discipline that generated a huge amount of interest during the recession was scenario planning. We wrote about it for Bloomberg Businessweek and advised many companies on it. The Corporate Strategy Board (CSB) ran a series of meetings around the globe on scenario planning where clients exchanged ideas and talked about how to implement the most successful practices we saw in our client networks. These discussions led to the six lessons below.

I will make it a bit simpler than the six lessons in the article – three points to keep in mind while setting up or maintaining a scenario-based planning process.  I had trouble with Scenario Planning at one of the organizations.  These three are my lessons learned from the experience.:

  1. Formalize Scenario Planning: Have clear ownership / accountability for scenario planning. Ensure that the responsibility / authority are clearly defined and delineated from other ongoing efforts.  Finally, define and expect clear deliverables and results from the scenario planning exercise.
  2. Develop and use Actionable and Plausible Scenarios: It is not easy to devise scenarios that engender useful discussion and lead to robust plans.  On the other hand, one of the biggest benefits of scenario planning is the discussion around assumptions of different scenarios.  All scenarios are based on assumptions.  Organizations should make these assumptions known (explicitly) and allow some discussion on them.  However, the assumptions discussion should be managed effectively and stopped at some stage – otherwise the scenario-based planning discussion never actually happens.  The CIA actually publishes very good global geopolitical scenarios that can be used as a foundation.  However, scenarios that you would have to use will depend on the level at which you are doing strategic planning…
  3. Integrate Scenarios into overall planning and risk management: Once results of scenario analysis are know, use them to drive strategic planning and integrate them into risk management process.  Nothing drives implementation as much as results…

R&D Portfolio Management case study – Microsoft Kin

It is not very  often do we get a look inside R&D management processes and tools at giants like Microsoft and Toyota. So, it is good to learn as much as we can when information becomes available.  I am studying new public disclosures on Toyota’s R&D process and will post about it soon.  The topic of interest today is Microsoft and its killing of Kin product line with only 10k units sold.  This was a big failure – the acquisition of Danger alone is reported to have been around $500M, which does not include the cost of developing the product line and associated software. Lets start off with a quick background from a great article in Ars Technica:

Microsoft’s ambitions with the KIN were sound. As much as the iPhone and, lately, Android handsets garner all the press attention, smartphones represent only a minority of phone sales—a growing minority, but a minority all the same. There are many, many people who don’t have a smartphone, and don’t even particularly want one, and they easily outnumber smartphone users.

Redmond wanted to be a part of this broader market. The company was already a big player in the smartphone market with Windows Mobile; the KIN was a product of its ambitions beyond that space. So rather than starting from scratch, in 2008 Microsoft bought Danger, the company behind the T-Mobile Sidekick line.

To a certain extent Microsoft succeeded in this new device.  Clearly they had great start from Danger and their cloud computing platform.  The idea of social networking focused phone for tweens was also great.  As the AnandTech article points out the phone did have some very good features:

KIN included a notable number of features Microsoft and its Danger team executed better than anyone else in the smartphone market today.

Amongst the notable features are innovative form factor, good usability, great battery life and aforementioned social media integration and very innovative packaging.  So why did Kin fail?  I guess the problems are related to a broad failure of R&D management processes:

  1. Portfolio Management: Executive sponsorship critical to R&D project funding
  2. Acquisition Integration: Not invented here
  3. Product Management: Positioning product as alternate to smart phones but the same cost
  4. Project Management: Significant development delays
  5. Overall R&D management: Unclear strategy, ambiguous goals 

Lets look at each one of these factors in detail:

Several posts such a Engadget and Mini-Microsoft have pointed out that Executive sponsorship is a critical part of Microsoft’s R&D portfolio management.  The Project Pink (which later became Kin) was sponsored by J. Allard, while Andy Lees sponsored a somewhat competing project of Windows Phone 7.  It is a bit strange to prioritize product portfolios based on executive sponsorship and leads to significant problems.  From engadget:

To get anywhere, a project inside Microsoft needs an executive sponsor, and for Pink, Allard had been that guy from day one. It was his baby. Of course, Allard was a visionary, an idea man; Lees — like most Microsoft execs — is a no-nonsense numbers guy, and to put it bluntly, he didn’t like that Pink existed. To quote our sources, Lees was “jealous,” and he was likely concerned that Kin was pulling mindshare (and presumably resources) from Windows Mobile’s roadmap. With enough pressure, Lees ended up getting his way; Pink fell under his charge and Allard was forced into the background

Having two competing priorities is not uncommon in R&D portfolios.  However, alignment of priorities and project pipeline gets done well in advance of launch (at early stages and continuously during portfolio reviews) in most companies with effective portfolio management processes.  In case of Microsoft however, the two projects ended being misaligned strategically, along market niches and through release schedule.  Apparently, Lees, the executive in-charge of Windows Phone 7 ended up re-aligning scopes only partially – which hurt overall results:

Having Lees in control changed everything, if for no other reason than he didn’t care about the project at all. This was right around the time that Windows Phone 7 was rebooting, and Pink didn’t fit in his game plan; to him, it was little more than a contractual obligation to Verizon, a delivery deadline that needed to be met. Pink — Allard’s vision of it, anyhow — was re-scoped, retooled, and forced onto a more standardized core that better fit in with the Windows Phone roadmap, which in turn pushed back the release date. Ironically, because they had to branch off so early, Kin would ultimately end up with an operating system that shares very little with the release version of Windows Phone 7 anyway.

Having acquired technology integrated into new products is not uncommon either.  However, there did not seem to be adequate integration of Danger into Microsoft.  The rejection of acquired technology from Danger and the move to enforce Windows Phone 7 structure on to a completely different OS ended up delaying the project by more than 18 months:

This move allegedly set the release of the devices back 18 months, during which time Redmond’s carrier partner became increasingly frustrated with the delays.

Since Windows Phone 7 is a smart phone OS and requires associated expensive hardware, this added to costs of the phone. Such a big delay in launch of the device soured relationship with the launch partner Verizon and reduced their appetite to subsidize the phone and service.

Apparently when it came time to actually bring the Kins to market, Big Red had soured on the deal altogether and was no longer planning to offer the bargain-basement pricing deals it first had tendered. The rest, as they say, is history — though we don’t think even great prices could have accounted for what was fundamentally a flawed product. Our source says that the fallout from this troubled partnership is that Microsoft has backed away from Verizon as a Windows Phone 7 launch partner, claiming that the first handsets you see won’t be offered on the CDMA carrier — rather that we should expect GSM partners to get first crack.

Product management processes ensure that product is aligned with the target market – in terms of price, functionality and usability.  Due to portfolio management failures, product management failed as well:

Some suggest that the KIN really failed because teenagers all want iPhones. There’s certainly some truth in that—iPhones are certainly aspirational goods—but iPhones are expensive. The comparison is made because the KIN was fundamentally priced like an iPhone—but it was never meant to be. Had it been priced like a Sidekick, as it should have been, and as Verizon initially set out to do, it would have substantially undercut the iPhone and been a better fit for the Facebook generation to boot. It wouldn’t do everything the iPhone could do, but it wouldn’t be operating in the same market anyway.

Furthermore, the schedule slips led to a very incomplete feature set that did not include a calender, instant messaging etc.:

That brings me to what else was lacking that was rather glaring – a calendar. With the right execution, the KIN could have perfectly integrated the Facebook event calendar, invitations, and exchange or Google calendars. Instead, the KIN has absolutely no planning tools or event notifications.

Nor was the data plan priced for the target market:

For starters, the devices lacked a realistic pricing structure – despite not quite being a smartphone, Verizon priced the data plans for the KIN as if they were, at $29.99 per month. There’s since been discussion that Verizon originally intended heavily reduced pricing for the KINs, but soured on the deal when Microsoft delayed release. At the right price, the KINs could have been a compelling alternative to the dying breed of featurephones. It’s hard to argue that there isn’t a niche that the KIN could have filled at the bottom, yet above boring featurephones. At $10 per month or less for data, the KIN would’ve been a much more successful sell.

Add to this mix strategic direction problems: First Microsoft could not get itself to support competitive social networking sites such as Flickr – which actually reduced the value of the product

The giants of the social networking space include Facebook and Twitter, for which Kin offered at least fair support. But rather than support Flickr for images and (Google-owned) YouTube for video, Microsoft plugged in its Windows Live services for these media. Kin also lacked established functionality such as a calendar and instant messaging as well as support for fast-growing services embraced by social networkers such as Foursquare.

Also attempting multiple very conflicting goals (compete with iPhone and be cheap like sidekick) led to muddled execution:

The heart of both Microsoft’s and Google’s mobile operating system strategy is to have diverse handsets running its software. Still, both companies look at the level of integration Apple can achieve with the iPhone and are drawn to have a heavier hand in the design of handsets. This sort of licensor regret is part of what drove Google to create the Nexus One and likely also contributed to Microsoft’s decision to create the Kin handsets. 

It appears that in absence of clear portfolio goals and metrics, there is a lot of politics – which further reduces efficiency and efficacy, drives morale down and leads to rumors of layoff:

But wait, there’s more — the Kin team is being refocused onto the WP7 project, but that’s not the only shakeup going on. Our source said there had been rumblings that Steven Sinofsky — president of the Windows and Windows Live groups — is making a play for the entire mobile division as well in an attempt to bring a unified, Windows-centric product line to market.

I hope you are with me: portfolio management problems along with acquisition challenges problems led to project management problems and resulted in very large schedule slips. Those schedule slips along with feature creep and problems with product management.  Unclear strategic direction and management in-infighting tied everything together and ensured that the project failed.

Many lessons to be learned here!  What do you think?


Customer Driven R&D

It is interesting how R&D managers have to navigate the complex world of management advice – I guess thats what makes it interesting. The article Avoid The Commoditization Trap from Forbes recommends customer driven R&D:

To do that, gather together the best minds in your business, including representatives of all the company’s critical functions, and ask them the following question: ‘Knowing what we all know, if you were our customers, how would you go about deciding whether to purchase our products or services?’ Your cross-functional and top-performing team should then make a list of all of the questions that arise about the problems to be solved for your customers and the questions those customers should be asking a potential solution provider. If those questions are positioned correctly, you’ll be able to expand your customers’ awareness of how you can address their needs, increase your credibility and ultimately set yourself further apart from your competition.

This is actually the opposite of the University of Illinois study recommending focus on technology instead of customers to drive innovation.  However both view points have value at probably different times in the R&D life-cycle.  In fact, managers need to balance investment between both approaches.

Clearly Intel believes in this approach – they have hired their on social scientists to design new computing solutions that could use their chips! The article has one good suggestion about deciding on customer impact that is quite useful in a B2B situation:

First, fully examine the impact your solution can have on a customer’s situation and how it can benefit them long-term. The only true measure of value is how your solution changes your customer’s net profit. Instruct your team in how to clearly and effectively relay such information, helping customers see your value from their own point of view–not in terms of industry averages, past experiences with other customers or generalizations, but in ways that will make them want to defend the validity of your solution to their own colleagues. That’s when you’ll know you’ve succeeded.

 Off to the races…


Don’t have access to customers? Hire stand-ins!

I guess hints about R&D strategy are everywhere one looks.  The article How Moore’s Law drove Intel into the arms of anthropologists talks about how Intel developed and evolved an innovative approach to identifying and understanding customer trends to help drive R&D (for those who do not know SoC, it means System On a Chip):

Now, the SoC business has fragmented into three main parts: 1) OEM customers, who design consumer products and put in orders for SoCs with specific kinds of capabilities, 2) fabless semiconductor shops, which work with a range of OEMs to make SoCs that fit certain market niches, and 3) the foundries, which manufacture the SoCs that are dreamed up by the first two parties.
Because Intel isn’t an OEM customer, a fabless shop, or a foundry, it ends up having to be all three at once if it wants to play the SoC game. That’s one place where the ethnographers come in.
The ethnographers essentially stand in for OEM devicemakers, in that they provide Intel with market-oriented input into the kinds of products that the company should be designing SoCs for. In other words, the user experience researchers can function as substitute “customers,” so that Intel can iterate its products internally in conversation with a kind of “market.”

I have heard of many companies hiring their customers to drive R&D.  It is very common in Aerospace world to hire retiring astronauts or generals.  However, what Intel has done is one step farther removed.  They have hired ethnographers, sociologists and psychologists to go a step beyond their customers.  These are people that their customers would hire to help them plan their products.

This might be helpful for Intel in more ways than one.  First, it helps Intel become more successful by providing reference designs that its customers can use – there by leveling playing fields and driving down costs.  More importantly, it helps diminish the impact of asynchronous development cycles.  It normally takes much longer to design, develop and produce a processor than a system that uses that processor.  By getting insights into what will drive its customer’s behavior down the road, Intel can effectively do codesign with less complex R&D management.  On the flip side, Intel than has to absorb the cost of hiring a skill-set completely outside its normal business and find ways to manage and motivate them…


Three Big Assumptions Leaders Should Question

In an article in the Washington Post, John Boldani points out Three Big Assumptions Leaders Should Question

  1. It is important for organizations to set firm goals
  2. Quick wins are essential to managers in transition
  3. Senior leaders believe in their CEOs
Many organizations I have seen suffer from too much focus on goals.  One widely known example of this is in “Stuffing the Channel” at the end of the measurement period to meet sales goals and get bonuses.

It is important for organizations to set firm goals. People need to have direction so it is important to point them in the right direction. But such a single-minded focus on goals may end up damaging individuals and the organization says a study conducted by Maurice Schweitzer of Penn’s Wharton School. Relentless pursuit of goals tempts managers to cross ethical boundaries and abandon ‘sound business practices.’ Unreached goals may then end up frustrating an organization rather than helping it to succeed.

However, if the goals are not firm than organizations tend to not really perform anyway.   If one enforces a culture that goals need not be met, how does one motivate and reward the organization?  I think a better approach would be to set up a tiered goal structure: An (exponentially) increasing reward for meeting or exceeding goals.  It is even more important to make these tiers somewhat achievable – encouraging teams to try to reach the next level (Remember the Lincoln Electric case in business school?)

Another key with goals is to have balanced goals: opposing goals that make sure that behavior does not become too goal focused.  In an R&D world for example, successful R&D projects are a goal most organizations have.  A success driven goal alone will encourage managers from hiding failures and impede risk taking.  A balancing metric would be wasted development effort: tying some fraction of bonuses to projects that fail – 90% of bonus for success and 10% for failures…  This would encourage R&D managers to take risks and encourage acceptance of failures.

The other recommendations are similar.  Senior leaders clearly should not always believe in the CEO.  However, a show of solidarity might be good for encouraging and motivating R&D teams.


Freescale CTO on R&D Strategies

NE Asia Tech-On has interviewed Freescale CTO on R&D Strategies.  The interview does focus quite a bit on the semiconductor industry, but there are some useful hints for R&D managers everywhere.

First – a clearly defined strategy is quite useful do build focus and drive efficiency (even though it is not done very effectively in many organizations):

Before the Lehman Shock, we detected a sign of business recession. So, we decided to retreat from the business for mobile phones and announced it in October 2008. At the same time, we decided to focus on four areas, namely, automobiles, networking, consumer and industrial products.

Among them, we will cover almost everything in the fields of automobiles and networking, which we consider are our core businesses. In the fields of consumer and industrial products, we will cover part of them such as smartbook PCs and electronic book readers in the field of consumer products and smart meters, smart grids and home-use mobile medical devices in the field of industrial products.

It is also important to define what will be done in-house and what will be sourced from the outside.  Many organizations run into problems with open innovation when there is a conflict between what is being done internally and what is sourced:

We did basic researches when we were a part of Motorola. But, currently, we do not do basic researches in our company. We tie up with colleges and consortiums for them. For semiconductor makers, the day of technological development for technologies ended long ago. 

There is also a need for tighter communications between R&D and marketing, and FreeScale clearly recognizes it

What is important now is to solve customers’ problems. Therefore, the ideas of the R&D division are summarized as PowerPoint files. The sales stuff and marketing people bring them to our customers and ask their opinions. If the customers do not like the ideas, they will be dumped

However, I am not sure if PowerPoint files are the best approach to communicate R&D intent to customers for many organizations.  Who will be developing these documents?  How does one maintain version control?  How does one bring feedback from the customers back and incorporate the into R&D – through PPT?

Finally, one more hint about being responsive to customer needs vs. being submissive to customer demands:

We cannot make products that have an impact on business just by using the ideas of the R&D people. We are doing research and development by considering customers’ opinions and market needs as well as taking advantage of our technologies. I said that we tie up with colleges and consortiums. But, in addition to that, we are collaborating with the industry leaders and our partners to solve our customers’ problems. 


R&D spending does not guarantee profits

In an article that corroborates TI’s findings, here is a 2005 article in Management Issues suggesting that higher R&D spending does not necessarily result in better profits. In some ways the material is still relevant, especially if one wants to find savings in R&D budgets.

Companies which invest heavily in research and development may be wasting their money. According to a new study, there is no direct relationship between R&D investment and significant measures of corporate performance such as growth, profitability, and shareholder return.

The article has some useful data about the R&D spending on the top 1,000 global players:

According to consultants Booz Allen Hamilton, who analyzed the world’s top 1,000 corporate research and development spenders, innovation spending is still a growth business. This 2004 Global Innovation 1,000 spent $384 billion on R&D in 2004, representing 6.5 per cent annual growth since 1999.
And the pace is accelerating. Measured from 2002, the annual growth rate jumps to 11.0 per cent.
While the top 1,000 corporate R&D spenders invested $384 billion in 2004, the second 1,000 spent only $26 billion – only an additional 6.8 per cent beyond the top 1,000 spenders.

This article points out the need for coordinated processes R&D planning, project portfolio management and R&D investment management: “How you spend is more important than how much you spend.”
However, getting coordinated processes in place for planning, portfolio management and investment management is rather difficult. Add to it the complexity of aligning investments with changing market needs and project progress/delays, and the real task of guiding R&D and invention becomes rather difficult.

In other words, the study argues, it is the process, not the pocketbook that counts. For example, Apple’s 2004 R&D-to-sales ratio of 5.9 per cent trails the computer industry average of 7.6 per cent, while its $489 million spend is a fraction of its larger competitors.

What do you think? Do you have any stories to share about success or failure around project portfolio management? Or are there any challenges that you face that you would like to discuss?