The Vasa Effect

A few days ago, I “rediscovered” a brochure from a museum in Stockholm. It reminded me of an early 17th century warship: The Vasa. She was the most powerful warship of her time — albeit for less than half an hour, as she sank during her maiden voyage. The reasons for this disaster include top management interference, overly sophisticated requirements, weak communication, and overengineering. Why is this relevant today? Because projects have not changed that much: The Vasa story reminds me of a number of interactions I had with Forrester clients about banking platform transformation projects that ran well — or not so well.

A large share of the less-successful projects showed a number of the ingredients of the Vasa story, causing what I like to call the Vasa effect: predictable failure. Examples include:

  • Off-the-shelf projects that had to manage a burden of business requirements that were so sophisticated that no off-the-shelf system could ever hope to cope with all of them in a cost-effective way. In parallel with the Vasa story, in these cases nobody dared discuss whether the last 15% or even 5% of the requirements were really important enough to justify the additional cost — or whether delivering 85% of the requirements would be good enough.
  • So-called off-the-shelf solutions that were more custom-built than a real custom-built solution. They had to align with a bank’s off-the-shelf strategy while living up to concretely defined, highly sophisticated, and very individual business requirements, including solitaire business process definitions.
  • A few banking platform projects that had to deliver on time in spite of all functional, architectural, and technology challenges. Failure to do so was not an option: “On-time” was part of the defined success metrics — and project success was a predetermined top management decision.

I also saw well-prepared banking transformation projects based on strategic business and IT plans and sensible, albeit not too detailed, medium-term planning that show many ingredients that enable rich business value for their respective banks. However, these projects are not yet the majority. Are these successful projects an indicator that the Vasa effect will soon be a thing of the past for banking transformation projects — or just some glimmer of hope? As always, please let me know what you think: JHoppermann@Forrester.com.

The Vasa Story In A Nutshell

During the Thirty Years’ War, a Swedish shipyard won contracts to build a number of smaller and larger warships, one of them being the Vasa. During the construction, Gustav II Adolf, King of Sweden, sent very specific orders regarding core design parameters that included, for example, an exact length — which put it in between the planned length of the two classes of ships — as well as heavy armament that made two gun decks mandatory: Vasa’s broadside is said to be the heaviest of her time. In addition to this top-management interference, the project manager changed, as the initial shipwright died before Vasa’s construction was complete. It certainly does not come as a surprise that the king, spurred by the fate of war, demanded the fastest possible delivery of the Vasa.

The outcome? Trials had shown already that Vasa was top-heavy and highly unstable: It had nearly capsized at the quay. But project staff (shipbuilders and shipwright) and procurement personnel (officers of the Swedish navy) did not dare tell the king about Vasa’s challenges or at least postpone the maiden voyage. Thus, Vasa left the harbor, capsized, and sank within less than a mile or 1.5 kilometers from the harbor. Afterwards, looking for the guilty got the highest priority.

If you are interested in more details, have a look at the Vasa museum Web site or visit the museum itself when you are in Stockholm (I highly recommend it).

Comments

Thank you for an Eye-Opener!

Yes, the off-the-shelf, out-of-the-box, best-of-breed nonsense linked with ridiculously overloaded RFP checklists, the follow-on competitive price pressure by purchasing, moving targets, while retaining the go-live date is a recipe for IT disaster!

But it is not just a banking project problem. It seems that IT has lost its ability for common sense ... how can we change it? I think that part of it has to be how analyst rate products as well, don't you agree?

The Vasa effect differentiated

Yes, indeed, “off-the-shelf, out-of-the-box, best-of-breed” has often caused nonsense approaches if this comes linked with ridiculously overloaded RFP checklists. I guess this is the core of the Vasa effect – or how to avoid it: Enterprises (inside and outside of financial services) need to determine whether they want to get a reasonable set or all of their business requirements implemented. “All” could be a good first indicator that (using today’s technologies) “off-the-shelf, out-of-the-box, best-of-breed” may be one solution, but custom-built could be another. “Reasonable” would indicate that off-the-shelf could be a better way to go. However, strong implemented governance processes will be necessary to avoid the Vasa effect.

You also said that a part of the reasons creating the Vasa effect is how analyst rate products. If an analyst drives hype, then this is likely correct (however, there is a variety of further factors). In parallel, the Vasa effect is often so deeply embedded into organizations that an analyst’s rating (or advice) cannot drive change. For example, I recently said to a financial services firm that their business requirements would likely cause about 40 percent customization of the preferred “off-the-shelf” solution. The firm did neither reduce its business requirements nor did they go for another off-the-shelf solution. The good news is that target state architectures such as Forrester’s banking platform of the future (http://www.forrester.com/rb/Research/banking_platform_of_future/q/id/541...) will soften the Vasa effect to some degree, but they are still a couple of years out in the future.

If you are interested, please participate in the discussion thread about the Vasa effect in the Application Development and Delivery Community.