• Home   /  
  • Archive by category "1"

Vasa Capsizes Case Study

What on Earth does a 17th-century Swedish warship have to do with agile software project management?

For those of you who aren’t familiar with this classic case study of project management gone wrong, repeated in business schools around the world, here’s some background about the Vasa.

Click Here To Download Your Practical Requirements Strategy Now (it’s free)

The Vasa Incident

The Vasa was a huge project commissioned by King Gustavus Adolphus of Sweden (1611-1632) between 1626 and 1628 as a way to bolster the might of the Royal Swedish Navy, back when the Swedish Empire was a leading military power in Europe and engaged in frequent battles against its neighbouring countries.

The King poured enormous amounts of money and man-hours into constructing one of the largest, most expensive military project ever undertaken till that point in time in history.

The Vasa would be 135 feet in length and carry 64 guns arranged over two gun-decks.

Or so were the requirements that the royal Product Owner specified at the end of an ever-changing list of decrees. In fact, the expected outcomes for the Vasa project kept changing constantly and this was one of the factors that ultimately contributed to its untimely end.

When it was time to launch the Vasa on its maiden voyage on 10 August 1628, the ship sailed for no longer than a few minutes, less than a mile from the coast, when a sudden gust of wind caused the ship to capsize and sink, taking down with it 50 of the 100 sailors who were on board.

The Vasa was eventually salvaged and it is now housed in its own dedicated museum. The salinity of the waters it sank into kept it surprisingly well-preserved, and the battleship today attracts hundreds of thousands of visitors each year who go to admire its tragic splendour and remind themselves of the potentially catastrophic consequences of flawed project management.

The ship in the main hall of the Vasa Museum.

Fast-forward to today: Vasa and agile software projects

Building a ship is an ambitious endeavour today as it was centuries ago during the time the Vasa was being constructed. Therefore, there are many parallels that can be drawn between the Vasa project and the software product you and your Scrum team are developing right now.

In fact, the Vasa syndrome is a term used in management which is inspired by that disastrous event and describes a collection of risk factors, including problems with goal-setting, team communication and handling unexpected changes in plans, which could spell doom for any project.

To make sure you avoid repeating the errors that contributed to the Vasa fiasco, I compiled a list of the top six software project management problems that this historic incident highlights.

Click Here To Download Your Practical Requirements Strategy Now (it’s free)

6 problems in software projects that could be your ‘Vasa’

1. An impossible work schedule

Putting too much pressure on your Scrum team members is almost guaranteed to set your project up for disaster. Changing requirements and a lack of estimates based on data from previous projects are often the cause of an overburdened schedule that needs to be trimmed down pronto.

2. Requirements that change too rapidly

I mentioned it in the previous point and I’ll mention it again: making changes in mid-project is a sure recipe for something to go wrong. Things get even more complicated when it’s your people who seem to be going in and out through a revolving door, not just your requirements!

3. Lack of detailed planning

Software projects often grow from small activities that the team is familiar with and then gradually snowball into bigger and more complex affairs. In many cases keeping track of an expanding project requires you to use sophisticated tools to list your technical specifications, cross-reference documentation and draw up detailed project plans that can be instantly circulated among the stakeholders.

4. Going overboard with innovation

Pardon the nautical pun, but this is one of the problems that Scrum teams almost constantly run into: letting their ambition take over practical considerations. Software projects always include some degree of innovation, however adding new features just to satisfy some creative impulse without regard for user experience and the company’s bottom line is a temptation that must be resisted at all costs.

5. Pumping too many requirements in a project

‘Requirements creep’ is a common symptom of projects destined to failure. This can happen both when old requirements are not updated periodically or when new ones are just included without looking at the bigger picture. A complication of this is when a project becomes so big that it’s almost impossible to dig through the layers of unnecessary code to fix any bugs lurking deep inside without incurring tremendous costs.

6. Ignoring obvious problems

One of the most shocking revelations about the Vasa is that the ship had failed its ‘acceptance’ test, which consisted of a group of sailors running along the deck to see how the ship would hold up to stability. The Vasa lurched horribly, so much that the test was suspended after a few tries, but this finding was never reported, probably to avoid displeasing the King. It behooves software engineers to speak out whenever they notice any problems that could detract from the users’ experience.

The Wrap-up: Saving your software project from disaster

The Vasa was a complex project that involved plenty of risk and pushed to the limit of the skills and knowledge that the people who worked on it had.

Human fallibility is a risk factor that can never be completely eradicated from a project, however the struggles your Scrum team experiences when working on software products are the same that any group of people face when getting together to work on a common goal.

Learning from past experiences that parallel your own is a great method to control these problem areas more effectively and keep your project afloat.

Click Here To Download Your Practical Requirements Strategy Now (it’s free)

Vasa was the world’s most high-tech warship when it set sail. Today, it’s a resource for naval historians and archaeologists–and a cautionary tale for those who seek to design technology.

The story of what happened to the ship has gone down in history: despite being one of the Swedish navy’s biggest achievements and among “the most spectacular warships ever built,” according to Eric H. Kessler, Paul E. Bierly III and Shanthi Gopalakrishnan in The Academy of Management Executive, Vasa sank within twenty minutes of setting sail, on this day in 1628.

“The warship survived the first blast of wind it encountered on its maiden voyage in Stockholm Harbor,” writes Lucas Laursen for Archaeology. “But the second gust did it in. The sinking of Vasa took place nowhere near an enemy. In fact, it sank in full view of a horrified public, assembled to see off their navy’s–and Europe’s–most ambitious warship to date.” Engineering problems sank the ship–but this PR disaster for the Swedish navy has become a boon for archaeologists. Here’s how it happened and how Vasa's influence is felt today.

The sinking

Vasa was a vast, beautifully decorated ship. It was covered in wooden carvings that told stories about the Swedish royal family, and most importantly the king, Gustav II Adolf, writes Rhitu Chatterjee for Public Radio International. It was the king who ordered the ship, which carried an unprecedented 64 bronze cannons, to be built–and who watched in horror as it sunk.

“Soon after, there was an inquest that concluded that the ship had been unstable,” Chatterjee writes. “But the reasons behind the instability have remained a point of debate over the centuries.” 

An archaeologist who has studied the remains of the ship in great detail thinks it sank because the gun deck was far too heavy–the result of its having been designed and built by someone with no experience building such a well-armed ship, Chatterjee writes. It didn’t help that the king rushed the building process.

The rediscovery

Although Vasa didn’t work out well for Gustav II Adolf, it’s become a boon for archaeologists. “The cold, oxygen-poor water of the Baltic Sea protected Vasa from the bacteria and worms that usually digest wooden wrecks,” writes Laursen. “Perhaps 95 percent of Vasa’s wood was intact when Sweden finally raised the wreck in 1961.”

Although keeping the wooden structures stable while raising the ship proved to be a huge engineering feat, it was managed. Preserving the ship was a process that took almost three decades, Laursen writes. During that time, there wasn’t much room for archaeology, but now that the ship is stable, investigators have worked to uncover why it sank. Beyond the simple engineering problems, writes Laursen, the “human question of why it was not” seaworthy is worth discussing.

The human factor

The management world has a name for human problems of communication and management that cause projects to founder and fail–Vasa syndrome. The events of August 10, 1628 had such a big impact that the sinking is a case study business experts still read about.

“An organization’s goals must be appropriately matched to its capabilities,” write Kessler, Bierly and Gopalakrishnan. In the case of the Vasa, “there was an overemphasis on the ship’s elegance and firepower and reduced importance on its seaworthiness and stability,” they write, “which are more critical issues.” Although it was originally designed to carry 36 guns, it was sent to sea with twice that number. At the same time, the beautiful ornamentation contributed to its heaviness and instability, they write. These and a host of other factors contributed to Vasa’s sinking and provide a cautionary tale for those designing and testing new technologies.

The remains of the ship can be found in Stockholm’s Vasa Museum. According to the museum, it is the only preserved 17th-century ship in the world, and the museum is a place for historical and anthropological study as well as for visitors from around the globe.  

Like this article?
SIGN UP for our newsletter

About Kat Eschner

We Recommend

One thought on “Vasa Capsizes Case Study

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *