Author: Susanne Marx, Aug 2019

1. Recommendations – Concept

1.1. Event concept

1.1.1. Hackathon conception

We recommend to ask these questions in your development of a suitable hackathon concept:

What do you expect to get from the hackathon? (e.g. contacts, creative ideas, problem solutions, prototypes, learn) Define your targets! How will you know, if the hackathon met your expectations?
How do the selection criteria for the winning teams of the hackathon link back to your targets?
Who are the “right” participants that help you reach your targets with the hackathon? (e.g. tech enthusiasts, visitors, school kids, professional programmers) What motivates them? How will you communicate with them? Which added value you will you provide them?
What will you do with the results?
How should a result look like (code, idea, …) that you can further use it? What legal aspects do you need to cover to further use the ideas/results?
Is the hackathon part of a larger process? How will it fit in, will you be in contact with the hackathon participants after the event?
What is the overall value of the hackathon for your organization?
How does it fit with your general innovation strategy?

1.1.2. Participants

Depending on your target, participants who you want to attract might differ. In our experience, we focused mainly on students and pupils in vocational training, in some cases also professionals. The motivation of the participants is manifold, however, only limited based on the prizes. Prizes are rather an additional eye-catcher in promotion and a feeling of reward for the time devoted to the hosting organizations. The drivers of motivation should be used in deciding how to communicate the event.

An overarching conclusion is for driving motivation you should provide participants with the maximum freedom to unfold their ideas, however, still reaching your expectations. This relates both to team setup, to the required final product of the team, to the topic and to ways of working.

Why do participants come to the hackathon in our experience:

- Gain new experiences and learn
- Get to know new people
- Fun
- Test of own skills (creativity, programming, team work, under time pressure)

But also (based on more programming oriented first three hackathons):

- Getting to know the people from IT industry (for business contacts/jobs)
- Curiosity
- Interesting topic of hackathon
- Compete, challenge
- Love programming
- Learn from other programmers

The aspect of competition is ambiguous. While some appreciate the competitive atmosphere, others disliked this aspect and preferred to see it as a learning experience only. In order to foster exchange and networking, we experienced that putting the joint experience and learning at the first step and having the competition as an add-on in all communication proved to be valuable.

Having a hackathon with several museums bringing their different topics and stories, seems to have increased the learning aspect, as the solutions are not directly comparable. This seems to have fostered exchange between the teams.

The setup of teams is recommended to be as interdisciplinary as possible, however, being too restrictive might make participant acquisition difficult. Also here it counts, the more freedom given to participants the better for their motivation.

We recommend to integrate a member of the hosting institutions providing the topics into the teams. Thus, the team has full access to the expert knowledge and the museum staff also learns about ideas that might not even be finally presented by the team in the end.

As for international hackathons, our experience is that on the one hand it adds to a great atmosphere, however, some participants have fears in presenting in a different language. If teams are not mixed with different countries, the team tends to speak their native language which might exclude the museum staff from another country from gaining full insights of the work process. So, either all the team is from one country, or it is fully mixed to have English as the only means of communication.

1.1.3. Mentors

Mentors are a basic concept of a hackathon. They inspire, give knowledge and help the participants. It is recommended to have different kind of mentors. For example, in Klaipeda, six external IT related experts and seven museums staff members acted as mentors and jury. In Malmö, mentors were available for questions since the warm-up. In Greifswald, museum mentors were fully part of the teams to take part in the creative process while a process mentor and several tech mentors were at disposition for all teams to use as a support. We found that this latest set-up was most beneficial.

Plan a briefing for all mentors to have same knowledge, expectations and understanding of the goal of the event (one voice to the participant).
If museum staff is integrated into the participating teams, they need a separate briefing, especially on how much to interfere, be careful in judging solutions too early (limits creativity) and how to act in case of conflict or stagnation of the team’s work.
Present all mentors with their competencies at the beginning of the hackathon (and also at the warmup if applicable).
Standardize, how mentors are to be approached during the hackathon – e.g. in an additional room/or corner to meet alone without disturbance, where also participants are not scared that their idea is “stolen” by others.
Mentors could go round the groups, however, this should though be limited, as participants might feel “disturbed”.
During the night, participants did not want to be disturbed and wanted to be focused on work. Consider, if a first part of the hackathon is with mentors to talk and discuss, followed by a part of quiet working time without mentors.

1.1.4. Jury and decision criteria

An interdisciplinary jury shall decide for the winners of the hackathon. In our final hackathon, there was a jury of five: Software Developer, Graphic Designer, Software Developer and Project Manager, Professor of Faculty of Business Studies, Culture Expert/City Employee.

It is recommended to have transparent judgement criteria for the jury. The judgement shall be objective, as otherwise the best storytellers seem to win.

Make the criteria transparent for the participants, e.g. present already before registration and have them visualized throughout the hackathon (e.g. on a screen).
Make criteria understood by all jury members.
Develop criteria together with all organizers as they define the target of the hackathon.

Figure 1 Jury Evaluation Criteria – initial concept

For our final hackathon, the jury grading was adapted, with each jury member judging each team on a 5 point Likert scale on agreement of following sentences. This proved to be transparent and well-understood.

Motivation: The game motivates the target group to visit the museum.
Innovativeness: The concept of the game has surprised me. I consider it innovative.
Simplicity: The concept of the game could be implemented now with todays current technical tools, just using the visitor‘s smartphone.
Completeness: The concept of the game demonstrates the full gamification mechanisms.
Additional: Fan factor: (Only 1 team by each jury member): The game motivates to be played several times and has fan potential.

The jury received a briefing document and held a 30-Min. briefing meeting prior to the final presentations.

TEAMNAME
Museum
Topic
Points		5	4	3	2	1
Scale		I strongly agree	I tend to agree	neither agree nor disagree	I tend to disagree	I strongly disagree	Total
Motivation to come to museum	The game motivates the target group to visit the museum.						0
Innovativeness/Out of the box	The concept of the game has surprised me. I consider it innovative.						0
Simplicity of implementation	The concept of the game could be implemented now with todays current technical tools, just using the visitor‘s smartphone.						0
Completeness	The concept of the game demonstrates the full gamification mechanisms.						0
Additional if same points result: Fan factor: (1 point by each jury member)	The game motivates to be played several times and has fan potential.
						TOTAL	0

Figure 6 Jury Evaluation Criteria – final concept

For the special situation of two institutions running the hackathon together:

It is recommended to have a joint jury. In Gdynia, it was divided into two parts for Experyment and NMFRI Aquarium which is not recommendable.
Consider the case, that the jury cannot come to a joint decision. An extra award could be a solution. The criteria in case of the extra award should be transparent and the same across institutions.

1.2. Awards

Looking at why people come to the hackathon (chapter 3.1.2), prizes are not mentioned with top priority. However, this may be specific to these hackathons, as they were done by public museum institutions. Supporting these might have a volunteering and social aspect.

For Gdynia sponsoring was limited and due to the project funding there were constraints for the prizes. Due to these constraints, prizes were not part of the promotion activity. It is considered that more attractive prizes would have been an additional asset.

In Klaipeda, the jury granted an award exclusively for one victorious competition entry: a SPECIAL AWARD which included a package of invitations for 2 persons to the best touristic destinations in Western Lithuania and a 100 Euros monetary prize. Winners of the audience award were presented with iPAD smart keypads.

In Greifswald, a 3D printer for each team member, although a simple model, was perceived as a major motivation, yet no reason to come. However, it grasped attention of potential participants in promotion.

In general:

Technology prizes are good if they are connected to the topic of hackathon and have an innovative character.
On some hackathons cash prizes are issued from a wide range of amounts – depends on budget and sponsors and the overall scale of the event.
For individual prizes: the maximum amount of participants in each team should be limited to acquire prizes accordingly.

1.3. Materials for participants

Content material was provided to the teams before the hackathon in Gdynia and just at the start of the hackathon in Greifswald:

Pictures, Logo
Videos
Audio
Texts

In Malmö, a brief selection of pictures was available online, along with the contact to the mentors who could provide texts and other input.

For the situation of several museums participating with different topics, we recommend to publish the available topics beforehand, however, have a draw only at the beginning of the event. This increases positive excitement, while allowing to getting familiar with the topics, though not working with them yet. Materials are then only provided to the team has won the lot for the specific topic.

1.4. Design of schedule

The hackathon events in Gdynia and Klaipeda lasted roughly 24 hours. Various participants said the hackathon was too short, compared to other hackathons, however, longer events would increase the infrastructure requirements (e.g. showers). The hackathon Greifswald lasted 30 hours, with some participants wishing it would have event started Friday evening with a welcome event, instead of Saturday.

Recommendations:

At least 30 hours of hackathon are recommended for the working atmosphere to develop and to allow for creative ideas and networking to evolve.
Plan elements for networking and getting to know each other across the teams, e.g. a party an evening before, workshops like yoga/drumming, introductory games
A moderator should guide throughout all plenary sessions. A separate time keeper is recommended.
Evaluate how much time to give for the final presentations: if short, there is limited time to fully understand the participants’ ideas and the focus seems to shift towards judging presentation skills. If presentation skills are judged (not recommended), teams seem to spend considerable time for preparing their final presentation, which is not dedicated to content anymore. We recommend 8 min. presentation and 4 min. Q&A of the jury/audience. Someone should take care of timing and moderate the discussion.
Teams should have their presentations randomly, for the first team it is most difficult for the final presentation.
Plan enough time during the final presentation for technical issues, changing laptops, microphones etc.
Allow enough time for the jury discussion.
Consider an energizer at night or after dinner: like an activity like stretching/Zumba/game/music
Offer workshops to enhance learning experience beyond hackathon event e.g. creativity

In Gdynia, a warm-up event was hosted on an evening one week before the actual hackathon, in both institutions. In Klaipeda, an introduction to the museum was given at the beginning of the hackathon. In Malmö, the hackathon was split in a warm-up, coding time at home and a six-hour final day. In Greifswald, no warm-up was held. Instead museums held a short presentation at the beginning of the event. A warm-up proved to be good to get to know participants, create an atmosphere and give an impression of the exhibition. However, it is more suited for hackathons with only one host and it could be problematic for teams coming from other areas.

Figure 3 Schedule Gdynia

DAY 1. 18.05.2019

09:00 Warm-Up (Registration)

09:30 Opening Ceremony (Getting to know the BalticMuseums project, museums, participants)

11:15 Start in the Teams

13:00-14:30 Lunch

18:00-18:45 Different Workshops

18:30-20:00Uhr Dinner

23:00-24:00 Chill Out & Networking DJ @ Lounge

00:00 Pizza & Networking

DAY 2. 19.05.2019

08:00-09:30 Breakfast

11:30-13:30 Final Presentation (max. 10 min. per Team)

13:30-14:15 Lunch

13:30-14:00 Lunch Jury (parallel Jury-Discussion)

14:15 Final Ceremony incl. Prize-Giving

15:00 End of event

Figure 4 Schedule Greifswald

The weekend is a good time for the hackathon, although it might limit participation of professionals who might participate during work hours. Choose the date of your event carefully. Avoid the summer, holidays, examination period for students, and other major events in your region, especially other hackathons. The date also depends on the target group you would like to address. For museums, off season is recommended.

DOWNLOAD FULL TEXT

BalticMuseus Hackathon Guide_20190805_FINAL

Bibliography

Jarvis, D. (2012) ‘MGT567 Creative Problem Solving’ [online], available: https://www.slideshare.net/dajarvis/mgt567-creative-problem-solving [accessed on 16 July 2018].

Leclair, P. (2015). Hackathons: A Jump Start for Innovation. Public Manager, 44 (1), 12–14.

Mergel, I. (2015). Opening Government: Designing Open Innovation Processes to Collaborate with External Problem Solvers. Social Science Computer Review, 33(5), 599–612.

Oxford University Press (2018). Hackathon. Retrieved from: https://en.oxforddictionaries.com/definition/hackathon (01.08.2018)

Piller, F., West, J. (2014). Firms, Users, and Innovation: An Interactive Model of Coupled Open Innovation. In: Chesbrough, H., Vanhaverbeke, W., and West, J. (eds.) New Frontiers in Open Innovation, Oxford University Press, Oxford, pp. 29–49.

Tauberer, J. (2018) ‘How to run a successful hackathon’ [online], available: https://hackathon.guide/ [accessed on 12 June 2018].