The sinking of the Vasa in 1628, a lesson in project management
The Vasa was a Swedish warship built between 1625 and 1628. After multiple defeats in the early 1620s, it was supposed to embody the renewal of the Swedish navy and to show the strength of the country. It did not have the opportunity to shine much though: it drowned less than 5 minutes after its first launch. During the maiden voyage, there was little wind, but it was enough to knock it over. Water poured in, and it sank 32m deep, 120m away from the shore. It stayed in Stockholm’s harbor for 333 years. The wreck was found in good shape in the early 1950s since it merely, calmly, sank without prior damage.
The Vasa, Klaus Stiefel
So what went wrong? There were a few problems.
- The first one was its client, King Gustav II of Sweden. He gave specifications (dimensions, number of cannons, etc.), while he was no expert. It was the job of the entrepreneur to make a realistic boat, not to accept anything the client asked.
- he compressed the deadlines, pressured the constructor into delivering faster, and went to the building site only once.
- he was the king, which made him hard to contradict.
The king was not the only problem though.
- many of the specifications were not writen.
- Critical specs changed over time. The king ordered 72 cannons for the ship, but this was too many to fit on a single gun deck. Since the order was issued less than five months after construction started, it was still time to add a second gundeck.
- the ship was not well balanced because the builders lacked experience building such big ships: until then, Swedish warships only had one gundeck.
- one of the builders died before the end (see the problem with non-written specs here?).
- warnings were ignored. There was a rehearsal a bit before the launch, intending to show the stability of the boat. But soon, the ship started to capsize, because there was too much weigh in the high decks. The vice admiral stopped the exercise and… did nothing more to cancel or delay the launch, since he did not want to contradict the king. Later, during the maiden voyage, the captain (who was attending the rehearsal as well) did not use that information either, since he shot the cannons on one side, which started to make the boat pitch.
That’s pretty much project management 101, but this story is a good reminder of some best practices you may want to enforce on your projects. It’s easy to see what others don’t do right, but maybe there are areas of improvement for you as well ?
- Write accurate specifications beforehand, or at least make sure people agree on what to build
- Don’t change specifications halfway. In the agile software development world, changes are OK, but not in the middle of a sprint
- Listen to people. Managers are often clueless :p while people who do things have a lot to say about what can be improved
- Talk about problems. Do it early
- When things are not OK, do what you can at your level to correct things
- Test a lot
More about this on Wikipedia.