Skip to main content

Case Study 7

Background

The motorcycle manufacturer that is featured in this case study won an order to develop a multifunctional motorcycle. Still, problems mounted over developing user interface (UI) peripherals. The decisive factor for quick development was a reference solution supported by a rich ecosystem.

The motorcycle manufacturer was consulted by a major distribution company on the development of a motorcycle for delivery only. There were many requests to prioritize a working environment for drivers. It was necessary to add various functions, which involved not only safety and security aspects but also the navigation system, connectivity to mobile devices and entertainment. Immediate action was needed, because the motorcycle had to be developed at a lower price in the short term.

Problem

The most important issue was to develop UI software.

How to develop UI software without relying on a third party or outsourcing?

The motorcycle manufacturer immediately set up a project within the development department to identify existing issues. According to the project leader K, there were three major problems.

“The first problem was that we didn’t have much experience in developing a user interface (UI) that converged many functions. The second was the number of man-hours to develop the software. Man-hours were expected to be enormous, because the software required a face authentication system for drivers and functions to play music and videos for their waiting time. The third was price. Since this software was a custom-made product, we wouldn’t be able to increase the price significantly from our standard product as our policy. For that reason, we needed to lower development costs as much as possible.”

During discussions within the project, there was a proposal to use a UI product (a set of hardware and software) developed by an overseas third party. The idea was to buy a product that was completed to some extent and develop what needed to meet requirements for this project. The project leader thought it was a bright idea and immediately contacted a third-party vendor.

After he heard about the product in detail, however, there was a problem here as well.

“Functions supported by the product covered only about a half of required specifications. If we had to develop the rest by ourselves, it would be a lot of burdens on us. In addition, since the software used the operating system (OS) independently developed by this third-party company, the only available software development tool was this poor one made by this company. There was also no software developer that could handle this tool.” (The project leader K)

Consequently, the project leader told required specifications to the third-party vendor and asked if it could customize the software to meet them. The vendor then presented outrageous fees and said it would take more than a year for development. This made it extremely hard to use a third-party product.

The discussion was right back where it started, and the time to consider a development policy was also limited. The project members were getting impatient.

Summary of the Problem

  • A lack of in-house experience in developing multifunctional UI software for motorcycles
  • The number of man-hours to develop software would be enormous, because many functions were requested in this project
  • Necessity to curb development costs as much as possible
  • A proposal to make alterations to a third-party product was found to require too much costs and time