I personally haven’t met a lot of people that are familiar of the Vasa Syndrome, but have experienced it in real life. Simply put, the Vasa Syndrome refers to the problems in communication and management affecting projects, that lead to the development of an erroneous end product. Sound familiar?
The reference dates back to a beautiful ship that was designed by Henrik Hybertsson back in the 1620’s, the Vasa, commissioned by the King of Sweden, Gustavus Adolphus in 1625. In Gustavus’s vision, the Vasa was supposed to be the symbol of power for the Swedish Navy, but it met a sorrower fate than intended. Though we’re getting ahead of ourselves; let’s look at the Vasa’s Journey a little closely (Fig. A: Full version available at the bottom of the article)
The Vasa was commissioned in January, 1625, along with 3 other ships that were to be deployed within 4 years in the “30 years war” to exhibit the true power of the Swedish military.
Briefly put, after starting the project, Gustavus ordered the ships be expedited as the Navy lost 11 ships during patrol. The deadline got even smaller, and the developers received another unexpected change: building two gun decks on the ship as the rival king of Denmark was developing the same.
There were several more changes along the line, however we will focus on two for two important insights to the Vasa’s development team:
a. They did not have the knowledge on how to build a 2 gun deck ship
b. They did not have experience building a ship this large
Henrik Hybertsson, the ship architect, simply scaled up the model to fit the king’s requirements, ignoring several problems that may create. Soon after his demise, his building crew was left with little to no instruction on how to continue, rather even communicate amongst themselves.
They conducted a topple test for the Vasa, and even though it failed, the project Manager, Admiral Fleming sanctioned the deployment anyway. On 10th August, 1628, the Vasa set out on its Maiden voyage, all the gun portals were open in all its glory. Twenty minutes into its journey from the deck a light gust hit the vasa, and the ship toppled over almost immediately because of its low center of gravity, and sank in the shallow waters of the Baltic Sea, claiming 50 lives with it.
The tragic tale of this magnificent ship brings us several learnings in the development and implementation of a new product. If you are a victim of the Vasa syndrome, then some of the reasons may sound quite familiar to you as well:
Defining Deadlines
Sometimes, product development can feel like going at war with the market, there is always a competitor available to rival your product. I know it is odd to assume that the King of Sweden would confer with his building team to set the goal for the ships as they were at war, though it is the learning from this scenario that I implore you to adapt: A good manager should know how to define deadlines according to the capability of his team.
Knowledge Expansion and Resource Management
One key event from the Vasa incident was that Henrik and his team tried to upscale their existing design to one that had a more complex structure, which ultimately led to the Vasa capsizing. If you put this in a regular product development scenario, you can estimate the problem areas that may create; when you increase the scope of the project, the scope of human error and failure also increases as there are now more touchpoints you need to be aware of. Hence, before you start a project, it is important to be aware of the scope, what changes the scope brings, the resources required (internal and external) to achieve the goal and the capabilities of your team, whether they are equipped to take on the project or may require scaffolding.
Defining Goals and Market
Catching up with the market is rough, no matter what stage of product development you are in. Companies gun to rush for fresher developments in their product to compete with their rivals. Same with the case of the Vasa: The King of Sweden ordered a ship to be built with 2 gun decks to rival the Danish, even though the Swedish team did not have the resources to build this kind of a product, their leader wanted a newer model built with new features. Eric H. Kessler(3) writes , “Do not tinker with product design to appease all internal groups.” In this particular case, it is the manager’s job to understand if the changes, as well as the amount of the same are not feasible, and communicate the same.
Planning and Communication
Planning and Communication are two of the strongest pillars of product development. If the priority or the current goal changes, companies usually implement a contingency plan they can fallback on; communication scaffolds it, reducing risk of failure as well as environment risk. The Vasa went through changes in priority, goal, implementation and the actual product itself, without communication and pre-set contingency plans. This increased both hazard and environment risks of the final product, which when released, led to its untimely failure, 20 minutes into its maiden voyage. It is also important that in all stages of the product development, stakeholders be aware of the changes being made, so the project has good organizational memory for it to be passed on to future stakeholders/team members if need be.
Testing and Feedback
Feedback, feedback, feedback; the backbone of any human centric design project. Both wishful and critical feedback are imperative in creating a better product for your end user; wishful provides the necessary motivation for newer developments and critical provides an insight to the flaws in the current version. Testing during the product development process means that you gain insights to the user needs early on, and can make changes as required without incurring large cost of development. As a product team lead, the feedback from tests or otherwise should be shared with the stakeholders, so they have an insight to the development process as well as can assess necessary changes or costs that can be adjusted in the next version. In the case of the Vasa however, this process was overlooked, as the “product manager”, Admiral Fleming was reluctant to relay test failure information to the king, even though there were glaring and obvious errors in their current version, leading to fatalities on launch.
Organizational Memory
Imagine you are a Product Lead, hiring someone for a User Interface design position in the company. In your case, you will have a set of brand design guidelines that you would like the User Interface designers to follow, so the brand identity is prevalent and is cohesive with everything you create. Simply put, this is organizational memory. Files, documentation, assets and everything created thus far for onboarding new talent or inviting new stakeholders is the organizational memory you pass on to create a better understanding of changes in the working environment. When Henrik Hybertsson died in 1627, he had not documented or communicated his plans for the Vasa to his team members, thus creating a mass of confusion in the development process.
Top Management and Yes-Men
Vasa had issues that were no more than management problems. The delivery time, overbearing requirements, lack of knowledge, poor organizational memory and communication etc. could all be solved under a better management. Once in my personal experience, I was required to change the typography across all product development and marketing systems. As the creator of the typographic systems of the company, I inquired the motivation behind this change from the top management, and managed to convince them that the current typeface being used was curated for the company’s ideology and the change would imply a large cost on man-hours, research and branding. A good manager knows that all changes from the top management should be respected, but the implementation of the same is upon their jurisdiction as they are the ones in touch with the end user.
In my article, Startups, Startups Everywhere, I list down 8 key points, that a project manager or a designer can use to better understand their project and its stakeholders better, so that you may be able to avoid the Vasa Syndrome in your future.
Below is the link of the comprehensive development journey of the Vasa, free and print-ready!
Sources:
3. Vasa Syndrome: Insights from a 17th Century new-product disaster by Eric H. Kessler, Paul E. Bierly, III and Shanthi Gopalakrishnan
コメント