03-09-2012, 12:30 PM
Digital Menu for Restaurants
1Digital Menu.pdf (Size: 303.76 KB / Downloads: 49)
Abstract:
In the last years the restaurant industry has lived through many changes. Anyway, there is an area that was not improved since several decades.
While technology is changing the way we do almost everything, menu cards are still mostly untouched - although they have several disadvantages that can be improved significantly by a digital approach.
The Digital Menu for Restaurants project aims to improve this situation. This document provides an overview of the project goals, the project structure, experiences as well as lessons learned and next steps.
Introduction
“For a more consistent and positive experience, it appears that self-order kiosks are coming to the rescue.” Patrick Avery (SO08, page 1)
Consumers today are adapted to interact with computer systems in many aspects of their day to day life. Sometimes we even prefer them to traditional methods, especially when they help to provide fast and convenient service. An example is the broad adoption of ATM’s for bank transactions.
One of the most import areas for the restaurant industry is obviously the customer service. To engage friendly and obliging service staff is most challenging for the majority of restaurant managers. But this is not the only issue in this area. It’s also hard to motivate people every day, because the customer service in restaurants might become very stressful.
Most of the stress occurs as soon as one customer service member needs to take care of way too many customers at once. That’s why this project aims to support processes needed for the restaurant staff and allow them to focus on the important part – friendly customer service. Adapting this goal for the customers this project increases the overall experience at the next trip to a restaurant.
Project organization
We used an agile project management approach. Therefore the project team agreed on suitable tasks for the next project phase every one or two weeks. The project phases were two weeks long at the beginning of the project – 4 weeks before the deadline we decided to switch to one-week working periods. This change helped a lot to actively cope with the customer feedback at the end of the development period.
Next to this phase-based approach we agreed on a rough project plan that included the most important dates and periods (e.g. deadlines, time for bug fixing). Figure 2 shows the most important dates and phases during the project
Project organization
We used an agile project management approach. Therefore the project team agreed on suitable tasks for the next project phase every one or two weeks. The project phases were two weeks long at the beginning of the project – 4 weeks before the deadline we decided to switch to one-week working periods. This change helped a lot to actively cope with the customer feedback at the end of the development period.
Next to this phase-based approach we agreed on a rough project plan that included the most important dates and periods (e.g. deadlines, time for bug fixing). Figure 2 shows the most important dates and phases during the project.
Intercultural Aspects
It’s often hard to understand the different project members because of cultural differences. We learned that we have very different ways to communicate and express ourselves. This challenge becomes even more important, because we don’t see the gestures of our conversational partner most of the time (e.g. in email / chat conversations).
Languages
The industrial partner comes from Mexico where most of the potential customers of the product speak Spanish. Also, most of the employees speak Spanish as their native language. Because of this the main language of the developed software is Spanish. On the one hand the frontend language is Spanish; on the other hand even the database schema is Spanish.
This is challenging for some of the project members, which don’t have any Spanish skills at all. To solve this issue we used the Google Language Tools9 to translate the database schema and add an English version to the comments. In addition, we elected Daniel Chavez to be responsible for language and styling questions.
Programming Experience
The project team members have very different experience with programming languages and software engineering. We tried our best to distribute the tasks among the member by applying a SWOT10 analysis at the project start aiming at identifying the individual strength of each member. Fortunately we had a broad range of skills and experiences in our team. The employees of the customer added additional experience to the project team, too. Thus we think that the total amount of work was equally distributed among the team members.
Anyways, the different level of experience with the required technologies is a critical issue. It is important to point out the required technologies in the project proposal to help everyone to find an appropriate project.
Informal Communication
During the Intercultural Awareness workshop we learned how important informal and non-work conversations are. Unfortunately, we didn’t do so well on this point during the project and had problems understanding each other sometimes. Thus, having more time for informal and non-work conversations are a lesson learned for further projects. Again, this point can also be found at the project analysis by Christian Lescher as shown in Figure 5.
The graph shows that we had informal and non-work conversations only between local team members.
In my opinion the establishment of informal communication between team members worldwide is a huge challenge that might improve projects significantly. One approach to establish such a communication – in a student context – might be to use social networking services such as Facebook.