Month: July 2010

Too many metrics?

The article The Only KPIs Your Firm Will Ever Need in AccountingWEB.com discusses why too many metrics are not value adding:

Measurement for measurement sake’s is senseless, as quality pioneer Philip Crosby understood when he uttered, ‘Building a better scale doesn’t change your weight.’

They seem to contrast it from the McKinsey maxim:

“What you can measure you can manage.”

 The example they have is of Continental turn around, where Mr. Bethune focused on just three high-level metrics:

  1. On-time arrival
  2. Lost luggage
  3. Customer complaints
Clearly, these are important for an airline.  However they are not the only metrics that need to be monitored in an operating airline.  The article makes sense and it is important for Managers to have dashboards that have unique metrics – Key Predictive Indicators.  However, in most cases, KPI need to be broken down into constituents that can be controlled to improve efficiencies.  So it is not that KPI replace detailed metrics – they provide a way to consolidate many metrics into meaningful indicators and help managers easily detect and eliminate problems.

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?


Hybrid Entrepreneurship

Management Science has an interesting paper on Hybrid Entrepreneurship with empirical data that a large fraction of entrepreneurs start off in a hybrid mode – keep the day job will working on a new venture:

In contrast to previous efforts to model an individual’s movement from wage work into entrepreneurship, we consider that individuals might transition incrementally by retaining their wage job while entering into self-employment. We show that these hybrid entrepreneurs represent a significant share of all entrepreneurial activity.


What drives satisfaction in virtual teams?

As you have probably noticed, management of virtual teams and co-development across multiple organizations is a favorite topic of mine.  Here is a very interesting paper from the Journal R&D Management: An analysis of predictors of team satisfaction in product development teams with differing levels of virtualness:

The purpose of this study is to empirically examine and assess the moderating effects of extent of virtualness on a variety of well-established predictors of new product development team satisfaction. We focus our study on 178 different new product development teams from a variety of industries and use extent of virtualness as a structural characteristic of the teams, measuring it on a continuum. 

The paper had three findings that I find are very important to any R&D manager (as the virtual teams pointed out, most teams become some what virtual even when the members are on different floors).

(1) relationship conflict has a more deleterious effect on team member satisfaction as teams become more virtual, mainly because it is very difficult for team members of virtual teams to resolve their interpersonal disputes; 

So, the article empirically establishes an increased need for active conflict management and effort to keep the team loose.

(2) the relationship between preference for group work and team satisfaction is moderated by extent of virtualness, such that preference for group work increases team satisfaction more as virtualness increases; 

I am not sure if I understand this.  Please help if you do.  From what I read, the people who love to work in groups are more satisfied with work in virtual teams.  Does that mean that R&D managers staffing virtual teams have to either not select or provide extra help to people who tend not to like work in groups?

(3) goal clarity and familiarity are not moderated by extent of virtualness, but have a significant direct effect on team satisfaction.

Pretty straight forward – for virtual teams to succeed, goals need to be extremely well communicated.  They also need to be effectively communicated across discipline, organizational and cultural boundaries.  This to me is the biggest challenge to codesign.  I am not sure if I have found effective tools and processes to address this challenge…


Cost overruns and schedule delays of large-scale U.S. federal defense and intelligence acquisition programs

Project Management Journal in the paper Causal inferences on the cost overruns and schedule delays of large-scale U.S. federal defense and intelligence acquisition programs provides some interesting data on cost and schedule overruns in USG programs:

For example, statistical data from a recent Government Accountability Office (GAO) report (2008a) on 95 weapons systems found that the total cost growth on these programs was $295 billion, and the average schedule delay was 21 months. These large numbers represent a growing trend in cost overruns and schedule delays since the GAO began tracking these metrics in 2000. For comparison, the estimated total cost growth in the year 2000 of 75 DOD programs was $42 billion, normalized to fiscal-year 2008 dollars.

 The author indicates three reasons for the overruns ineffective human resources policies and practices, consolidation of the aerospace industry, and too many stakeholders:

A study was undertaken to understand why cost overruns and schedule delays have occurred and continue to occur on large-scale U.S. Department of Defense and intelligence community programs. Analysis of data from this study infers the causes of cost overruns and schedule slips on large-scale U.S. federal defense and intelligence acquisition programs to ineffective human resources policies and practices, consolidation of the aerospace industry, and too many stakeholders. 

Specifically, he posits that ineffective human resource policies lead to inexperienced personnel both in contractors and customers, people rotate through jobs too frequently, and there are too many contractors involved.  I can imagine that most of these are realities of the current economic and cultural environment.  Just as Toyota found out, these come from inability for R&D management tools and processes to deal with that environment and increasing complexity.

The author also posits that too many stakeholders lead to frequent changes in requirements.  I am not sure if the environment that leads to requirement changes is going to change any time soon.  I guess that means that the R&D managers need to come up with processes to deal with requirements changing effectively – without adding cost overruns and schedule slips…

The block diagrams that the author came up with look interesting.  However, I am not sure if I am able to agree with them fully.  It appears that he had his conclusions made first and then fit the analysis to support them…

Overall, a great article – well worth reading.


Get Immediate Value from Your New Hire

HBR has some excellent advice on Get Immediate Value from Your New Hire:

  1. Start Early:  Start as early as possible in the process to expose your new hire to the organization’s or unit’s culture and to explain how work gets done. 
  2. Get Them The Right Network: The first thing a manager can do is ensure that the new hire understands how important the informal or ‘shadow’ organization is in getting things done
  3. Get Them Working: Giving them real work immerses them in the way things function at the organization. This doesn’t mean you should let them “sink or swim”; definitely provide the support they need. 

This are useful reminders for both manager hiring new team members and team members getting involved in new organizations.  My success in several organizations has been hampered by lack of understanding of informal / shadow networks.  One interesting observation: Supervisors in companies with strong shadow organizations were much more reluctant to explain them!  And some principles to Remember:

Do: Hire for cultural fit as much as for capabilities and skill; Introduce your new hire to ‘culture carriers’ and ‘nodes’; Explain how work actually gets done at your organization 

Don’t: Let a new hire stay in ‘learning’ mode for too long; Assume your new hire can’t be productive from the start; Rely on the org chart to help explain lines of communication


Does innovation improve with external collaboration?

The article Effects of Supplier and Customer Integration on Product Innovation and Performance in the Journal of Product Innovation Management has some empirical evidence on impact of co-design and information sharing with suppliers and customers:

After surveying 251 manufacturers in Hong Kong, this study tested the relationships among information sharing, product codevelopment, product innovativeness, and performance with three control variables (i.e., company size, type of industry, and market certainty). 

The findings seem to indicate a direct, positive relationship between supplier and customer integration and product performance. However, there are a couple of key learnings: For brand new product families (that have not yet percolated through the supply-chain), it is much more important to partner with the emerging customer to learn and perfect the product.  On the other hand, for improving existing product lines, it pays to work with suppliers.  Information sharing with existing customers is not that important, but customer intimacy is:

The empirical findings show that product codevelopment with suppliers improves performance, mediated by innovation. However, the sampled firms cannot improve their product innovation by sharing information with their current customers and suppliers as well as codeveloping new products with the customers. If the adoption of supplier and customer integration is not cost free, the findings of this study may suggest firms work on particular supplier and customer integration processes (i.e., product codevelopment with suppliers) to improve their product innovation. The study also suggests that companies codevelop new products only with new customers and lead users instead of current ones for product innovation.


How To Be An Innovative Leader

Forbes.com had an article with three pointer towards how to drive innovation (How To Be An Innovative, Not Just Business, Leader):

  1. Reframe the challenge. 
  2. Focus on the customer experience.
  3. Practice rapid prototyping. 
Of the three, I find the first one of most interest.  We often forget to ask about the challenge itself and that in itself limits the possible solutions we come up with:

Innovative thinking can be used to redefine, or reframe, a problem. This is not a cosmetic or semantic change; it is a process of reexamining the situation. … By reframing problems, you uncover new places to innovate, or new angles to take. To reframe your challenge, ask powerful questions, challenge assumptions and bring in multiple perspectives. … He reframed the challenge away from fixing a past problem and toward differentiating the product and the company for the future. That was a vision that could focus and motivate the whole team. 

Here are a few more tips from another article in Forbes – Innovator’s Nirvana:

–Get strength at the top. “You can change business models,” said Miller, “but changing culture requires leadership.”

–Watch timing. The change may be great, but are all the support systems there? Remember what you innovate has to exist in an ecosystem to thrive.

–Communicate discovery for open innovation. The discoveries of Alcatel-Lucent’s scientists frequently end up in products far from their respective specialties.

–When ideas just keep failing despite tweaks to the prototype, have the guts to admit you were wrong. Just because it’s different, that doesn’t mean it was right. That judgment is more important. Plus admitting that and going on to try other new things can actually make you braver


Innovation’s Dirty Little Secret

The Businessweek Article Innovation’s Dirty Little Secret talks about how many organizations pay lip-service to Innovation:

Recently I spoke with a group of executives from a $3 billion division of a large industrial company. They were faced with a mandate from the chief executive to expand the firm’s service revenue from 20 percent to 33 percent. That’s almost $400 million in new revenue, yet when I asked how many people were on the team, the leader replied meekly: “Two.”

Some organizations like IBM clearly seem to invest a lot in Innovation and have found ways to make it successful (I am not sure what is innovation in a transformation from product to service business…)

Rosabeth Moss Kanter’s October 2009 Harvard Business School case study, ‘IBM in the 21st Century: The Coming of the Globally Integrated Enterprise,’ details many acts carried out by the leadership team during the company’s fabled transformation from a product to a service company. Executives were prepared to put big money where their mouths were when it came to supporting service-based ideas, such as ‘Innovation Jam,’ or such businesses as ‘On-Demand’ software, and strong messages about the importance of services were sent.

One last interesting learning from Kaiser – it is a great approach to make sure high risk high reward projects actually get implemented:

when a promising innovation project is about 50 percent complete, she brings together representatives from information technology, patient services, and facilities management to assess how to scale it across the company’s vast system. By evaluating the “O-Gap”—that is, the space between pilot and operations—this group takes into consideration everything from process realignment to environmental modifications, as well as the training requirements needed to foster wide adoption of the change.