Developing Product Platforms – Microsoft Example


Recent news suggests that a new version of Microsoft’s critically acclaimed Surface Book is entering mass production. It appears that Microsoft had to make significant changes to the original Surface Book to meet some of its business goals…

The sources believe Microsoft’s decision to lower the price range for its new Surface Book is because the existing Surface Book’s high price level has significantly limited demand, while the detachable design also created conflict with its Surface Pro product line in terms of product position. Because of the two factors, the sources estimate that Microsoft only shipped 500,000 Surface Books in 2016.With the Surface Book to be positioned as a traditional notebook product and feature a friendlier price level, the sources expect related shipments to reach 1.2-1.5 million units in 2017, while the Surface Pro, despite weakening demand for tablets, will enjoy on-year shipment growth of 20% to reach six million units in 2017.

New product platforms that are significantly different from existing product-lines are notoriously hard to develop. It appears that even a very successful product platform such as Surface Book may actually need updates.
Read More


What is Research, Development and Engineering (RD&E) Management?

As we have discussed in the past, different organizations include different processes and disciplines in Research and Development. We at InspiRD have started using Research, Development and Engineering (RD&E) as a generic term that includes technology development, product development and sustaining engineering.

Integrated management of RD&E can provide immense benefits to organizations…
Read More


Categorizing Project Execution Risks

Here is an interesting article in the Project Management Journal about types of risks in project management:

  1. Strategic risks: Those that relate to project goals (short-term or long-term)
  2. Operational risks: Those that relate to project operations, individual outputs and results
  3. Contextual risks: Those from circumstances outside of the project that may influence the scope of work and the performance of the organization. Examples are competing projects, change in ownership and management, legislation and governmental directives, media attention,  market conditions, and accidents.
As is the case in most activities, project managers tend to focus on operational risk at the expense of strategic risks:

In this study, risks are categorized as risks to operational, long-term, or short-term strategic objectives, and, by studying a dataset of some 1,450 risk elements that make up the risk registers of seven large projects, we examine how operational and strategic risks are distributed in the projects. The study strongly indicates that risks to a project’s strategic objectives rarely occur in the project’s risk registers, though project success and failure stories indicate their importance.


Managing Project Execution Risks (wonkish)

The Project Management journal has an article called Managing risk symptom: A method to identify major risks of serious problem projects in SI environment using cyclic causal model.  The article lays out an interesting framework for managing project execution risks in large system integration (SI) environment.  Some of the concepts are work remembering.

Serious problem projects (SPPs) often occur, particularly in a system integration environment, and it is difficult to prevent them, since the relationships among phenomena that occur throughout the project life cycle are extremely complicated. Our goal is to make it easier to identify major risks by distinguishing phenomena that are sources of future SPPs from phenomena observed in actual field projects. By choosing several events whose causal relation is known to be cyclic, we constructed a causal model and clarified that it can contribute to the easier recognition of SPPs empirically, by analyzing actual SPP cases.

The overall message is to anticipate major problem spirals by the analyzing events, understanding if the problems are root cause of a death spiral or a derivative of the death spiral and then taking effective action not only to mitigate the problem (event) but also the underlying death spiral.

The paper is a bit difficult to read – probably because I am not familiar with Japanese project management terminology and because of Japanese English….  However here are the major take aways:


Risk events have different consequences depending on the development phase.  The article divides the project into three pages upper (proposal / award), middle (early development), lower (detailed development and launch).

The article lays out a model with three types of consequences of risks based on the phase (Devil Spiral and Death Spiral):
When an event occurs or it is anticipated, the article suggests to map them to the model based on the phase of the project and then determine if it is a Derivative event – a result of the spiral (as per the article a case that is derived from a death spiral) or an Accelerating event – a root cause that accelerates the spiral.  Once done, the idea is to actively manage events, understand the nature of the spiral and take counter measure to prevent the spirals from accelerating.
Finally, here is an example of the completed analysis:

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.


Enemy Lurks in Briefings on Afghan War – PowerPoint

NY times had a quick little post on how PowerPoint can sometimes lead to meaningless briefings:  Enemy Lurks in Briefings on Afghan War – PowerPoint:

“The slide has since bounced around the Internet as an example of a military tool that has spun out of control. Like an insurgency, PowerPoint has crept into the daily lives of military commanders and reached the level of near obsession. The amount of time expended on PowerPoint, the Microsoft presentation program of computer-generated charts, graphs and bullet points, has made it a running joke in the Pentagon and in Iraq and Afghanistan. – Sent using Google Toolbar”

Another place where I have found PowerPoint to cause problems is project reviews.  Not only do R&D teams spend a significant amount of time developing review packages, but also the briefings tend to be so dense that it is rather difficult to identify and focus on issues of importance.  I am sometimes amazed that reviews actually are useful.  Templates can definitely help, but in the end, I am still looking for a meaningful solutions…


Use of checklists in R&D management

A blog post in the Harvard Business Review talks about “What Sort of Checklist Should You Be Using?”  The post lays out five types of checklists based on Mr. Gawande’s work.  I believe two are important to R&D management

3. At a construction site in Boston, Gawande encounters what I’ll call a coordination list. You have an extremely complicated endeavor that no one person can fully understand, so you set up procedures that force the various specialists involved to consult each other on a regular basis. Again, this seems like something with all sorts of applications outside of construction (and medicine).

4. Gawande describes several value investment managers who use checklists to make sure they always follow certain steps before putting money into a company. This is a discipline list. In a calm, reasoned state of mind, you set down a list of procedures you want to follow to keep you from making bad decisions later, in the heat of the moment. It seems like these can’t really be standardized but, in part because they’re not standardized, they can be used almost anywhere.

Add a sixth type which I have found to be extremely important in R&D Management: Review Checklist. This is probably a combination of 3 and 4 with a flavor of risk management and project management.  My experience is that feedback from project reviews is very useful, but extremely difficult to capture.  There is also a lot of variability on types of responses you get from reviewers (based on their backgrounds).  I believe standardized checklists can help improve review effectiveness immensely.  Even so, many firms I have visited do not use them consistently.  Even when the do, they do not capture all aspects of project management in their checklists.  What have you seen?