If you ever find yourself in Stockholm, go check out the Vasa Museum. Guidebooks, other tourists, and even locals will tell you this should be on your list. The museum is great, big, and airy with lots of great artifacts and stories. Right in the middle of it is a big old ship, the Vasa. With one look, you can tell why the warship sank. It was so top heavy and unstable that it sank on its maiden voyage, 390 ft off shore due to a gust of wind.
I love coming to see the Vasa. The first time I came, it was to enjoy the nice lunch at the museum restaurant and to check it off my list of things to do in Stockholm. I have since been there four times. It is beautiful to look at: the ornate designs symbolizing King Gustav’s riches, the huge sails, the bronze menacing cannons, but what I marvel in is the failure of it all. How did this happen? And I as I read the history behind it, I couldn’t help wonder how the Vasa parallels so much in our industry. Companies with huge budgets failing on their first launches or barely clinging on after non hits.
Vasas happen, but how can you prevent a ship from sinking? I’ve experienced a few Vasas in my career and each one had different reasons for the sink, but there are some commonality that crossed over. Let’s examine some points on why the actual Vasa sank and how that ties in with game development.
The King frequently changed his orders.
Whether it’s a publisher pressing a developer to add more features or your own team/boss constantly changing plans, this can not only kill motivation for a project, but also derail it completely. Who was there to keep the King in check? How do you keep the people funding your project grounded in reality when they want things added/changed all the time? I find this issue happening even in marketing projects and the best way to control the situation IS a reality check whether people like it or not. You need data to back up your arguments: show them how the change is going to affect the budget and the schedule.
The Vasa was rushed to completion under an excessive schedule and time constraints to launch for war with Poland- Lithuania.
I’ve seen this too many times and it’s painful. Either due to not having proper project management or unforeseen bumps, development lags and then is rushed to meet an unreasonable launch date. I often wonder what would have happened if development had an extra week or month. We all need proper deadlines or projects can go on forever, but rushing development doesn’t result in a good outcome for the end product or the team.
Excessive innovation with lack of experience. No one in Sweden, including the shipwright, had ever built a ship having two gun decks.
I worked on a project before where we were making a 3D game, but we only had two people that actually knew how to build a 3D game, everyone else on the team only had 2D experience (especially the leads). This resulted in a lot of chaos on how to make things or even how to build levels properly. I’ve also worked at a couple of places where the executives were really into the latest buzzword in tech and wanted to implement something with “cloud”, “blockchain” or “machine learning” into a project, but no one on the team had experience with any of these and couldn’t figure out a way to implement them organically into the tech. Again, sometimes you have to push back and ask why these features are relevant or important to the project. Did the Vasa really needed TWO gun decks?
Lack of proper project management. When the shipwright died, there was no documentation on the project plan and nothing prepared for the assistant to take over.
Some people I’ve worked with hate project management and prefer to do development organically. When you have a small team, this might work, but it’s always good to have plans and someone overseeing them. One thing I really love about working with Niklas and Tobias, they immediately started documentation of our technology, processes, and even vocabulary. We do this so that when we hire new people or introduce new tech to our community, people can immediately dive in and also be self reliant by referencing the materials themselves. And Buddha forbid if one of us isn’t around, we at least can pass down our knowledge to the next person taking over. But I’ve seen games under bad project management and it gets ugly in the end, lots of finger pointing, covering of asses, and no trouble-shooting to fix issues.
The Vasa underwent a stability test before launch that concluded it was not seaworthy.
This part of the whole Vasa saga really hits home. They tested this ship and it wasn’t SEAWORTHY! Then this fact wasn’t conveyed to the proper people, probably because they were scared of the consequences of telling the king his over-budgeted, bloated project was a no go. But instead of doing the right thing, 30 people died. Test your product! If you are developing a game do: peer testing, beta testing, and/or hire a freelancer to give you a mock review. Take the data from the tests and really evaluate what you have before launching.
Too many “captains” on the ship. (Although this wasn’t really an issue with the Vasa, but I wanted to make a nautical pun.)
This could also be filed under point 1 (if you have multiple “Kings”) and 4, but I wanted to talk about this separately. I’ve seen several companies/projects fail because there were too many people involved in making final decisions. Or too many people voiced loud opinions on disciplines they didn’t have experience in but bullied other teams into bad outcomes. How do you avoid this? It’s a red flag for me if upper management is top heavy and projects under their care haven’t launched or didn’t do well, steer clear! Or if you are starting to build your company, really discuss with your co-founders what’s the final decision making process, how do you streamline opinions and make the right choices? Also, listen to the people with experience in their disciplines, that’s why you hired them. You can learn a lot on how to move forward with what they did in their past.
If find yourself on a Vasa, do everything you can to bail it out, but just know, sometimes jumping off to save yourself might also be the right thing to do.