Vasa

A Project Management Nightmare: 

A Project Management Nightmare The Swedish Warship Vasa

The Swedish Warship Vasa(from “Why Did the Vasa Sink” on the Museum Web Site): 

The Swedish Warship Vasa (from “Why Did the Vasa Sink” on the Museum Web Site) The warship Vasa, pride of the Swedish Navy and built at the cost of 4% of the Swedish GNP that year, was launched in Stockholm harbor in August 1628. Twenty minutes after launch, a small gust of wind capsized her, and she sank to the bottom of the harbor, where she remained for 333 years.

The Vasa: 

The Vasa

Why Did the Vasa Sink?: 

Why Did the Vasa Sink? In the 17th century there were no scientific methods of calculating a ship's stability. It was not uncommon that warships heeled over and sank. Their cargo - the guns - were placed relatively high up in the ship, whereas merchant-vessels stored their cargo in the hold, ie in the bottom of the ship.

Why Did the Vasa Sink?: 

Why Did the Vasa Sink? Instead of using calculations, the 17th century shipbuilders used so called reckonings, which recorded certain ship-measurements. However, the reckonings used in building the Vasa were intended for smaller ships with only one gundeck.

Why Did the Vasa Sink?: 

Why Did the Vasa Sink? The Vasa was built differently. She had two gundecks with heavy artillery (when the norm was to place lighter guns on the upper gundeck). The standard rules obviously did not apply here.

Why Did the Vasa Sink?: 

Why Did the Vasa Sink? Deep down in the Vasa several tons of stone were stored as ballast. They were meant to give the ship stability. However, the main reason for the Vasa capsizing was that the ballast was not enough as counterweight to the guns, the upper hull, masts and sails of the ship.

The Stability Test: 

The Stability Test In the inquiries after the Vasa disaster it was revealed that a stability test had been performed prior to the maiden voyage. Thirty men had run back and forth across the Vasa's deck when she was moored at the quay. The men had to stop after three runs, well before the test could be completed - otherwise, the ship would have capsized.

After the test failed: 

After the test failed Present was Admiral Klas Fleming, one of the most influential men in the Navy. His only comment to the failed stability test was "If only His Majesty were at home!" After that he let the Vasa make her maiden voyage.

Who was to blame?: 

Who was to blame? Admiral Fleming. Partly. He could have stopped the ship after the stability test. On the other hand, the ship was already complete and the king was waiting impatiently in Polish Prussia.

Who was to blame?: 

Who was to blame? King Gustavus Adolphus. Partly. He was anxious to acquire a ship with as many heavy guns as possible. He had also approved the Vasa's dimensions and was keen to have her completed rapidly.

Who was to blame?: 

Who was to blame? The shipbuilder Henrik Hybertsson. Partly. Although he built the hull too narrow, he was a skilled shipbuilder who had previously built many good ships. His unexpected death the previous year just complicated matters.

Who was to blame?: 

Who was to blame? The captain Söfring Hansson. According to a new theory the capsizing of the Vasa may be blamed on the captain. He sailed a brand new ship with open gunports. The Vasa sank when water gushed in through the lower gunports! It would have been wiser to test the new ship on her maiden voyage with closed gunports.

Who was to blame?: 

Who was to blame? However, the inquiries showed that no one could really be blamed for the disaster. The main reason being the insufficient theoretical know-how of the period. The Vasa was something new - a military experiment.

After the Vasa: 

After the Vasa After the Vasa, many successful ships were built with two, three and even four gun decks. The shipbuilders learned from their mistakes with the Vasa and improved later designs.

The Vasa Museum: 

The Vasa Museum The Vasa Museum, P.O. Box 27131 S-102 52 Stockholm, Sweden Tel +46 8 519 548 00

What can we learn from the Vasa?: 

What can we learn from the Vasa? Don’t let a customer without technical qualifications set the technical requirements. The Vasa was built according to royal decrees. Apparently, no-one was willing to disagree with the king when he suggested a change.

What can we learn from the Vasa?: 

What can we learn from the Vasa? Control Requirements Creep. Although designed for one deck of guns, King Gustavus Adolphus heard that Denmark was building a ship with two gun decks. He told the builder to add a second gun deck.

What can we learn from the Vasa?: 

What can we learn from the Vasa? If you don’t have a tested design, build a prototype. The Vasa had no plans. They designed it as they went along. They didn’t know whether it would float until they finished building it. A scale mode would probably have shown the flaw in the design at a much lower cost.

What can we learn from the Vasa?: 

What can we learn from the Vasa? When a test fails, fix the problem before releasing the product. Thirty men had run back and forth across the Vasa's deck when she was moored at the quay. The men had to stop after three runs, well before the test could be completed - otherwise, the ship would have capsized.

What can we learn from the Vasa?: 

What can we learn from the Vasa? Take responsibility. Stick your neck out. No one was willing to cancel the launch because the King was in Prussia waiting for the ship. He had not delegated enough authority to the people left behind to avoid a disaster.

What can we learn from the Vasa?: 

What can we learn from the Vasa? Beware unrealistic schedules. The Vasa was built in two years under extreme pressure. It is not known how many shortcuts were taken as a result. “There is never enough time to do it right, but there is always time to do it over.”

What can we learn from the Vasa?: 

What can we learn from the Vasa? Don’t allow Requirements Gold Plating The Vasa had extensive ornamentation and delicate carvings. Clearly a lot of the budget was spent on decoration.

Software Projects: 

Software Projects Following are thirty-five classic mistakes in software development. As you read the list, consider how many mistakes had a parallel in building the Vasa. Why are we still making the same mistakes that were made 350 years ago?

Thirty Five Classic Mistakes in Software Development: 

Thirty Five Classic Mistakes in Software Development From Chapter 3 of Rapid Development: Taming Wild Software Schedules, by Steven McConnell

The Book: 

The Book

People-Related Mistakes: 

People-Related Mistakes Undermined Motivation Weak Personnel Uncontrolled Problem Employees Heroics Adding People to a Late Project Noisy, Crowded Offices Friction between Developers and Customers Unrealistic Expectations Lack of Effective Project Sponsorship

People-Related Mistakes (2): 

People-Related Mistakes (2) Lack of Stakeholder buy-in Lack of User Input Politics placed over Substance Wishful Thinking

Process-Related Mistakes: 

Process-Related Mistakes Overly Optimistic Schedules Insufficient Risk Management Contractor Failure Insufficient Planning Abandonment of Planning under Pressure Wasted Time during the Fuzzy Front End Shortchanged Upstream Activities Inadequate Design

Process-Related Mistakes (2): 

Process-Related Mistakes (2) Shortchanged Quality Assurance Insufficient Management Controls Premature or overly Frequent Convergence Omitting Necessary Tasks from Estimates Planning to Catch Up Later Code-like-Hell Programming

Product-Related Mistakes: 

Product-Related Mistakes Requirements Gold Plating Feature Creep Developer Gold Plating Insufficient Planning Push-me, Pull-me Negotiation Research Oriented Development

Technology-Related Mistakes: 

Technology-Related Mistakes Silver Bullet Syndrome Overestimated Savings from New Tools or Methods Switching Tools in the Middle of a Project Lack of Automated Source Code Control

Bibliography: 

Bibliography The Vasa Museum Web Site http://www.vasamuseet.se/ What Can We Learn From the Vasa? Joe Marasco, VP of Rational Software, quoted in Robillard and Kruchten, Software Engineering Process, (Addison Wesley, 2002) pages 151-152 Rapid Development: Taming Wild Software Schedules, by Steven McConnell (Microsoft Press)